Passing a deal to Delivery is not the same as transferring a usable commitment. Model the required information, the acceptance decision and the exception path before specifying CRM automations, integrations or notifications.
A closed deal is not yet an executable job
Consider a B2B maintenance provider. Sales agrees an annual contract with a new customer. A CRM workflow creates a service ticket when the deal is marked Closed Won. The ticket is generated successfully, but Operations cannot assign an engineer: the location, required work, response window and equipment list have not been confirmed.
The automation is operating as specified. The handover fails because the system transfers a commercial state without establishing the information required for an operational decision. More notifications will not fill that gap.
Model the handover as an explicit interface
| Interface element | Question to settle | Illustrative rule |
|---|---|---|
| Trigger | Which event makes the handover necessary? | Contract accepted, not merely deal marked won. |
| Payload | Which records describe the commitment? | Customer, site, equipment, service level, scope, planned start. |
| Producer | Who can verify each record at source? | Sales confirms commercial commitments; customer supplies site detail. |
| Consumer | Who decides whether the package is executable? | Service coordinator or authorised operations lead. |
| Acceptance | What conditions allow planning to begin? | Required service level and equipment scope confirmed; resource feasibility checked. |
| Exception | What happens when requirements are missing or contradictory? | Return for clarification with reason and owner; do not silently proceed. |
Only after these rules are agreed can an implementer decide whether the interface belongs in CRM workflow, a field-service platform, an integration layer or a manual review step. Not every handover needs a new application.
Map responsibility separately from system permissions
Software can prevent a transition when a declared condition fails. It cannot decide which commercial promises the company is prepared to make, what level of delivery risk is acceptable or who has the authority to reject an incomplete order. Those are operating-model decisions.
I would ask the prospective sponsor who owns the handover result. If Sales owns submission but Delivery bears the cost of omissions, there must be an agreed acceptance authority and a response to disputes. Without it, a validation rule can merely move the disagreement to another screen.
What data granularity does the receiver need?
A single deal may cover several sites, different equipment, separate delivery dates or multiple service levels. If the downstream system plans work at site or job level, deal-level fields may be the wrong data structure. This is a modelling problem, not simply a data-completeness problem.
Record the entity whose state changes: contract, service location, installed asset, work order or visit. For each entity, specify its identifier, owner, allowed states, event timestamps and relation to the commercial commitment. Avoid duplicating the same operational state across systems without an authority rule.
Decide whether a technical intervention is justified
| What the investigation shows | Next action |
|---|---|
| A complete handover package exists, but two systems cannot exchange it. | Evaluate an integration against volume, latency, reliability and support cost. |
| Inputs are inconsistent because definitions and owners differ. | Agree the process contract and responsibility before system development. |
| Acceptance is manual but timely and accurate at current volume. | Document the control; automation may not provide enough additional value. |
| Work cannot be planned because asset/job records do not exist at the required granularity. | Assess the operational data model before choosing a CRM custom object or separate system. |
What I would return to the IT supplier
The assessment should identify the failing decision, the documented boundary of the existing implementation, the missing evidence and the smallest question that could resolve it. For example: “Can Operations reject a sold service package before engineer capacity is committed, and where is that rejection recorded?”
If the client already has an effective acceptance process outside the CRM, a new workflow may not be warranted. If there is no acceptance rule, an implementation project should not be quoted as though the rule were already settled.
Related: Business decisions and system coverage · Where operational records belong.
Scope of the note. This is a diagnostic framework, not a finding about any particular client. Examples are illustrative. Evidence from the actual client and system is required before recommending implementation work. Method and responsibilities.