When should pre-sales join a B2B deal?

Pre-sales should join a B2B deal once it is qualified and the buyer’s questions turn technical. That means the buyer has confirmed a problem worth solving, you know who holds the budget and how the decision will be made, and the next step needs technical evidence the account executive cannot give alone: a technical discovery session, a tailored demo, a proof of concept, a solution design or an RFP response. Before that point, the seller owns the deal and runs discovery. After it, the two work as a pair, with a written handover and a clear split of who does what.

This guide is for sales directors, heads of pre-sales and founders whose solutions consultants are overbooked, pulled into deals too early or too late, or unsure what they are accountable for.

What a pre-sales engineer does

Job titles vary: pre-sales engineer, solutions consultant, solution engineer, sales engineer. O*NET, the US Department of Labor’s occupational database, lists tasks for sales engineers that include:

• collaborating with sales teams to understand customer requirements and provide sales support
• conferring with customers and engineers to assess equipment needs and determine system requirements
• preparing and delivering technical presentations that explain products or services
• developing, presenting or responding to proposals for specific customer requirements, including request for proposal responses
• arranging demonstrations or trial installations

In a B2B software or services business, that translates into four jobs: technical discovery, demonstrations, proofs of concept and solution design, plus the technical parts of proposals, RFPs and security questionnaires. It is skilled work with limited capacity, which is why the timing matters.

Signs pre-sales joins at the wrong time

Too early

• Solutions consultants sit on first calls that end without a next step.
• Demos are given to people who cannot buy and have not described a problem.
• The pre-sales diary is full, but conversion from demo to proposal is low.
• Sellers use pre-sales instead of doing discovery themselves.

Too late

• Pre-sales sees the deal for the first time when an RFP arrives with a deadline in three days.
• The proposal promises something the product does not do, and the gap appears in procurement.
• Technical objections arrive at the end, from a buyer nobody had met.
• Deals in “Commit” slip because technical sign-off was never planned.

When to involve pre-sales, stage by stage

Tie the rule to your pipeline stages, so it is visible in the CRM and nobody has to negotiate it deal by deal. A starting point for a typical B2B sale:

The stages and exit criteria behind this table are covered in our guide to improving sales forecast accuracy. If your stages have no exit criteria yet, write those first.

The handover brief

The handover brief is the simplest habit to introduce between sales and pre-sales. Before the first technical session, the seller writes down what is already known, so the solutions consultant does not repeat discovery in front of the customer.

A handover checklist

• The customer’s problem, in their words, and why it matters now
• Who will attend, their roles, and who holds the budget
• How the buyer will evaluate options and who decides
• Current systems, integrations and constraints mentioned so far
• Competitors or alternatives in play, including doing nothing
• What the seller wants from the session, and the next step it should lead to
• Deadlines: RFP dates, budget cycle, go-live date

Keep the brief on the deal record, not in an email. HubSpot, for example, lets you choose properties that appear when a user moves a deal into a stage, and mark them as required so the record cannot be created or updated until they are filled in. A few required fields at the “Qualified” stage can carry most of the brief.

Technical discovery: what to ask

Technical discovery builds on the seller’s discovery; it does not replace it. Questions that tend to matter:

1. What does the current process or system look like, step by step?
2. Which systems would this need to connect to, and who owns them?
3. What are the requirements for security, data location and access?
4. Who will run it day to day, and what skills does that team have?
5. What would a successful first three months look like, in measurable terms?
6. What has been tried before, and why did it not work?
7. Who needs to approve the technical choice, and what will they check?

The last question connects to qualification. MEDDPICC, for example, includes Decision Criteria (“how your solution is evaluated”) and Decision Process (“how the buyer decides on your solution”). Pre-sales is well placed to find out the technical side of both.

Demos and proofs of concept

Demos

A demo should show the customer’s own scenario, in the order of their priorities, using their language. Agree the agenda with the seller beforehand, and stop to check reactions. A generic tour of every feature is a sign that discovery was skipped.

Proofs of concept

A proof of concept costs both sides real time. Before agreeing to one, write down:

• Success criteria, agreed with the buyer, that would show the solution works for them
• A time limit, with a start and end date
• The buyer’s commitment: named people, data or access, and time
• The decision it leads to: what happens if the criteria are met

If the buyer will not agree to these, the proof of concept is unlikely to decide anything, and the time is better spent elsewhere.

How sales and pre-sales share the work

Write this split into your sales playbook, so new sellers and new solutions consultants learn the same rules.

Managing pre-sales capacity

1. Use one request route, such as a field or task on the deal, not messages to whoever is free.
2. Prioritise by stage and size, with a simple rule everyone can see.
3. Record involvement on the deal: which deals had pre-sales, at which stage, and what was done.
4. Compare outcomes each quarter. Look at conversion for deals with and without pre-sales, and at the stage where it joined. If deals with early involvement convert no better, move the trigger later.
5. Protect time for product learning, so the team keeps up with releases.

How we can help

Our sales process and pre-sales work sets the point at which pre-sales joins a deal, the handover brief and the split of work between sellers and solutions consultants. It is part of the CRM, Pipeline and Forecast Set-up package, with deal stages and exit criteria, deal-strength scoring and pre-sales rules, manager dashboards and a weekly forecast routine. It takes four to six weeks, from £6,500 + VAT; software configuration and data moves are quoted separately (see pricing). If sellers need to explain the product better before pre-sales joins, see pitch and product training. To talk it through, book a 30-minute call.

Sources

All checked on 26 October 2026.

• Sales Engineers, 41-9031.00 (O*NET OnLine, US Department of Labor): tasks of the role.
• What is MEDDIC, MEDDICC and MEDDPICC (MEDDICC): Decision Criteria and Decision Process.
• Set up and manage object pipelines (HubSpot Knowledge Base): conditional stage properties and required properties.

Frequently asked questions

When should a pre-sales engineer join a sales call?

Once the deal is qualified and the next step needs technical evidence: a technical discovery session, a tailored demo, a proof of concept or an RFP response. Earlier only if a technical buyer is attending and the seller has asked in advance.

What does a pre-sales engineer do?

Works with sellers to understand customer requirements, runs technical discovery, gives demonstrations, designs the solution and writes the technical parts of proposals and RFP responses.

What is the difference between sales and pre-sales?

Sales owns the relationship, qualification, commercial terms and the forecast. Pre-sales owns the technical case: discovery, demos, proofs of concept and solution design.

What should a sales-to-pre-sales handover include?

The customer’s problem, attendees and roles, how the buyer will decide, current systems and constraints, competitors, deadlines and what the session should achieve. Keep it on the deal record in the CRM.