The sales-to-delivery hand-off: turning a signed quote into a build plan

Why the hand-off is where the money leaks

Most agencies obsess over two moments: winning the work and shipping the work. The bit in between gets almost no attention, and it's the most expensive part of the whole job.

Here's the pattern. New business writes a persuasive proposal. It gets signed. Then a project manager or lead developer opens that PDF and has to reverse-engineer it into something buildable, what was actually promised, at what price, with what assumptions, and in what order. Anything the salesperson knew but didn't write down is gone. Every hour spent decoding the sale is an hour you can't bill, and every decision that gets re-made is a chance to build the wrong thing.

The proposal was written to win the work. It was never structured to run it. That mismatch is the hand-off problem, and no amount of goodwill fixes a structural gap.

The four things that break

When a scope moves from sales to delivery, four specific things tend to fall through:

• The "why" behind the numbers. A line reads "Custom checkout, £4,200". The scoper

knew that price assumed the client's existing payment provider and no multi-currency. Delivery doesn't, so they either over-build or hit a surprise mid-project.

• The assumptions and exclusions. What was deliberately left out, data migration, third-

party licences, content population, lived in the salesperson's head or a caveat nobody re-reads. It resurfaces as a scope dispute six weeks in.

• The estimated effort. The hours that justified the price rarely travel with the

document. Delivery re-estimates from scratch, and the two numbers don't match, so the project is behind before it starts.

• The structure itself. The proposal is organised to read well for a buyer. The build

needs to be organised by component and sequence. Someone has to re-type and re-shape it, which is both slow and lossy.

None of these are people failing at their jobs. They're the predictable result of asking one document to do a job it was never built for. We go deeper on each in the hand-off problem.

The root cause: three documents, not one

Trace almost every hand-off failure back and you find the same thing: the quote, the specification and the task list are three separate documents, created in three different tools, at three different times.

1. 1The quote lives in a proposal tool, written for the client.
2. 2The spec gets written later, often in a shared doc, as a fuller technical version.
3. 3The task list gets re-typed a third time into a project management tool by whoever

picks up delivery.

Each transcription is a chance to drop a decision, quote one thing and build another, or lose the reasoning behind a figure. And because most proposal tools charge per seat, the developers who most need to read the original scope never get a login, so they work from screenshots and second-hand summaries.

The fix isn't a better hand-off meeting or a tidier PDF. It's refusing to create three documents in the first place. This is our core view, and it drives everything below: the document should survive the sale and become the build plan.

What a clean hand-off looks like

A hand-off works when delivery inherits context instead of reconstructing it. In practice that means:

• One structure, carried through. The sections you agreed with the client are the exact

sections your team builds from, no re-shaping.

• The commercial logic stays attached. The price, the estimated hours and the reasoning

behind them travel with the scope, so delivery starts from the numbers that were sold, not a fresh guess. See estimating hours at quote time.

• Assumptions are written where the work is. Exclusions and technical notes sit against

the section they affect, not buried in a caveats paragraph.

• The client-facing version and the build version are the same source. When the quote

becomes a buildable specification, you add detail, you don't retype.

• Delivery gets a real task list, not a PDF. The scope produces a combined task list your

PM can actually work from. More on that in from spec to task list.

How ScopeDeck closes the gap

ScopeDeck is built around a single idea: one Scope, viewed through three stages.

You write a light, client-facing Quote from structured sections. When it's approved, you promote it to a Specification, the detailed technical version, seeded from your quote wording so you start from what you already wrote, not a blank page. Then the same Scope rolls into Tasks: delivery buckets attached to your sections and reusable snippets, combined into one list you can export as Markdown for your project tool. Throughout, internal Notes, dev notes and open questions sit against the sections they affect and never reach the client PDF.

Because it's one section tree the whole way through, nothing gets re-typed and nothing gets lost between the sale and the build. The hours you estimated while quoting are still attached. The exclusion your scoper flagged is right there against its section. Delivery opens the Scope and reads exactly what was sold, down to the section they're building this week. That's the whole point of quote → specification → tasks, and it's why we say the document survives the sale.

To be honest about limits: task export is Markdown or CSV today, with a Zapier integration planned so you can push scopes and tasks to Avaza, Linear and thousands of other apps. What's live now is the part that matters most, the scope itself doesn't get rebuilt three times.

A checklist for your next hand-off

Whatever tool you use, a hand-off holds up better when you can answer yes to all of these:

• Does the build version share its structure with the version the client signed?
• Are the estimated hours behind the price written down and attached to the work?
• Is every exclusion and assumption recorded against the specific section it affects?
• Can a developer who wasn't in the sales call read the scope without a briefing?
• Does the task list come from the scope, rather than being re-typed alongside it?

If you're building the answer to those from scratch every project, the quote-to-spec-to-tasks workflow is worth a look, it's designed to make "yes" to all five the default, not the exception. Agencies running this end to end can see how it fits their team on the agencies page.