You sold performance monitoring on the proposal, and the contract is signed. Now delivery has three days before someone asks why nothing is live yet.

Onboarding is where many retainers wobble. Teams either rush a PageSpeed screenshot into Slack, or disappear into setup for two weeks and lose the client's attention. A repeatable workflow fixes that because every client moves through the same phases, owners, and outputs.

This guide is the process layer. For a copy-and-paste audit list, use our Site Audit Checklist: Onboarding a New Client for Performance Monitoring. Here we cover who does what, in what order, and what "done" looks like before the first monthly review.

What successful onboarding produces

Before you open a tool, agree on the finish line. For most agency retainers, onboarding is complete when you can show:

1. A written scope (domains, environments, priority templates, mobile and desktop).
2. Scheduled tests running on priority URLs without manual PSI tabs.
3. A baseline snapshot with three named actions, not a score dump.
4. Budgets and alerts with one internal owner and one client-facing contact.
5. A client note that explains what you monitor, what is failing, and what happens next.

If you cannot tick those five, you are still in setup. That distinction keeps account managers from promising monthly packs before the signal is trustworthy.

Phase 1: Align scope before kickoff (sales to delivery handoff)

The fastest onboarding failures start in sales. Delivery inherits a vague line like "monitor Core Web Vitals" with no page list, no cadence, and no alert owner.

Run a fifteen-minute internal handoff while the deal is fresh. Capture:

• Production domain(s) and whether staging is in scope.
• Business-critical URLs (homepage, pricing, lead form, checkout, booking).
• Reporting promise (weekly internal, monthly client-facing, or alert-only).
• Whether the client expects fixes, monitoring only, or both.
• Quota reality: how many URLs, how often, mobile plus desktop.

If the sale included monitoring but not remediation, say that in writing before kickoff. Clients who expect you to fix every regression on day three will treat alerts as broken delivery.

For positioning and packaging, see How to Sell Performance Monitoring Services to Your Clients. For why automation belongs in the retainer at all, see Why Agencies Need Automated Performance Monitoring in 2026.

Phase 2: Kickoff call (day 0 to 2)

Keep the client kickoff under forty-five minutes. You are confirming facts, not performing a full audit live.

Attendees

• Client: one business owner (priorities) and one technical contact (access, releases).
• Agency: delivery lead plus whoever owns alerts and reporting.

Agenda that works

1. Confirm domains and environments (production only unless staging is contracted).
2. Confirm priority templates and any excluded paths (search, preview, admin).
3. Confirm consent and tag constraints if they ever ask for real-user monitoring later.
4. Confirm alert recipients and who responds first internally.
5. Confirm first client-facing summary date (usually end of week one).

End with a single follow-up email listing decisions. Ambiguity here becomes "why is that URL monitored?" in week two.

Phase 3: Configure monitoring in the app (day 2 to 5)

Tool steps differ by vendor. The sequence below matches how we see agencies run Apogee Watcher; adapt if you use another stack.

Create the client site in your organisation

Add the client as a site under your agency organisation so quotas, roles, and history stay separate from other clients. If several account managers need access without billing rights, assign team roles and access control before the first scheduled run: the Admin role configures, the Manager role tunes budgets, and the Viewer role reads dashboards in the app.

Build the URL inventory

Start from the sitemap, then force-add URLs the sitemap misses. Automated page discovery reduces paste-and-forget gaps when marketing publishes new landers, but you still curate what enters the scheduled set.

Practical first pass for most clients:

• One homepage.
• Two to five conversion URLs.
• Five to ten template representatives (service pages, product grids, key articles).

Resist monitoring every tag archive on day one. Expand after triage stays manageable.

Set test frequency and priority

Match cadence to release risk, not equality across clients. A Shopify store in peak season earns more frequent runs than a stable brochure site. Our guide on scheduling test frequency and priority across a portfolio walks through hourly-to-monthly bands and quota trade-offs.

Enable mobile and desktop as separate series. Sponsors still ask about desktop even when analytics skew mobile.

Run the baseline

Trigger an initial run on priority URLs. Record LCP, INP, CLS, and performance score, plus one line of context per failing URL: likely cause and business impact. A number without context does not survive the first QBR.

For a fuller setup walkthrough across many sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Phase 4: Budgets, alerts, and internal response (day 5 to 7)

Monitoring becomes operational when thresholds and owners exist.

Set starter budgets

Use pragmatic thresholds on the first pass. Tighten after you have a month of noise and signal. The Performance Budget Thresholds Template gives starting bands you can mark provisional in the client file.

Wire alerts to a human

Email alerts are enough for many teams today. Define:

• who receives the first alert,
• who triages (dev vs account manager),
• who talks to the client,
• what counts as escalation versus backlog.

Without that path, alerts land in a shared inbox and regressions age quietly. For alert philosophy and cooldown thinking, read From Reactive to Proactive: How Smart Alerts Change Performance Monitoring.

Log the internal runbook

One page in your wiki is enough: scope, owners, budget notes, link to the site in the app, and the three current actions. Future you will not remember why /pricing is on high priority.

Phase 5: Client-facing onboarding (end of week one)

Clients do not need a forty-slide deck. They need clarity.

Send a short onboarding complete note:

• what URLs and devices you monitor,
• baseline status in plain language (how many URLs pass, which matter most),
• top three actions with owner and date,
• when the first monthly review happens.

The checklist post includes a ready-to-send email skeleton you can adapt.

If the client bought monitoring to prove value before optimisation work, be explicit: week one is measurement and prioritisation, not every fix shipped.

Phase 6: First thirty days and handoff to steady state

Treat the first month as calibration, not perfection.

Use the Monthly Performance Review Template for Agency Teams in week four so the client sees rhythm, not a one-off fire drill.

After day thirty, onboarding is "closed" internally. Ongoing work is fixes, reporting, and scope changes when they add templates or microsites.

Onboarding across multiple clients without chaos

Agencies that onboard well run the same phases in parallel, not custom theatre per logo.

• One organisation in your monitoring tool with a site per client.
• A standard role map (who is Admin vs Manager vs Viewer).
• A standard starter URL set per vertical (brochure, ecommerce, SaaS marketing).
• A standard week-one email and week-four review slot.

Portfolio visibility matters when you have more than a handful of sites. Managing multiple client sites in one dashboard is the product shape we built for that; the onboarding phases stay the same whether you use one dashboard or several logins.

Common onboarding mistakes

Skipping the sales-to-delivery handoff

Delivery discovers staging was never in scope, or the client expected unlimited URLs. Fix scope on paper before schedules run.

Monitoring everything on day one

Large URL lists create alert noise and burn quota. Start narrow, expand with intent.

No named alert owner

Shared responsibility is no responsibility. One internal name on the runbook.

Confusing onboarding with full remediation

Capture issues, prioritise, assign. Deep dives belong in delivery sprints, not in the kickoff call.

Promising polished reporting before signal stabilises

Month one is baseline plus top actions. Polished packs come after trends exist.

How this guide relates to the site audit checklist

Think of two layers:

• This article: phases, owners, timelines, client comms, handoff to month one.
• Site audit checklist: tick boxes for access, URLs, measurement, budgets, reporting, handover.

Run the process here; execute ticks from the checklist inside each phase. For ongoing CWV operations after onboarding, keep the Core Web Vitals monitoring checklist for agencies nearby.

FAQ

How long should onboarding take per client?

With clear access and a standard URL set, many teams finish setup and a baseline in one to two working days. The full first-month cadence is four weeks.

Should we onboard staging and production together?

Only if the contract includes staging. Otherwise you alert on environments the client does not care about publicly.

What if the client has no performance budget yet?

Use provisional thresholds, label them as starters, and revise after four weeks of runs.

Can we onboard before the new site launches?

You can baseline a preview URL, but schedules on production should start at launch or you will chase the wrong environment.

We already use a checklist. Do we need this workflow too?

Yes, if teams still drift on owners and client comms. The checklist records tasks; this guide records sequence and outcomes.

Does onboarding differ for WordPress or ecommerce?

URL priorities differ (checkout, category templates, plugin-heavy pages), but phases stay the same. Platform-specific measurement notes live in guides like WordPress performance monitoring and e-commerce performance monitoring.

---

Onboard with the same five outputs every time: scope, schedules, baseline with actions, alerts with an owner, and a client note that sets expectations. Run the site audit checklist inside that frame, then move into monthly reviews once week four lands.

If you are standardising onboarding across a growing roster, start a free Apogee Watcher account or run a free domain check on the client's production host before kickoff so the baseline conversation starts with data, not promises.