How Many Deals Can One Sales Engineer Actually Support?
The short version
There is no industry number, and the ratios that circulate — one SE per two or three AEs — describe someone else’s product, deal size and sales motion. The useful answer comes from your own data: how many technically-evaluated deals a single engineer can carry at your average technical intensity, which is a number you can calculate this week.
The question arrives from finance, usually phrased as a benchmark request, and answering it with a benchmark is how technical sales teams end up staffed to somebody else’s business.
Why published ratios do not transfer
Three variables dominate SE load, and they vary more between companies than the ratios do:
- Technical intensity per deal. A product that requires an architecture review, a security questionnaire and a four-week POC is a different job from one that requires a good demo. The same headline ratio describes both.
- How much of the work repeats. If most requirements and questionnaire items recur across deals, effective capacity is far higher than raw hours suggest — provided the reuse is actually accessible.
- What else the SE owns. Enablement, partner support, escalations, answering product questions in Slack. This routinely consumes a third of the week and appears in no capacity model.
A calculation you can do this week
Not a formula to adopt — a procedure to run against your own last quarter:
1. Measure the unit of work
For ten recent evaluated deals, estimate SE hours end to end: discovery, demo, RFP or questionnaire, POC, follow-up. Ten is enough to see the distribution, which matters more than the mean.
2. Find the shape, not the average
Technical intensity is almost never normally distributed. A few deals consume multiples of the median. Staffing to the mean guarantees the tail lands as overtime.
3. Subtract the non-deal week
Enablement, internal support, training, hiring. Measure it for two weeks rather than estimating it — the estimate is always low.
4. Divide, then hold capacity back
Available deal hours over median deal hours gives a theoretical load. Run at meaningfully less than that: a fully-loaded SE team has no slack for the large deal that arrives unannounced.
The number that actually matters
Not deals per SE — concurrent deals per SE. Presales load is about simultaneity, not throughput. Six deals spread over a quarter is comfortable; six deals in the same fortnight, each expecting responsiveness, is the condition that produces both burnout and quality loss.
Why the answer changes when reuse works
Capacity is not fixed. The share of an evaluation that is genuinely novel is usually smaller than it feels, because the same requirements and the same objections recur. Whether that repetition costs full price depends entirely on whether previous answers are findable — which is why knowledge that lives in individuals functions as a capacity constraint rather than a documentation problem.
It also means a capacity answer computed before fixing reuse will understate what the team could carry. Fix the queue first: the constraints are usually upstream of the SE’s hours.
What to bring to the staffing conversation
Three numbers beat any benchmark: median SE hours per evaluated deal, the ratio of the 90th percentile to the median, and current concurrent load per engineer. Together they answer the real question, which is not “how many can one SE support” but “what happens to our technical win rate at the load we are running.”
That framing also moves the conversation from cost to outcome, which is where technical win rate does the arguing for you.
Related reading
Run the ten-deal calculation
Ten recent evaluated deals and two weeks of honest non-deal time give you a defensible number. WinIQ tracks SE load and skills against live opportunities if you want it maintained rather than recalculated.
Request a Demo