Sales has marked the job as won, but delivery doesn't have the access instructions, agreed scope or customer's preferred date. Creating a project automatically won't solve that gap on its own.
Automate the handoff around a readiness check. The next team should receive the information it needs, an owner and a clear way to say that something is missing.
Agree what “ready” means
Pick a real handoff and ask the receiving team what they need to begin. A fictional installation company might require the accepted job version, site address, access contact, equipment list and confirmation that a survey is complete.
Classify each item as required before scheduling, required before attendance or useful background. That avoids blocking every task on information that isn't needed yet. It also prevents the system treating a sales note as permission to book a visit.
A project can be created in a waiting state when a sale is agreed. Scheduling should happen only when the conditions for scheduling are met. Those are different events.
Give the receiving team a real acceptance step
Use a short handoff record that names:
- the job and version being handed over.
- the person sending it and the receiving owner.
- the scope and any agreed exclusions.
- the readiness checks already completed.
- missing items, risks or unusual commitments.
- the next action and its due date.
The recipient should be able to accept the handoff or return it with a specific reason. A notification marked “delivered” doesn't prove that the team has accepted responsibility.
If your platform has approval actions, check which action actually waits for a response. Microsoft distinguishes creating an approval from waiting for its outcome. The practical lesson is to make sure downstream work depends on the intended decision, rather than the sending of a request.
Don't turn a date field into a promise
Keep requested dates, provisional slots and confirmed appointments separate. A customer preference isn't a booking, and a task appearing in a staff calendar isn't proof that the customer has been told.
Before anything confirms an appointment, decide who checks capacity, travel, dependencies and any special requirements. You might automate preparation of available options while leaving final confirmation to the scheduler.
For the fictional installer, an accepted handoff can create an internal scheduling task. It doesn't need to choose an engineer and email a fixed arrival window immediately. The first improvement is getting a complete job to the right queue.
Make later changes travel with the job
Once delivery has accepted a handoff, sales may still receive a scope change. Don't silently replace the original description and hope the team notices.
Record the changed version, what differs and who needs to acknowledge it. If the change affects a booking or purchase, flag those dependencies for review. A single “updated” notification is easy to miss among routine messages.
Cancelled jobs also need an explicit route. Decide which open tasks should close, which commitments need a person and who confirms that the cancellation reached the customer. Deleting a project record can hide the evidence needed to finish that work.
Demonstrate the handoff before widening it
Run fictional examples through both teams. Include a complete job, a job missing a required survey, a revised scope after acceptance and a cancellation after provisional scheduling.
Ask the receiving person to explain their next action from the record. Then repeat the same accepted-sale event and confirm it hasn't created another project or booking task.
Useful measures include handoffs returned for missing information, time waiting without an owner and rework caused by changes that didn't reach delivery. A run count won't tell you whether the customer still has to repeat everything to the next team.
Keep the first version within one handoff. Once the team can see that it works, the same approach can guide the next connection without trying to automate the entire business at once.