In Consensus's 2026 Sales Engineering Compensation & Workload Report, the most common setup was one sales engineer for every three to five account executives, reported by roughly 40% of respondents. So every hour your SE spends on one of your calls is an hour two to four other reps can't have. So save that hour for the moment your own knowledge runs out. Knowing when to bring in a sales engineer starts with knowing which calls you can run alone.

Calls that are yours

Early discovery is the rep's job. You're finding out who owns the problem and what it's costing them. You're also mapping what they use today. And somewhere in those first calls you need to learn who signs, and by when.

An SE on that call mostly listens and waits for a technical question that may never come.

Run the overview demo yourself unless the buyer has already told you their setup is unusual, or a technical evaluator is joining. Standard functionality, shown to a business buyer, doesn't need an SE, and SEs who spend their week on generic demos have less time for the deals that need them.

First-line technical questions are also yours. "Do you have SSO?" "Is there an API?" "Can we see your SOC 2 report?" You should be able to answer these from your enablement material. Our posts on SOC 2 questions and explaining APIs cover how far your answer can go before it's someone else's.

When to pull them in, most urgent first

Bring in the SE immediately when your answer would change what the buyer builds. Take field mapping: if you say a custom field will sync and it won't, someone on their side has already planned work around it. The same goes for error handling and for how the product behaves with their identity provider. A guess there costs the buyer real work later, and costs you the deal when they find out.

A proof of concept comes next. Before anyone agrees to start one, the SE should help write the success criteria. They should also settle where the test runs and put an end date on it. Without those, a POC can drift for weeks with no clear point at which the buyer says yes.

When an architect, IT lead or developer gets added to the invite, treat it as a request for your SE even if nobody said so. That person is there to test whether your product holds up, and they'll want someone who can answer on the spot.

Custom demos and competitive comparisons belong to the SE as well. If the buyer wants to see their own workflow, or says another vendor "does this natively," you need the person who knows how the product behaves in detail. Improvising a custom demo in a shared sandbox is how reps end up watching a broken environment load live on screen.

Making the request

Most teams route SE requests through a field on the CRM opportunity, a request form, or a dedicated Slack channel. Some assign SEs to a pod of AEs. In any of those setups, write the request so the SE doesn't have to come back to you with questions.

Hold a ten-minute prep before the meeting. Agree who opens, which questions go to whom, and how you'll hand back to each other. On the call, you keep time and steer toward business outcomes; the SE handles depth. Write the recap email yourself afterwards, and get the SE to check the technical lines.

Example request:

Northwind Freight, Head of RevOps (champion) + their Salesforce admin joining. Problem: reps re-type call notes into Salesforce; they want it automatic. Stack: Salesforce, Outreach, Gong. Shown so far: overview demo on call 2. Said we have a native Salesforce integration; did not commit to custom objects. Open questions: can we write to a custom object? How do we respect their field-level security? Goal: admin confirms fit so they agree to a pilot. Thursday 15:00 UK, 45 min. Prep Wednesday?