How to Provision a New WordPress Client Site From Your Agency Playbook

Provisioning, for an agency running an operating layer, is the act of wiring a new site into the accumulated context of your entire fleet before the first client conversation begins. The traditional definition covered server setup: domain, hosting, database, WordPress install. That sequence still runs. But for agencies operating a fleet, provisioning now has a second layer that matters more to long-term delivery than the server choice does.

Before anyone opens a page editor or picks a color palette, the site needs to exist inside the operating system. Three things are in place before the work starts:

• The Playbook for this client is open and pre-populated with what you already know: industry, audience, and decisions from comparable clients in the fleet.
• The branding kit is configured so every output from this point forward reflects the client’s identity, not a generic default.
• The site is visible in the Workspace alongside the rest of the fleet, so pattern detection runs from day one rather than being retrofitted after launch.

Agencies that skip this step spend the first month building institutional knowledge that should have arrived on day zero. The ones that run a deliberate provisioning sequence find the site operating at full capacity weeks earlier, and the compounding effect of the Playbook kicks in from the first conversation rather than the tenth.

The Playbook entries you write before launch are the most valuable ones you will ever write for this client, because every subsequent entry references them. The Playbook’s Brand and Audience chapters are not post-launch documentation; they are provisioning inputs that shape every command the site agent runs from the first session.

Here is what to populate before the WordPress install is complete:

• Brand chapter: Client name, primary and secondary colors, typefaces, and tone notes (formal, conversational, or technical), plus anything from the brief or discovery call that would otherwise sit in a document and get lost after the project lead rotates off the account.
• Audience chapter: Who the client’s site serves, primary geographic markets, and any audience language that differs from the client’s own. This is what prevents the site agent from defaulting to generic copy on the first task.
• Decisions log: Log the decisions made during the sales or discovery phase. A note like Client requested no e-commerce now but wants WooCommerce-ready architecture is a Playbook entry, not a message in a chat thread that will scroll out of reach within three weeks.
• Internal chapter: Which team member owns this site, the contact cadence, and the billing structure. Context that matters to operations but is never client-facing.

Populating these four areas before launch means the first time anyone opens the Command Center for this site, they are working with a fully contextualised operating layer rather than a blank screen.

A branding kit configured before the first commit ensures every asset the operating layer produces for this client is consistent, without a team member checking it manually on every pass. The branding kit lives inside the Command Center and ties directly to the Playbook’s Brand chapter, so the two stay in sync as the engagement develops.

Three inputs are required at provisioning:

1. Primary hex values: Enter the client’s brand colors. If the brief includes a full palette, add secondary and tertiary colors now so the operating layer never defaults to arbitrary choices.
2. Tone directive: One sentence describing how the site agent should communicate on behalf of this client. Make it specific: not professional but direct, evidence-first, addressed to procurement leads at mid-market SaaS companies. This single sentence is the highest-return input in the provisioning process.
3. Vocabulary controls: Add the terms the client uses specifically and the terms they have asked to avoid. Brand language they expect to see, and competitor language that is off-limits.

This configuration takes under ten minutes at provisioning. Skipping it means correcting outputs manually every week for the lifetime of the engagement, because every generated draft will require a tone pass that the branding kit would have made automatic.

Adding the new site to your fleet in the Workspace is what activates fleet-level pattern detection; until the site is there, the operating layer cannot compare it against your other sites or surface cross-client patterns that reveal risk before clients see it. Once the WordPress install is live, add it as a new site from the Workspace and install the Command Center from wp-admin. From that point, the site is part of the fleet.

For agencies already managing multiple WordPress sites, a fleet-wide view of site health becomes the primary way to catch drift before clients notice it and the primary source of the pattern detection that makes the operating layer compound in value across every client engagement.

Two things to confirm at connection:

• Site status: Set it correctly in the Workspace: In Development, Live, or Maintenance. This determines how pattern detection scores the site and what the site agent flags as requiring attention.
• Fleet-wide Connectors: Any Connectors that apply across the entire fleet (your project management platform, your reporting stack) are inherited by the new site automatically. Client-specific Connectors require a separate step covered in the next section.

At this point the site is in the fleet. It is not yet fully operating. The Playbook has context, the branding kit is active, and the site is visible in the Workspace. What remains is client-specific Connector and Skills configuration.

The Connectors and Skills you configure in the first week determine how much of the agency’s existing stack this site operates within, and how much manual handoff remains between the operating layer and the client’s own systems. WPOS connects to over 1,000 external services. Not all of them apply to every client. The provisioning task is to identify and activate the ones that do.

Priority Connectors for a new client site:

• CRM: If the client manages leads through a CRM, wire it in at provisioning. This lets the site agent surface contact context during content and WordPress maintenance tasks without requiring a team member to switch platforms to check it.
• Project management: Connect your agency’s project management platform so tasks created in the Command Center appear in the same queue as the rest of your delivery work. This is a fleet-wide Connector for most agencies; confirm it is active for the new site.
• Analytics: Wire in the client’s analytics account so site status reporting draws on real traffic data, not just uptime. A site the client considers performing well deserves a Playbook entry logging why.

For Skills, review the agency Playbook library and activate the ones relevant to this client’s vertical. A Content Review skill built for a similar client last quarter may apply directly here. The Skills library compounds in value across the fleet the more consistently it is applied at provisioning rather than added mid-engagement under delivery pressure.

The first week is the highest-return configuration window: the Playbook is fresh, the client is engaged, and corrections to context cost minutes rather than months of compounding misalignment. A structured sequence keeps the provisioning work from getting absorbed by delivery pressure before it is complete.

Days 1 and 2: Complete the pre-provision Playbook entries across the Brand, Audience, Decisions, and Internal chapters. Configure the branding kit with colors, tone directive, and vocabulary controls. Add the site to the Workspace fleet and set the correct status.

Day 3: Activate fleet-wide Connectors and confirm they are running for the new site. Add client-specific Connectors for the CRM, analytics platform, and any service the client manages directly. Assign Skills from the agency Playbook library.

Days 4 and 5: Run the first Command Center session for this site. The site agent’s first responses will draw on the Playbook context you set on day one. Correct anything that is wrong immediately: early Playbook corrections carry the greatest return because they prevent an error from compounding across every subsequent session. Log the corrections back to the Decisions chapter.

By the end of week one, the site is operating. The Workspace shows it in the fleet with the correct status. The Playbook holds a minimum of seven entries. The branding kit is producing consistent outputs. Review the current plan tiers to confirm your fleet size and Skills capacity for this client.

The WPOS provisioning sequence separates client-facing access from agency-level context, so you hand the client a site they can operate without exposing the operational layer your agency built over months of delivery. This is one of the structural advantages of running an operating layer over running a collection of individual sites: the institutional knowledge is in the system, not the personnel.

Traditional agency handoffs carry a hidden cost. The project lead knows why the template is structured a certain way. The account manager remembers what the client rejected in discovery. When those people move to other accounts or leave the agency, that context goes with them. Every new person who picks up the site starts the same reconstruction process. The context cost compounds quietly.

The WPOS provisioning sequence builds differently. The Decisions chapter logs why choices were made. The Internal chapter holds team context. The Conversations chapter preserves the reasoning behind major calls. None of that is visible to the client in normal operation. What the client sees, if you extend them access, is the Command Center for their site: the operational view of their site’s health, the branding kit, and the ability to log their own requests.

Guest agent access lets a client interact with the site agent without seeing the agency’s fleet structure, Playbook architecture, or Skills library. The handoff gives them operational capability. It does not export your operating system. That distinction compounds in value every month you run the engagement: six months in, the Playbook holds context no individual person carries. At twelve months, it holds context no individual person could carry.