Sales to Engineering Handoff: An FDE Commitment Record

A sales to engineering handoff should record what the customer expects, what the demo demonstrated, which dependencies remain unknown, and what scope the receiving team accepts. Use this worked commitment record before turning a pilot expectation into an implementation date.

Editorial tool: the record below is our proposed method. It is not an industry standard or a claim that either cited company uses this checklist.

What the primary sources establish

OpenAI’s current Seattle FDE posting assigns the role discovery, technical scoping, implementation, and production rollout. It also asks engineers to sequence delivery and make tradeoffs among scope, speed, and quality. This is evidence of one employer’s stated expectations, not a measure of how frequently sales handoffs fail.

GitLab’s pre-sales to post-sales transition guidance calls for an account-team handoff covering the customer and success plan, including objectives and measurable success criteria. This is a documented customer-success process, not an FDE-specific study or proof that a particular checklist improves delivery.

Both primary pages were checked September 24, 2026. Together they provide a narrow starting point: technical scope is part of this FDE role, and another software company explicitly documents transferring customer expectations across the sale. The method below is our proposed application of those ideas.

Interpretation

Editorial interpretation: a useful handoff should let the receiving engineer distinguish what the customer expects from what the team has demonstrated and what it can responsibly commit to building next.

Those can be three different things. A demonstration may show a relevant answer from a prepared dataset. The customer may interpret it as evidence that the system always uses the latest information. The delivery team may have estimated only a scheduled import. If nobody records that distinction, the same word—“fresh”—can conceal different projects.

We propose a small sales-to-build commitment record. It follows one promise across the handoff: original wording, evidence, missing dependency, estimate confidence, decision owner, and customer acknowledgement. This is an editorial tool to try, not an established industry standard or an observed practice at either cited company.

The focus is deliberately narrow. The deployment context packet in Issue #040 collects broader implementation context. The evaluation contract in #042 defines launch evidence. Issue #047 assigns cross-company decision authority. This record captures the specific promise engineering is being asked to accept before implementation starts.

Operator Lesson

A fictional retrieval pilot

The entire scenario, all quantities, estimates, people, and decisions below are fictional. They are teaching examples, not customer testimony or measured results.

A support team buys a pilot that helps agents find the right answer in internal troubleshooting documents. In the sales demo, the assistant retrieves a passage, cites it, and drafts an answer. The sponsor asks whether it uses fresh documentation. The response is that it can work from the company’s knowledge base.

At handoff, the delivery ticket says: “Connect the knowledge base and use current articles.” The pilot has a proposed ten-business-day delivery window. The receiving FDE asks for the demo setup and learns that it used a one-time export of approved articles.

That export proved something useful: the retrieval path could produce a cited answer for the demonstrated questions. It did not establish continuous ingestion, treatment of deleted articles, permission propagation, or a maximum time between a source edit and a changed answer.

The sponsor explains why freshness matters. Support guidance sometimes changes during an incident. An old answer could send an agent through a troubleshooting step the team has withdrawn. In this fictional case, the desired behavior is for eligible edits to become available within five minutes, with deleted articles excluded from retrieval.

The FDE cannot honestly turn that clarification into an implementation promise yet. The team has access to a nightly export, but has not established access to a change feed. It also has no verified deletion signal. The missing work sits partly in the customer’s source system and partly in the deployment pipeline.

The record at the receiving boundary

Keep the original wording and the clarified requirement side by side. That avoids quietly rewriting the historical promise to match what is easy to build.

The estimate is intentionally split. One part can be bounded using known inputs; another remains unknown. Inventing a precise estimate for the second part would hide the decision that the team needs to make.

“Accepted for discovery” also has a specific meaning: engineering will investigate a dependency within an agreed effort limit. It does not mean the desired feature or the original date has been accepted.

What changes after the review

For this fictional example, assume the sponsor agrees that a limited trial can still answer a useful question: do the selected documents support helpful answers for a small set of support tasks?

The revised commitment becomes: “Run an evaluation on an approved snapshot, show its capture time, and prohibit operational use that depends on later source changes. Continuous updates and deletion propagation are outside this trial.” The team records the data boundary, evaluation questions, and responsible reviewer before proceeding.

The delivery lead confirms capacity for the smaller trial. The commercial owner checks that the revised scope is handled through the existing agreement process. The sponsor acknowledges the limitation and the next decision date. Engineering accepts only that version of the work.

If the sponsor instead says that five-minute freshness is essential even for the trial, the smaller scope is not a valid substitute. Keep the pilot on hold while the team inspects the change path and prepares a new estimate. A handoff record cannot make an unacceptable compromise acceptable by documenting it neatly.

Make acceptance visible

A ticket being assigned to an FDE should not silently stand in for that FDE accepting every promise attached to it. Our suggested record uses a small set of explicit states: received, investigating, accepted with conditions, or held for a decision.

Attach conditions to something checkable. “Pending access” is weak. “Estimate starts after the administrator provides an approved export and confirms its permitted use” tells both teams what must happen next.

Customer acknowledgement means the relevant customer owner has confirmed their understanding of the recorded boundary. It is not a substitute for contractual approval, nor does a document give the FDE authority to change commercial terms. Keep technical feasibility, staffing commitments, and commercial decisions with the appropriate owners.

Practical Playbook

1. Recover the actual promise

Choose the three promises most likely to change engineering effort. Find their provenance in the approved scope, demo notes, or customer conversation record. Preserve the language and context; do not turn a salesperson’s tentative possibility into a firm commitment by paraphrasing it.

If the record is missing, write “unverified” and ask the people involved to reconcile it. Do not invent a quote or assume that the customer and seller remembered the same condition.

2. Ask what would count as fulfillment

Translate one ambiguous word into an observable requirement. For “fresh,” ask which source events matter, how quickly they must appear, and what should happen when updates fail. For “integrated,” ask which system actions are required and under whose identity.

Record the customer’s intended behavior separately from the team’s ability to deliver it. This is a requirements conversation before it is a negotiation over dates.

3. Attach evidence and name the gap

Write what the demo or test actually showed, including its data and environment limits. Then name what remains unverified. Link the minimum internal evidence needed by the receiving team; avoid copying confidential customer content into a broadly shared planning document.

In the fictional pilot, the useful gap is specific: continuous source updates and deletion handling were never demonstrated. “Needs more testing” would hide that dependency.

4. Separate investigation from implementation

Give unknown dependencies a bounded investigation with an owner and a review point. State which estimate depends on its result. Avoid a calendar commitment that assumes the missing dependency will resolve in the team’s favor.

Where a smaller deliverable has independent customer value, describe it as an option. Where it cannot satisfy the customer’s objective, preserve the hold and explain what evidence would change it.

5. Record the accepted version

Close the handoff with a versioned scope statement, receiving engineer, delivery owner, customer acknowledgement, and links to the appropriate approvals. Update the implementation ticket to match that version.

Reopen the affected commitment when its assumptions change. A new data source, tighter freshness requirement, or expanded user population should trigger review of the corresponding row. Keep the history so the team can explain why its estimate changed.

Career Implication

For an engineer moving from solutions work into delivery, this is a useful portfolio exercise. Build a fictional demo, document exactly what it proves, and write the handoff you would want before implementing it in a customer environment.

Show how one requirement changes the architecture or estimate. A snapshot-to-continuous-update example can expose ingestion, permissions, deletion, and operational decisions without using real customer data. Label simulated results and untested assumptions.

For an experienced FDE, prepare a real story about a promise you clarified: what the customer intended, what evidence was missing, who could decide, and what scope was ultimately accepted. If you cannot substantiate an outcome, describe the decision you made without claiming it saved a specific amount of time or money.

Hiring / Team Implication

A hiring team can use a fictional handoff as a work sample. Supply a demo description, a loose customer expectation, and an incomplete dependency list. Ask the candidate what they would accept now, what they would investigate, and how they would explain the difference to the customer.

Look for clear questions, an understanding of the demonstrated boundary, and estimates tied to evidence. Do not reward confidence that erases unknowns. This exercise evaluates a proposed skill; we have no evidence here that it predicts hiring performance.

For a delivery team, place these fields in the artifact people already use. If the CRM-to-delivery handoff already captures promises, dependencies, estimates, and acceptance, improve that record instead of creating a second source of truth. The useful behavior is explicit acceptance of a scoped commitment.