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.

Presales vs sales: what is the difference?

The difference between presales and sales is what each one owns. Sales owns the commercial outcome, which means which deals get time, the negotiation and the forecast, and it is measured on closed revenue. Presales owns the technical case for the same deal, which means technical discovery, solution design, the demo and any proof of concept, and it is measured on the technical win.

The word is spelled both ways, presales and pre-sales, and the hyphen changes nothing about the job. The US Bureau of Labor Statistics files the seat under the title sales engineer and describes the work as selling "business products or services, such as software or support, that require technical expertise". Two lines of its duty list describe the boundary from the presales side: sales engineers "Talk with customers, the sales team, and engineers to determine product needs and system requirements" and "Work with sales teams to secure and renew orders". The BLS Occupational Outlook Handbook page counts 51,600 sales engineer jobs in 2025 and gives a median annual wage of $124,900 in May 2025.

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. It fails on qualification and on the buying group. 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 names vary with region and industry habit more than with the job. It is measured on something harder to state cleanly, which is why the seat is easy to misdesign. 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. The seat fails on scoping, and on promises made to win a moment.

	Sales	Presales
Owns	The commercial relationship and the outcome	The technical case for the same deal
Measured on	Closed revenue	The technical win
Fails on	Qualification and the buying group	Scoping, and promises made to win a moment
Contested	Who runs the demo, who decides a proof of concept is warranted, who can disqualify on technical grounds, who answers the security questionnaire

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.

In a deal that runs in that order, sales opens the first conversation and establishes that there is a problem worth a meeting. Discovery states the problem in the buyer's own terms, and whether presales is in the room for it is the single biggest design choice in the arrangement. The demonstration shows the product against that specific problem, and presales owns what the environment is allowed to claim. The buyer's own people then test the claim through a questionnaire, an architecture review or a proof of concept. Sales returns to the front for price, terms and the signature, and at handover whatever was promised in the demonstration becomes somebody's implementation problem.

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 gets 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 easiest to leave 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. A measure that works is win rate within the deals the seat 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 easiest to skip.

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.

1

Does the buyer's technical staff have to approve?

A security review, an architecture review or an integration test between the deal and the signature means the work exists, seat or no seat.

2

Does the product need configuration first?

A data model the buyer has to map into needs a solution designer, whatever the title.

3

Is the same question answered from scratch every deal?

The work exists and is being done badly; a demo library or an interactive demo comes before a headcount.

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 easiest to leave 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.