What a pre-sales deal support template is
In most B2B software teams, solutions engineers (also called sales engineers or pre-sales consultants) are shared across several account executives. Requests arrive as a direct message, a calendar invite with no agenda, or a forwarded security questionnaire due the next morning. This template gives every request the same shape, so the SE can judge it before saying yes: what the deal is, where it stands, who on the buyer side is technical, what exactly is being asked for and by when.
It has two parts. The request form is filled in by the account executive, once per ask. The tracker is kept by the SE manager, one row per request, and shows the load on each engineer across the week alongside the deals taking the most engineering time. Read over a quarter, it also shows whether that time went to deals that closed.
Requests come in six common types: a discovery call, a tailored demo, a proof of concept, a security questionnaire, an RFP response and an architecture review. Each needs different lead time and different input from the account executive. The template lists the minimum the AE must provide for each type, so an SE never walks into a demo without knowing the buyer's use cases.
The last part is the outcome log. After the work, the SE or AE records what was delivered, how the buyer reacted and what changed in the deal as a result. Over time this is the evidence an SE manager needs to decide which requests to decline, which lead times to change and when to ask for another engineer.
When to use a pre-sales request template
- Solutions engineers are shared across several account executives, and requests arrive in direct messages with no deal context.
- Demos get booked before discovery is done, so the SE learns the buyer's use cases during the call.
- Security questionnaires and RFPs land with deadlines a few days away and nobody knows who answered the last one.
- The SE manager cannot say how many hours went to each deal last quarter, or which requests were turned down and why.
- Leadership is deciding whether to hire another solutions engineer and wants the request volume behind the decision.
Pre-sales request vs POC plan vs mutual action plan vs stakeholder map
These four documents often describe the same deal. They differ in who writes them and what they are for, and a pre-sales request frequently leads to one of the others.
| Document | Who writes it | What it records | When it is used |
|---|---|---|---|
| Pre-sales deal support request | Account executive, accepted by the SE manager | One piece of SE work on one deal, with context and a due date | Each time the AE needs engineering help |
| Proof of concept plan | Solutions engineer and AE, agreed with the buyer | Success criteria, owners and timeline for a technical test | After a POC request is approved |
| Mutual action plan | AE with the buyer's champion | Every milestone from evaluation to go-live, with owners on both sides | Throughout the deal, shared with the buyer |
| Stakeholder map | AE, reviewed in deal reviews | Every person in the buying group, with role, influence and stance | Before and during the evaluation |
The pre-sales deal support template
The account executive fills in the request form and the stakeholder table before asking for time. The SE manager checks the request against the minimum input for its type, assigns it from the capacity view and logs it in the tracker. The outcome log is filled in within a day of the work being delivered.
Support request form
| Field | What to write |
|---|---|
| Requested by and date | [Account executive, team, date of request] |
| Account and opportunity | [Account name and the opportunity record in the CRM] |
| Stage and value | [Current stage, amount, forecast category and target close date] |
| Business problem | [The problem the buyer is trying to solve, in their words] |
| Why the deal needs SE support now | [The question or doubt this work will answer for the buyer] |
| Competitors in the deal | [Named competitors, or none known] |
| Already shared with the buyer | [Decks, demo recordings and documents the buyer has seen] |
| Support type | [Discovery call / tailored demo / proof of concept / security questionnaire / RFP / architecture review / other] |
| Due date and meeting time | [The buyer's deadline, and any meeting already booked] |
| Success looks like | [What the AE expects to be true after this work, such as the buyer's architect approving the integration approach] |
Buyer technical stakeholders
| Name and title | Role in the evaluation | What they care about | Attending | Concerns raised so far |
|---|---|---|---|---|
| [Name, title] | [Technical evaluator / architect / security / IT owner / end-user lead] | [Their priorities for this purchase] | [Yes / no] | [Concerns raised so far] |
| [Name, title] | [Role] | [Priorities] | [Yes / no] | [Concerns] |
| [Name, title] | [Role] | [Priorities] | [Yes / no] | [Concerns] |
Minimum input by support type
| Support type | Suggested lead time | The AE must provide | The SE delivers |
|---|---|---|---|
| Discovery call | 2 working days | Account research, an agenda shared with the buyer and the attendee list | Technical requirements notes and a fit assessment |
| Tailored demo | 3 to 5 working days | Discovery notes, the buyer's top use cases and the attendee list | A demo built around those use cases, and a written recap |
| Proof of concept | 1 to 2 weeks to plan | A qualified opportunity, a named buyer sponsor and draft success criteria | A POC plan with criteria, owners and a timeline |
| Security questionnaire | 5 to 10 working days, depending on length | The questionnaire file, the buyer's deadline and any portal access | Completed answers, reviewed by security where required |
| RFP response | Agreed per RFP | The RFP document, the bid decision and the sections assigned to the SE | Technical sections drafted and reviewed |
| Architecture review | 3 to 5 working days | The buyer's current systems, integration needs and attendees | A proposed architecture and a list of open questions |
SE assignment and capacity
| Solutions engineer | Specialism | Requests open this week | Hours committed | Hours available | Next free slot |
|---|---|---|---|---|---|
| [Name] | [Industry, product area or security] | [Number] | [Hours] | [Hours] | [Date and time] |
| [Name] | [Specialism] | [Number] | [Hours] | [Hours] | [Date and time] |
| [Name] | [Specialism] | [Number] | [Hours] | [Hours] | [Date and time] |
Request tracker
| Request ID | Account | Support type | Requested by | Assigned SE | Due date | Status | Hours spent |
|---|---|---|---|---|---|---|---|
| [ID] | [Account] | [Type] | [AE] | [SE] | [Date] | [New / accepted / in progress / delivered / declined] | [Hours] |
| [ID] | [Account] | [Type] | [AE] | [SE] | [Date] | [Status, with a reason if declined] | [Hours] |
| [ID] | [Account] | [Type] | [AE] | [SE] | [Date] | [Status] | [Hours] |
Outcome log
| Request ID | What was delivered | Buyer reaction | What changed in the deal | Follow-up owner |
|---|---|---|---|---|
| [ID] | [What the SE produced or presented] | [What the buyer said or did next] | [Stage change, new stakeholder, next step booked, or nothing] | [Name] |
| [ID] | [Delivered] | [Reaction] | [Change] | [Name] |
Prefer a file? We email the Word, Excel and PDF versions to your work address, free.
Email me the filesPre-sales deal support example
Example: fictional company
Here is the template filled in for two requests on one invented deal, with a third request from another account in the tracker. The account executive filled in the form before booking anything, and the SE manager assigned both requests on the day they arrived.
Sam Whitley, an account executive at Ferncastle Analytics, is selling Ferncastle's forecasting platform to Marlow & Finch Logistics. Discovery is done and the buyer wants to see the product on their own forecast process, so Sam asks solution engineering for a tailored demo, followed by an architecture review with the buyer's IT team.
Support request form
| Field | Example entry |
|---|---|
| Requested by and date | Sam Whitley, mid-market team, 2 March |
| Stage and value | Evaluation; $84,000 a year; best case; target close end of June |
| Business problem | Regional managers rebuild the forecast in spreadsheets every Monday because they do not trust the CRM view |
| Why the deal needs SE support now | Dana Okafor, Director of Revenue Operations, will only propose a POC once she has seen the regional forecast view on data shaped like hers |
| Competitors in the deal | Harborview Metrics, and the existing spreadsheets |
| Support type | Tailored demo, then an architecture review with IT |
| Due date and meeting time | Demo on 12 March at 14:00; architecture review the following week |
| Success looks like | Dana agrees the use cases for a POC, and the enterprise architect approves a read-only CRM connection |
Buyer technical stakeholders
| Name and title | Role in the evaluation | What they care about | Attending | Concerns raised so far |
|---|---|---|---|---|
| Grace Lindqvist, Sales Operations Analyst | Technical evaluator | Forecast totals that match the CRM | Yes, both meetings | Asked how deal changes are tracked between calls |
| Ken Ito, Enterprise Architect | Architecture and IT approval | Read-only access and single sign-on | Architecture review only | Does not want any tool writing to the CRM |
| Luis Moreno, Regional Sales Manager | End-user lead | Running the Monday call without a spreadsheet | Demo only | None yet |
Request tracker
| Request ID | Account | Support type | Requested by | Assigned SE | Due date | Status | Hours spent |
|---|---|---|---|---|---|---|---|
| REQ-031 | Marlow & Finch Logistics | Tailored demo | Sam Whitley | Nadia Brennan | 12 March | Delivered | 9 |
| REQ-034 | Marlow & Finch Logistics | Architecture review | Sam Whitley | Nadia Brennan | 19 March | Delivered | 4 |
| REQ-036 | Harborview Metrics (prospect, separate deal) | Security questionnaire | Priya Shah | Owen Clarke | 20 March | In progress | 6 |
Outcome log
| Request ID | What was delivered | Buyer reaction | What changed in the deal | Follow-up owner |
|---|---|---|---|---|
| REQ-031 | Demo of the regional forecast view on sample data with Marlow & Finch's region and stage structure | Dana asked for a four-week POC covering two regions | POC planning started; success criteria drafted with Grace | Nadia Brennan |
| REQ-034 | Architecture review of the CRM sync and single sign-on | Ken Ito approved a read-only sync and asked to test single sign-on | Single sign-on added as a POC success criterion | Sam Whitley |
Example: fictional company. Ferncastle Analytics, Harborview Metrics, Marlow & Finch Logistics and every person named in this example are invented for illustration. Any resemblance to real companies or people is coincidental.
How to run pre-sales deal support
Publish the support types and lead times
Agree with sales leadership which kinds of help solution engineering offers and how much notice each needs. Put the list where account executives will see it, so the first conversation about a request can be about the deal itself.
Ask for the form before the calendar invite
The form is the qualification step. If the account executive cannot write the buyer's problem in a sentence or name the technical stakeholders, the deal needs more discovery before it needs an engineer.
Assign from the capacity view
The SE manager assigns each request by load and specialism, records it in the tracker the same day and tells the account executive who is on it. Requests that cannot be staffed in time get a new date or a decline, with the reason written down.
Hold a short internal prep call
Before any buyer meeting, the AE and SE spend fifteen minutes on the form together: what the buyer has already seen, who will attend and what a good outcome looks like. Most demos that go badly could have been saved here.
Log the outcome within a day
Record what was delivered, how the buyer reacted and what changed in the deal. It takes two minutes while the meeting is fresh and is almost impossible to reconstruct at the end of the quarter.
Review the tracker every month
Compare engineering hours by deal and by support type with the deals won and lost. Use it to change lead times, decline the request types that rarely move a deal, and make the case for headcount with numbers from your own team.
Common pre-sales deal support mistakes
Requests by direct message
A request in a chat thread has no stage, no value and no deadline attached, and it disappears from view once answered. Route every ask through the form, even the small ones.
A demo before discovery
A generic demo to a buyer whose problem nobody has written down shows features the buyer may not need. If the form cannot be completed, book discovery first.
No way to decline
If solution engineering can only say yes, the busiest account executive gets the most engineering time, whatever the deal is worth. Allow a decline or a new date, with a reason logged.
Security questionnaires answered from scratch
Most questionnaires repeat questions the team has answered before. Keep approved answers in one place and review them on a schedule, so each new questionnaire starts from current material.
Hours not tracked
Without hours per request, nobody can see that one stalled deal took a third of an engineer's month. A rough number logged at the end of each request is enough.
Outcomes never recorded
If the tracker only shows work done, it cannot show which work helped. The outcome log is what turns a queue into evidence.
How Revspire supports pre-sales work
Revspire Content Hub keeps approved technical material, such as security documents and architecture overviews, searchable and versioned, so a solutions engineer starts each request from the current version. In Revspire Digital Sales Rooms, what the SE produces goes into the buyer's room next to the mutual action plan, and buyer engagement analytics show which technical stakeholders opened it.
Pre-sales deal support template FAQs
What should a pre-sales request form include?
The account and opportunity, the stage, value and target close date, the buyer's problem in their words, the type of support needed, the due date, the buyer's technical stakeholders and what the account executive expects to be true after the work. Add what the buyer has already seen, so the SE does not repeat it.
How do you prioritise pre-sales requests?
Start with deadline and stage: a buyer meeting already booked on a late-stage deal comes first. Then weigh deal value and whether discovery is complete. Requests with no buyer deadline and thin discovery wait or go back to the account executive. Record each decision in the tracker so the rules stay visible.
How much lead time should solutions engineers get?
It depends on the type of work. A discovery call can be staffed in a couple of working days, a tailored demo usually needs most of a week, and a security questionnaire or RFP needs as long as its length demands. Publish your own lead times and review them against the tracker each quarter.
Who owns the pre-sales deal support tracker?
The SE manager or head of solutions engineering owns the tracker and the capacity view. Account executives own their request forms and the accuracy of the deal context. The outcome log is shared: whoever ran the meeting or delivered the work fills it in within a day.
Is pre-sales the same as solutions engineering?
Mostly, yes. Pre-sales, solutions engineering, sales engineering and solution consulting are different names for the technical team that supports account executives before a sale. Some companies also put bid management or demo engineering under pre-sales. The template works for any of them.
Related templates and reading
- Free templateSales enablement business case templateA one-page sales enablement business case: the problem, what ramp, rep time and turnover cost today, the options, the numbers and a dated decision ask.
- Free templateSales close plan templateEvery remaining step between verbal intent and signature, with owners on both sides, the approval chain and the risks the buyer never sees.
- Free templateDigital sales room templateThe sections of a buyer-facing deal room in order: summary, stakeholder map, mutual action plan, content by stage, business case, security, next steps and handoff.
- Free templateSales quote templateAn itemised B2B and SaaS quote: header and validity, line items with discounts, commercial terms, an internal approval record and a signature block.
- Blog: tools solutions engineers use for demos, POCs and RFPsBest presales software
- Template: the plan for a POC request once it is approvedProof of concept template
- Template: where SE milestones sit in the shared deal planMutual action plan template
- Template: the full buying group behind the technical stakeholdersStakeholder map template