Catch churn signals and answer them

The prompt

The real prompt behind the steps above — detailed enough that an agent with a people-search tool, email/phone enrichment, and CRM access can run it as written.

# Catch churn signals and answer them

You have access to product analytics, a CRM, and email. Run this
weekly across **[active paying accounts]**.

## 0. Set up (skip if you're already connected)

If you don't already have live tool access for this, connect it
first. This prompt is only as real as the tools behind it:

1. Create a free account at app.tulina.ai.
2. Add Tulina's MCP server to your assistant: https://mcp.tulina.ai/mcp
3. In Tulina, connect your own API keys for the tools this
   prompt uses: your product analytics, your CRM, and your email.

Once connected, your assistant has real tool access and the rest of
this prompt runs as written.

## 0b. Already on Tulina? Three things around the run

An account and the MCP server are not the whole setup. Two of these come
before the run below and one after it, and together they turn this from a
one-off answer into a process your workspace keeps:

1. **Activate this process's connectors first.** Call
   `oto_connector(op="list")`, match it against the tools named in step 3
   above, and `oto_connector(op="select", name="...")` every one that
   isn't active yet. Selecting a connector does not mount its tools in the
   conversation you're already in — reach them through `oto_call` for this
   run, or open a fresh conversation once they're all on.
2. **Attach the work to an existing project.** `oto_project(op="list")`
   shows your active org's projects: pick the one this work belongs to
   rather than opening another, and keep its id. The project is where this
   process, the tables it writes to and the connectors it uses hang
   together.
3. **When the run is done, save it as a process — with its graph.** Write
   the body with `oto_procedure(op="set", ...)`, then attach it with
   `oto_project(op="link", project_id=..., target_type="procedure",
   target_ref="<your slug>")`. The body has to carry a drawing: read
   `oto_guide(op="read", slug="procedure-flowchart")` and follow it
   exactly — ONE untagged fenced block in that grammar, opening with the
   trigger and a quoted example of what you'd type to start a run. Tulina
   parses that drawing back into the graph it renders as the process's
   default view, which is what makes it come out in the same style as
   every other process in the app; a drawing the grammar can't read falls
   back to raw characters instead. Saving a process needs org-admin
   rights — without them, hand the finished body to someone who has them.

The hard part is not detecting a drop. It is distinguishing a drop
that means something from the ordinary noise of a business that takes
holidays.

## 1. Measure the decline properly

For each account, compare the last 30 days of activity against the
preceding 90, not against the previous 30. A month-on-month comparison
turns every August and every Christmas into a churn alert, and after
two of those nobody reads the list.

Measure three things separately, because they mean different things:

- Active users. A fall here is an adoption problem.
- Events per active user. A fall here means the people still using it
  are doing less with it, which is usually worse.
- Breadth of features used. Narrowing to a single feature is the
  clearest early signal there is.

Flag an account when any of the three has fallen by more than 30% and
the account has more than a trivial baseline. Under that baseline the
percentages are noise.

## 2. Rule out the boring explanations

Before treating a drop as a signal, check the explanations that are
not churn:

- Seasonality. Compare against the same period last year where you
  have it.
- A known outage or a release that changed how events are recorded. A
  renamed event looks exactly like abandonment.
- Seat changes. Fewer users because they removed seats is a
  contraction, which is a different conversation from disengagement.

Anything explained here is dropped and counted, not emailed.

## 3. Read the account's history

Pull the record: plan, renewal date, owner, support tickets, and the
last contact of any kind. Two things change what happens next.

If the renewal is inside ninety days, this is not an email. Flag it
for the account owner to call, and say why.

If they raised a support ticket that went unresolved shortly before
the decline started, that is very likely the cause. Say so plainly in
the handover; do not write a reactivation email that ignores the
complaint that caused the problem.

## 4. Write one email about what they stopped doing

One email, to the person who was most active before the decline rather
than to the billing contact.

It has to name the specific behaviour. "We noticed you have not used
the weekly export since March" is a sentence only someone reading the
data could write. "We noticed you have been less active" is a sentence
anyone could write about anyone, and it reads as automated because it
is.

Then one question about what changed, with a low cost to answering. No
discount, no feature pitch, no calendar link. The email is a question,
not a save attempt.

Draft it. Nothing sends to a paying customer without a person reading
it first.

## Output

Report: accounts measured, accounts flagged, how many were explained
away and by what, how many were escalated to a call because of an
imminent renewal, how many had an unresolved ticket preceding the
decline, and drafts written.