# Planning a deployment The nine-box: one agreed planning grid that decides what gets configured, so the account is built from a plan rather than accumulated. Source: https://replicatelabs.ai/docs/admin/planning-a-deployment Last updated: 2026-09-03 --- The failure mode for a well-intentioned rollout is an account that accumulates. Someone builds a roleplay, someone else uploads a document, a scorecard gets written for one team, and six months later nobody can say what the deployment is for. The fix is one agreed planning grid, settled before anything is configured. ## The nine-box Three columns, three cells each. Every cell is a real job someone does, in their words.
Rep plays
Prepare for a named callA specific upcoming conversation, rehearsed against the buyer they will actually meet.
Work a stalled dealThe opportunity that has gone quiet, taken to the coach rather than to the forecast call.
Handle the objection we keep losing toThe one that actually costs you deals, practised until it is not a surprise.
Manager plays
Team snapshotWhere the team is and who needs an hour this week.
One repPreparing a specific coaching conversation with evidence.
Coverage riskWhere the forecast is thinner than it looks.
Foundation
Deploy across the teamOne scenario everyone runs, so results are comparable.
Standing cadenceThe rhythm that keeps it in the week rather than in a launch.
Review rhythmThe recurring look at whether anything is actually changing.
An example grid. Yours should be your organisation's jobs in your organisation's words. This one is illustrative, not a template to adopt.
## Each column compiles to something different This is the part that gets missed. The columns are not three lists of the same kind of thing.
Rep playsCompile into roleplays. Each cell yields a persona, a scorecard and optionally a product, bound into a roleplay whose scenario is the cell itself. See Building roleplays.
Manager playsDo not become roleplays. They are the manager coach surface, driven by its prompts and its button row, and they are configured with your provider.
FoundationNeither. These are programme decisions: which roleplays are published to which teams, what the standing cadence is, and how often you review.
The fan-out. Treating manager cells as roleplays is the single most common planning error, and it produces roleplays nobody runs.
## Agreeing it is the one human gate Everything downstream is a projection of the grid, so the grid is where the argument should happen. Once it is agreed, configuration is largely mechanical, and a cell that changes tells you exactly which objects to rebuild. Draft it from evidence rather than opinion where you can: recorded calls, the deals you actually lost last quarter, and what reps say they are stuck on. Then get it agreed by the person accountable for the number, not just by enablement. ## Keeping it honest Treat the grid as canonical. When someone edits a roleplay or uploads a document directly, that is fine, but it should be visible as drift from the plan rather than quietly becoming the plan. Revisit it once a quarter. Cells that no reps use are telling you something: usually that the cell described a job the business talks about rather than one anybody does.