Works with
Works in any MCP client.
Pathbound is one remote MCP server, so the recipe runs wherever your agent does. Pick the product your team already uses and follow its setup.
Don’t see yours? Any MCP client connects the same way.
For a founder or CS lead at a company under about a hundred people, the job is: know which accounts cooled off this month—before the renewal, not after—without a data team to keep the numbers joined.
It sounds like a small ask. Answering it means joining billing to support to product usage and keeping that join current: who logged in less, who stopped filing tickets, whose seat count quietly slipped. At a company with a data team, that’s a dashboard someone owns. At yours, it’s a Sunday night in three browser tabs and a spreadsheet, done rarely enough that the account that went dark in March gets noticed at the June renewal that doesn’t close.
The signal is a drop in activity, and it already lives in Pathbound—events from every source land on the profile as they happen. The agent reads the trend first, then reads only the accounts that moved.
aggregate_data Group events by account for this month and for the prior baseline, and the accounts that dropped surface on their own. This runs server-side across every account without pulling a single full profile, so scanning the whole book is fast and free—no activation until you dig in.
batch_get_details Up to 25 accounts per call: plan, seat count, lifecycle stage, the company behind the domain. Now the shortlist isn’t a column of IDs, it’s the paying accounts with a renewal in sight—which is the list worth acting on.
get_company_conversations A quiet account that has also gone silent in support reads differently from one still trading friendly replies. Rolling up every contact’s threads at the company tells real disengagement apart from a slow month.
create_company_note The verdict lands as a note on the account: what cooled, the likely reason, and the next move. Open the account on Monday and the review is already written; syncing notes into two-way CRMs is rolling out.
Run it every Monday morning, or on the first of the month before renewals.
First, connect Pathbound to your agent—about five minutes, in whichever client your team runs. Then paste this prompt. This is how you find at-risk accounts on a schedule: run it as a recurring Monday-morning task in ChatGPT or Claude, or as an n8n cron on the first of each month ahead of renewals.
Find the accounts that got quieter this month. Compare each account’s activity against its recent baseline and pull the ones that dropped the most. For each, get the company details—plan, seat count, lifecycle stage—and read the recent support and email tone to tell real disengagement from a slow week. Rank them by churn risk, weighted toward paying accounts near renewal, and leave a short note on each with what cooled and what I should do about it.
The Monday churn question turns into something you can just ask, instead of a data-team project you keep putting off. The account that goes quiet in March gets flagged in March, while there’s still time to send a real email or book a call, not discovered at the renewal that never closes. And because the ranking runs on aggregation that never pulls a full profile, scanning every account costs nothing until you choose to dig into the few that matter.
Pathbound is one remote MCP server, so the recipe runs wherever your agent does. Pick the product your team already uses and follow its setup.
Don’t see yours? Any MCP client connects the same way.
It can tell you which accounts got quieter, which is the earliest honest signal—a drop in logins, tickets, and email against that account’s own baseline. This recipe ranks accounts by that drop and reads the support tone to separate real disengagement from a slow month. Pathbound is the customer data MCP the agent reads; the judgment call stays yours.
Fewer tracked events than the account’s recent normal: product sessions from Events, support threads from Intercom or Zendesk, emails, meetings. The agent compares the current window to each account’s own baseline, so a naturally low-touch account isn’t flagged just for being low-touch.
No. Pathbound is the context layer your CSM—or your CSM’s agent—reads: one profile per account holding the activity, conversations, and CRM state that answer “which accounts got quieter.” The assembly is what gets automated; the judgment and the relationship stay with whoever owns the account. If you run a CSM agent in Claude, Cowork, or n8n, this recipe is what feeds it.
No, and that’s the point. The joins a data team would hand-build (billing to support to usage, kept current) are already done on the profile. aggregate_data answers the “which accounts moved” question server-side, so you’re not exporting CSVs to join them by hand. A warehouse is the right tool for deep historical analysis; this is the operational read you need on a Monday.
No. The ranking runs on aggregate_data, which doesn’t activate profiles—it’s free. You only spend an activation when you pull a full account with batch_get_details or get_company, which the recipe does just for the accounts that actually dropped.
A note on each at-risk account with create_company_note: what cooled, the likely reason, and a suggested next step. The note lives on the unified profile every connected agent reads; syncing notes into two-way CRMs like HubSpot is rolling out. Nothing else changes unless you ask the agent to update fields or send an email.
Monthly catches renewals; weekly catches faster-moving churn. The calls are stateless, so a scheduled task in ChatGPT or Claude, an n8n cron, or your own runner all work. Start monthly with a human reading the output, then tighten the loop once you trust the reads.
Sign up, connect one CRM or drop the events snippet, and point your MCP client at
mcp.pathbound.ai/mcp.