Resources · automationagenciesoperations
Automate agency project handover - stop delivery starting from a sales call
To automate an agency project handover, create one card from the closed-won record and stop delivery until sales approves it. The card should state the promised outcome, exclusions, source links, named owner, next decision, deadline, and known risks.
This is not another project-management template. It is a control that prevents delivery from starting with an incomplete version of what was sold.
What must be on a project handover card?#
A delivery lead should be able to read this card without joining the sales call.
| Field | What it answers |
|---|---|
| Promised outcome | What result did the client buy? |
| Deliverables | What will the team actually produce? |
| Exclusions | What is clearly outside the agreement? |
| Source links | Where are the proposal, contract, notes, and assets? |
| Client context | What does the team need to know before kickoff? |
| Named owner | Who owns the next client decision? |
| Deadline and dependencies | What date matters, and what could block it? |
| Risks | What was uncertain during the sale? |
The exclusions field matters as much as the promise. It gives the team a reference when a new ask arrives later, which is where a visible scope-change record helps.
Why is a sales-call replay not enough?#
A recording can hold context, but it does not create a decision. Delivery needs the sales person to say what is true, what is uncertain, and what was not sold. Asking a busy team to find that in an hour of audio moves the handover problem downstream.
The card also gives the client one consistent story. When sales and delivery use different words for the work, trust drops before the first deliverable. Client onboarding begins more cleanly when the kickoff brief is already verified.
How does the handover build actually go?#
We first map the records sales already uses when a deal closes. We write the card fields in the owner's language and agree which source is authoritative for each field. The client keeps that card structure, the source links, and the final approved cards.
Then the build reads the closed-won record and creates a draft card in the delivery workspace. It can pull existing notes and attach the proposal. It does not invent an exclusion, set a deadline, or tell delivery to begin. The salesperson receives the draft and confirms or corrects it.
We shadow-run the card against several past wins. Sales and delivery compare the draft with the first-week questions that actually came up. If a field cannot be completed from the source records, that is a sales-process gap, not a prompt to hide. Once the card is complete, an approved version opens the onboarding sequence.
The approval is a real gate. It belongs before project creation, not as a checkbox someone can ignore after work starts. The same pattern is useful for client approvals: one named decision maker and a visible state.
What should sales and delivery test this week?#
Take the latest signed client. Give the delivery lead the proposal and ask them to fill the card without speaking to sales. Every blank field is a future handoff problem. Fix the card, not the person's memory.
Where does this fit with the rest of the operation?#
This early control makes the sequencing in scaling an agency without hiring more reliable because delivery begins with facts, not memory. The shadow run follows the same cost-saving discipline in what an automation build costs.