WordPress Agency Client Onboarding - A Process That Actually Works

A structured WordPress client onboarding process reduces scope creep and sets clear expectations. The full process from intake to post-launch handoff.

Dobromir Dechev
Dobromir WordPress agency owner

Most agency project problems - scope creep, unclear expectations, delayed launches, and unhappy clients - have their roots in a bad onboarding process. What you collect from the client before the project starts determines how smoothly the project runs.

This is the onboarding process we run on every new WordPress project. Adapt it to your context, but the structure is sound.


Phase 1 - Pre-project intake

Before a contract is signed, you need enough information to price accurately and identify red flags.

Discovery call checklist

Run through these in the discovery call. Take notes - they inform the proposal:

Business context:

  • What does the site need to do? (Lead generation, e-commerce, content, portfolio)
  • Who is the target audience?
  • What does success look like in 6 months? (Specific metrics if possible)
  • Why are they building/redesigning now?

Technical current state:

  • Existing site? What platform?
  • Who manages it currently?
  • Any existing integrations? (CRM, email, booking systems, payment processors)
  • Any past technical incidents? (Hacks, data loss, major downtime)

Red flags to probe:

  • "We need this by next week" (scope underestimation)
  • "Our last agency disappeared" (unclear what happened there)
  • Multiple people have conflicting views on what the site should do
  • They are not sure who the final decision maker is

Document everything. The proposal should reference specific things the client said - it signals you actually listened.

Intake form (send after discovery call)

A written intake form gets the specifics you need for accurate scoping:

  • Site URL (if rebuilding an existing site)
  • Analytics access request (Google Analytics - get access before scoping, not after)
  • Brand assets: logo (SVG or high-res PNG), brand colours (hex or Pantone), fonts
  • Hosting preference (or current host login details if taking over)
  • Domain registrar login (or contact for DNS access)
  • List of required pages
  • Content status: does the client have copy and images, or do they need this?
  • Third-party services to integrate (list them all, including obscure ones)
  • Budget range (if they have not disclosed it - this conversation must happen before you write a proposal)

Phase 2 - Project kick-off

Once the contract is signed and deposit received, the kick-off phase sets the project up technically and organisationally.

Technical setup checklist

Do this before any design or development work:

  • [ ] Set up project management workspace (Notion, ClickUp, Linear - whatever you use)
  • [ ] Create shared folder for assets (Google Drive, Dropbox, or Notion database)
  • [ ] Set up communication channel (dedicated Slack channel or email thread)
  • [ ] Set up staging environment (see the staging site guide)
  • [ ] Confirm hosting account is ready (create if new, get access if existing)
  • [ ] Get DNS access credentials (domain registrar login or delegate DNS zone)
  • [ ] Install WordPress on staging with your standard starting configuration
  • [ ] Set up version control if using (Git repository with staging deploy)
  • [ ] Add client to staging environment with view access (not admin)

Standard WordPress starting configuration

Every project starts with the same base:

Plugins installed by default:
- WP Rocket or LiteSpeed Cache (performance)
- Wordfence (security)
- UpdraftPlus (backups configured to off-site storage)
- SEO plugin (Rank Math or Yoast)
- WP Staging (for staging workflow)
- Migration plugin (WPvivid or All-in-One WP Migration)

Standard wp-config.php additions:

define( 'DISALLOW_FILE_EDIT', true );
define( 'WP_POST_REVISIONS', 5 );
define( 'AUTOSAVE_INTERVAL', 300 );
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_DEBUG', false );

Remove default WordPress content:

  • Delete "Hello World" post and "Sample Page"
  • Delete unused default plugins (Akismet, Hello Dolly) unless needed
  • Delete unused themes (keep one default theme as fallback)
  • Delete the default admin user admin and create a project-specific admin account

Set up the backup destination

Before you write a single line of code, ensure off-site backups are configured and working:

  1. Configure UpdraftPlus to send backups to the client's Google Drive (or your agency's storage)
  2. Run a manual backup and verify it completes successfully
  3. Confirm you can see the backup files in the destination

If the site is lost before launch, you want a backup. This is not hypothetical - it happens.


Phase 3 - Design review and approval

Before development, get explicit written approval on design. Verbal agreement is not enough.

Design approval process

  1. Present mockups in your preferred tool (Figma, Adobe XD, or browser preview)
  2. Define which pages are included in the design scope (every template, not just the homepage)
  3. Get written approval on:
    • Colour palette and typography
    • Component styles (buttons, cards, navigation, forms)
    • Mobile layout approach
    • Any custom interactions or animations

Document the approval date and who approved. This protects you when a client says "that is not what we agreed" three weeks into development.

Design change protocol

Define the change process in the contract and remind the client during kick-off:

  • Minor changes during design phase: included
  • Changes to approved designs during development phase: treated as change requests
  • Change requests are quoted and added to a change log

A change log in a shared document (not email threads) keeps this transparent and avoids disputes.


Phase 4 - Development handoff and review

Staging review access

When the site is ready for client review, provide:

  • Staging URL
  • Login credentials (a separate editor account, not admin)
  • A review form or feedback tool (Pastel, BugHerd, or a simple Notion database)

Do not give clients admin access to staging during review. They will accidentally break things and blame you.

Feedback rounds

Define how many feedback rounds are included in the project scope. Three rounds is standard:

  • Round 1: Global feedback (layout, design, navigation)
  • Round 2: Content and copy edits
  • Round 3: Final polish and bug fixes

After round 3, additional changes are change requests. Document this in the contract.


Phase 5 - Launch checklist

Never launch a site from memory. Use a written checklist every time.

Pre-launch

  • [ ] All content proofread and approved by client
  • [ ] All links verified (no broken internal or external links)
  • [ ] Contact forms tested (submission, notification email, confirmation email)
  • [ ] SEO plugin configured (unique titles and descriptions on all key pages)
  • [ ] XML sitemap verified
  • [ ] Analytics tracking confirmed working
  • [ ] Google Search Console property set up
  • [ ] SSL certificate installed and verified
  • [ ] WP_DEBUG set to false
  • [ ] Caching configured for production
  • [ ] Performance tested on staging (PageSpeed Insights score over 80)
  • [ ] Security plugin configured and active
  • [ ] Off-site backups verified

Launch day

  • [ ] Take a full backup of staging before DNS changes
  • [ ] Update WP_HOME and WP_SITEURL to production domain
  • [ ] Update any absolute URLs in the database (WP-CLI search-replace)
  • [ ] Change DNS A record to point to production server
  • [ ] Wait for DNS propagation (10-30 minutes typically)
  • [ ] Verify SSL is active on production domain
  • [ ] Clear all caches
  • [ ] Verify forms work on production
  • [ ] Submit sitemap to Google Search Console
  • [ ] Turn off staging search engine blocking
  • [ ] Enable staging redirect (optional: redirect staging domain to production)

Phase 6 - Post-launch handoff

Client training

Every client gets a recorded Loom walkthrough of:

  • How to add/edit posts and pages
  • How to manage media
  • How to update plugins and themes (or a clear instruction to contact you)
  • Any specific custom functionality they will use regularly

A written SOP document for the most common tasks (saved in their shared folder) reduces future support requests significantly.

Maintenance agreement

Present the maintenance offer at handoff, not as an upsell at a later date. Clients who just went through a smooth launch process are the most receptive.

A standard maintenance package:

  • Monthly plugin and theme updates (tested on staging first)
  • Monthly security scan
  • Quarterly performance review
  • Priority support response time
  • Off-site backup management

Price monthly retainers based on site complexity: $99-299/month for standard sites, $300-600/month for e-commerce with active inventory.

The maintenance relationship is where agencies build long-term, predictable revenue. A project that ends at launch is a transaction. A project with a maintenance agreement is a client relationship.


Was this article helpful?