--- title: "How do you hand a won deal over to the team that delivers it?" blueprint: 010 slug: handover-from-sales-to-delivery category: Handover revised: 2026-09-09 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/blueprints/handover-from-sales-to-delivery/ publisher: Coevera customer_data: none --- # How do you hand a won deal over to the team that delivers it? **Short answer.** Give delivery **its own pipeline**, and clone the won opportunity into it. Do not add delivery stages to the end of the sales pipeline — one record moving through two lifecycles corrupts conversion rate, sales cycle and weighted forecast all at once. Clone **conditionally**, on whether the deal actually contains something to deliver, and set per-service defaults on the new record from what was sold. Then treat the go-live date as a single field change that **fans out**: onto the account, into derived deadlines, and outward as the handoff to support. The part everyone discovers late: a clone is a **snapshot**, the two records drift, and nothing reconciles them. Write the backfill jobs at the same time as the clone. ## 01 · The 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. ## 02 · Why 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. ## 03 · Data 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: | Stage | What it means | Exit condition | |---|---|---| | Waiting for payment / intro | Won, not yet started | Payment received and intro meeting held | | Setup in progress | The implementation clock is running | Configuration complete | | User training — system live | Customer is using it | Training delivered | | Services delivered | Done | — | 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](https://blueprints.coevera.com/blueprints/where-should-this-data-live/) 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. ## 04 · Field-level configuration The delivery record needs a small set of fields that the sales record has no use for. | Purpose | Type | Set by | Notes | |---|---|---|---| | Type of implementation | Dropdown | Clone / manual | Branches the deadline rules — see §5. Project versus consulting hours behave differently. | | Per-service quantities (setup, training, data, admin training) | Numeric | **Clone, from the product mix** | Defaults per service combination, so the record arrives populated rather than empty. | | Project start date | Date | Process, at initiation | Not the won date. The implementation clock starts when work starts. | | Go-live date | Date | Manual | The single field that fans out. See §5. | | Onboarding end date | Date | Process, derived | Computed from go-live. | | Training must be completed by | Date | Process, derived | Computed from go-live *or* from record creation, depending on implementation type. | | Customer portal / subscription link | URL | Clone, plus a backfill job | Frequently empty at clone time. See §6. | | Go-live date *on the account* | Date | Process, from the project record | So account-level automation can see it without traversing to the project. | > **Why the account carries its own copy of the go-live date.** It is duplication, and it is > deliberate. Account-side automation — customer-success cadences, health checks, anything > scheduled — needs to filter on "is this customer live and since when" without reaching across to > a related record. Coevera's calculated fields can only reference fields on the same entity, so a > derived field on the account cannot read the project's date. Copying it at the right moment is > the mechanism that makes it available. ## 05 · Automation & 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: | Process | Trigger | What it does | |---|---|---| | The canonical setter | Go-live date changes | Copies the date onto the account; computes the onboarding end date | | Deadline derivation | Go-live date changes | Sets the training deadline, branching on implementation type | | Support handoff | Stage becomes *system live* | Notifies support with licences, tier and implementation scope | | Loop closure | Scheduled, the day after go-live | Notifies the owner and creates a follow-up task | 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. > **Every automatic setter wants a manual, re-runnable twin.** The production estate pairs the > go-live setter with a manually-triggered process containing identical logic. > > The reason is structural, not defensive: a process that fires on change cannot be replayed. > Go-live dates move, records get created out of order, an automation is disabled for an > afternoon. Without a manual twin, the only repair is editing fields by hand and hoping you > remembered all of them. The same reasoning appears in [Blueprint > 009](https://blueprints.coevera.com/blueprints/automating-on-integration-owned-fields/), where a > re-runnable derivation is the recovery tool for a whole class of failure. ## 06 · Limits & 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. ## 07 · Verification 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](https://blueprints.coevera.com/blueprints/where-should-this-data-live/) — the prior question. Whether delivery deserves a pipeline, a custom entity or nothing at all is decided there. - [Blueprint 008](https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist/) — 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](https://blueprints.coevera.com/blueprints/automating-on-integration-owned-fields/) — why a re-runnable derivation is the recovery tool, and what happens to date-stamping automation when it fires late. --- Published by Coevera. Abstracted to the reusable pattern — no customer names, no client data, no personal data.