Automate the handoff from sales to onboarding or delivery

What goes wrong at handoff

Most handoff problems are information problems, not effort problems. A salesperson knows a lot that never made it into a field: what was promised, what the client cares about, who actually decides, which deadline is real. When that lives in a call memory or a long email thread, delivery reconstructs it by asking the client again, and the client's first impression of the new relationship is repeating themselves.

• Promises made in the sale that delivery only learns about when the client mentions them.
• Contact details for the wrong person, or only one contact when three are involved.
• Scope described differently in the proposal, the CRM note and the contract.
• No agreed start date, so nobody knows whether the work is late.
• The handover email goes to a shared inbox and nobody is sure who picked it up.

Required fields at close

Decide what delivery needs on day one, and make the deal unable to move to Won without it. Keep the list short: every extra required field is friction for the person closing, and a long list gets filled with placeholders. A useful method is to ask delivery for the last five kickoffs, what they had to ask the client that sales could have recorded. Those answers are your fields.

Typical candidates are the agreed scope in a sentence or a link to the signed document, the primary contact and the decision maker, the requested start date, anything non-standard that was promised, and the commercial terms that affect how the work is set up. Use structured fields, such as pick lists and dates, wherever the answer is one of a known set. Free text is for the nuance, not for facts you will need to filter on.

Triggers

The trigger is normally the deal moving to a closed-won stage. Make that stage mean one thing. If reps use Won for both verbal agreement and signed contract, the automation will start work on deals that are not real. Decide which event is the trustworthy one, and if it is a signature, trigger from that rather than from a rep's click.

Also decide what happens on reversal. If a deal is moved out of Won by mistake, the workflow should not have already sent a client-facing email. A common pattern is to make internal actions immediate and client-facing actions wait for a short confirmation window or a manual approval on the first version.

Task and record creation

On trigger, the workflow creates the delivery record in whatever system delivery works in: a project, a ticket, a row in an operations database or a case in a custom tool. It copies the fields from the deal, links back to it, and creates the standard task set for that type of work. Templates matter here. If every engagement type has its own task template, the automation picks the right one from a deal field, and exceptions are handled by a person adjusting the tasks, not by a different workflow.

Copy by reference where you can. If the delivery record links to the deal and reads the contact from it, an update to the phone number is not stuck in two places. Where the two systems must each hold a value, decide which system owns it; the page on choosing a system of record for integrations covers that decision.

Owner notification

Assign a named owner in the record, then notify that person where they work. A notification to a group inbox is a suggestion; a task assigned to a person is a commitment. If the owner is chosen by rule, such as by client region or service line, write the rule down and put a fallback in it, so an unassigned record goes to a coordinator instead of nowhere.

Include in the notification the few things the owner needs to start: who the client is, what was sold, the promised start, any flagged promises, and a link to the deal. Aim for a message that lets them act without opening three systems first.

The missing-information loop

Even with required fields, information will be missing or wrong. Design for it. When delivery finds a gap, the workflow should let them mark it in one action, which sends a specific question to the salesperson and sets a reminder. When the answer arrives, it writes back to the record and clears the flag. The loop should have a visible age: a handoff that has been waiting for information for several days should appear on someone's list.

If the missing information must come from the client, route it through a defined intake step rather than an ad hoc email. Doing this once, in one place, is what stops the client being asked the same question by two of your people.

What stays human

Automation should move information and create the structure. A person should still decide staffing on unusual work, judge whether a stated scope is realistic, and hold the kickoff conversation. A short live handover between salesperson and delivery owner is worth keeping for larger or more sensitive engagements, and the workflow can prompt for it instead of replacing it. Failures in the workflow itself are a separate topic; see workflow exception and escalation design for how to own the cases the automation cannot resolve.

How LATYNEX scopes this

One handoff workflow across up to three systems fits the fixed-scope Automation Sprint (€1,690). Several service lines with different templates, custom permissions or a custom delivery tool is larger custom scope, quoted once we map the process. We do not assume any particular ready-made connector exists between your tools; we confirm what the two systems actually expose before promising a design. The Automation Opportunity Finder helps you check whether handoff is your best first workflow, and the wider service is workflow automation and systems integration.