Name the blocking dependency in the first call, before the demo

Why do deals that wait on another system keep slipping?

They slip because discovery never recorded what the deal waits on, who owns that date or whether the budget waits for it. So the forecast takes a champion’s hope as a close date. Every market has these deals. A bank waits on its core conversion, a manufacturer on an ERP migration, a hospital on an EHR go-live. Buyers anywhere wait on an incumbent’s notice date, a validation queue or a security review.

None of those clocks belongs to the person who asked for the demo, and few of them run in quarters. The demo builds the case and the champion agrees. Only then does someone say “come back when we’re live”. By then the deal has a stage, a value and a close date that nobody at the buyer gave. It moves a quarter at a time until it leaves the forecast or closes lost as “timing”.

The usual advice stops a step short. Of the 2 AI answers and 3 cited pages we read for this question in October 2026, none said who must confirm a dependency’s date before the deal counts as qualified.^↗ Without that step, a rep can record any date the champion offers.

Ask 4 dependency questions in the first call

Ask 4 questions before any demo is booked: what has to happen first, who owns that date, what the date rests on and whether the purchase waits for it.^↗ Ask them on every opportunity above your smallest deal size, and say why: you’d rather not demo something the buyer can’t use this year. A plain opener works: “Before I show you anything, what has to change at your end before you could buy or go live?”

The second question does the most work. The person who runs a conversion, a renewal or a review queue is often not the person who asked for the demo. End the first call with that seat named, by person and role, and an introduction requested. The third question separates a date from a hope. A signed plan, a contract’s notice date or a booked review slot is a basis; “next spring” is not.

If the champion answers “nothing”, record that with their name and put the same question to the budget owner before discovery ends. A dependency the champion doesn’t know about still sets the date.

Where your product connects to the system that is changing, add a question: does your integration already run on the system the buyer is moving to? If it doesn’t, building it is a dependency of its own, with an owner and a clock the buyer may not know about.

If the answers put the dependency inside your window, book the demo. If they don’t, book the next meeting with the seat that owns the date, or a session that helps the buyer plan you into the change.

Make the dependency a discovery exit criterion

A deal leaves discovery only when each dependency has 5 fields filled and the seat that owns it has confirmed its date.^↗ Confirmed means a two-way exchange: a call, a meeting or a written reply to a question you asked. “None” is a valid answer, recorded with who gave it.

The close date then follows from the fields. It is the dependency’s date, plus any freeze the buyer sets after the change, plus your median lag from clearance to signature on won deals that waited on the same kind of dependency. If the buyer’s own readiness comes later, that date wins. It is calculated, never typed, as in the rule we set for deals waiting on an outside approval.^↗ Until you have enough won deals of a kind, write the lag down as an assumption with a date to test it.

In the CRM, make the 5 fields required at the stage change out of discovery and let a formula or a flow write the close date, so nobody types over it. When the dependency’s date moves, record the reason; the close date moves with it, and the reason shows whose clock slipped.

The forecast then follows 4 rules:

• A deal whose calculated close date falls after the period sits in that later period’s pipeline, never in this one’s commit
• A dependency that is only reported, or unknown, keeps the deal in discovery with one task: reaching the seat that owns the date
• A confirmation older than 90 days, or a date that moved, takes the deal out of commit until its owner confirms again^↗
• A deal that waits gets a look-again date at the dependency’s next milestone, and someone on your side owns the relationship with that seat

Qualified means a budget owner has confirmed the timeline

We count an opportunity as qualified only when a budget-owner seat, the budget owner or their direct report, has confirmed the timeline it waits on. Otherwise interest from one hand-raiser gets forecast as revenue. We think a deal that waits on another system’s timeline is a stage-definition problem, and treating it as a rep problem misses the cause.

Only 45% of sales leaders and sellers report high confidence in their forecast accuracy.^↗ In our experience that points at what the stages ask for, and coaching reps harder rarely moves it. A rep who types a champion’s “spring” as a close date is doing what the stage allows. So we put the dependency, the seat that owns its timeline and the date it clears into the exit criteria for discovery.

We rarely see the champion give that confirmation alone. The average B2B buying decision involves 13 people.^↗ Across 655,000 opportunities, win rates rose by 55% when decision makers were actively involved in the first 2 stages of the sales process.^↗ We don’t read that as a reason to engage every seat before discovery ends, only the 2 that decide when money can move: the owner of the date and the owner of the budget.

Internal gates need an owner and a date before the pilot

An internal review needs an owner and a date before the pilot starts, because it is a dependency too. Model validation, a security review or a vendor risk review can each hold the production deal after the pilot has worked. The pilot proves the product. The review decides whether the buyer may use it. A hospital’s security and privacy review and a pharma site’s supplier qualification work the same way.

So the pilot plan carries the reviews. Before it is signed, ask the sponsor which reviews production needs and who runs each one, then meet those people with the plan. The pilot starts when 3 things are true:

• Every review’s owner is named and has had a two-way exchange with you
• The evidence each review needs is written into the pilot plan, so the pilot produces it
• Each review has a date in the plan, and the budget owner has confirmed the production decision date

A review found at the readout costs whatever its queue takes. Found in the first call, it costs a meeting.

The dependency check worked through at a community bank

At a community bank, the check catches the conversion before the demo. Take a fictional vendor of loan origination software that sells to US community banks at about $90k a year (Illustrative).^↗ Of its last 40 first demos, 20 ended with “come back when you’re live on our core”.^↗

Full core conversions can take several years.^↗ The core provider keeps clocks of its own: connecting a vendor outside its preferred network commonly takes 18–24 months, the American Bankers Association told the Office of the Comptroller of the Currency (OCC) in January 2026.^↗

This quarter its reps ask the 4 questions first. In 11 of 30 first calls the bank names a conversion before any demo is booked; at 8 of those banks the rep reaches the executive running it within 2 weeks, and the other 3 stay in discovery.^↗

At the bank whose conversion lands first, the COO confirms go-live on 10 May 2027 and a 90-day freeze on new integrations after it.^↗ The chief lending officer, who holds the budget, confirms the purchase waits. The vendor already runs on the new core, so no integration clock is added. With its median of 60 days from restart to signature, the close date calculates to 7 October 2027, and the deal leaves this year’s forecast with a look-again date of 1 March 2027.^↗ Of its 6 committed bank deals, worth $540k, 3 wait on conversions dated in 2027, so commit falls to $270k in the quarter’s first week rather than its last.^↗

The same vendor’s AI underwriting pilot at a fictional $3bn bank succeeded, but model risk first saw the model at the readout and production waited 2 quarters.^↗ In the guidance the Federal Reserve, the OCC and the FDIC revised in April 2026, validation of vendor products is “an important element of model risk management”, and validation “generally occurs prior to a model’s first use”.^↗ That guidance is expected to be most relevant to banks with over $30bn in assets,^↗ so a $3bn bank’s own policy sets the steps. The next pilot starts only once the head of model risk, compliance and vendor management have each agreed the evidence their review needs and its date.