First two weeks of a performance onboarding (realistic scope)
New monitoring clients often expect fixes in week one. Realistic onboarding scope is narrower: access, URLs, owners, baseline, and thresholds before anyone promises remediation
A new client signed the monitoring retainer on Monday and asked on Wednesday when checkout would be green in Lighthouse. Fair question: the SOW mentioned Core Web Vitals, and their last agency had sent a PDF full of red bars.
We had not finished agreeing which checkout URL counted, who owned first response on alerts, or whether mobile field data even existed for that template yet. The work was not missing; the calendar was wrong.
Most onboarding failures we see are scope failures, not skill failures. Teams either treat week one like a mini audit with twenty remediation tickets, or they spend fourteen days in tooling setup and call it done without a baseline the client can repeat. Below is the two-week frame we use with agencies: what we promise, what we defer, and how it lines up with the longer checklists on our main blog.
What goes wrong when onboarding scope is vague on day one
Without a written two-week boundary, three collisions are common. Sales language drifts into delivery: "We will monitor performance" becomes "we will improve Core Web Vitals" in the client's head while engineering still waits for staging access. The URL list balloons when someone exports a sitemap, adds every campaign landing page from the last three years, and schedules tests before anyone marks which routes actually convert. Remediation starts before measurement is trusted when a developer fixes hero images on the homepage while checkout still lacks field data and nobody has agreed on alert severity.
Procurement and delivery can both be happy if week one and week two have named outputs. Those outputs are not "site is fast"; they are "we know what we watch, who acts, and what broke first."
Week one: what to lock before you run PageSpeed tests
Week one is contracts and context, not optimisation. We aim to close five agreements in writing (email is fine):
- Primary domain and environments (production first; staging only if the client expects pre-release checks).
- Five to ten priority URLs: homepage, main conversion path, one high-traffic template, and commerce or form routes if they exist.
- Mobile and desktop coverage (both, unless the client has a documented mobile-only audience).
- Alert recipients and a named first responder (one person, not a channel full of @here).
- Reporting rhythm: weekly internal scan, monthly client-facing review, and who owns each.
If access is slow, week one still produces a blocker log: who owes credentials, which firewall ticket is open, which analytics consent rule blocks synthetic tests. That log is a deliverable, and it prevents week two from quietly slipping to week four.
Our site audit checklist for onboarding new clients into performance monitoring has the full tick list for access, URL inventory, and handover. On Hashnode we are only arguing for order: scope and owners before quotas and schedules.
Week two: baseline, thresholds, and the first client-safe summary
Week two is when tools earn their place. Run initial tests on the priority URL set from week one, record LCP, INP, and CLS for mobile and desktop where data exists, and mark pages with no field data so nobody interprets a lab-only score as a production guarantee.
Set conservative thresholds on those same URLs. Tight budgets on day ten usually mean alert noise by day seventeen, so we would rather start slightly loose, watch one full weekly cycle, and tighten after we see variance.
Wire alerts to the routes agreed in week one: one internal channel for regressions that need same-day eyes, and a separate, slower route for client-visible summaries if the contract includes them.
Draft a short "what we monitor and why" note the account lead can send without engineering in the thread. Three paragraphs cover which URLs, which metrics, what happens when a threshold breaks, and what is explicitly out of scope for the monitoring retainer.
End week two with three actions from the baseline, each with an owner and a due date. They can be investigative ("confirm whether tag X loads on checkout") rather than shipped fixes; the client should see prioritisation, not a promise that all three close before month end.
What we deliberately defer past the first two weeks
Saying no early protects the retainer later. Full template coverage across hundreds of URLs belongs in month two unless the contract priced it; CI gate design, CrUX versus lab reconciliation workshops, and third-party script triage across every tag manager container are real work, but they are not week-two work.
We also defer client-facing dashboard polish, because a screenshot of a green score without context creates the same false confidence as the PDF they received from the previous vendor. Remediation sprints stay separate from monitoring setup unless the SOW merged them with hours attached; mixing the two in fortnight one is how agencies absorb unpaid engineering.
If the client pushes for fixes immediately, we point to the three actions from the baseline and offer a change order for implementation. Monitoring onboarding is complete when everyone can answer what broke first, who got pinged, and what we do next.
How the two-week frame maps to ongoing CWV operations
Fortnight one is intake; the recurring habit starts afterward. After week two, we hand teams the Core Web Vitals monitoring checklist for agencies for weekly scans, monthly deep dives, and deploy checks. That document assumes monitoring is live and scoped. Without the two-week frame, teams treat the checklist like a one-off audit and abandon it when the first sprint ends.
In practice the split looks like this:
| Phase | Question it answers | Typical owner |
|---|---|---|
| Weeks 1–2 (this post) | What do we watch, who responds, what is the baseline? | Delivery lead + technical lead |
| Week 3 onward (Watcher checklist) | What do we do every Monday and every month? | Account manager + engineering |
Agencies managing several clients benefit from the same shape every time. Portfolio onboarding is repetitive; the client's internal politics are not. Reusing the two-week boundary makes it easier to compare sites without pretending each onboarding is bespoke heroics.
What to put in the client email at the end of week two
We keep the end-of-fortnight email short enough to forward inside the client's organisation:
- Confirmed URL list (with one-line business reason per URL).
- Baseline table for LCP, INP, CLS on those URLs (note where field data is missing).
- Alert routes and first responder name.
- Top three findings with owners (not necessarily fixes).
- Explicit "starts week three" items: expanded coverage, remediation quotes, workshop dates.
That email sets expectations better than another Lighthouse export: procurement sees deliverables, engineering sees assigned tickets, and sponsors see that monitoring is operational rather than a slide in the pitch deck.
Next step
If you are onboarding a client this month, write the two-week outputs before you buy more test quota. Use the site audit checklist for ticks inside each week, then move into the agency CWV checklist once alerts have survived a full weekly cycle without being muted. Realistic scope is not pessimism; it is how monitoring retainers survive contact with real clients.
