Score the fit before you build the second demo

Run a functional and technical qualification (FTQ) before you build the second demo. Score functional fit and technical fit from 1 to 5, weight the critical criteria and decide: invest, conditional or pause. A written score makes the call repeatable. Enthusiasm from sales does not count as a score.

The situation

Say discovery went well. The champion (opens in a new tab) is friendly, sales is excited and the customer asks for a second demo, this time on their own data. Building it will take days of your time.

Before you start, ask what you are about to commit. A feature that fits the business but cannot be built in the customer's environment is worthless. So is a perfect build that misses the business need. The FTQ is the point where those two views meet.

Why the second demo is the right gate

The first demo is cheap. You show a standard story and learn how the room reacts. The second demo is where your cost jumps. Their data, their workflow and often their integration questions all land on your desk.

It is also where commitment starts to feel real on both sides. Once you have spent days on a tailored build, walking away feels like a loss. That feeling bends judgement. A score written before the build cannot be bent by hours you have not spent yet.

The FTQ does not replace discovery. It reads your discovery notes and turns them into a documented decision. The handbook is direct about the cost of skipping it. Teams that run discovery, demos and solution work on unqualified deals burn capacity on things they cannot deliver.

What to do

Gather the three inputs

The first is the Opportunity Scoping Document (opens in a new tab) (OSD). The second is the BANT summary from sales discovery. The third is the input from the opportunity review call (ORC). The FTQ reads the OSD and scores it. It does not become a second copy of it.

If the OSD is thin, you are not ready to score. Go back to functional discovery (opens in a new tab) first. Feedback from the first demo counts too, so collect it before you score. The post on what to do after the demo (opens in a new tab) covers how.

Score in two blocks

Functional fit. Pull the described challenges and major pain points from the OSD. For each one, write down the implications and the root causes. Add the desired outcomes and vision, because the solution has to serve the aspirations as well as today's problems.

Technical fit. Pull the IT overview and the architecture. Which systems are in play, how do they connect and where do legacy constraints sit? The assumptions and gaps section matters just as much. It marks what still needs validation before anyone commits.

Give every criterion a score from 1 to 5. Let the critical criteria carry more weight, so one weak spot moves the total. Document each score, so the decision stays transparent.

A worked example

Here is an illustration, not a real deal. Say you pick five criteria. Three are functional: the main pain, the desired outcome and the process change. Two are technical: the integration with their core system and the data volumes.

The functional criteria score well, a 4 and two 5s. The integration scores a 2, because nobody has confirmed the interface yet. You marked integration as critical before you started.

The average looks healthy. The weighted result does not, and that is the point of weighting. A simple decision rule helps here: a critical criterion at 1 or 2 caps the outcome at conditional, whatever the total says.

Decide

There are three outcomes.

Invest. Both fits pass. Go for the demo, the proposal and the roadmap.

Conditional. The deal looks good but has named gaps. Close them first, each with an owner and a date. In the example, the gap is the interface. The owner is the customer's IT lead and your technical colleague. The date sits before the second demo.

Pause. One fit fails. Walk away politely and give your hours to a deal you can win.

Say the result out loud to sales in one sentence. "The business fit is strong, the integration is unproven, so I build the demo once their IT confirms the interface." That sentence is easier to accept than a spreadsheet.

Run the review call

The ORC feeds this decision with judgement from other departments. Run it weekly. Bring the deals where the fit needs discussion. Bring also the ones that meet 90% of the requirements, where the missing 10% need commitments from other teams.

Share a filled-out OSD before the call, plus a short note on what you want to discuss and who needs to attend. In the call, review last session's actions first. Then discuss two or three opportunities in depth. A named moderator keeps time, takes notes and captures the actions. Every opportunity leaves with actions, a named owner per action and a timeline.

The scoring framework itself sits in the FTQ chapter (opens in a new tab), and the spreadsheet is on the templates page (opens in a new tab). For the wider logic of saying yes or no, read the qualification chapter (opens in a new tab).

What can go wrong

The score follows the mood. If the loudest voice wins, you have a vote and not a score. Write the criteria and the weights down before you look at the deal.

The framework is too heavy. A long checklist that nobody finishes helps nobody. Pilot the framework on a few deals first and refine it with the feedback of the people who use it. Then make it a standard step.

The ORC turns into a talking shop. Without the notes, the owners and the follow-up before the next call, the ORC becomes a discussion forum. It stops being a qualification gate.

Conditional becomes a polite yes. A gap with no owner and no date stays open until the demo exposes it. Check the open gaps at the start of every review call.

You qualify too late. If you score after the second demo is built, you have already paid for the answer. Score first, then build.

When the counter-argument wins

Sales will say the FTQ slows a hot deal down. Sometimes that is right. If the second demo is a small change to your standard story, a short check in your head is enough. The full score earns its time when the build is large or the integration is unproven.

The edge case matters too. In an expansion deal with an existing customer, you often know the technical fit already. Score the functional side properly and keep the technical block short. With a new logo, both blocks need the full work.

The signals

It is working when sales starts asking for the score before they promise a demo. It is failing when every deal comes out as invest. A gate that never says pause is not a gate. Track the success rate of qualified opportunities and the time you save, and adjust the weights when they drift. For why that discipline pays off across the pipeline, read why only a hard-qualified pipeline is a good pipeline (opens in a new tab).