Presales vs Sales: Who Owns the Technical Win

Three weeks into a deal forecast to close this month, the buyer's security reviewer returns a questionnaire with four items flagged. The account executive can see the flags and cannot answer them. Who picks them up, what authority that person has if one of the four turns out to be real, and whether the deal is still forecastable in the meantime, is the substance of what the two words divide.

Presales is the work that establishes whether the product actually solves this buyer's problem, and sales is the work that establishes whether this buyer is going to buy. Both descriptions are accurate and neither settles an argument, because the interesting questions are all about the boundary: who runs the demo, who can say no, and who is measured on the answer.

What each function is

Sales owns the commercial relationship and the outcome. The seat is measured on closed revenue. It decides which opportunities are worth time, sets the commercial frame, runs the negotiation and carries the forecast. Its unit of work is a deal, and its clock runs in months. The seat is covered in full in the account executive entry.

Presales owns the technical case for the same deal. The seat goes by several names, including sales engineer, solutions engineer, solution consultant and technical seller, and the variation is mostly regional and industry habit rather than a difference in the job. It is measured on something harder to state cleanly, which is why the seat is so often misdesigned. The usual formulation is the technical win: the point at which the people who will have to live with the product agree that it does what it needs to do.

The technical win is a real event and it is not a stage in a CRM. It happens when the buyer's engineer stops asking whether and starts asking how, or when the security reviewer closes their questionnaire without a blocking finding. A deal can hold a technical win and die on price. A deal cannot close without one and survive implementation.

SalesOwns the outcome

• Measured on closed revenue
• Decides which opportunities get time
• Owns the commercial frame and the negotiation
• Carries the forecast
• Fails on qualification and on the buying group

ContestedWhere the design has to be explicit

• Who runs the demo, and which demo
• Who decides a proof of concept is warranted
• Who can disqualify on technical grounds
• Who answers the security questionnaire
• Whether the technical seat carries a number

PresalesOwns the technical case

• Measured on the technical win, however the company defines it
• Owns solution design and the depth of technical discovery
• Owns the demo environment and what it is allowed to show
• Owns the proof of concept and its criteria
• Fails on scoping and on promises made to win a moment

The boundary is an event rather than a skill set

The common way to describe the split is that sales is relational and presales is technical. That description survives contact with a job advert and nothing else. Good account executives carry a great deal of technical fluency, and the presales seats that matter spend more of their time managing people than managing systems.

The boundary that holds is an event. Somewhere in every deal there is a first moment at which the answer to a buyer's question requires opening the product, reading their architecture, or making a claim that will be tested in implementation. Everything before that moment belongs to one seat and everything after it is shared. Where a company draws that line, and whether it draws it in writing, determines almost everything else about how the two functions get along.

Drawing it early means presales attends discovery, hears the problem first hand, and shapes what gets demonstrated. Drawing it late means presales receives a briefing and demonstrates against somebody else's summary of a conversation they were not in. The second version is cheaper per deal and it is the version that produces demos that impress the wrong person. What a discovery conversation has to establish before anybody builds anything is worked through in running a discovery call.

1. Step 1First conversation

   Sales establishes that there is a problem worth a meeting and a person willing to describe it

2. Step 2Discovery

   The problem is stated in the buyer's own terms. Whether presales is in the room here is the single biggest design choice

3. Step 3Demonstration

   The product is shown against that specific problem. Presales owns what the environment is allowed to claim

4. Step 4Technical validation

   The buyer's own people test the claim, through a questionnaire, an architecture review or a proof of concept

5. Step 5Commercial close

   Sales returns to the front. Price, terms and the signature belong here

6. Step 6Handover

   What was promised in step three becomes somebody's implementation problem, which is why step three has an owner

Who owns which decision

Job descriptions list activities. The version that prevents arguments lists decisions, because the activities follow from them.

Which deals get technical attention. Presales capacity is finite and demand for it is not, so somebody decides. When sales decides alone, attention flows to the loudest deal rather than the most winnable one. When presales decides alone, the criteria drift toward technically interesting problems. The workable version is a written threshold that either seat can point at.

What the demo is allowed to show. A demo environment carries claims. Somebody has to own the difference between what the product does today, what is configurable, and what would be a project. That owner is presales, and the reason is accountability rather than knowledge: the seat that will be in the room during implementation has the strongest incentive to be accurate.

When a proof of concept is warranted. A proof of concept is the most expensive thing either seat can agree to, and it is routinely agreed to because saying yes feels like progress. The criteria, agreed in writing before anything is built, are what separate an evaluation from a free trial with a project plan attached. The reasoning and the refusal cases are in proof of concept sales.

Whether the deal is technically dead. This is the decision most often left unassigned, and the cost of leaving it unassigned is deals that stay in the forecast for two quarters because nobody had the authority to remove them. A presales seat that cannot disqualify is a demo service.

The four places they collide

Engagement without a threshold. Presales is pulled into early calls as a credibility prop, capacity disappears, and the deals that genuinely needed technical depth get a rushed version. The fix is a written standard for when the seat is engaged, agreed by both sides before anybody is measured against it.

Measurement that points in opposite directions. Sales is measured on closed revenue in a period. Where presales is measured on the same number with no separate quality signal, the seat has no incentive to say a deal is unwinnable. Where presales is measured on nothing, it becomes a shared service with no view. Companies that get this right usually measure the seat on win rate within the deals it touched, plus something about implementation outcomes, which is the only measure that punishes a promise made to win a moment.

The battlecard problem. Competitive claims made in a demo are the hardest to walk back, because they were demonstrated rather than asserted. What belongs on a competitive card, and the level of detail that survives contact with a buyer who already uses the competitor, is covered in the competitive battlecard.

Handover to delivery. Whatever was shown in the demonstration becomes an expectation, and the person who set it is frequently not the person who has to meet it. A written record of what was demonstrated, and what was described as a project, is the cheapest artefact on this list and the one most often absent.

Does a company need the seat at all

Three tests decide it, and none of them is company size.

Does the buyer's own technical staff have to approve the purchase. Where a security review, an architecture review or an integration test stands between the deal and the signature, the work exists whether or not a seat exists to do it. Without a seat, it lands on the account executive, on an engineer borrowed from delivery, or on a founder.

Does the product require configuration decisions before it is useful. A product with one obvious setup does not need a solution designer. A product with a data model the buyer has to map into needs one, and the mapping conversation is presales work even when the title does not exist.

Is the same technical question being answered from scratch every deal. That is the signal that the work exists and is being done badly, and it is also the argument for a demo library or an interactive demo before it is an argument for a headcount. What that category of tooling actually is, and what it costs, is read off the vendors' own pages in Navattic pricing.

Does this company need a presales seat

• ~Depends: A security or architecture review stands between the deal and the signature
• ~Depends: The product needs configuration decisions before it produces value
• ~Depends: The same technical question is answered from scratch in most deals
• ~Depends: Proofs of concept are being agreed to without written success criteria
• ~Depends: Deals sit in the forecast because nobody is allowed to call them technically dead
• ~Depends: Implementation regularly discovers a promise made during the demonstration

The handoff, and where the value leaks

The reason to separate the seats is specialisation. Establishing that a product fits and establishing that a buyer will pay need different work, run on different clocks and fail in different ways, and one person doing both will do the urgent half.

The reason the arrangement disappoints is the boundary between them, and the failure has the same shape as the one between the seat that creates conversations and the seat that closes them, which the BDR seat entry works through. A technical session happens, the deal stalls, and afterwards the two people disagree about whether it should have happened at that depth. One points at the pipeline stage. The other points at the questions the buyer was not yet asking. Both are describing the same session.

What is missing is a written standard agreed before anybody was measured against it: what has to be true for the technical seat to engage, what it is entitled to ask for, and what it is allowed to conclude. The same document answers the disqualification question, which is why writing it is worth more than any amount of process around scheduling.

The broader version of that argument, applied to two operations functions rather than two selling ones, is in RevOps against sales ops, and the pattern is identical: the definition everybody agrees on settles nothing, and the authority to decline is what actually separates the seats.

Where outbound sits against both

An outbound programme lives entirely before either of these seats is doing its real work. Its job is to produce a first conversation with somebody who has the problem, at a company where the problem is worth solving. Presales arrives later, and a well designed programme keeps it that way, because technical depth spent on a conversation that has not been qualified is the most expensive kind of waste in this whole arrangement.

RevenueFlow runs cold email and LinkedIn outbound rather than technical presales. The relevance of this page to that work is upstream: the qualification standard that decides when an outbound conversation becomes an opportunity is the same class of document as the standard that decides when a technical seat engages, and companies that have written the second usually find the first easier to agree.

The short version

Sales owns the commercial outcome and is measured on closed revenue. Presales owns the technical case and is measured on the technical win, which is a real event in the buyer's organisation rather than a stage in a system. The boundary between them is the first moment a buyer's question requires opening the product, and where a company draws that line decides almost everything else.

Four decisions need an owner in writing: which deals get technical attention, what the demo is allowed to claim, when a proof of concept is warranted, and who may call a deal technically dead. The last one is the one usually left unassigned and the one that costs the most.

If the constraint is upstream of all of it, and the technical seat is idle because there are not enough qualified conversations to work on, that is an outbound problem before it is an organisational one. We will build the first campaign against your own segment, priced per qualified meeting against criteria agreed in writing before anything sends.