|
TUESDAY / DEEP DIVE
Your calls already know which deals are dying
Dave Killeen, a CPO at a $2.6B software company, stays across 45 enterprise deals without sitting in a single pipeline review. His system reads the transcript of every customer conversation, checks it against what the CRM claims, and tells him which deals moved. The write-up is here.
I care about this one personally. For years I was the pipeline review: the state of every deal lived in my head, refreshed whenever someone happened to tell me something, and the version in my head was always a little out of date. If you're like most of the room here, your setup looks like mine did. No sales ops person, no pipeline analyst. You, a calendar full of calls, and a list of open deals you carry around in your head.
Here's what that list gets wrong: deals don't die in meetings. They die between meetings, in the stretch where nobody booked the next step and nobody noticed. The buyer said "send it over and let's reconnect next week" on a Tuesday. The reconnect never got scheduled. By the time you feel the silence it's three weeks old, and the evidence was sitting in the transcript the whole time.
You can build the fix in an evening.
> THE ARCHITECTURE
How it actually works
Four parts: an evidence stream, a claim, a reader, and a digest. Each one carries a choice.
The evidence stream is a transcript of every revenue conversation. If you run Granola (the notetaker that transcribes your meetings) you already have this; any notetaker that can export text works. The requirement that matters: the transcripts have to land as files somewhere Claude Code can read them, a folder on your machine or a repo. A transcript trapped inside a notetaker's app is evidence you own but can't use.
The claim is your CRM, or at your scale, a deals file. One file listing every open deal: the company, the stage you believe it's in, the next step, and the date that step is due. If you have HubSpot or Salesforce, an export works. If you don't, don't go buy one. A deals file with nine honest rows beats an empty Salesforce, and this system only needs the rows.
The reader is Claude Code, and its whole job is the diff. The temptation is to ask for summaries: "summarize my calls this week." Summaries are re-reading your meetings with extra steps. The useful frame is different: the deals file is what you claim is true, the transcript is what actually happened, and the system reads one against the other. The claim says "proposal stage, close this month." The transcript says the buyer mentioned a budget review in September and nobody booked a next call. That gap is the signal.
What it looks for, strongest signal first:
- A committed next step with an owner and a date, or the absence of one
- A mismatch between the claimed stage and what was said on the call
- A silence gap: no conversation in two weeks on a deal marked active
- Your champion going quiet: the person who was on the first three calls is missing from the last two
What it should not score is enthusiasm. Buyers are enthusiastic on calls that go nowhere; it's the cheapest thing they can give you.
The digest is one channel, on a schedule, reporting movement and risk only. A Slack message or an email, weekly to start. Every deal gets one line: moved, stalled, or no signal. "No signal" is load-bearing. A deal the system has no transcript coverage on must say so, because a digest that silently skips deals reads as "everything's fine," and an incomplete picture that looks complete is the exact failure you're building your way out of.
The step-by-step build lives here: pipeline hygiene from transcripts. I run the sibling of this system on my own calendar: every call goes through Granola, and a copilot reads each transcript and pulls out the commitments before I'm back at my desk. The deal version is the same machine pointed at revenue.
> THE PRODUCTION PROMPT
Paste-ready
Here's the prompt to stand it up. The constraints are the load-bearing part.
You're building a weekly pipeline read. Draft-only, read-only.
Task: read every transcript in /transcripts from the last 14 days
and the deals list in /deals.md. Produce one digest.
Constraints:
- /deals.md is my claim. Transcripts are the evidence. Your job is
the diff between them, deal by deal.
- For every flag, quote the transcript line that justifies it.
Never infer beyond what was said. No quote, no flag.
- Rank signals: missing or slipped next step first, stage mismatch
second, silence gap third. Do not report tone or enthusiasm.
- One line per deal: MOVED / STALLED / NO SIGNAL, then the reason.
If a deal has no transcript coverage, say NO SIGNAL. Never skip
a deal silently.
- Read-only: never edit /deals.md, never draft outreach, never
email anyone. The digest is your only output.
Run it once now on the last two weeks so I can grade the output.
Do not schedule anything until I confirm the read is right.
You never schedule a system you haven't watched run once with your own eyes.
> TRADE-OFFS
What this sacrifices
This design trusts transcripts, and every leak flows from that.
The coverage gap is the dangerous one. The system only sees deals that happen on recorded calls. The deal moving over email and text is invisible to it, and a digest that looks complete but isn't is worse than no digest, because you'll stop carrying the list in your head before the system has earned that trust. Mark email-only deals as exactly that in the deals file so they surface as NO SIGNAL instead of vanishing.
Transcripts are testimony, not truth. People say yes on calls and disappear. That's why the prompt bans tone and requires a quoted line for every flag: a committed date is evidence, "this looks great" is not. If you let it score enthusiasm you've built a machine that returns your own optimism to you, formatted.
The first digest is loud, and the loudness is real. If your deals file has drifted from reality, the diff flags most of the list on day one. That's not the system failing; that's the backlog of things you were carrying wrong. Week one hurts, week three is quiet, and quiet is the point.
These transcripts are customer data. Recording calls has consent rules that vary by region, so use a notetaker that announces itself, and keep the processing inside accounts you control: your machine, your repo, your API key. Nothing about this design requires handing transcripts to a third party. The deeper treatment is here: using AI without leaking customer data.
And the hard line: read-only, draft-only. A system that watches your pipeline and writes a digest can't hurt you. A system that emails your buyers can. Where I'm honestly still tinkering: email. Plenty of deals move in threads, not calls, and I haven't found a way to fold email into the read without doubling the noise in the digest. When I crack it, you'll get it here first.
> THE MOVE
What you should do next
Pick your five most alive deals. Just five.
Write the deals file by hand tonight: company, stage you believe, next step, due date. Export the last two weeks of transcripts into a folder, run the prompt above once, and grade the digest against what you know. It will get something wrong; correct it in the prompt and run it again. Only when it's beaten the list in your head twice do you put it on a schedule, laptop closed, using a routine.
Then reply and tell me what it flagged. I read every reply, and I'd bet the first run catches one deal you thought was fine.
Andrew
P.S. If you only steal one line from this issue, steal "no quote, no flag." It's the difference between a pipeline read you can act on and a horoscope.
|