Sales engineer: what the job involves, what it pays and how to do it well

This guide is for engineers and other technical people considering sales engineering, new SEs, and the account executives and managers who work with them. It covers the job across a deal, how SEs are measured, federal pay data, a worked example of SE capacity, and templates for the two documents that matter most: the demo plan and the proof of concept success criteria.

What a sales engineer does

The Bureau of Labor Statistics (BLS) defines sales engineers (SOC 41-9031) as workers who "sell business goods or services, the selling of which requires a technical background equivalent to a baccalaureate degree in engineering." In practice, the SE is the person on a sales team who can answer "will this actually work for us?" with authority.

Companies use several titles for much the same job: sales engineer, solutions engineer, solutions consultant, presales engineer and presales consultant. The BLS lists the core duties as:

• Preparing and delivering presentations that explain technical products to customers
• Working out product needs and system requirements with customers, the sales team and engineers
• Planning or modifying products and services to meet customer needs
• Arranging installation and delivery, and helping customers troubleshoot problems
• Recommending improvements that lower costs or raise output

The job isn't only about software. In 2025, the BLS counted the largest employers of sales engineers as durable goods merchant wholesalers (22%), manufacturing (21%), computer systems design (18%), software publishers (6%) and wholesale trade agents and brokers (5%).

A deal from the SE's side

1. Technical discovery. Learn the buyer's current systems, data, integrations and constraints, and who signs off technically.
2. Tailored demo. Show the three or four workflows that matter to this buyer, in their terms, with their kind of data.
3. Questionnaires and RFPs. Answer security reviews, architecture questions and the technical sections of formal requests.
4. Proof of concept (POC). When it's needed, prove one or two specific capabilities against criteria agreed in writing.
5. Technical close. Get the buyer's technical evaluator to confirm the product meets their requirements, ideally in writing.
6. Handoff. Brief the implementation team on what was promised, what was shown and any workarounds.

How sales engineers are measured

SE metrics vary more than AE metrics, and few reliable public benchmarks exist, so treat these as measures to agree with your manager rather than targets:

How SEs and AEs split the work

The BLS notes that some sales engineers team with other salespeople, which lets the SE concentrate on the technical side. How many AEs one SE can support depends on how many evaluations each SE can run, as the worked example below shows. The account executive guide covers the deal from the commercial side.

Pay and job outlook

BLS Occupational Employment and Wage Statistics (OEWS) for SOC 41-9031, May 2025, covering about 51,790 jobs:

Pay depends heavily on what you sell. Median annual wages in the industries that employ the most SEs, May 2025:

These figures include commissions and production bonuses but not overtime, nonproduction bonuses or benefits, and they leave out the self-employed. The BLS says employers usually pay sales engineers a combination of salary and commission or salary plus bonuses.

The BLS projects employment of sales engineers to grow 3% from 2025 to 2035, about as fast as average, with about 3,800 openings a year, most of them replacing people who move to other jobs or retire. The typical entry route is a bachelor's degree in engineering or a related field, though candidates without a degree sometimes qualify with sales and technical experience. The BLS notes that SEs who sell software may have worked as software developers or computer systems analysts first.

Worked example: how many deals can one SE support?

Illustrative example. The company and hours are invented to show the arithmetic.

Ledgerline (ledgerline.example), a mid-market ERP vendor, has 12 AEs and 4 SEs. A typical evaluation takes this much SE time:

An SE has about 480 working hours a quarter (12 weeks × 40), but only around 60% goes on live deals after internal meetings, training, travel and early calls that go nowhere: 288 hours. That's 288 ÷ 37 = 7.8 evaluations a quarter per SE, or about 31 for the team.

Each AE starts 4 evaluations a quarter, so 12 AEs need 48. The team is 17 short. The options, cheapest first:

• Qualify POCs harder. Agree success criteria up front and run a POC in one evaluation in five instead of one in three. POC time per evaluation falls to 9 hours, the total to 31, and capacity rises to 288 ÷ 31 = 9.3 per SE, 37 for the team.
• Reuse demo builds. A standard manufacturing demo cuts build time from 10 hours to 5. The total falls to 26 hours, and capacity rises to 11 per SE, 44 for the team.
• Hire a fifth SE. At 11 evaluations each, five SEs cover 55, more than the 48 needed.

SE capacity is a planning number, and qualifying before a POC is the cheapest capacity you can buy.

Templates for the two documents that matter

Account: [company]
Attendees and what each cares about: [name, role, concern]
The business problem in their words: [quote from discovery]

Three workflows to show:
1. [workflow], because [discovery finding]
2.
3.

What we won't show: [features that would distract]
Their data or scenario: [e.g. a stock transfer between two plants]
Proof point: [customer example we're allowed to name]
Technical questions we expect: [list]
Ask at the end: [a specific next step]

Account: [company]    POC dates: [start] to [end]
Why the buyer needs a POC: [what they must be sure of]

Success criteria (each testable, agreed in writing):
1. [e.g. Import 12 months of item master data with manual fixes on under 2% of records]
2. [e.g. Run material requirements planning for 3 plants in under 30 minutes]
3.

Out of scope: [what we won't test]
Buyer's resources: [names, hours a week, data delivered by (date)]
Our resources: [SE, support engineer]
Decision: if criteria 1 to 3 pass, [buyer name] will [recommend purchase / move to contract] by [date].
Signed off by: [buyer], [SE], [AE]

How to do the job well

• Discover before you demo. Prepare by reading what the account has said publicly about its systems and plans; Bebop researches each account and writes a playbook with recent events and the people involved, a useful starting point to check.
• Demo their problem, not your product. Three workflows that matter beat twenty features.
• Say no clearly. When the product doesn't fit, saying so protects your credibility on the next deal.
• Refuse open-ended trials. No POC without signed success criteria, an end date and a decision.
• Build a library. Answered security questionnaires, demo environments by industry and architecture diagrams save hours on every deal.
• Prepare for the competition. Keep technical comparisons current in your battlecards.

Common mistakes

• Running the full product tour because discovery was skipped.
• Agreeing to a POC without criteria, an end date or a named decision maker.
• Answering questions the buyer didn't ask and raising new concerns.
• Promising roadmap features to win the technical stage.
• Leaving implementation to rediscover what was promised.

Self-check before a technical evaluation

• You can state the buyer's business problem in their words.
• You know who signs off technically and what they're worried about.
• The demo plan is agreed with the AE and fits on one page.
• Any POC has written success criteria, an end date and a decision attached.
• You know which requirements you can't meet and have said so.

Next step: see how the commercial side of the deal works in the account executive guide.