Builing a deal intelligence platform
I run a nightly deal intelligence agent that reads sales calls and updates deal notes automatically. It started as a way to save my reps thirty minutes of CRM hygiene per deal. But there’s a grander strategy behind it. It serves as an input engine into a broader “AI Brain” which many operators are talking about in GTM AI circles.
Here’s what I mean. Gong records the call, transcribes it, and coaches the rep on that call. Clari looks across the pipeline and tells you which deals are at risk based on engagement signals. Both are good at what they do.
But what if you looked at both holistically to get an actual read on the deal. For example, what should happen by call six based on what happened in calls one through five? Does the deal stage in Salesforce reflect where it should be? Is this a common pattern for this particular rep and is that good or bad compared to the rest of the team?
So what does “AI in sales” look like? For many teams it’s giving Claude to the sales team to run a specific task. Help me prep for this call. Help me write this proposal. The rep shoves in a bunch of information in the chat window. What makes the most difference in my opinion is to feed it cumulative evidence. All calls, all research, all emails, all documents passed back and forth. Have it work with you as a strategist, analyst, and coach.
MEDDICC is a strong first use case
Go back to what MEDDICC actually asks you to track. Metrics, economic buyer, decision criteria, decision process, identified pain, champion, competition. You just can’t get all of it in a single call. A champion doesn’t get identified in one conversation, they get confirmed over three or four, as the person keeps showing up, keeps advocating internally, keeps answering your emails before the rest of the buying committee does. Decision process doesn’t reveal itself in one meeting either. It usually leaks out sideways, a comment about legal review in call two, a mention of a budget cycle in call four, a stray line about who actually signs in call five.
A tool that summarizes each call in isolation will flag “champion not yet confirmed” on call #5 even though the evidence for a champion has been sitting in the transcript since call #2. It’s not wrong, exactly. It’s forgetful. And forgetful in a system that’s supposed to be helping you remember is close to useless.
Once you stop treating each call as its own event and start treating the deal as a thing with memory, four capabilities open up that a call by call tool structurally can’t give you. Deeper and wider deal inspection across a full call history. Coaching that’s about the rep’s pattern across deals, not their performance on one call. Preparation for the next call that’s actually informed by everything before it. And a rep level view that tells you something about how a person is developing, not just how one deal is going.
None of this needs a platform vendor, but I totally understand if it’s just easier to buy a platform. Proper AI systems need an architecture, a framework to hang the evidence on, and the discipline to build the thing so it accumulates instead of resets. Let’s walk through what that looks like in practice.
A five level way to think about where you are
I’ll lay out a rough maturity curve. Not because you need to hit level four to get value, level two alone is already a real jump for most teams, but because it’s useful to know which rung you’re actually standing on before you decide what to build next.
Level zero is the status quo for most teams. Calls happen, notes get written if they get written at all, and the deal’s real state lives in a rep’s head until they leave the company and take it with them.
Level one is where most conversation intelligence tools sit today. Every call gets recorded, transcribed, and summarized. You get a scorecard, maybe a sentiment read, maybe a list of competitor mentions. This is genuinely useful. It’s also where the story usually stops, because the summary of call five doesn’t know anything about calls one through four.
Level two is cumulative deal state, and this is where the SHIfT gets real. Before the agent analyzes the newest call, it first builds a running picture from everything that came before, so it knows the champion was confirmed in call two and doesn’t need call five to prove it again. This is the deep and wide inspection you’re asking about. Deep, because a deal that’s five or six calls into a proposal stage has accumulated a lot of evidence that a single call summary throws away. Wide, because the analysis is now checking the full MEDDICC picture against the full call history, not just what happened to come up in the most recent conversation.
A brand new cohort for the AI for RevOps course is open for enrollment! Enroll today.
Level three is coaching, but coaching that’s actually looking at the rep, not the deal. Once you’re extracting the same structured evidence buckets, metrics, champion, decision process, and so on, across every deal a rep runs, you can roll that up. Not “how did this call go” but “how does this rep tend to build champions across their deals.” That’s a completely different coaching conversation, and it’s one a manager sampling calls at random almost never gets to have, because they’d need to remember six deals worth of detail to spot the tendency.
Level four is where accumulated state turns into preparation instead of just retrospection. If the agent already knows the deal cold going into call five, it can brief the rep before call six starts. Not a generic call prep template. An actual briefing built from what this specific buyer said in the last five conversations, what’s still unconfirmed, what objection came up twice and never got fully answered.
What deep and wide inspection actually catches
Let’s make level two concrete, since “cumulative state” can sound abstract until you see what it changes.
Imagine you have a deal in proposal stage with six calls behind it.
A level one tool analyzing call six in isolation is working from whatever got said in that one conversation, plus maybe whatever fields already exist in the CRM. If the rep didn’t explicitly restate the economic buyer’s name in call six, a naive scoring pass might flag it as a gap. It’s not a gap. It was nailed down in call two and confirmed again in call four. The tool just doesn’t know. It’s only looking at one call!
A cumulative system reads all six calls before it says anything about call six specifically. It builds a running assessment of every MEDDICC component first, then checks what’s genuinely still missing against what’s actually been said across the whole relationship. The practical effect is that your gap list gets shorter and more honest at the same time. Fewer false alarms about things that were already answered three calls ago. More real ones about things that have never come up at all, which is a much sharper signal for a rep or a manager to act on.
Brownie points if you throw in deal stage property history, contact roles, contact role create dates as well, what your stages mean, and exit criteria
This also changes what “deep” means. A single call rarely contains enough for a manager to catch something like a champion who’s been quietly softening their language over three calls, more hedging, less certainty, the kind of drift that’s obvious across a stretch of conversations and invisible in any one of them. It’s exactly the kind of signal a system with memory is positioned to catch and a system without it structurally cannot, because there’s nothing to compare against.
Coaching that looks at the rep, not just the call
Once you’re pulling the same evidence categories out of every deal a rep touches, something else becomes possible that most coaching programs never get to. You can ask what this rep tends to do well and where they tend to come up short, across their whole book, not their last call.
Say a rep is strong at identifying pain early. Call one, call two, they’ve got real specificity on what’s broken and what it’s costing the buyer. But across a dozen deals, champions never seem to get much stronger after they’re first identified. The rep finds the person, gets an initial yes, and then never does the follow up work to build that relationship into an internal advocate who’s actually fighting for the deal in rooms the rep isn’t in. That’s not visible from any single call review. It’s only visible once you’re looking at the shape of a rep’s deals as a set.
This is the coaching conversation managers actually want to have and now it’s even better because you’re providing evidence. Not “you missed a question in this call.” More like “here’s a tendency across your last eight deals, and here’s what it’s probably costing you at the proposal stage.” Sales enablement has been trying to get to this kind of coaching for years with call libraries and manual scorecards. It’s slow, it depends on a manager remembering enough detail across enough deals, and it doesn’t scale past a handful of reps a manager can genuinely track in their head.
Prep before the call that hasn’t happened yet
Level four is the one that turns this from an analysis tool into something a rep actually uses before they need it, not after.
If the system already has a running picture of a deal after five calls, it can generate a brief before call six starts. Not “here’s what MEDDICC is missing,” which is retrospective and a little accusatory. More like a working document. Here’s what this buyer has said matters most to them. Here’s the objection that came up in call three and got a soft answer that never got revisited. Here’s the name that’s come up twice as someone the champion mentioned but the rep has never actually talked to.
That’s the difference between an audit and a briefing. An audit tells a rep what they did wrong. A briefing tells a rep what to walk into the next room already knowing. Reps read briefings. Reps tend to ignore audits, especially audits that show up after the deal’s already lost momentum.
The rep level rollup, and where the numbers get real
Pull all of this up one more level and you get something genuinely useful for a RevOps or enablement function specifically, which is a way to see how a rep is actually progressing against their ramp, not just their quota.
The average AE ramp time is at 6.2 months because of deal complexity and stakeholder count both climbing. Quota attainment across B2B SaaS sits in the low fifties on a good year. Those two numbers together mean sales organizations are running a ramp program that takes over half a year, aimed at a bar that half the team still won’t clear once they’re through it.
A per rep rollup built off the same deal level evidence gives you something ramp programs usually can’t, which is a signal that isn’t just “did they hit number in month four.” It’s closer to “is this rep’s champion identification getting sharper deal over deal, or is it flat.” That’s the kind of signal that tells you whether a rep is actually ramping or just getting lucky on a couple of deals, months before the quota number would tell you the same thing. If you’re the person building the ramp curve for a new cohort, that’s the difference between catching a stalled rep in month three and finding out in month seven when it shows up as a missed number.
None of this replaces a manager’s judgment. It gives the manager something to point at that isn’t just their own memory of who seemed sharp in the last forecast call.
AI infrastructure that learns
The system I run keeps a versioned memory layer in the same GitHub repo as the code, daily diffs, learning entries, snapshots of the instructions the generator is running on. This type of setup is what enables level three and four to be possible, because a coaching rollup or a call six briefing is only as good as the accumulated record it’s built from, and a record that isn’t versioned is a record you can’t trust six months in.
Anyway. Let’s get into what you could actually build.
The three roles, at minimum. A context builder that reads everything before the newest call and produces a running MEDDICC state. A generator that takes that running state plus the newest call and produces the actual analysis, gaps, next steps, evidence. And an evaluator that checks the generator’s output against a rubric before anything touches your CRM, so a bad run doesn’t quietly corrupt the deal record. I run the generator role on Sonnet 5, for what it’s worth, mostly because the reasoning gains on evidence extraction and gap identification are the part of this pipeline where model quality actually shows up in the output.
Again, the three roles are:
The context builder
The generator
The evaluator
The rubric matters more than the model. Your evaluator is only useful if it’s checking for something specific. This is where humans make a huge difference with AI. You train the AI on what good looks like. Evidence quality, meaning does every claimed gap or confirmation trace back to an actual quote, not an inference. Component coverage, meaning did the generator actually check all seven MEDDICC components or just the ones that came up naturally. False gap rate, meaning is it flagging things that were already resolved earlier in the deal. Write the rubric before you write the generator prompt.
Deal prep is a separate generation pass, not a repurposed audit. Don’t try to make one prompt do both jobs. The rubric for “what’s missing” and the rubric for “what should this rep walk in knowing” are different enough that combining them produces a document that’s mediocre at both.
The rep rollup is a query, not a new pipeline. If you’re already extracting structured evidence per deal, the rep level view is a matter of grouping that evidence by rep and by month, not building new infrastructure. This is the part people tend to over engineer.
One honest caveat before you build any of this. A system that accumulates deal state is also a system that accumulates its own mistakes if nobody’s checking it. A bad context builder read in call two can quietly poison every analysis after it, since the whole point is that later calls build on earlier state. Review the learning loop’s output periodically. Don’t set this to fully unattended and check back in a quarter.
The paid deliverable for this edition is a build blueprint. It includes the three role prompts as editable templates, ready to adapt to your own MEDDICC or MEDDPICC rubric, a GitHub Actions cron file you can drop into a repo as is, the evaluator rubric spelled out as actual pass and fail criteria rather than vague guidance, and the rep rollup query structure. Open it and you have something to paste into a repo within the first few minutes, not a framework to fill out before you get anything usable.
