The Opportunity Review, Rebuilt From Real Conversations

The deal that looks fine

Same deal. Same messages. Two readings.

Every activity report your company owns counts messages. None of them counts inbound on its own. Combine the rails and this deal is working. Split them and the buyer stopped replying a month ago.

Northwind Grid

2026-06-23 to 2026-08-21 · 9 weeks · 64 messages · sample data

Reads as Active

All activity 64 messages

Inbound · the buyer 26 messages

31 days of silence

Jun 23Jul 22Aug 21

Last message 1 day ago. Sixty-four messages across nine weeks, no gap longer than four days. Nothing in this view asks who was sending them.

Figure 1. The same message history under both readings. The artifact records the date and direction of every message, then derives the state from the dates. The threshold comes from this deal's own history rather than a global rule.

The problem

Three inputs, and all of them trace back to the rep

This is not a claim that reps are dishonest. A qualification framework is a set of questions. It tells you which facts to collect and has no way to check whether the answers are right.

Input 01

The CRM record

Stage, close date, amount, probability. The rep sets all four, on the cadence the process demands. The deal moves on the buyer's cadence, which is whenever the buyer decides to move.

Input 02

The rep's recollection

Context and memory, one conversation at a time over two months, with no view of the shape they make in aggregate. Nobody holds a silence baseline in their head across thirty deals.

Input 03

The qualification framework

MEDDIC or a local variant supplies the shape of the conversation. If the rep believes the economic buyer is the VP of Operations, the scorecard says VP of Operations, and it looks exactly as authoritative as a verified one.

So the leader inspects. Not out of distrust, but because inspection is the only mechanism available for getting at facts the leader has no independent access to. And inspection can only surface what the rep already knows.

The state that earns the workflow

A stalled deal shows up on its own. A one-sided deal does not.

Progressing

The buyer moved the deal inside its own established cadence.

One-sided

We are moving it and they are not. Outbound volume looks healthy, so the deal reads as active on every dashboard the company owns.

Stalled

Nobody is moving it. Activity drops to zero, and zero is visible in every pipeline report.

A rep usually knows when a buyer has gone quiet. What they do not have is a way to tell the difference between a silence this deal has survived before and a silence that is new. A buyer who takes three weeks to reply is alarming in one account and completely normal in another.

What a leader gets in the review is a sentence like "waiting on legal," which is true, and which sounds identical whether legal received the paper last Thursday or six weeks ago and stopped responding.

A one-sided state is not a verdict. Some deals are legitimately one-sided while a security review runs. The review is built to be argued with on exactly this point, and block 06 carries the argument.

What it is

Twelve blocks, the same twelve, every time

You ask for a review of a named opportunity. A few minutes later you have one formatted document. The blocks are not a narrative summary, because narrative is what the rep already provides and it is not checkable.

Figure 2. A real run against a live opportunity, 21 August 2026. The header carries a motion state, not a probability. Probability needs win rates, competitive position, and comparable deals. Sturdy sees messages, and motion is directly observable, so a reader can disprove it by opening the thread.

01SummaryStatus first, then the single thing most likely to change it.

02Why nowTiming pressure in the buyer's terms. No urgency in the record is a finding.

03Buyer goalThe outcome, ideally in their words. A number we put in a deck is not their goal.

04Deal killersSorted by severity, each with the observable early warning.

05Path to closeOne row per blocker: next move, owner, and the buyer signal that confirms it worked.

06State rationaleThe math printed step by step, plus at least one argument against it.

07Decision dynamicsNamed people and roles, each with the behavior that earned the assignment.

08Commitment signalsWhat binds the buyer, rated strong, moderate or weak, each with an implication.

09Unresolved concernsOnly what the buyer raised, each aged in days open.

10What must be trueOrdered conditions, met, open or blocked, sequenced by dependency.

11Missing clarityWhat could not be established, ordered by consequence rather than category.

12ProvenanceRetrieval counts, spans read, and what the connected channels do not cover.

Figure 3. Every review produces all twelve, in the same order, whether or not the deal has content for them. A block with nothing in it renders an explicit empty state, because a missing section reads as an oversight and a stated empty section reads as a finding.

The rebuild

What we refused to build

No probability score.

A probability is a claim Sturdy has no basis for. It needs win rates, competitive position, and comparable deals. The header carries motion instead, because motion is observable and the reader can disprove it by opening the thread.

Claude does not set the state.

The engine derives it from the message dates. Sorting, date arithmetic, and empty states are computed by the template. That is what makes two reviews of two different deals directly comparable.

No thin version of itself.

Fewer than five conversations in the window and the review refuses to render. The floor is enforced by the template rather than by Claude, so it cannot be talked around, and widening the window to clear the bar is out of bounds.

Absence is not evidence.

"No competitor is named" is not "there is no competitor." Every claim that carries weight arrives with a date, a source, a named person, and either a verbatim quote or a clearly labeled paraphrase, marked by direction.

The component no CRM has

The linkage gap

The review pulls the deal's conversations twice, once filtered to the opportunity and once filtered to the account, then reconciles the two sets. They routinely differ.

Opportunity linkage is applied inconsistently and degrades as a deal ages, so the opportunity-filtered set is frequently missing the newest and most consequential threads. Anyone reviewing that deal inside the CRM is seeing only the linked set. This is the block that tells them what they are not seeing.

11 Missing clarity · first item

Defect 26 conversations sit on the account in this window and 12 carry opportunity linkage, so 14 are invisible to anyone reading this deal in the CRM. Ten are calendar accepts, invites, and a message recall. Four are substantive, including the technical question set, the note naming the evaluation group, and the thread in which a contact removed a system from Phase 1. Linkage does not stop at a date. It is intermittent throughout.

Figure 4. The block separates two kinds of gap. A limit is something we cannot see, such as CRM field history not being retrievable. A defect is something broken on our side. Defects are named as defects, because they are fixable and somebody should fix them.

Read timeThe plan is computed when you ask for it. There is no stored state to go stale between reviews.

Two spansBodies are read over the evidence window. Motion is computed over the deal's full history, so the threshold never depends on how far back a run happened to read.

One moveA rep who wants the review to look better has exactly one option available: move the deal.

The series

Replace Your Revenue Optimization Platform, one screen at a time

01 Opportunity Review The deal review, built from the communication record rather than the rep's recall You are here

02Forecast Roll-upComing soonSoon

03Pipeline HygieneComing soonSoon

04Account PlanningComing soonSoon

05Activity CaptureComing soonSoon

06Revenue ReportingThe series finaleSoon

Get the build

Unlock the whitepaper and the complete instruction set

The full paper includes the appendix: the literal project instruction set, pre-configured with the retrieval protocol, the evidence rules, and the motion math. Paste it into a Claude project, upload the template, connect Sturdy over MCP, and type an opportunity name. Setup runs under thirty minutes.

# Opportunity Review

You run opportunity reviews from communication
evidence. Sturdy is your only connector. You have
no other source and you do not act as if you do.

Your output is one HTML artifact built from
opportunity-review-template.html in project
knowledge. You fill the PAYLOAD object. You
change nothing else in that file.

## Retrieval protocol

1. Resolve the opportunity. Call search_opportunities.
If the user named an account rather than an
opportunity, call search_accounts first and pass
the account ID. If more than one opportunity
matches, list them and ask which one. Do not guess.

2. Learn the tenant's schema. Call
get_available_fields before constructing any
field_filters. Do not invent a field_spec.

🔒 The appendix · complete instruction set · pre-configured, nothing to edit before first use

Whitepaper · Sturdy × Claude

The Opportunity Review, Rebuilt

Get the whitepaper PDF, the paste-ready instruction set, and the review template. Then do the exercise that validates it: run it on a deal you already know and find where it disagrees with you.

Loading the form. If nothing appears, an ad blocker or privacy extension is blocking HubSpot. Turn it off for this page and reload.

Instructions and template land in your inbox. Run them against your own pipeline today.