Sales Engineering Fundamentals Questions

Direct answer

The technical section of a request for proposal (RFP, a formal buyer document that vendors answer in writing, usually scored against a rubric; this section is written by the pre-sales team, the technical people who support the sale before signature) answers three things: can you meet each stated requirement, how will it work, and how will you deliver it with acceptable risk. I decide detail by one rule: depth follows scoring weight, risk, and where we genuinely differ from competitors, not where the content is easiest to write. Mandatory requirements get a precise yes, no or partly, with the evidence; the high-weight differentiators get the most space; boilerplate gets a short reference to an appendix.

What goes in (ten sections)

1. Compliance matrix (the table that answers every numbered requirement; this is the centre of the response and the first thing evaluators score): every requirement answered (meets, meets with configuration, roadmap, does not meet), each with a one-line explanation and a reference. Example rows: "R-12 Single sign-on: Meets. Standard SAML support, see Security Guide section 4." "R-31 Data kept in the EU: Meets with configuration. Needs the EU region selected at setup; no extra cost." "R-47 Offline mode: Roadmap. Planned for Q4, not a commitment; interim: scheduled exports." "R-58 On-premises hosting: Does not meet. Cloud-only; we propose the dedicated regional instance instead."
   If time is short, the must-haves are the compliance matrix, the architecture section with the context diagram, and the security section; the rest are scaled by the rule below.
2. Solution overview and architecture, with the context diagram.
3. Security, privacy and compliance controls.
4. Integration and data migration.
5. Deployment model and hosting (cloud, on-premises or hybrid, meaning part on the customer's own servers and part in the cloud).
6. Performance, scalability and availability (the non-functional requirements: qualities such as speed and uptime rather than features).
7. Implementation approach, plan and milestones.
8. Support, service levels (SLA, the contractual uptime and response-time promises) and operations.
9. Assumptions, dependencies and exclusions.
10. Team, experience and references.

Supporting artifacts and diagram types

If I could keep only two, I would keep the context diagram (so the evaluator sees the whole picture) and the data flow diagram (so the security reviewer sees where data goes). The others are supporting.

How I decide how much detail each part gets

Score each section on three questions: how many evaluation points does it carry, how much risk does it hold for the customer, and is it something we do uniquely well? High on two or more: long and specific, with a diagram. High on one: moderate. None: a paragraph and an appendix reference. Example (illustrative): if scoring gives security 30 percent and integration 25 percent, those two sections together are over half the score and deserve over half the effort.

Scenario: regulated multinational bank

Compliance, regional latency and a cost-neutral migration pull against each other, and I say so in the response:

• Keeping data inside each regulatory region satisfies compliance but adds latency for reports that span regions. I name the option chosen (regional data stores with an aggregated, anonymised reporting layer) and its cost.
• "Cost-neutral migration" means run costs (what the bank pays each month to operate the service) after migration at or below current, not that migration is free. I state what is included, what the bank must fund, and the assumptions behind the claim.
• I give the trade-off table, my recommendation, and what changes it. Evaluators trust a response that shows its trade-offs.

Hybrid on-premises and cloud pre-sales: communication plan (short)

One named technical contact per side, a weekly architecture sync, a shared decision log, and a written answer to every clarification question within two business days.

Artifact set for a named enterprise evaluation

Architecture pack, security whitepaper (a document describing in detail how the product protects data) and control mapping, reference architecture for their scale, sample project plan, a scripted demo environment, and references from similar customers.

An honest paragraph from a junior author

When the team is newer than a competitor, say so and show strengths:
"Our delivery team for this engagement has three engineers who have each run two migrations of this type, supported by a senior architect from the product team who is available through the design phase. We have not yet delivered a deployment at your scale in a single phase, so we propose a pilot at the first site, with scale-up gated on measured results."
Assumptions and dependencies are written as conditions the customer controls ("assumes read-only access to the source system by week 2"), never as delivery guarantees we cannot control.

Trade-offs and pitfalls

• Answering "yes" to every row of the matrix wins a score and loses a contract later.
• Copy-pasted text from past responses leaks other customers' names and stale claims.
• What would change my allocation: an evaluation rubric that weights price or references more than technical depth.

Direct answer

Assign exactly one accountable owner per step, make everyone else responsible, consulted or informed, and write down a tie-break rule for overlaps. Technical truth belongs to presales and product or security; commercial commitments belong to the account executive and legal; customer-side decisions belong to the champion (the customer insider who advocates for you) and procurement.

RACI by step

RACI means Responsible (does the work), Accountable (one person who answers for the outcome and has the final say), Consulted (gives input before) and Informed (told after). AE is the account executive, the salesperson who owns the deal. SE is the presales (sales) engineer.

Check: six steps, and each row has exactly one A.

Why each assignment

• Discovery: the AE is accountable for the deal and the relationship, the SE runs the technical questions. The champion helps assemble the right attendees.
• Demo and POC: the SE is accountable because technical claims must be true; the AE is consulted on the story and timing. In the POC the champion is responsible for the customer's data, users and time, which is where POCs usually stall.
• Security review: security engineering is accountable for what we say about our controls; the SE coordinates and translates; legal is consulted on contractual commitments in the answers.
• SOW: the SE writes the technical scope and assumptions; the AE is accountable for the price and commercial fit; legal checks the language.
• Contract: legal on our side and procurement on the customer's negotiate the terms; the AE keeps the commercial deal; the SE is consulted if a term has technical consequences (for example an uptime commitment, called an SLA, service-level agreement).

When two owners overlap

1. Test the rule: one A per step. If two people believe they are accountable, the step has no real owner.
2. Common overlaps and the tie-break: SE versus AE on discovery (the SE owns technical questions, the AE owns the business case and budget); SE versus security on questionnaires (security owns the answer, the SE owns the timeline); SE versus legal on the SOW (the SE owns what we build, legal owns what we promise).
3. Ask them to resolve it between themselves within one business day; if they cannot, escalate to the AE's and SE's managers, who decide the same day.
4. Record the decision in the deal notes, and change the RACI if the same overlap occurs three times.

Pitfalls

A RACI with two As, with the customer's champion treated as informed only, or with nobody accountable for the security answers (the one where a wrong sentence can create a legal obligation).

Direct answer

An estimate is defensible when every number can be traced to a stated scope, a stated unit rate and a stated assumption, and when the uncertainty is shown rather than hidden. I build it bottom-up from a work breakdown (the project split into small tasks, each costed separately), use three-point estimates (optimistic, most likely, pessimistic) for the uncertain tasks, calibrate against actual hours from past projects, add an explicit and explained contingency (a separate, reasoned buffer for risk), and present a range with what would narrow it, unless the scope is tightly bounded, in which case I quote a fixed price that already contains the contingency.

What makes it defensible when the customer pushes back

• Scope-linked: each cost line points to a deliverable the customer can see.
• Transparent unit rates: the customer can see days x rate, so they argue about assumptions rather than totals.
• Assumptions written down: volumes, environments, access and who does what.
• History-based: estimates compared against actuals from similar delivered projects.
• Contingency is explicit: a separate line with its logic, not padding hidden in every task.
• Ranges where uncertainty is real: a single number implies a precision we do not have.

Cost categories

How to build it (worked example, illustrative inputs)

Scenario: a reporting platform for 400 users. Each task has optimistic (O), most likely (M) and pessimistic (P) effort in person-days. The expected effort per task uses the PERT (program evaluation and review technique) weighting, (O + 4M + P) / 6, and the standard deviation (SD, a measure of spread) is estimated as (P - O) / 6. Task variances are added and the square root taken, which assumes the tasks overrun independently (an assumption; correlated overruns make the true spread wider). Blended rate (one average day rate across the mix of junior and senior staff): $1,200 per person-day. Licences: 400 users x $30 per user per month. Support: 20 percent of licence cost per year.

Why the statistics are valid, in plain words: the standard deviation is a typical size of the miss either side of the expected value. Spreads from independent tasks do not simply add, because one task running long is often cancelled out by another running short. What adds is the variance (the standard deviation squared), so I add the four variances and take the square root to get the project-level spread. In a normal (bell-curve) distribution, 90 percent of outcomes fall below the average plus 1.28 standard deviations; that 1.28 comes from standard normal tables, so the contingency means a roughly 9-in-10 chance of finishing inside the expected effort plus buffer.

tasks = {
 "Discovery and design":      (8, 10, 15),
 "Data integration build":    (20, 30, 50),
 "Migration and testing":     (10, 15, 28),
 "Training and handover":     (4, 5, 8),
}
RATE = 1200  # USD per person-day, blended
tot_e = tot_var = tot_o = tot_p = 0
for name, (o, m, p) in tasks.items():
    e = (o + 4*m + p) / 6
    sd = (p - o) / 6
    tot_e += e; tot_var += sd**2; tot_o += o; tot_p += p
    print(f"{name:26s} O={o:3d} M={m:3d} P={p:3d} expected={e:6.2f} days")
sd_tot = tot_var ** 0.5
print(f"total expected={tot_e:.2f} days, sd={sd_tot:.2f}, expected+1.28sd (~90th pct)={tot_e+1.28*sd_tot:.2f}")
print(f"sum of optimistic={tot_o} sum of pessimistic={tot_p}")
labour_exp = tot_e*RATE
contingency_days = 1.28*sd_tot
print(f"labour expected = ${labour_exp:,.0f}; contingency = {contingency_days:.2f} days = ${contingency_days*RATE:,.0f}")
lic = 400*30*12
sup = 0.20*lic
print(f"licences = ${lic:,}/yr; support = ${sup:,.0f}/yr")
print(f"one-time low={tot_e*RATE:,.0f} high={(tot_e+contingency_days)*RATE:,.0f}")

What the code does: it loops over the four tasks; for each it computes the expected days and the spread, adds them into running totals, and prints a line. After the loop it takes the square root of the summed variances, converts days to dollars at the blended rate, and works out licences (400 users x $30 x 12 months) and support (20 percent of that).

Output of running the program exactly as shown above:

Discovery and design       O=  8 M= 10 P= 15 expected= 10.50 days
Data integration build     O= 20 M= 30 P= 50 expected= 31.67 days
Migration and testing      O= 10 M= 15 P= 28 expected= 16.33 days
Training and handover      O=  4 M=  5 P=  8 expected=  5.33 days
total expected=63.83 days, sd=5.98, expected+1.28sd (~90th pct)=71.49
sum of optimistic=42 sum of pessimistic=101
labour expected = $76,600; contingency = 7.66 days = $9,191
licences = $144,000/yr; support = $28,800/yr
one-time low=76,600 high=85,791

Reading it: expected effort is 63.83 days, which at $1,200 is $76,600. Contingency is set at 1.28 standard deviations (about the 90th percentile under a normal approximation), 7.66 days or about $9,191, which gives a one-time range of roughly $76,600 to $85,800. Adding up all pessimistic values would give 101 days: far too high, because every task rarely overruns at once. Recurring: licences $144,000 per year and support $28,800 per year.

Range or single number?

• Scope clear and bounded: quote a fixed price near the top of the range ($86,000 here) with a change-control process (a written way to price and approve any request that falls outside the agreed scope).
• Scope uncertain (data quality unknown): quote the range, state what narrows it (a two-week discovery with a fixed fee), and agree to firm up the price after.
• Never give a single number without the assumptions beside it.

When the customer pushes back

"Which line would you like to change?" Walk the table. If they push on the rate, trade scope, not rate. If they push on the contingency, offer to remove it in exchange for a time-and-materials clause (the customer pays actual hours worked, so the customer carries any overrun). Never cut effort silently; that moves the risk to delivery.

Trade-offs and pitfalls

• The estimate is most sensitive to the integration task (20 to 50 days); a better-scoped integration shrinks the range more than a lower rate.
• Forgetting support and the customer's own time understates total cost of ownership (everything the customer pays over the life of the product, not only the purchase price).
• The normal approximation is rough; for a skewed distribution I would use historical overrun data instead.

Direct answer

I will walk through how I handle this situation, using a representative case shape (the numbers below are illustrative, not from a real deal). The product was technically a fit; we lost because the competitor's packaging matched how the customer buys and budgets, and ours did not. The lesson is that technical fit is only one of three things a buyer evaluates: fit, risk and price structure. I now test packaging fit at qualification, bring commercial structure into the technical conversation early, and involve the AE (account executive) and deal desk (the internal team that approves pricing and discounts) before the proposal, not after the loss.

The story shape (situation, action, result)

Situation. A mid-sized logistics company wanted a monitoring platform. Our POC (proof of concept) met every success criterion, and the technical lead told us we had won on capability. Two weeks later, procurement (the customer's purchasing and contract-negotiation team) chose a competitor.

What I found out (debrief call with the customer's champion, the internal supporter of our solution): our price was per monitored host, and hosts grow with their container count (more containers means more servers to run them on, so their bill would have risen as they grew). The competitor offered a flat annual platform fee up to a stated ceiling (a maximum usage level included in the fee), with a three-year price hold (a promise that the price will not rise for three years). Even though our first-year quote was comparable (illustration: 200 hosts at $500 per host per year is $100,000, against the competitor's flat $110,000), the customer's finance team preferred the predictable cost: their budget owner could not tolerate a bill that moved with container count. We had compared features and ignored how they would budget.

My part in it (own it). I had not asked in discovery how they fund and forecast this spend. I had given the AE a technical go and never questioned how our model would look next to a flat fee. I had also let the champion present our value without a total cost comparison across three years.

Actions after the loss.

1. Debriefed with the AE and a pricing owner within the week, and wrote down what we learned.
2. Added three questions to my technical discovery template: who owns the budget and how is it forecast (fixed, usage-based, capex versus opex: capital spending versus ongoing operating spending), what are the contract-length and price-protection expectations, and who are the competitors being compared and on what basis.
3. Started building a simple three-year total cost of ownership (TCO: all costs over the life of the solution) comparison for each serious deal, using the customer's own volumes and growth. Worked example (illustrative): per-host at $500 with hosts growing 30 percent a year is year 1: 200 x $500 = $100,000; year 2: 260 x $500 = $130,000; year 3: 338 x $500 = $169,000; total $399,000. The competitor's flat fee is $110,000 x 3 = $330,000. We looked cheaper in year one and were $69,000 more expensive over three years, and the finance team could not forecast ours at all. If growth were 0 percent, ours would be $300,000 and would win, so the customer's growth forecast decides the comparison. The comparison also assumes the competitor's flat fee ceiling covers the 338 hosts of year 3; if the stated ceiling were lower, the competitor's overage terms would have to be added to its side before comparing, so I ask for the ceiling and overage terms in writing and apply the same growth assumption to both bids.
4. Worked with the AE and deal desk on packaging options for usage-based buyers (a committed-spend tier (the customer commits to a yearly amount in return for a cap or discount) with a ceiling, multi-year price lock), instead of discounting after a loss.
5. At qualification, I now flag "technically fit, commercially at risk" as its own status.

Result. I would not quote a win rate improvement I cannot support. What I can say truthfully is that on later deals, the packaging concern surfaced during discovery rather than at procurement, which let the AE shape the proposal earlier. If asked for measures, name the ones you track (for example: share of deals with a TCO comparison attached before proposal, or the number of losses with price structure as the stated reason), not invented percentages.

If you have no real lost deal

Say so, and say how you would handle one: run the same debrief, ask what the customer valued, check whether packaging, procurement terms or risk drove the decision, and feed the answer into qualification and pricing. Do not invent a story; the interviewer will probe the details.

Trade-offs and pitfalls

• Do not blame price after the fact without evidence. Ask the customer; the stated reason and the real reason sometimes differ, so triangulate with the champion and the AE.
• Do not respond to one loss by discounting everywhere. Packaging changes (structure) and discounts (level) solve different problems.
• A technical lead should influence packaging through the AE and deal desk, not around them.

Direct answer

It is one proposal with three entry points. Each audience gets a different first page, because each is asking a different question: the CEO and CFO ask "is this worth it and what is the risk", the CTO and architects ask "will this work in our environment", and procurement (the customer's purchasing team that negotiates and approves the contract) and legal ask "are the terms acceptable and can we compare this fairly". I put each audience's answer first, keep one source of truth underneath so the three views never disagree, and move everything else to appendices.

What each group sees first, and what moves out

How I run it

1. Build the single source (one master document every view is cut from, so a number is changed in one place): one proposal master with all sections, owned by me, with the same numbers everywhere.
2. Cut three views from it: a two-page summary for executives, a technical volume for the CTO, a commercial volume for procurement.
3. Pre-wire: speak to each group before the formal presentation, so their first objection is already answered. Example: a 20-minute call with the CTO's lead architect two days before: "We assume read-only access to your order system. Is that realistic?" If the answer is no, the page changes before the meeting instead of derailing it.
4. Present in the order that matches who decides: open with the executive view, then the technical session, then a separate commercial review.

Example: the executive first page

An illustrative page one: "Cost: $480,000 over three years. Expected benefit: $300,000 a year lower stock write-offs. Payback: $480,000 / $300,000 = 1.6 years, about 19 months. Main risks: integration with the warehouse system (mitigated by a 6-week pilot). Decision requested: approve the pilot by 30 June."
One item moved to an appendix: the full SLA text. The CFO needs only the headline uptime figure, while procurement finds the full text in the commercial volume.

Example: opening lines

• To the CEO and CFO: "This proposal is designed to cut stock write-offs, and the cost, payback and main risks are on page one."
• To the CTO: "Here is how the platform connects to your existing systems, where your data lives, and what we have assumed about your environment."
• To procurement: "Here are the price breakdown, the terms we propose, and where we have departed from your standard contract and why."

Trade-offs and pitfalls

• Three separate documents risk inconsistent numbers: avoid it with one master and a reviewer who reads all three.
• Do not hide risk from the executives to look better. It reappears later as distrust.
• What would flip it: if one person is decision-maker and technical evaluator (a small company), a single short document is better than three.