How many sales engineers does a 30-person SaaS need?

There is no right number, and any ratio you read is a guess about someone else's company. The number for your team comes from three inputs you can measure: the sales engineer hours your deals demand each quarter, the hours an SE really has for deal work, and how much of that demand is the same first demo given again. Divide the first by the second and you have a headcount. The third tells you whether the answer is a hire or a change in who does what.

This post runs that arithmetic on round, illustrative numbers (not a benchmark, and not a description of your company), then covers the signs the SE is already the bottleneck and the four ways out, including when hiring is simply right. For why the pinch appears in the first place, read the sales engineer bottleneck. This one is about sizing.

How do you size a sales engineer team from your own numbers?

Work in hours, not ratios. Four steps, and a spreadsheet is enough.

1. List last quarter's deals that needed a technical conversation and sort them into types. Three is plenty: first demos, technical deep dives, and heavy work such as security reviews or custom environments.
2. Estimate the hours per deal for each type, end to end. Preparation, the call, follow-up questions and any environment work. Ask the SE, then check the estimate against five or ten real calendars. Estimates run low.
3. Work out usable SE hours. Take a real week and subtract internal meetings, enablement, product syncs and the questions colleagues ask in chat. What is left is deal time. Trust the calendar, not the job description.
4. Divide demand by usable hours, and hold some back. Demand that equals capacity on paper is a queue in practice, because requests arrive in bursts. How much to hold back is a judgment call. A reasonable start is a quarter of capacity, adjusted once you see how lumpy the pipeline is.

Then run it again on next quarter's pipeline, not last quarter's. A hire you make now works against the pipeline you are building now.

What does that look like with real numbers?

Here is a made-up example. Every figure is illustrative, not a benchmark, and yours will differ. A 30-person SaaS has one SE. Last quarter's demand looked like this.

• First demos: 60 deals at 1.5 hours each, which is 90 hours.
• Technical deep dives: 20 deals at 5 hours each, which is 100 hours.
• Heavy work (security reviews, custom environments): 6 deals at 8 hours each, which is 48 hours.

That is 238 hours of demand. Now supply. The quarter has 13 weeks. Take off 2 for leave and holidays and 11 remain. If the SE has 20 hours a week for deal work after internal commitments (again illustrative), that is 220 hours. Demand is 238 and capacity is 220, so the SE is 18 hours short before any buffer. Hold back a quarter of capacity for bursts and the usable figure is 165 hours, which puts demand 73 hours over. One SE cannot cover this, however hard they work.

Headcount is 238 divided by 165, about 1.4. The example needs a second person, or needs some of that demand to land somewhere else. Now look at the mix. The 90 hours of first demos are the only slice that is the same conversation repeated. Suppose, hypothetically, they moved off the SE calendar entirely. Demand falls to 148 hours, which fits inside 165, and the one SE copes. No approach moves all of it, and your real share is something you have to measure. The point is that the mix matters as much as the total.

Now double the pipeline. Demand becomes 476 hours, and 476 divided by 165 is about 2.9, so three SEs. If the first-demo slice were handled elsewhere, demand is 296 hours, and 296 divided by 165 is about 1.8, so two. Same company, same growth, a headcount of three or two depending on who delivers the repeat work. That one-person gap is the decision this post is about.

One caveat: hours per deal do not scale in a straight line. Larger deals bring heavier work, so a move upmarket makes the third row grow faster than the deal count.

How do you know the SE is already the bottleneck?

If your calculation says demand is over capacity, the calendar should agree. Three checks, each answerable from data you already have.

• Queue time. Measure the gap between a demo being requested and it happening, using CRM or booking timestamps. If it is growing, the SE has become a queue.
• Where the hours go. Tally one fortnight of the SE's calendar by type. If most of it is first demos, you have a distribution problem and senior capacity is covering for it. If most of it is deep technical work, you have a headcount problem.
• Stalled deals. Read the notes on deals that went quiet mid-funnel and count the ones waiting for SE availability. Nobody logs "lost because the demo was weeks out", so you have to go looking.

Any one of these can have another cause. Two or three together, plus an over-capacity result in your own arithmetic, is a bottleneck.

What are your options when demand is over capacity?

Four, and they combine. None is free.

Hire another SE

A hire adds capacity for every kind of work, including the kinds nothing else touches. The costs are real. It is a fixed cost against a pipeline that may move, and a hire takes time to find and time to learn your product, so the relief arrives after the queue does. If most of what the new person does is repeat first demos, you have bought an expensive way to give the same walkthrough.

Tier the demo work

Decide in writing which questions an AE answers alone, which go to the SE and what triggers the handoff. It costs only discipline, and it works when the repeat work is simple enough for a prepared AE. The failure mode is an AE who half knows an answer and gives it with confidence, so keep the list short and make escalating socially cheap.

Give buyers a recorded or interactive demo

This moves the standard walkthrough off the calendar: buyers watch or click through on their own time. It works for the question you predicted. The question you did not predict sends that buyer back to booking a call. It also goes stale after each release, so someone has to own the upkeep.

Put an AI demo agent on first-line demos

An agent talks with the visitor, asks what they are trying to do, walks them through the relevant part of the product, answers questions in the moment and leaves a record of what they asked and explored. Repeat questions get answered without an SE slot, and the SE who joins later starts from that record. The tradeoffs: it is only as good as the product material and approved messaging it works from, someone has to keep that accurate after releases, and it does not belong in architecture reviews, security conversations or custom evaluations. Draw that boundary before you switch it on.

When is hiring simply the right answer?

When the work only an SE can do is itself over capacity. Run your calculation with the first-demo row removed. If the deep dives and heavy work alone still exceed usable hours, nothing upstream fixes it. Tiering, recordings and agents all shrink the repeat row. None of them shrinks a security review or an architecture discussion.

Hire early in two other cases. One is a move upmarket, where the heavy row grows faster than the deal count and a new SE needs time to ramp, so the hire belongs ahead of the shift, not after the first enterprise deal stalls. The other is a single SE who holds all the knowledge of the product's hard edges, because one person is a single point of failure whatever the arithmetic says. If your repeat row turns out to be small, hire, and do not let anyone talk you out of it, including us.

Where does Inkly fit?

Inkly is the AI demo agent that turns website visitors into buyers. It qualifies the visitor, guides them through the product live, answers questions in context and hands buyer intelligence to sales, so the SE who joins already knows what the visitor saw and asked. Its job is the repeat row in the example above. It does not replace SEs for complex evaluations, and it does nothing for the heavy row. See how it works and how solutions engineering teams use it.

Plans are priced by active visitors, where one person counts once a month. Free covers 30 visitors a month, enough to try it on your own product. The pricing page has the rest.

FAQ

Is there a standard ratio of AEs to sales engineers?

No. Ratios depend on product complexity, deal size, how technical your buyers are and how much of the product they can see without a person present. A ratio borrowed from another company imports their numbers, not yours. Use the hours method above.

When should a 30-person SaaS hire its first sales engineer?

When technical conversations are taking real founder or AE time and deals are waiting on them. Run the calculation: if the work that needs deep product knowledge alone fills most of a person's usable hours, hire. If it is mostly repeat first demos, try tiering or a recorded or interactive demo first.

Can an AI demo agent replace a sales engineer?

No. It can take on repeat first-line demo questions so SE time goes to technical deep dives. Architecture reviews, security conversations and custom evaluations still need a person who can be accountable for the answer.

How many hours does a typical deal take from a sales engineer?

There is no typical deal. Sort last quarter's deals into types, ask the SE for hours on each and check against a few calendars. Your own numbers beat anyone's average.

What should you do this week?

Pull last quarter's deals that needed a technical conversation, sort them into three types, estimate the hours for each and set the total against the SE's real calendar. That is an afternoon, and it replaces a ratio with a number you can defend to finance. Then split the total in two: hours only an SE can do, and hours that are the same demo repeated. The first is your hiring case. The second is where the other options go to work.

If you are an SE with a growing queue of first calls, see how solutions engineers use Inkly.