How many sales engineers does a SaaS team need?
The AE-to-SE ratio everyone quotes is a symptom, not a target. Here is what actually drives it, and how to plan presales headcount without guessing.
The question usually arrives as a ratio — two AEs per SE, three, four — and the ratio is the least useful part of the answer. What drives presales headcount is how much of your sales motion requires someone who can be wrong about the product in an expensive way.
How many sales engineers do you need?
Commonly quoted ratios run between two and five AEs per SE, and the range is wide because the ratio is downstream of things that vary enormously between companies. Quoting the ratio without those inputs produces a plan that is wrong in a specific direction: teams with technical products under-hire, and teams with simple products over-hire and then wonder why presales looks unproductive.
A more useful framing: count the deals per quarter that genuinely cannot progress without a technical conversation, multiply by the hours each consumes end to end including preparation and follow-up, and divide by the hours an SE actually has for deal work — which is well under half their week once enablement, internal reviews, and answering colleagues' questions are counted.
What actually drives the ratio?
Four things. Product complexity, which sets how long a credible answer takes. Deal size, which sets how much bespoke attention is economically justified. Buyer sophistication, because a technical buyer asks questions an AE cannot field. And how much of the product a buyer can evaluate without a person present — the only one of the four you can change quickly.
That last variable is the reason two companies with similar products and similar deal sizes can need very different presales teams. If buyers can reach the product and answer their own first-order questions, the SE enters later and on a harder question. If the only path to seeing the product runs through a scheduled call, every deal consumes SE time from the first conversation.
Why is the ratio a symptom rather than a target?
Because managing to a ratio optimises the wrong variable. A team that decides it should be at three-to-one will either hire ahead of need or starve deals to hit the number, and in both cases the ratio is being treated as the goal rather than the readout. The number tells you something about how your sales motion is structured; it does not tell you what to do.
The version of the question worth asking: what fraction of SE hours goes to work only an SE can do? If that number is above about two thirds, your ratio is roughly right and more volume means more hiring. If it is well below, hiring will buy you more of the same problem, and the fix is upstream.
How do you plan presales headcount honestly?
Instrument the current state before forecasting the future one. Most teams cannot say what share of SE time goes to first demos versus deep technical work, which means headcount discussions run on anecdote and whoever is loudest about being overloaded. A month of rough time tracking, even self-reported, changes the conversation more than any benchmark.
Then plan against pipeline shape rather than pipeline size. A quarter with twice the deals but the same mix needs proportionally more SE time; a quarter that shifts upmarket needs disproportionately more, because larger deals bring security reviews and architecture questions that scale worse than the deal count suggests.
When do you genuinely need to hire?
When the work that only an SE can do is itself the constraint — deals waiting on architecture conversations, security reviews queueing, technical objections going unanswered long enough that momentum dies. That is a capacity problem with no software solution, and delaying the hire costs deals directly.
The honest caveat to everything above: a team with a complex product and no sales engineers will feel the gap on exactly the deals it most wants to win. Reducing SE load is a good goal; running without the function is not, and no tool changes that.
How do you calculate it from your own numbers?
Take last quarter's closed-won and closed-lost deals and mark the ones that involved a technical conversation. For each, estimate total SE hours including preparation, the call itself, follow-up questions, and any custom environment work. Sum, divide by the quarter, and compare against realistic SE capacity — around fifteen to twenty deal hours per week per SE once internal work is deducted.
The number that falls out is usually uncomfortable, because it reveals either that SEs are over capacity and deals are being under-served, or that a large share of hours goes to deals that were never going to close. Both are actionable; neither is visible from a ratio.
Should sales engineers be shared or dedicated?
Dedicated pairing produces better deal outcomes and worse utilisation; pooling produces the reverse. The right answer depends on deal size distribution. If a small number of large deals drives most revenue, pair SEs to those AEs and accept the idle time, because the cost of a fumbled large deal exceeds the cost of underused capacity.
If revenue is spread across many mid-sized deals, pooling with a triage step works better — but only if the triage is real. A pool without a rule for what qualifies for SE time becomes first-come-first-served, which systematically allocates your scarcest resource to whoever asks most persistently rather than to the most valuable deals.
What about hiring AEs who can demo?
It works for products a motivated generalist can learn to demo credibly, and it fails quietly for products where they cannot. The failure mode is specific and damaging: an AE who half-knows the technical answer gives a confident wrong one, and a technical buyer who catches it discounts everything else in the evaluation.
A reasonable middle path is to define, explicitly, the question types an AE handles alone and the ones that always escalate — and to make escalating socially cheap. Teams that leave the boundary implicit get AEs guessing, because guessing looks better in the moment than admitting they need to bring someone in.
How does this change as you move upmarket?
Worse than the deal count suggests. Enterprise deals bring security reviews, architecture discussions, procurement questionnaires and multiple technical stakeholders, each consuming SE time that mid-market deals do not. A team moving upmarket typically needs presales capacity to grow faster than pipeline, and plans built on the old ratio underestimate it consistently.
This is the one case where hiring genuinely is the answer and delaying it is expensive. Automation reduces the load of repetitive early-stage work; it does not sit in a security review. Plan the hire ahead of the segment shift rather than after the first enterprise deal stalls.
Related reading
Ship your next demo before the meeting starts
Interactive demos built from your real product and kept current as you ship, done for you.
