Prepare for a customer call

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 the customer call brief is built from

The run opens from the next customer meeting on Google Calendar, timed so the brief is waiting before anyone joins. It reads four systems, each for a question the others cannot answer:

• Past calls, from Granola, found by attendee email and separately by company domain, since a call is recorded by whoever hosted it. Only what carries forward is kept: anything they asked for and whether it was promised, anything either side committed to with a date, and any complaint with whether it was resolved. Requests are quoted in the customer's own words.
• The account record, from Attio: plan, renewal date, owner, open opportunities and support history. Anyone who appeared on past calls but is no longer on the record has probably left, and a departed champion is the most important line a brief can carry.
• Product usage, from PostHog: weekly active users over the last quarter and their direction of travel, which features the account uses and which it has stopped using, and whether it uses the thing it bought the product for or only the edges of it.
• Request status, from Linear: for each request found on the calls, whether it shipped, is in progress with a target, sits in the backlog, or was declined.

The brief is posted to Slack before the meeting.

What makes customer call prep hold up

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.

Usage is read as a direction across the quarter, since a flat number can hide a halving followed by a recovery. The same goes for features: one the account used weekly until two months ago and has not touched since is a specific question to ask on the call.

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. A request with no ticket is an item for the call, not an omission.

Biggest risk first

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.

So the brief opens on whichever of these is true and most serious: usage has fallen materially, a champion has left, a commitment was made and missed, or the renewal is inside ninety days. The detail follows: what they asked for and where it stands, what they use and what they stopped using, and the open commitments on both sides.