Skip to content
Tulina
Book a demo
← Processes

Prepare for a customer call

Before the call, the last conversations, the account's state, how the product is actually being used, and where their requested features stand, in one brief.

Run this in TulinaBook a demo

Customer call preparation is four systems and about twenty minutes, so in practice it is one system and about two. Someone opens the CRM, sees the plan and the renewal date, skims the last email thread, and goes into the call. What they do not have is whether the account has been using the product since the last conversation. That one fact decides how the call should go.

All four systems are already recording the answer. The calls are transcribed, the account is in the CRM, the usage is in analytics, and the feature requests are tickets with statuses. Nobody joins them because joining them means opening four tabs before every call, every week, forever.

What you get

One brief in the channel before every customer call, joining what they said last time with what they have actually been doing since and where their requests now stand.

The part worth getting right

The contradiction between what they said and what they did is the highest-value line in the brief, and no single system can produce it. "We are rolling this out to the wider team next month", said on a recorded call in April, sitting next to a user count that has not moved since, is a specific and answerable question. Either system alone shows nothing worth mentioning. The call sounds positive. A flat user count, with no promise attached to it, is a number.

Match feature requests on substance, not on wording, or the brief turns actively harmful. A customer says "we need to see who changed what" and the ticket is called "audit log". A literal match finds nothing, the brief reports no ticket, and the rep goes into the call apologising for something that shipped six weeks ago. Semantic matching, plus an explicit "no ticket found" for genuine misses, is the only version safe to trust.

Leading with the worst true thing rather than with a chronological summary is a formatting decision that determines whether the brief gets read. Someone opens it ninety seconds before a call. If a departed champion is in the fourth paragraph it may as well not be in the brief at all.

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.

# Prepare for a customer call

You have access to a call-recording tool, a CRM, product analytics, an
issue tracker, and a messaging tool. Run this for **[the account and
the meeting time]**.

## 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 call-recording tool, your CRM, your product analytics, your
   issue tracker, and your team's messaging tool.

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 failure this prevents is specific: walking into a renewal
conversation without knowing that usage halved in March.

## 1. Pull the last conversations

Find the recorded calls with this account, most recent first. Search
by attendee email and separately by company domain, since a call is
recorded by whoever hosted it.

Extract only what carries forward:

- Anything they asked for, and whether it was promised.
- Anything either side committed to, with a date.
- Any complaint, and whether it was resolved.

Quote the request in their words. It is what step 3 has to match
against the tracker, and a paraphrase into internal vocabulary is
exactly what makes that match fail.

## 2. Read the account's state

Pull the account record: plan, renewal date, owner, open opportunities,
and any support history. Note whether the renewal falls within ninety
days, because that changes what the brief should lead with.

Check the contacts. Anyone who appeared on past calls but is no longer
on the account record has probably left, and a departed champion is
the single most important line in this brief.

## 3. Read what they actually do in the product

This is the half a CRM cannot answer.

- Weekly active users over the last quarter, and the direction of
  travel. A flat number hides a halving followed by a recovery.
- Which features they use, and which they have stopped using. A
  feature they used weekly until two months ago and have not touched
  since is a specific, answerable question for the call.
- Depth: are they using the thing they bought it for, or only the
  edges of it?

Compare against what they said on the last call. "We are rolling it
out to the wider team next month" said in April, against a flat user
count in June, is the most useful contradiction the brief can carry.

## 4. Find where their requests stand

For each feature request from step 1, find the matching issue in the
tracker and report its real status: shipped, in progress with a
target, backlogged, or declined.

Match on the substance of the request, not on wording. A customer
asking for "a way to see who changed what" and an internal ticket
called "audit log" are the same thing, and reporting no match is
worse than useless because it means the call repeats a request
somebody already actioned.

Where a request has no matching ticket, say so. That is an item for
the call, not an omission.

## 5. Post the brief

Post to the channel before the meeting, led by whichever of these is
true and most serious:

- Usage has fallen materially.
- A champion has left.
- A commitment was made and missed.
- The renewal is inside ninety days.

Then the detail: what they asked for and where it stands, what they
use and what they stopped using, and open commitments on both sides.

## Output

Report: calls found, requests extracted and matched to tickets,
requests with no ticket, usage direction, features abandoned, contacts
who appear to have left, and open commitments.

Questions about this process

Because they answer different questions. The CRM says whether anyone has spoken to the account lately; analytics says whether the account is still getting value. Those two disagree often enough that reading only the first is how a renewal gets lost quietly.

The brief says so explicitly. That is an agenda item rather than an omission, and it is better surfaced before the call than discovered when the customer asks about it for the third time.

On substance rather than wording. A customer asking for "a way to see who changed what" and a ticket called "audit log" are the same request, and reporting no match there would cause the call to repeat something already delivered.

Whichever is true and most serious: usage falling materially, a champion having left, a missed commitment, or a renewal inside ninety days. The detail follows underneath, but the first line is the thing that changes how the call should go.

Related processes

  • Call feedback becomes tickets and docs

    Every call recorded during the day is distilled overnight, with bugs and feature requests routed to the right team as tickets and docs, plus a Friday digest.

  • Prepare for a demo from the last call

    The last calls, the deal's state, and fresh research become one prep brief, plus a deck built around that company's own use cases, posted before the meeting.

  • Revive deals that went cold

    Deals lost more than 90 days ago come back with fresh signals, contacts checked for job moves, and the features they asked for that have since shipped.

Experience Tulina for 14 days.

By continuing, you agree to our Terms of Use and Privacy policy.