The handoff is the bug

Ask a services team where they lose the most time and almost nobody says selling or delivering. They say the part in between. The deal closes on a Friday. The kickoff happens the following Wednesday. In those four days, the work does not pause so much as fail to start.

We spent a long time treating this as a discipline problem — a checklist somebody forgot, a template nobody filled in. It is not. It is a data problem wearing a process costume.

What actually goes missing

When a rep closes a deal, they are holding a specific and perishable set of facts: what the customer actually asked for, which constraint they mentioned twice, who signs off, and what will go wrong first. None of that is in the contract. Most of it is in notes, call logs, and a thread nobody outside the deal has read.

The handoff meeting exists to move those facts from one head to another. It is a lossy transfer under time pressure, run by someone who has already moved on to the next deal. The delivery team gets a summary of a summary, then spends its first week re-discovering what was already known.

A handoff meeting is a manual export of context that was already written down, into a format nobody keeps.

Why templates do not fix it

The obvious answer is a project template. Every won deal gets the same eight tasks, and the team edits from there. We built that first. It fails in a specific and predictable way: the template is right about the shape of the work and wrong about all the details that matter, so the first thing anyone does is delete half of it.

Worse, a template that is mostly wrong is more expensive than a blank page, because now someone has to audit it. The team stops trusting generated tasks and starts ignoring them, which is how you end up with projects carrying eleven tasks nobody has looked at since day one.

Reading the record instead

The facts the delivery team needs were never missing. They were sitting on the lead the whole time — in the notes the rep wrote after each call, in the referral that explains why this customer trusts you, in the objection that will resurface during implementation.

So the trigger we built does not fill in a template. When a lead moves to Closed/Won, it reads the accumulated conversation on that record and proposes a milestone and task breakdown from what is actually there. A customer who spent three calls worrying about their driver roster gets a task about the driver roster.

What we deliberately left out

The generated plan is a starting point, not an authority. It creates real tasks that a human immediately owns, edits, and closes. It does not set a project status, it does not email the customer, and it does not decide the deadline. Anything that leaves the building is either written by a person or computed from state that a person can check.

• If Slack is not connected, the channel step is skipped and logged — the rest of the run still completes.
• If the drafted plan is wrong, deleting a task costs one click and no meeting.
• If the model returns nothing useful, you still have a project, an owner, and the lead history attached.

The result is boring, which is the point

Nothing dramatic happens when a deal closes now. A project appears with a handful of tasks that look like the conversation, the owning rep gets a notification, and a Slack channel opens with a two-line summary. The Wednesday kickoff still happens if the team wants it — but it starts from work already in motion rather than from a blank page and a fading memory.