# Prepare an evidence-based at-risk customer review > Bring together recent usage, support context, and billing identifiers for one customer before a renewal or health review. Canonical: https://www.mcpfolio.com/workflows/prepare-at-risk-customer-review ## Target user A small SaaS customer-success team building account reviews from analytics and spreadsheets without a dedicated CS platform. ## Trigger A customer is approaching a renewal, has gone quiet, reports a problem, or is selected for a weekly health review. ## Why run it repeatedly A CSM might prepare this before renewal or a recurring account review; ask pilot users to log actual review frequency, time, and current tools. ## What you receive A source-linked account brief with recent usage evidence, unresolved support themes, current billing state, missing data, and questions for the CSM to validate. ## Pain evidence First-person CS reports describe a 1,500-row usage/revenue spreadsheet with manual review and missed data, and a separate team reports eight weekly hours copying customer-call notes into a spreadsheet. These are self-reports from small, potentially biased community samples; the latter thread includes product/tool promotion. They show a reported workaround, not prevalence or willingness to adopt this recipe. ## Alternatives and remaining gap Dedicated CS platforms and a warehouse-backed health model are built for this job and are usually better for recurring/bulk scoring. A simple SQL/BI report is more reliable for fixed metrics. MCP can help a CSM interpret unstructured conversation context alongside selected metrics for one reviewed account. ## Execution flow 1. Input one approved Intercom company/contact ID, review date, renewal date if known, and the team's definitions for usage decline and billing risk. 2. Fetch the Intercom company and recent relevant conversations. Extract only customer-stated blockers, dates, and next steps; separate quotes from interpretation. 3. Use the configured Amplitude group type and a stable company/account ID to query the same account's agreed usage measures for current and baseline windows. If group mapping is absent, stop rather than joining on company name. 4. Read Stripe subscription/invoice details only through an explicit stored Stripe customer ID. Do not search or join using a guessed email/name. Mark absent mapping as unavailable. 5. Compare the three evidence streams, preserve contradictory signals, and prepare a review brief. Do not score churn probability, contact the customer, or update a CRM record without an approved model and human review. ## Required tools - Intercom: search_conversations, get_conversation, search_contacts, get_contact, list_companies, get_company - Amplitude: query_amplitude_data, get_amplitude_charts, get_group_types - Stripe: stripe_api_search, stripe_api_details, stripe_api_read ## Prerequisites and costs Intercom workspace and read access; Amplitude project with a configured group type and account-level events; Stripe read access; stable shared account IDs across systems; a written usage-health definition. Plan, permissions, and Stripe authentication depend on connected accounts. For bulk account review, use a deterministic data pipeline or CS platform instead of a long interactive MCP session. ## Run this prompt ```text Prepare a read-only health brief for Intercom company [ID] as of [date], with review window [current window] and baseline [baseline]. Use only stable account identifiers already recorded in each system. Read relevant Intercom conversations, query the agreed Amplitude account metrics [metric definitions], and read Stripe subscription/invoice state only if an explicit Stripe customer ID mapping is present. Separate source facts, customer quotes, and interpretation. Show missing or conflicting identifiers as unknown. Do not invent renewal dates or churn scores, and do not contact the customer or change records. Return evidence links and 3 questions for the CSM to verify. ``` ## Review checkpoints The CSM confirms the account joins, metric definitions, dates, account context, and whether a billing state is relevant. Human approval is required before outreach, escalation, a health-score change, or CRM write. ## Limitations A single account brief is not churn prediction. Event instrumentation and account grouping may be incomplete; Stripe subscription state is not a full contract or renewal forecast. A CS platform or warehouse model may already combine these data more reliably. No background schedule is provided by MCP. ## Manual work and missing capabilities Account ID crosswalk, usage metric definition, baseline window, renewal/contract system if outside Stripe, and human decision on outreach remain outside the workflow. If integration joins are not stable, do not run it. ## Failure handling Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify. ## Pilot acceptance criteria A 20-account synthetic test exactly matches approved IDs with zero name/email fuzzy joins; usage window and metric definition are included; billing access is not treated as renewal data; each claim links to its source or is marked unavailable; no writes or outreach occur. ## Product fit MCPfolio recipe for one-account preparation. A production health-score product requires deterministic bulk joins, persistence, schedules, alert review, and tested CS-specific policy. ## Demo storyboard Use synthetic account IDs present in all three systems, with usage down, an unresolved support thread, and an active subscription. Include a second similar company name with a different ID and show that it is excluded from the join. ## Evidence Pain reported by users; official tool docs/catalog checked; workflow not runtime tested ## Required MCPs - [Intercom MCP](https://www.mcpfolio.com/servers/intercom): Retrieves recent customer conversations and company identity fields. - [Amplitude MCP](https://www.mcpfolio.com/servers/amplitude): Queries agreed account-level usage metrics over a specified time window. - [Stripe MCP](https://www.mcpfolio.com/servers/stripe): Reads current subscription and invoice state when the account has an approved Stripe ID mapping. ## Official sources - [CS lead reports manually reviewing 1,500 customer rows and missing data in a spreadsheet](https://www.reddit.com/r/CustomerSuccess/comments/1m5h02a/starting_customer_success_function_in_my_company/) - [CS team reports weekly call-note copying and missing revenue context](https://www.reddit.com/r/CustomerSuccess/comments/1s7vist/how_do_you_get_customer_feedback_to_product/) - [Intercom MCP documentation](https://developers.intercom.com/docs/guides/mcp) - [Amplitude MCP documentation](https://amplitude.com/docs/amplitude-ai/amplitude-mcp) - [Stripe MCP documentation](https://docs.stripe.com/mcp) ## Related - [All workflows](https://www.mcpfolio.com/workflows)