How do you hand a won deal over to the team that delivers it?

01The business problem

A deal closes. Something now has to be built, configured, migrated or taught before the customer gets any value from what they bought — and the people who do that are not the people who sold it.

The handover is where this usually lives:

• A conversation, or a message in a channel, and a spreadsheet that the delivery team maintains privately.
• Whatever the salesperson happened to write in the deal notes, which is never the thing the delivery team needs to know.
• A start date nobody agrees on, because "won" and "ready to start" are different events separated by an invoice.

The consequences are predictable and expensive. Nobody can answer how many customers are mid-implementation right now, or which ones are overdue, because the answer lives in a spreadsheet. Support learns a customer went live when that customer raises their first ticket. And the sales team's own reporting quietly degrades, because the deals they closed are still sitting in their pipeline months later.

02Why the obvious approach fails

Adding delivery stages to the sales pipeline

This is the first instinct and it is the expensive one. The pipeline already has stages, the deal record already exists, so the delivery phases get appended: Won → Setup → Training → Delivered.

It corrupts every pipeline metric simultaneously, because a pipeline measures one lifecycle and it is now carrying two:

• Sales cycle becomes sell-time plus delivery-time. A deal closed in March and live in July reports a four-month cycle that no salesperson influenced.
• Conversion rate stops meaning anything, because records leave the pipeline for delivery reasons, not sales ones.
• Weighted forecast counts committed revenue as though it were still being won.
• Stage ageing — the report anyone uses to find stuck deals — fills with records that are not stuck, merely being delivered.

It also forces one field set and one owner onto two teams. The salesperson keeps a record they no longer act on; the delivery team inherits a form full of fields about competitors and discount approval.

Tracking it on the account instead

Better instinct, still wrong shape. The account is the customer, and a customer can buy more than once — a second project, an upsell that needs its own configuration. Delivery state on the account can only describe one engagement, so the second one overwrites the first and the history is gone.

A task list

Tasks are the right tool for steps and the wrong one for a lifecycle. A checklist of ten tasks cannot tell you which stage a project is in, cannot be reported on as a funnel, and has no notion of a project being overdue as opposed to a task being overdue.

03Data model — two pipelines, one relationship

Delivery gets its own pipeline, with its own stages, its own owner and its own field set. The won sales opportunity is cloned into it.

In Coevera an opportunity type is one-to-one with a pipeline, so a second pipeline necessarily means a second type — which is convenient here, because it is exactly the separation you want: a delivery record is a different kind of thing from a sales record, with a different form.

The stages describe delivery, not selling

The production deployment this is drawn from uses four, and the shape generalises:

Note the first stage. Won and ready to start are different events, usually separated by an invoice, and giving that gap its own stage is what stops the delivery team's queue from filling with work they cannot begin.

Clone conditionally

Not every won deal needs delivering. The clone fires only when the deal contains an actual deliverable — a setup, a training, a data migration, a block of consulting hours. A pure licence renewal produces no delivery record and never appears in that team's queue.

This one condition is the difference between a delivery pipeline the team trusts and one they ignore because it is full of things that are not their work.

Rejected alternatives

• A custom entity for the project rather than a second opportunity type. Defensible, and it costs you the pipeline: stages, a funnel view, stage ageing and forecast-style reporting all come free with an opportunity and have to be rebuilt on a custom entity. Choose it only if delivery genuinely has no stage progression — see Blueprint 003 for that decision.
• Moving the record between pipelines instead of cloning. Then the sales pipeline loses the deal it closed, and historic sales reporting changes retrospectively every time something is delivered.
• One record, two status fields — a sales status and a delivery status on the same opportunity. Every report, view and process then needs to know which field it cares about, and the pipeline still shows one of them.

04Field-level configuration

The delivery record needs a small set of fields that the sales record has no use for.

05Automation & logic

The clone, and one process per source pipeline

The clone triggers on the sales opportunity's status becoming won, filtered to deals containing a deliverable. It creates the delivery record at the first stage, copies the base fields, applies the per-service quantity defaults, and sends the customer a confirmation whose body varies by what they bought.

Deals can arrive from more than one sales pipeline — new business and upsell, typically. The production estate uses a sibling process per source pipeline rather than one process with a compound condition. Slightly more to maintain, and worth it: each is readable on its own, each can be disabled independently, and neither grows a condition nobody can safely edit.

Treat go-live as a fan-out, not as one process

When a project goes live, several unrelated things must happen. Writing them as one process produces something nobody will touch in a year's time. Writing them as four gives four things that can be read, disabled and re-run independently:

The third is the one teams forget, and it is the actual handoff. Delivery finishing is not the end of the story: whoever answers this customer's first support ticket needs to know what was implemented, and a notification carrying the scope is what stops them starting from nothing.

The fourth deliberately fires the day after rather than on the day. Go-live day is busy and a follow-up nudge lands better once the customer has used the thing.

Branch the deadline by type, not by convention

The same field wants different arithmetic per kind of engagement — a project counts from go-live, a block of consulting hours counts from when it was sold and expires whether or not it was used. Two branches on one process, driven by the implementation-type field, is all this needs, and it stops the deadline being a thing people remember to set.

06Limits & trade-offs

A clone is a snapshot, and nothing reconciles the copies

This is the cost of the design, and it is worth paying, but it must be planned for. At the moment of cloning the two records agree. Afterwards both keep changing and no platform mechanism keeps them aligned.

The production deployment runs backfills in both directions:

• A daily scheduled job filling the customer-portal link on open delivery records from the account, for records created before the account had one.
• A manual job copying the go-live date from the account back onto the project, for the case where someone recorded it on the account first.

Neither is elegant. Both are necessary. Write them when you write the clone — the alternative is writing them in a hurry the first time somebody asks why two records disagree.

The clone fires on status, and line items may not be attached yet

The trigger is the deal becoming won; the per-service defaults are read from what the deal contains. If the status is flipped before the line items are on the record — an optimistic salesperson, an import, an integration writing status first — the service-mix branch sees an empty product list and the defaults are silently wrong. No error, just a delivery record with nothing planned on it.

Mitigations, in order of preference: trigger on a later signal that implies the products exist; or accept it and give the delivery team a view of records where the quantities are all empty, which is a five-minute filter and catches every instance.

There is no native convert-to-project

The platform has no built-in "turn this won deal into a delivery record" operation. What is described here is assembled from a create-related-record automation and field mapping you maintain. When the sales form gains a field the delivery record needs, the clone has to be told about it — nothing notices on your behalf.

Cross-pipeline reporting has to be assembled

"How long from won to live, by service mix" spans two record sets, and neither pipeline can answer it alone. This is the direct trade for clean per-pipeline metrics: you get truthful sales reporting and truthful delivery reporting, and the question that spans them costs a join. Copying the go-live date onto the account exists partly to make the common version of that question answerable from one place.

07Verification

Everything here fails quietly, so the checks are about records that should exist and do not, rather than about errors.

• Win a deal with each service combination and confirm a delivery record appears with the right quantities. One combination working does not mean the branch table is right; the defaults are per-mix and each mix is a separate path.
• Win a deal with no deliverable and confirm that nothing is created. The conditional clone is as much about what it does not do.
• Query for delivery records with all quantities empty. That is the fingerprint of the ordering hazard in §6, and it should be a saved view rather than an occasional check.
• Set a go-live date and check all four consequences — the account copy, both derived deadlines, the support notification, and the follow-up task the next day. Then change the date and check they all update. Re-firing on change is where this usually breaks.
• Reconcile the two copies as a query: delivery records whose go-live date disagrees with their account's. It should return nothing. When it does return something, the backfill either has not run or is running the wrong way.
• Run the manual twins on a record that is already correct and confirm nothing moves. A re-runnable process that is not idempotent is a worse repair tool than none.

What would signal a regression: a won deal with a deliverable and no delivery record; delivery records whose stage has not moved in longer than a typical implementation, which is either a stuck project or a process that stopped firing; any date field where a large number of records share one value, which means something stamped "today" across a batch.

Related blueprints

• Blueprint 003 — the prior question. Whether delivery deserves a pipeline, a custom entity or nothing at all is decided there.
• Blueprint 008 — the same argument about pipeline hygiene, applied to renewals: records that sit in a pipeline for reasons unrelated to selling degrade every metric the pipeline produces.
• Blueprint 009 — why a re-runnable derivation is the recovery tool, and what happens to date-stamping automation when it fires late.