A project kicks off. The delivery lead reads a one-page brief assembled from the deal, builds a plan, and runs it. Six weeks later the client asks why the data migration is not finished, and the delivery lead says it was never in scope. The client forwards the signed quote. It is in scope, on line four, and it was in the brief’s second bullet as “migration support” which the delivery lead read as advisory.
Nobody lied. The scope crossed a boundary as prose, and prose is lossy.
The closed deal already contains what delivery needs
The information delivery needs is not missing at the moment a deal closes. It exists, in structured form, in the records the sales process produced. The handoff problem is not discovery. It is transcription.
| What delivery needs | Where it already exists | What is lost when it is re-typed |
|---|---|---|
| Scope, line by line | The accepted quote’s line items | Quantities and unit-level detail collapse into a summary phrase |
| Commercial terms | Deal value, currency, payment schedule, agreed rate | The rate that priced the estimate, which is the rate the work must be delivered at |
| Contacts and roles | CRM contacts on the account, with their relationship to the deal | Who can approve, as opposed to who attends the calls |
| Dates | Expected close date, any committed milestones | The distinction between a date discussed and a date committed |
| Assumptions and exclusions | Quote notes, the deal’s activity history | Everything. This is the field that never survives a summary |
| Approval chain | Who signed, and under what authority | The name on the signature, which matters at the first change order |
The last two rows are where money is lost. An exclusion is a negative statement, and negative statements are the first casualty of summarising. A brief lists what will be done. It does not naturally list what was priced out.
Re-keying is not an inefficiency, it is a lossy conversion
The usual argument against re-entering deal data into a project tool is that it wastes twenty minutes. That understates it. The problem is not the time, it is that a human is compressing a structured record into free text, and then a second human is decompressing it into a different structure.
Both steps are interpretive. The compressor drops what seemed obvious at the time, and the decompressor fills gaps with what is usually true. Neither notices, because the output looks like a competent brief.
There is also a timing problem. The brief is almost always written by the person who is handing off, at the moment their attention has moved to the next deal. The document with the highest downstream consequence is produced at the point of lowest incentive.
The structural fix: reference the deal, template the method
Two mechanisms, and they solve different halves.
Reference the deal. The project should hold the deal’s identifier and read from it, rather than carrying a copy of its fields. A reference stays correct when the commercial record changes. It also means the delivery team can open the quote, the activity history and the account context from the project, instead of asking the account owner what was agreed.
A reference needs one guard to be useful: at most one live project may claim a given deal. Without that rule, a second project created by someone who could not find the first quietly becomes a second source of truth, and the two diverge from the day they exist.
Template the method. A project template holds your delivery method as structure: milestones, the tasks under each, and their offsets from the project’s start date. Applying a template to a new project materialises real milestones and real tasks, dated relative to the actual start.
The division is what makes this work. The template is the part that is the same for every client, and the deal is the part that is different. Teams that instead copy the last project and rename things carry the last project’s mistakes forward indefinitely.
The failure case: an exclusion that did not survive the summary
An agency sells a website rebuild. During negotiation the client asks about content migration for an eleven-year-old blog. The account executive prices it as a separate optional line, the client declines it, and the accepted quote carries the line at zero quantity with a note that migration is excluded.
The kickoff brief says “rebuild of marketing site, launch by end of Q3”. Accurate and useless. The delivery lead, planning a launch, assumes the existing blog posts come across, because they always do, and schedules two days for it.
The migration takes nineteen days. The posts have inconsistent markup, four hundred broken internal links and image references to a server that was decommissioned. None of it is billable, because the delivery team never raised a change order, because they did not know they were doing excluded work.
The exclusion existed, in structured form, on the quote. The project was built from a paragraph. Nineteen days of unbilled work was the cost of a conversion from structure to prose and back again.
What should not be copied across automatically
Automatic handoff is not the same as automatic commitment, and the distinction is worth enforcing.
Sales dates should cross as expectations, not as project dates. A close date is a forecasting field, and an expected go-live discussed in a negotiation is not a schedule. Copying either directly into a delivery plan creates a commitment no one has capacity-checked.
Optimistic effort estimates deserve the same treatment. The estimate that priced the deal was made to win it, under time pressure, without the delivery team in the room. It belongs in the project as a budget to track against, not as the plan.
And the project should start invisible to the client. A project record created at the moment a deal is won contains a draft plan, unvalidated dates and internal notes. Client visibility is a deliberate, later act, which is the subject of what a client portal should show.
How Oneop moves a won deal into delivery
In Oneop, a project can carry the identifier of the CRM deal it came from, so the commercial record stays reachable from the delivery record. That link is guarded: a project cannot take a deal identifier that a live project already holds, and an attempt to re-link is refused with a conflict rather than silently accepted. Two live projects cannot claim the same deal.
Stage gates on the sales side are what make the handoff worth having. A gate can require an expected close date, a quote or a logged activity before a deal moves stage, so the fields delivery depends on exist because the pipeline refused to advance without them, not because someone remembered.
Project templates hold milestones with day offsets and tasks with day offsets and story points, optionally pinned to a milestone. Applying one mints the project and materialises the milestones and tasks in a single transaction, dated relative to the project’s start date, so a failure part-way leaves no half-built project behind.
Underneath, a project task and a CRM task are the same object on one task engine, alongside tickets, invoices, purchase orders and inventory items. Dependencies, recurrence, watchers and saved views behave the same wherever the work came from, and a person’s workload is one list rather than one per module. Time approved against the project prices at a rate that is frozen onto the entry before it can be invoiced, and converts to a draft invoice exactly once under a locking read, so the same hours cannot be billed twice through Finance.
Project management is activated separately in Oneop, with the plan entitlement starting at Starter, and billing, public intake, role-based rates and the AI assistant are each independently switched.
The handoff audit
Take your last three projects. For each, find the accepted quote and compare its line items and notes against what the delivery team actually planned. Count the exclusions that survived. That number is the size of the problem, and it is usually zero.
The same boundary-crossing argument applied to orders and stock is in why CRM and inventory need the same customer and order context, and the identity half of it is in why your help desk and CRM should share the same customer record. For services businesses specifically, the delivery side of this is what agency operations lives or dies on.