White-labelling a report means customising the document a client receives. White-labelling the operations layer means configuring every client-facing surface, including access environments, status pages, and communication standards, to carry the agency’s brand. The operations layer is what clients interact with between reports; the report is one output of that layer.

Assign each client a Guest agent role through the Workspace access tier settings. This gives clients a view of their site status and relevant decisions without exposing the Command Center, Connectors, or Skills the agency uses internally.

Yes. Workspace-level configuration, including branding kit settings, access tiers, and site status standards, applies across the entire fleet. Per-site customisation is available within that framework for clients with specific requirements.

The Playbook’s Chapter structure separates client-facing content from internal operational records. Reports and status updates draw from the Brand, Decisions, and Conversations Chapters, while Internal Chapter entries remain inaccessible to Guest agent access tiers.

A runbook is a type of standard operating procedure, but written specifically for execution under time pressure. Runbooks include explicit trigger conditions, rollback paths, and failure modes that a general SOP often omits. The defining test: a runbook should be self-sufficient for anyone on the team, including someone new to the operation, without requiring additional guidance from a senior colleague.

Long enough to be self-sufficient, short enough to be read under pressure. A well-structured entry for a site launch typically covers one to three pages: trigger condition, a numbered procedure of 10 to 20 steps, a verification checklist, and a rollback path. Entries that run longer often carry information that belongs in site records or separate reference documents. If an entry requires deep background reading before execution, it needs to be split.

After every incident that required improvisation, after every significant change to the agency’s operating environment (new server infrastructure, a major WordPress release, a change in standard procedure), and on a quarterly scheduled review for entries that have not been touched. The incident-driven updates matter most: do not wait for the quarterly review to record what an incident has already exposed.

One runbook covers all clients. The runbook holds the constant procedures; the site-specific variables (URLs, contacts, constraints, baselines) are recorded in each client’s site record. Running the site launch procedure means following the runbook and substituting the variables from that client’s record. This structure scales to a fleet of any size without duplicating procedures, which is what makes consistent delivery across many clients operationally possible.

The core provisioning sequence, including Playbook setup, branding kit configuration, fleet connection, and Connector activation, takes two to three hours spread across the first three days of a new engagement. The most time-intensive part is populating the Playbook’s Brand, Audience, Decisions, and Internal chapters from the discovery brief. Agencies that maintain a provisioning template in their Playbook reduce this to under ninety minutes per new site.

The site agent operates from an empty context and produces generic outputs until the Playbook is populated. There is no technical consequence, but every session before the Playbook is complete is a session the operating layer cannot draw on later. Populating the Playbook retroactively is possible but more time-consuming than doing it at provisioning, because you have to reconstruct decisions that were fresh during the discovery phase.

The Playbook is per-site, but agencies can copy entries from existing sites when a new client operates in the same vertical or has similar requirements. The recommended approach is to maintain a set of agency-level template entries in a dedicated Playbook site in the Workspace, then copy and customise them at provisioning. This is how the Skills library compounds: patterns that proved effective for one client become the starting point for the next.

Once a site is in the fleet, WordPress maintenance including update monitoring, status changes, and recurring operational tasks runs through the Command Center. The site agent draws on Playbook context when flagging maintenance tasks, so a site with a detailed Decisions log surfaces maintenance flags with more relevant context than one with a minimal Playbook. Fleet-level maintenance visibility runs through the Workspace across all connected sites.

The access and configuration layers can be transferred in a few hours if they were documented during delivery. The context layer, including decisions, stakeholder maps, and known constraints, typically takes one to three days if it was not captured progressively. Agencies that document decisions in real time throughout a project reduce handoff time to a half-day verification pass.

The context layer: the reasons behind architectural decisions, known client preferences and constraints, and a stakeholder map. Access credentials and configuration details are necessary but recoverable. The reasoning behind why the site is built the way it is cannot be recovered once the people who built it move on.

The only reliable protection is a decisions log written progressively, not retrospectively. If every significant decision is recorded at the time it is made, with a brief note about what was considered and what the client required, a new developer can pick up the project without needing a knowledge transfer session from the person who is leaving.

Both. The outgoing developer writes the technical context: why specific code exists, what was considered and rejected, known quirks. The agency lead writes the relationship context: stakeholder map, client sensitivities, ongoing commitments. Neither produces a complete handoff record alone.

WordPress Playground is a browser-native WordPress environment that runs in WebAssembly, requiring no server setup, no hosting, and no teardown. A staging site is a persistent, hosted environment that mirrors production. Playground is disposable and ephemeral: you spin it up to run a specific test, then discard it. For update pre-flight testing, the speed and disposability of Playground make it more practical than maintaining a dedicated staging server per client.

The WordPress Playground CLI is available to download as an npm package. You do not need to install it permanently: run npx @wp-playground/cli to download and invoke it on demand. To launch a local Playground server from a blueprint file, run: npx @wp-playground/cli server u002du002dblueprint=blueprint.json. The blueprint is a JSON file that specifies the WordPress version, PHP version, plugins to install, and any setup steps to run on first boot.

For major core releases, test core first against your existing plugin set to isolate any core-specific regression before plugins introduce additional variables. Once core passes your pre-flight checks, update plugins one at a time or in small batches, running a focused check after each update. For security releases, the risk profile is lower and you may abbreviate the sequence. The key principle is that the Playground environment is where you answer this question for each specific release, not in production.

Playground replicates the WordPress version, PHP version, plugin set, theme, and imported content accurately enough to catch the majority of regressions. What it does not replicate exactly is server-level configuration (web server rules, server-side caching, environment variables) and the full production database. For most update pre-flight purposes this level of fidelity is sufficient. If a regression is server-configuration-dependent, a dedicated staging environment is the right tool for that specific check.