Past the Summary

Most of what gets sold as "AI in sales" stops at the same place: it joins the call, transcribes it, writes a tidy summary, and files it in the CRM. That is genuinely useful, and it is also where almost everyone stops. The work that actually moves revenue starts one step later – when the context you already own decides what to do next, instead of just getting logged.

Here is the claim, stated so you can disagree with it in one sentence: in a business with long relationships and real deal complexity, the value of AI is not the summary – it is the layer past it, and that layer runs on your internal data, not on external signals. If your mental model of "AI for revenue" is bolt-on enrichment and prettier notes, I think you are optimizing the cheap half.

This is not a pitch. I run a different ICP than the kind of company most people reading this are building, and if this were a pitch I would be talking about your dream outcome over your time-to-value – it isn't, so I won't. It is a compilation of patterns from two companies I actually worked with: one where the pattern mostly landed, one where I didn't finish. No rosy version. The parts that didn't work are the parts worth your time. I've argued the higher-level version of this in the thesis; this is the ground floor.

The four things past the summary

Strip the branding off both engagements and the same spine shows up. Four layers, each only as good as the one beneath it:

Layer	The question it answers
Context understanding	What is actually true about this account, right now?
Prioritization	Of everything open, what deserves attention today?
Next action	Given this account's state, what is the single most useful move?
Assessment	Are the right actions actually being taken, across the whole book?

The summary is the bottom of the context layer. Everything that pays off sits above it. And the honest state of the art – mine included – is that the first three are buildable today, while the fourth is where most efforts quietly never arrive.

Company A: a collections floor that had to see itself

The first is a US tax-credit firm running a large collections floor. Efficiency business: the CEO is the economic buyer, thinks in run rate and variance, and controls demand from the top. Deals are won easily and then monetized over a long, painful tail – the client gets paid by the IRS, goes quiet, and someone has to chase the fee through months of silence.

The load-bearing decisions were about truth, not models. The financial fields collections acts on were anchored to the firm's own filing portal, not the CRM everyone trusted – because a rep who catches the system out on a money number once stops reading it forever, and then you have built an expensive thing nobody uses. Prioritization was a deterministic queue over real internal state (what is owed, at what stage, reachable in which time zone), not a vibe. The next-action layer had one rule that matters more than it sounds: the model's suggested step had to resolve to something the floor could actually do that day. A next step the team can't execute is not advice, it's noise.

The real product turned out to be the fourth layer. Not the summaries – the assessment: are the reps doing the required work, are the clients doing theirs, where is effort hiding risk. Graded against a fixed rubric, pass or fail, not activity theatre.

What was hard is the useful part. Thousands of summaries went out and the feedback loop was near-silent – the first dashboard drew almost no views. Powerful tools nobody opens are worth zero, and adoption is not a launch event, it's the actual work. "Addressed" and "resolved" are different states, and conflating them punishes exactly the multi-touch effort you want. And the moment the work turned to litigation prep, the stakeholder graph fell apart: contacts orphaned across systems, numbers that belonged to no deal. The single-deal picture was fine; the cross-entity picture was not.

Company B: enterprise deals I didn't finish

The second is a Series A vertical SaaS selling large, heavily customized deals into industrial and logistics enterprises. Long cycles, ACV from five figures to seven, multiple stakeholders per deal, a founder personally in the room. This one is closest to where a lot of you are headed, so I'll be specific about where it stalled.

Built: deal context assembled from meetings, notes, and the CRM into a framework score (MEDDPICC-shaped, deliberately anti-inflation); weighted prioritization that valued expansion and POC-to-production over net-new logos; a per-stakeholder recommended action; and an in-person motion that worked out who was worth meeting when the team was already going to be in a given city.

What I did not finish: the highest-value next action is the one that depends on factors outside the deal – "the founder knows Mike, and Mike knows twenty people at the account you're chasing." I scoped it, I proposed it, I believe it is buildable, and I did not ship it as a working engine. There was also no assessment layer like Company A had. And the context layer was starved from underneath: roughly a fifth to a third of customer meetings never reached the CRM at all, so every score was reasoning over a partial record. The engagement wound down to project work before the in-person motion fully ran, and the forecasting piece I built I parked myself, because it wasn't good enough to hand over.

The full case study at that company tells the finished half. This section is the other half – the half that doesn't make the case study.

What transfers if you're building this from scratch

If you're stepping out of a scaled, horizontal org into an early-stage vertical SaaS with a wide ACV spread and long enterprise cycles, here is what I'd carry over:

1. Internal signals beat external ones, badly. Enrichment – job changes, web visits, second-degree connections – is a bonus, not the engine. The value in the down-funnel is staying on top of the loops that are already yours.
2. A "next action" only counts if the team can execute it. Constrained selection among moves that exist and are doable, not a model free-associating a plausible sentence. This is the honest answer to "I still haven't seen the manual data entry actually go away."
3. Build the assessment layer or you are flying blind. It was Company A's real product and Company B's biggest gap. Without it you cannot tell whether any of the layers below are working.
4. Sequence to support the team early, and fix the context intake before you scale the analysis. Company B is my counter-example: I let urgency pull the build out of order, and analysis over a partial record is analysis you can't trust.
5. Attention is the scarce input, not model quality. Output quality hinges on feedback iterations, and getting an authoritative human to look at the right artifact is the bottleneck – not the size of the model.
6. Mind the size cliff. A single deal fits in a prompt. A relationship graph does not. That is a different architecture, and it's precisely why the highest-value action is the hardest to build.

What I still haven't cracked

The cross-deal relationship graph is the honest frontier. Everything above it – summaries, scores, single-deal next steps – I know how to build. Turning "who knows whom, and how warm" into a ranked, executable next action across a whole book, at a size that blows past a single prompt, I have not shipped. I think it's doable. I have not done it.

What would change my mind about any of this: an "AI for revenue" build that lives entirely on external signals and prettier summaries, skips the assessment layer, and still reliably changes what a team does on a Tuesday. I haven't seen it. If you have, I'd genuinely like to.

If you put someone onto building even one of these, that is a good outcome by me – I would rather the idea get built than sit in a case study. And if you want to argue with any of it in person once you're settled in the new seat, I'm in.