/churn-scanner

name: "Churn Scanner"
description: >
  Cross-vendor client retention risk ranking from ticket volume, customer
  sentiment, SLA misses, overdue invoices, upcoming agreement renewals, and
  RMM availability proxies. Covers evidence-based scoring, source coverage,
  and incomplete-data reporting through Conduit.
when_to_use: >-
  When scanning an MSP client portfolio for churn risk or deciding which
  accounts need retention attention. Use when: churn scanner, at-risk clients,
  retention review, who might leave, customer health ranking, or churn signals.

Churn Scanner

Rank clients for human retention review using observed evidence. This is an explainable prioritization, not a calibrated probability of cancellation. A client roster is required; every signal family is optional.

Anti-triggers

• **Working a single contract, invoice, or ticket record:** use the connected

vendor skill, such as `autotask-contracts`, `autotask-tickets`, `qbo-invoices`, `xero-invoices`, or `halopsa-tickets`.

• **Contract entitlements versus invoices:** use `finance-pack-agreement-reconciliation`.
• **Per-client profitability or margin:** use `finance-pack-margin-analysis`.
• **Executing escalation for tickets already breaching SLA:** use

`ops-pack-sla-escalation-playbooks`.

Workflow

1. **Discover first.** Start every scan with `conduit__search_tools`. Search for company/client rosters, tickets, surveys, invoices, agreements, and devices. Read returned schemas and use the exact discovered names, often shaped like `<vendor-slug>__<tool_name>`. The table below lists canonical MCP names, not guaranteed gateway spellings. Never assume a vendor is connected or invent a tool. A connected vendor without an allowed tool for the needed data is an unavailable signal, with the missing capability described in prose. 2. **Establish the roster.** Use every discovered roster tool from the table, one per connected PSA (Autotask, HaloPSA, ConnectWise PSA, Syncro, or SuperOps). If none is available, stop: "No client roster tool is available through Conduit, so a client churn ranking cannot be produced." Do not substitute ticket or invoice customers for a complete roster. Page through each roster fully, retaining source, stable client IDs, and active/inactive status. Then reconcile them into one roster: merge a client that appears in more than one PSA only after confirming identity, and keep unconfirmed duplicates separate and listed as coverage gaps. If one roster read fails, continue with the others and report that PSA's clients as out of scope; if all fail, report the errors and stop. If the operator limits the scan to one PSA, state that scope in the summary. 3. **Set scope and join identities.** Default to active clients, the most recent complete 30 days versus the preceding 30 days, and renewals within 90 days. State dates, timezone, as-of time, and operator overrides. Match sources by explicit cross-system IDs first, then verified unique company identities. Ask about ambiguous matches; exclude unresolved joins from scoring, and list them as coverage gaps. Deduplicate invoices and tickets across sources. 4. **Read available evidence.** Use only the discovery result matching an allowed table entry. Paginate and apply the same client, date, and status scope across both comparison windows. Retain source, record identifiers, timestamps, counts, and denominators. Use detail tools only where needed. On permission errors or missing fields, mark the affected signal unavailable; on rate limits, follow the returned retry guidance with bounded retries. Unfinished pagination is incomplete coverage, never a zero result: if any required page for a family cannot be read, that family is unassessable for every client the missing pages could cover. Do not score partial counts. 5. **Score and report.** Apply the rules below per client. Preserve every roster client, including those with no usable signals. Recommend human review only; this scan does not contact clients or change operational records.

Only read-only list, get, search, or report tools are permitted. Never create, update, delete, send, void, resolve, run, install, reboot, or use raw-request, execute-tool, custom-mutation, or other passthrough tools, even if discovered.

Allowed evidence sources

| Family | Canonical MCP tools and interpretation | |---|---| | Required roster | `autotask_search_companies`; `halopsa_clients_list`, `halopsa_clients_get`, `halopsa_clients_search`; `cw_search_companies`, `cw_get_company`; `syncro_customers_list`; `superops_clients_list`, `superops_clients_get`, `superops_clients_search` | | Ticket volume and text | `autotask_search_tickets`, `autotask_get_ticket_details`, `autotask_search_ticket_history`, `autotask_list_ticket_priorities`, `autotask_list_ticket_statuses`; `halopsa_tickets_list`, `halopsa_tickets_get`; `cw_search_tickets`, `cw_get_ticket`; `syncro_tickets_list`; `superops_tickets_list`, `superops_tickets_get`; `ninjaone_tickets_list`, `ninjaone_tickets_get`; `atera_tickets_list`, `atera_tickets_get` | | Sentiment | Prefer a survey platform. CrewHu: `crewhu_surveys_list`, `crewhu_surveys_search`, `crewhu_surveys_detractors`, `crewhu_surveys_promoters`, `crewhu_surveys_get`. SmileBack: `smileback_reviews_list`, `smileback_reviews_list_recent`, `smileback_reviews_get`, `smileback_nps_responses_list`, `smileback_nps_responses_get`, `smileback_csat_companies_list`; it has no per-client endpoint, so group reviews and NPS responses by company. Preserve the returned survey scale and detractor classification. Fallback: `autotask_search_ticket_notes`, `autotask_get_ticket_note`, `cw_get_ticket_notes`, or subject/description fields from allowed ticket tools. Label fallback sentiment as inferred from ticket text, never as a CSAT score. | | SLA misses | Use the allowed ticket list/get tools and their SLA/due-date fields; there is