A sales engineer's CV is read by two people who want different things from it. The sales leader wants to know whether deals close when you are on the call. The technical lead wants to know whether you understand the product well enough that engineers stop getting pulled in to rescue you. Most presales CVs satisfy one of them and lose the other.
Two readers, two scans
The sales leader reads for commercial instinct. Which deals were you on, the large ones or the ones nobody else wanted? Can you sit in front of a finance director without a chaperone? They skim past your stack and stop at anything with a currency sign next to it.
The technical lead reads the other way round. They skip the revenue and look for evidence that you built something: an integration, a working proof of concept, a reference architecture that survived a customer's security review. A list of twenty product names tells them nothing. One sentence about a nasty single sign-on problem you solved tells them a lot.
So every role on the page needs at least one line for each reader. The best line works for both: a technical obstacle removed, then the deal that closed behind it. I would open each role with a commercial line and follow it with a technical one, because in most hiring processes the sales organisation holds the budget and reads first. If the hiring manager is an engineering-minded head of solutions, swap the order.
Each role needs one line a sales leader would stop on and one line a technical lead would stop on. If a role has only one kind, half your audience has nothing to read.
Supported revenue, stated honestly
This is where presales CVs go wrong most often. An account executive carries a personal quota, and how to present that is covered in our article on quota attainment on a CV. A sales engineer usually does not carry one. You are typically measured on a team number, a regional number, or an overlay target shared with the reps you support, and your CV should say so in plain words.
Writing "closed $4M in new business" when you were the technical half of a six-person pursuit is the fastest way to lose a sales leader's trust. They know how credit works, and they will ask in the interview whose number it was. The honest wording is "supported", "technical lead on", "contributed to". It sounds weaker, and it reads as someone who understands the job.
Two details make a supported number credible:
- Whose number it was. "Team quota", "overlay target for the northern region", "supported four account executives".
- Your share of the work. Were you the only sales engineer on the deal, or one of several specialists brought in for an afternoon?
Before: Closed $4.2M in enterprise deals in 2024.
After: Sole sales engineer for four account executives; team attained 108% of a $4.2M target in 2024 (illustrative figures). Technical lead on 9 of the 14 deals closed.
The second version claims less and proves more. It also answers the question before anyone asks it.
The proof that only presales has
Some numbers belong to this seat and to nobody else's. Use them, because they separate your CV from a seller's on one side and a developer's on the other.
Technical win rate is the share of opportunities where the customer accepted your solution on technical grounds, whatever happened commercially afterwards. If your company tracks it, quote it and say how it is defined. If nobody tracks it, do not rebuild a percentage from memory; give counts. "Technical sign-off on 11 of 15 evaluations" is fine. Skip any comparison with an industry average too. There is no reliable public one, and a made-up benchmark is easy to spot.
Demos matter less by volume than by audience. "Delivered 120 demos" is activity. Say who was in the room and what happened next.
Proofs of concept are the strongest material you have, because each one has a start, a success criterion and a result. State how long they ran, what the customer needed to see, and how many converted.
Tender responses (RFPs, RFIs, security questionnaires) are unglamorous, and sales leaders love people who handle them well. Mention the volume, your role, and whether you left behind anything reusable.
Before: Ran product demos and POCs for prospects.
After: Ran 6 proofs of concept in 2024, each scoped to written success criteria and capped at three weeks; 5 converted to paid contracts (illustrative).
Before: Responsible for RFP responses.
After: Technical author on 18 tender responses; built an answer library that cut the first draft from five days to two.
Depth without the keyword dump
The skills block on most sales engineer CVs is a wall: every cloud, every database, every protocol the product has ever touched. A technical lead reads that as "has heard of". Depth shows up in context, inside the bullet where you used the thing.
Keep the skills section short and sort it by how well you know each item. Two levels are enough: what you can build live on a call, and what you can discuss with a customer's architect. Then let the role bullets carry the proof.
Before: Skills: AWS, Azure, GCP, Kubernetes, REST, SQL, Python, SAML, OAuth, Kafka, Terraform.
After: Built a Python connector during a proof of concept to sync 40,000 customer records nightly through the REST API; the prospect's architect signed off on the integration plan the same week.
The same goes for solution design. Saying you designed a solution proves little. Name the user volume, the systems it had to connect, and the constraint that forced a choice.
There is one more piece of evidence almost nobody includes: the handover to delivery. Presales people have a reputation, fair or not, for promising things that implementation teams then have to build. A line showing that what you sold is what got deployed is worth more to a technical lead than another certification.
Before: Worked with the professional services team.
After: Wrote the solution brief handed to delivery for each closed deal; 8 of 9 projects went live inside the scope agreed at signature.
The title problem
Sales engineer, solutions consultant, presales consultant, solutions engineer, solutions architect. Companies use these for nearly the same job, and recruiters search for whichever one their own company uses.
Keep your real title, since that is what a reference check will confirm. Then put the market variants where a search can find them: in the summary line at the top ("Sales engineer (presales, solutions consulting) for B2B data platforms") and once in the body. Be careful with "solutions architect". In many companies that is a post-sale or delivery role with real design accountability, so use it only if it was your actual title or if your architectures went into production.
If you start from your LinkedIn profile, a LinkedIn-to-CV tool such as Postulit will get the structure and dates onto the page quickly. The title line and the two-reader edit are still yours to do by hand.
Two exits, two tilts
Presales is a seat people leave in two directions, and the CV should lean towards the one you want.
Towards sales. If the next step is account executive or sales management, push the commercial lines up. Show discovery calls you ran alone, pricing or procurement conversations you handled, and any period when you covered a rep's accounts. A sales leader needs to believe you can own a number and not only support one, so be explicit about the closest you have come to that.
Towards product or architecture. Here the weight moves to what you built and what you fed back. Feature requests you documented from lost deals that later shipped. Reference architectures other people reuse. Internal tooling. Revenue stays on the page as context, one line per role.
For this week, take your current role and write exactly two lines. One names the revenue you supported, whose target it was, and your share of the work. The other names one thing you built or solved, with the technology inside the sentence. If both hold up when you imagine each reader asking "and what did you do, exactly?", build the rest of the page the same way.