FTQ: Functional and Technical Qualification

Functional and technical qualification (FTQ) answers two questions before you commit people to a deal. Does the solution serve the business need? Can it be implemented in the prospect's technical environment? A feature that fits the business but cannot be built is worthless. So is a perfect build that misses the need.

The FTQ is where those two views meet. It turns discovery notes into a scored, documented decision about whether the opportunity is worth pursuing.

How the FTQ Runs

(opens in a new tab)

Three inputs, two fits, one decision. The scores turn notes into a decision.

Three inputs go in: the OSD, the BANT (opens in a new tab) summary from sales discovery and the input from the ORC. You score them in two blocks, functional fit and technical fit. Every criterion gets a score from 1 to 5. The critical ones carry more weight.

Then you decide. Invest means both fits pass. Go for the demo, the proposal and the roadmap. Conditional means the deal looks good but has named gaps. Close them first, each with an owner and a date. Pause means one fit fails. Walk away politely and give the hours to a deal you can win.

The sections below walk through each step.

Using the OSD

The Opportunity Scoping Document (OSD) (opens in a new tab) is the input to the FTQ, not a second copy of it. The FTQ reads the OSD and scores it.

On the functional side you pull the described challenges and major pain points. For each one, you need the implications and the root causes. You also pull the desired outcomes and vision, because the solution has to serve the aspirations as well as the current problems.

On the technical side you pull the IT overview and architecture. That tells you which systems are in play, how they connect, and where the legacy constraints sit. The assumptions and gaps section matters just as much. It marks the areas that still need validation before anyone commits.

The project prioritisation and business release sections give you the rollout sequence. That sequence drives both the functional order of features and the technical readiness of the infrastructure for each phase.

How the OSD works as a filter is covered in the qualification chapter (opens in a new tab). This chapter is about the framework you build on top of it.

Key Components

An FTQ framework has five parts. Build them in this order.

Objective and scope: Write down what the FTQ decides. Then name which parts of the business and the technical environment you will evaluate.

Evaluation criteria: Functional criteria cover the features, process changes and value the solution must deliver. Technical criteria cover integration, scalability, sustainability and known constraints.

A scoring system: Use a simple scale, for example 1 to 5, or weight the criteria so the critical ones move the total. Document every score so the decision stays transparent.

An evaluation process: Define the steps. Gather the initial data, interview stakeholders, review the technical documentation, then score against the criteria. Involve Sales, PreSales, Product Management and Development.

A rollout plan: Train the team, pilot the framework on a few deals, then refine it with their feedback. Make it a standard step in the sales process and track whether it works. Useful metrics are the success rate of qualified opportunities, client satisfaction and time saved.

The scored sections themselves usually cover:

• the summary from the BANT and the summary from the ORC
• strategic alignment and company information
• technical requirements and compatibility
• workflow and process analysis
• pain points and needs
• the decision-making process
• competition and differentiation
• legal and compliance
• implementation and adoption
• value and ROI (opens in a new tab)
• future growth and scalability
• cultural and organizational fit
• solution-specific questions such as volumes and modules

Opportunity Review Call (ORC)

The ORC is where the cross-department judgement enters the FTQ. Its output becomes one of the scored sections: deal worth, evidence, value, weight and score.

Run it weekly, so opportunities stay front and centre. Not every deal needs a slot. Bring the ones where the functional or technical fit needs discussion. Bring also the ones that meet 90% of the requirements, where the missing 10% need commitments from other departments.

Before the call, collect all important opportunities. Let team members request a slot from the moderation team. Share a filled-out OSD upfront, plus a short note on what will be discussed and who needs to attend.

The call itself follows a fixed order. Review the action items from the last session. Clear the open points. Then discuss two or three opportunities in depth. A Solution Consultant (opens in a new tab) presents each one from the OSD, covering the summary, the key issues and the proposed solution.

A named moderator runs the discussion. The moderator keeps it on track, takes notes and captures action items. Every opportunity leaves the call with defined actions, a named owner per action, and a timeline.

Afterwards, send the notes with all action items and owners. Set deadlines and follow up before the next call. Without that follow-up the ORC becomes a discussion forum instead of a qualification gate.

PreSales Perspective

The FTQ is a first sketch. An opportunity that passes it earns the rest of your effort.

Demo preparation comes next. Every slide, click and example should mirror the prospect's environment. Show why each feature matters to them. Run the demo as a workshop. Ask, listen, answer objections while they are fresh.

Then the proposal consolidates everything. It ties together the technical specification, the integration into the existing systems, likely customisations and the challenges you already see. Resource estimation belongs with it: time, people and hardware, stated honestly so nobody is surprised later. An implementation roadmap with milestones, timelines and deliverables keeps both sides in step.

A proof of concept (opens in a new tab) is not always needed. Where doubt remains, it gives the prospect a preview and settles the question. An RFX (opens in a new tab) process may follow, and then negotiation. Treat negotiation as a joint search for the point where value and investment meet.

Skip the FTQ and you pay for it later. Teams that run discovery, demos and solution work on unqualified deals burn capacity on things they cannot deliver.

Key Takeaway

Two questions, one gate: FTQ asks whether the solution fits the business need and whether it can be implemented. Both have to pass.

Score it: A documented scoring system makes the decision objective and repeatable. Sales enthusiasm does not count as a score.

The ORC feeds the FTQ: Cross-department input from Sales, PreSales, Professional Services, Product Management and Development becomes a scored section of the FTQ.

Qualification is the start: After the FTQ come the demo, the proposal, the resource estimate, the roadmap and the close.