Agency handoff playbook
How an agency brings a client website into Dispatch, configures it for the client’s team, and hands it over without losing the record.
Dispatch governs the work; the client’s own coding agent, repository, and host execute it. Nothing in this playbook asks you to move code, hosting, or content into Dispatch.
Before you start
Decide up front which organization the site lives in. A client site belongs in the client's Dispatch organization, with agency staff invited as members, so ownership transfers cleanly at handoff. Sites created inside the agency's organization have to be reconnected later.
Phase 1
Exit criteria: the Activity page shows a commit and a deploy from the client's real repository, the Slack channel has received one Dispatch message, and every page on the site has a score.
From Websites, choose Connect a website: name, production URL, repository, default branch, deploy platform, framework, and the coding agent the team uses. Dispatch validates the repository and the host before it saves anything; a dead token is refused, not stored.
On the site's Activity page, follow the setup card for the repository webhook and the deploy webhook. Dispatch tells you when a secret is stored and armed. Cloudflare Workers has no deploy webhook; Dispatch polls builds with the stored token instead.
Run the page sync so the site map, source paths, and the first AEO score per page exist. This is the baseline every scheduled crawl is compared against.
In site settings, paste the Slack incoming webhook. Only URLs on Slack's webhook host are accepted. Send one test transition and confirm the message lands in the channel.
Approvers receive email for preview-ready, approved, and live transitions. Check that each approver's profile email is one they read.
Phase 2
This is where the client's judgment gets written into the system, so the agent, the approvals, and the crawl all behave the way the client would.
Run the intake with the client: brand voice, banned claims, tone, product facts, and the source documents behind them. Mark what the client has signed off as approved.
Set these per site, with the client's approver in the room.
Settle in writing who approves what, and whether agency admins may approve at all during the engagement.
Phase 3
Do one real change together before anything runs on its own. When it is done, the request page shows the whole trail: who asked, who approved, the commits, the deploys, and the time from intent to live.
From the site's Requests tab, say what should change and why, pick the target page, pick the tier. Dispatch drafts the agent handoff prompt with the request, the page's source files, and the approved context.
Copy the prompt into the coding agent the client uses. The prompt names the working branch and the request id and tells the agent not to merge.
When the agent pushes to the named branch, the commit, the pull request, and the preview deploy attach to the request on their own and the request moves to preview-ready. Approvers get the Slack message and the email, each carrying the request summary, the page, the tier, and the next step.
The approver opens the preview from the message. Approve, or send back with a note; a send-back regenerates the handoff prompt with the revision on top and clears any approvals the old preview had.
Merge the pull request, confirm the production deploy lands in the activity feed, mark the request live.
Use restore on the change so the client sees what one-click reversal looks like before they need it.
Handoff checklist
Work through this with the client owner present. Do not skip the confirmations; each one is a thing that silently breaks after the agency leaves.
Weekly operating rhythm
For the person who owns the site after handoff. When a change goes wrong, restore first and discuss second. The record is the point: every request, approval, commit, and deploy stays attached, whether a person or a policy made the call.
Approve or send back everything awaiting you. A request waiting more than a week is either not important or stuck; close it or ask.
For each finding from the week's crawl, either draft the fix (it opens a request with the page context attached) or dismiss it with a reason.
Look for anything that shipped without a request. Direct pushes to the default branch are the thing governance exists to catch; talk to whoever made them.
For the pages that matter most, a page that slipped is a request waiting to be written.
Is the low-risk tier still being used for low-risk work? Do the approvers still work here? Is the crawl cadence right for how often the site changes?
The Inbox, findings, autonomy levels, and alerts this playbook relies on are all in production today.