Sales Engineer: The Role and How to Document Technical Meetings

Picture Elena, a sales engineer at a pump manufacturer, in a customer's conference room on a Wednesday afternoon. The process engineer says the new line needs 450 gallons a minute at 180 degrees, with about 2% solids. Elena is sketching the piping on the whiteboard, so her notebook gets "450 @ 180".

Two weeks later the applications engineer sizes the seals for 180 degrees Fahrenheit. The plant is European-owned and runs its process sheets in Celsius. The quote is wrong, the re-quote takes three weeks, and the customer's buyer starts returning a competitor's calls.

Elena knew her pumps. What failed was the record of the meeting.

If you searched "sales engineer" to understand the job, the first half of this guide covers it from primary sources: the role, the work, the skills, and the pay. If you already do the job, the second half is for you. It's a way to document technical meetings so specs, units, and promises survive the trip from the customer's conference room to the quote.

Want the template first? Skip to the nine-field technical meeting record below. And if you'd rather talk than type, you can try ParrotNotes free and dictate the record on the drive back.

What is a sales engineer?

A sales engineer is a technical specialist who sells products that need engineering knowledge to specify, such as pumps, conveyors, machine tools, control systems, or software. They work beside an account manager, translate the customer's technical problem into a product configuration, and carry the requirements back to their own engineering team.

The U.S. Bureau of Labor Statistics puts it in one line in its Occupational Outlook Handbook entry for sales engineers: they "sell business products or services, such as software or support, that require technical expertise."

You'll see the same job under other titles: applications engineer, technical sales engineer, solutions engineer, presales engineer, and field sales engineer.

Where sales engineers work

Most articles about the role are written for software presales. The BLS numbers tell a broader story. Durable-goods wholesalers employ 22% of sales engineers and manufacturing employs 21%, ahead of computer systems design at 18% and software publishers at 6%.

So a sales engineer is as likely to be standing on a plant floor in steel-toe boots as sharing a screen. The customer's questions are about flow rates, tolerances, and floor space, and the answers end up in an RFQ response.

Sales engineer vs account manager

The account manager owns the relationship, the commercial terms, and the forecast. The sales engineer owns the technical truth: whether the product fits, what has to change, and what it'll take to install.

That split decides who writes what down. The account manager tracks budget, timing, and who signs, which is the ground a BANT qualification guide covers. The sales engineer tracks requirements, constraints, and every technical promise made across the table.

What does a sales engineer do all day?

The BLS lists the duties plainly. Sales engineers deliver technical presentations, and they "talk with customers, the sales team, and engineers to determine product needs and system requirements." They also help secure orders, arrange installation, modify products to fit, and help customers troubleshoot.

Put in the order a deal runs, the work looks like this:

1. Discovery. Visit the site, walk the process, and find out what the customer is trying to fix.
2. Requirements. Pin down the numbers: rates, loads, temperatures, materials, utilities, space, and standards.
3. Solution. Configure or modify the product, with help from applications engineering.
4. Proof. Run the demonstration, the trial, the sample, or the customer's visit to your plant. (Hosting one soon? Our manufacturing plant tour run sheet covers it.)
5. Proposal. Write the technical half of the quote or RFQ response.
6. Handover. Brief the installation and service teams, then stay close during startup.

O*NET, the U.S. Department of Labor's occupation database, adds a task the career guides skip. Its task list for sales engineers includes "Document account activities, generate reports, and keep records of business transactions with customers and suppliers." Record keeping is in the sales engineer job description.

Sales engineer skills and how people get into the role

The BLS names six qualities for the occupation: analytical skills, business skills, initiative, interpersonal skills, organizational skills, and persuasion. On organization, it says sales engineers need it "to manage multiple projects and customers." Picture supporting four account managers and 20 open opportunities, each with its own drawings, revisions, and open questions.

On entry, the BLS says the typical requirement is a bachelor's degree in engineering or a related field, followed by on-the-job training in sales technique and product detail.

People arrive from two directions: engineers who like customers, and salespeople with deep product knowledge. Both groups get trained on products and selling. Almost nobody gets trained on how to take notes in a technical meeting.

Sales engineer salary and job outlook

Here's what the BLS reports. These figures come from its sales engineer page, last modified August 27, 2026.

The median annual wage for sales engineers was $124,900 in May 2025. The lowest 10% earned less than $73,870, and the highest 10% earned more than $195,270.

Pay depends heavily on the industry:

The BLS adds that employers pay sales engineers "using a combination of salary and commissions or salary plus bonuses," so the mix matters as much as the headline number. Ask about it in any interview.

On outlook, sales engineers held about 51,600 jobs in 2025. Employment is projected to grow 3% from 2025 to 2035, about as fast as the average for all occupations, with about 3,800 openings a year. The BLS also notes that travel can mean days away from home each month.

The skill nobody trains: documenting technical meetings

Go back to the BLS duty: talk with customers, the sales team, and engineers to determine requirements. A sales engineer is the only person in all three conversations. If the record is thin, three groups work from three different memories.

Technical meetings are harder to document than a regular sales call, for four reasons.

You're presenting. The person who understands the numbers is at the whiteboard, notebook closed.

Numbers travel without their units. "180" means nothing without Fahrenheit or Celsius. The same goes for psi and bar, inches and millimeters, and 50 and 60 hertz.

Promises are verbal. "We can hold that tolerance" is a commitment the customer writes down, even when you don't.

The cycle is long. A capital equipment deal can run past a year. The customer's engineer may change jobs in month five, and the new one will ask what was agreed.

A structured record fixes most of this, and it doesn't need to be long.

Doing this on your next site visit? Download ParrotNotes free, talk through the nine fields below when the meeting ends, and you'll get a transcript, an AI summary, and action items from the recording. The free plan includes 100 minutes of recording a month, up to 30 minutes per recording.

What to capture: the technical meeting record

This is the record. Nine fields, one page. Copy it into your notes app, your CRM's notes field, or a pocket card.

1. Meeting basics. Customer, site, date, project or RFQ number, and everyone in the room with their job title.
2. Application. What the customer is trying to do, in their words, and what's wrong with how they do it now.
3. Requirements, with units. Every number that was spoken, its unit, and who said it. Rates, loads, dimensions, temperatures, pressures, materials, voltages, and standards.
4. Constraints. Floor space, utilities, the shutdown window, existing equipment you have to connect to, site rules, and approved-vendor lists.
5. Assumptions. Anything you filled in yourself because nobody knew. Mark each one so it gets confirmed instead of quietly becoming a spec.
6. Open questions. What nobody could answer, and who is finding out, on each side.
7. Promises. What your side committed to and what the customer committed to, each with an owner and a date.
8. Decision and competition. Who approves the spend, the budget process, the timeline, and any other supplier or approach that came up.
9. Next step. The agreed next meeting or milestone, with a date.

Field 3 carries the quote, so never write a bare number. "450 gpm at 180 °C, 2% solids, per the process engineer" takes four more seconds than "450 @ 180" and saves a re-quote.

Field 5 is the one people skip. An assumption you don't label turns into a spec the customer never gave you.

Field 8 is where the account manager's notes and yours meet. If the room holds a plant engineer, a maintenance supervisor, and a buyer, write down what each one cared about. Our stakeholder mapping template shows how to turn those names into a map of the buying group.

A worked example: conveyor retrofit meeting

Here's the record filled in for an illustrative meeting. The company and people are fictional.

1. Basics. Ridgeline Foods, Plant 2, packaging line 3. September 14. RFQ 2291. Present: Marta Ilves (plant engineer), Dev Anand (maintenance supervisor), Carol Whit (purchasing), plus the sales engineer and the account manager.

2. Application. Replace 42 feet of case conveyor between the case sealer and the palletizer. Today's line jams at the merge and caps the line at 40 cases a minute.

3. Requirements. Target 55 cases per minute (Marta). Case size 16 x 12 x 10 inches. Case weight 35 lb average, 52 lb maximum (Dev). Power 480 V, three-phase, 60 Hz. Ambient 38 °F, because the run passes through the cold room.

4. Constraints. Building column 18 feet from the sealer. Install only during the shutdown, December 21 to January 3. Must connect to the existing palletizer infeed.

5. Assumptions. No washdown in this zone. Floor loading is adequate. Both unconfirmed.

6. Open questions. Who owns controls integration, their integrator or us? Marta to confirm by September 21. Floor loading drawings: Dev to send.

7. Promises. Ours: layout sketch by October 2 (sales engineer), budget price by October 9 (account manager). Theirs: CAD of the area by September 28 (Marta).

8. Decision and competition. Capital request goes to the November committee. Under $250,000, the plant manager signs. Their current integrator has already quoted a like-for-like replacement.

9. Next step. Layout review call, October 5, 10:00 AM.

Read it as the applications engineer would. There's nothing to re-ask, the two assumptions are flagged, and the 52-pound case carries the name of the person who supplied it.

How to take notes when you're the one presenting

You can't write and whiteboard at the same time. So move the note-taking to the moments when you can: before the meeting, at checkpoints during it, and in the first minutes after it.

Before: send the questions ahead

Two days before the visit, email the customer the requirements you'll need: rates, product dimensions and weights, utilities, space, and standards. Ask them to bring drawings. Half the numbers then arrive in writing, from the person who owns them.

Agree roles with your account manager too. When you're presenting, they write. When they're talking commercial terms, you write.

During: read the numbers back

Stop at natural breaks and read the numbers back aloud. It feels slow, and it's the cheapest error check in the sales cycle.

The read-back script

• "Let me read that back so I have it right."
• "[Number], in [unit], measured at [where or when]. Is that your normal figure or your worst case?"
• "Who should I credit that number to, in case our applications team has a question?"
• "I'm assuming [assumption]. Can anyone here confirm that, or should I mark it as open?"
• "I don't want to guess at that one. Let me park it, and I'll come back to you by [date]."

Picture Tomás, the sales engineer in that Ridgeline meeting. Near the end he reads back, "55 cases a minute, 35-pound cases, 480-volt three-phase. Right?"

The maintenance supervisor shakes his head. "35 is the average. The heaviest case on that line is 52 pounds."

That correction changes the motor sizing. It took 10 seconds, and it happened because the numbers were said aloud in front of the person who knew better.

The parking line matters as much. "Let me park it" protects the quote, and it gives you a reason to follow up.

Recording a technical meeting: ask first

A recording is the most complete record you can have. Ask before you start: "Do you mind if I record this so we get your requirements right?" If anyone says no, take notes instead.

The law on recording conversations varies by place. In the United States, federal law permits recording when one party to the conversation consents (18 U.S.C. § 2511(2)(d)).

Some states go further: California Penal Code § 632 covers recording a confidential communication without the consent of all parties. Other countries have their own rules. This isn't legal advice, so the safe habit is simple: ask everyone, every time, and say so at the start of the recording.

Consent law isn't the only limit. Check your NDA, follow the site's phone policy, and if the project involves export-controlled technical data, talk to your compliance officer before you record anything. When recording isn't allowed, the voice debrief below still works.

After: the three-minute voice debrief

The next meeting will overwrite this one in your memory. So before you start the car, open ParrotNotes, hit record, and talk through the nine fields. Recording continues with the screen off, so you can set the phone down and speak.

The three-minute debrief script

• "Technical meeting at [customer, site], [date], about [project]. In the room: [names and titles]."
• "They're trying to [application]. The problem today is [problem]."
• "Requirements: [each number, with its unit, and who gave it]."
• "Constraints: [space, utilities, shutdown window, existing equipment]."
• "I'm assuming [assumptions]. Still open: [questions], and [name] is finding out."
• "We promised [what, who, by when]. They promised [what, who, by when]."
• "Decision: [who approves, process, timing]. Also in the picture: [competitors]."
• "Next step: [what, date]."

ParrotNotes turns that recording into a transcript, an AI summary, and a list of action items. It can also draft the follow-up email from what you said, so you're editing instead of starting from a blank page.

Every note is searchable by keyword, which matters in month seven. On ParrotNotes Pro you can ask a recording questions with AI chat, such as "What did we promise on lead time?" Pro also includes custom insight templates, so a template of your own can follow the nine fields.

Pro transcribes in 99+ languages and can translate, so a requirements discussion held in Spanish or German still produces notes your applications team can read. Pro is $19.99 a month, or $14.99 a month billed annually, with 3,000 recording minutes a month and recordings up to 3 hours. Technical meetings carry confidential specs, so you may want to read how we protect your data first.

Then: hand the record off within 24 hours

The record has three readers, and each one needs a different cut of it.

The customer gets a confirmation email within 24 hours. List the requirements with units, the assumptions you need confirmed, the open questions with owners, and both sides' promises with dates. Ask them to reply with corrections. Our guide on how to never miss action items from sales calls covers the follow-up habit in more depth.

Applications engineering or estimating gets fields 2 through 6 in full. Paste the numbers with units and sources, and attach the drawings.

The account manager gets fields 7 through 9, because those change the forecast and the next call.

Picture Priya, a sales engineer seven months into a packaging machinery deal. The customer's new project engineer says nobody agreed to a December installation. Priya searches her notes for "shutdown," opens the record from the first site meeting, and forwards the confirmation email his predecessor replied to. The dispute ends in five minutes.

The record is part of the sales engineer's job

A sales engineer earns their place in a deal by being right about the technical detail. The meeting record is how that detail stays right after everyone leaves the room.

The short version:

• Never write a number without its unit and the name of who gave it
• Label assumptions so they get confirmed, and park what you can't answer
• Read the numbers back aloud before the meeting ends
• Dictate a three-minute debrief before you drive away, and send the customer a confirmation within 24 hours

Think back to Elena and "450 @ 180." With a read-back, the Celsius would have been caught in the room, and the first quote would have been the right one.

Every sales engineer has a technical meeting coming up this week. Download ParrotNotes free, copy the record above, and dictate your first debrief before you leave the customer's parking lot.