---
title: How to Manage 10, 50, or 100 Client Websites
description: Scale agency maintenance from 10 to 100 client websites with service tiers, ownership, portfolio standards, alert routing, capacity planning, and evidence.
source: https://pingvera.com/blog/manage-multiple-client-websites.html
---
# How to Manage 10, 50, or 100 Client Websites

Managing multiple client websites stops scaling when every project has unique tools, private knowledge, shared credentials, and alerts routed to whoever happens to notice. The solution is a portfolio operating model: service classes, a complete inventory, standard checks, named owners, controlled exceptions, one work queue, and capacity reserved for incidents.

At ten sites, memory can conceal process gaps. At fifty, those gaps become daily noise. At one hundred, the agency needs platform ownership, automation, access governance, and portfolio-level evidence.

## At a glance

To scale website maintenance:

1. place every production site in a service class;
2. maintain one authoritative website inventory;
3. standardise onboarding, monitoring, release, incident, and offboarding;
4. define a minimum monitoring bundle for each class;
5. route actionable events into one queue with P1 fallback;
6. separate site owner, on-call responder, and platform owner;
7. control credentials and client-specific exceptions;
8. measure alert quality, unowned risk, recovery readiness, and workload;
9. reserve capacity for incidents and preventive work;
10. review the portfolio, not only individual tickets.

## The operating model changes with scale

Headcount and complexity matter more than the exact number. Ten high-traffic stores may require more structure than one hundred brochure sites.

## Step 1: define service classes

Example:

Service class should affect price, staffing, frequency, communication, and recovery—not just a label in a spreadsheet.

## Step 2: make the inventory authoritative

The inventory should answer:

- Which production websites are we responsible for today?
- What does each site do for the client?
- Who owns domain, DNS, hosting, code, data, and vendors?
- Which checks and incident routes apply?
- Which software, region, time zone, and renewal risks exist?
- When was recovery last tested?
- Which exceptions have been accepted, by whom, and until when?

Use the [client website inventory template](https://pingvera.com/blog/client-website-inventory-template.html). A monitor list is not a complete inventory, and a billing list is not an operational inventory.

## Step 3: create standard bundles

### Standard external bundle

- canonical URL and content marker;
- critical page;
- TLS and domain expiry;
- redirect/security signal;
- primary conversion journey;
- primary and fallback alert routes.

### Transactional add-on

- form delivery to mailbox/CRM;
- checkout or booking smoke path;
- scheduled-job heartbeat;
- ERP/PIM/OMS/payment reconciliation signal;
- multi-region verification where relevant.

### Platform add-on

- CMS/application health;
- update and vulnerability workflow;
- queues, storage, database, cache, and worker signals;
- backup age and restore-test evidence.

Templates need controlled per-site parameters, not copy-pasted monitors that drift silently.

## Step 4: separate roles

One person may hold several roles at a small agency, but the responsibility still needs a name and backup.

## Step 5: route work, not noise

Use different paths:

- P1/P2: on-call notification plus incident record;
- confirmed actionable P3: help-desk task;
- expiry and preventive risk: scheduled task with escalation date;
- isolated transient event: retained as evidence, not immediately sent to humans;
- recurring noisy event: problem record assigned to improve the check or service.

Never let a chat channel become the only system of record. Link each confirmed incident to the website inventory and client record.

## Step 6: calculate operational capacity

Track at least:

- contracted maintenance hours and service windows;
- average routine workload;
- incident load by class and time zone;
- recurring manual checks;
- on-call interruptions;
- ageing known risks;
- preventive work completed;
- actions from incidents and restore tests.

If every engineer is allocated to planned project work, incident response will always break delivery promises. Reserve explicit capacity or price a separate response function.

## Portfolio review dashboard

Avoid celebrating total checks or total alerts. Those are activity measures, not reliability outcomes.

## Copyable portfolio standard

# Client website portfolio standard

Owner: [operations role]
Version: [number]
Review: [monthly/quarterly]

## Admission
No site enters active maintenance without:
- accepted scope and service class;
- inventory record and named owners;
- controlled access;
- baseline and known-issues register;
- recovery status;
- required monitoring and escalation.

## Templates
- Class A: [template ID/version]
- Class B: [template ID/version]
- Class C: [template ID/version]

## Exceptions
Every exception requires reason, risk owner, approval, expiry, and compensating control.

## Work routing
- P1/P2: [route]
- P3: [queue]
- P4/preventive: [backlog]
- fallback: [route]

## Reviews
- Weekly: incidents and unowned alerts
- Monthly: critical sites, renewals, overdue actions
- Quarterly: access, recovery, templates, service classes

## Exit
Offboarding follows [handover checklist] and removes monitoring only after accepted transfer.

Maturity checklist
Ten sites

every site has a named owner and passport;
access is in an agency-managed secret system;
primary journey and expiry risks are monitored;
one incident playbook is used.

Fifty sites

service classes and templates exist;
one inventory and help-desk queue are authoritative;
on-call and fallback roles are scheduled;
portfolio review identifies missing controls and noise;
access and restore evidence are reviewed.

One hundred sites

templates are versioned and deployed through API/code where useful;
exceptions expire automatically or surface for review;
platform changes are tested before bulk rollout;
shared dependencies and blast radius are mapped;
operations capacity and reliability work have owners;
client reporting is generated from evidence, not manual recollection.

Example: a plugin update across 70 WordPress sites
Without service classes, the agency updates all sites in one batch and discovers a checkout conflict after clients complain. In the portfolio model, the platform owner tests the change on a representative canary set, Class A stores require journey checks and longer observation, unsupported sites remain explicit exceptions, and rollout stops automatically when the failure threshold is met.

Scale comes from controlled sameness plus visible exceptions—not from treating every client identically.

## Common mistakes

- using one shared administrator account across clients;
- selling 24/7 response without an on-call design;
- creating a unique checklist for every site;
- routing every monitor to everyone;
- automating configuration before the standards are stable;
- measuring ticket closure but not repeat incidents;
- keeping expired clients in production tools indefinitely;
- hiding unsupported legacy sites inside the normal portfolio.

## FAQ

### What tool should an agency use to manage multiple sites?

The operating model matters first. You normally need an inventory, secret manager, help desk, monitoring platform, repository/automation, and reporting—not necessarily one product that controls everything.

### When should an agency create a dedicated maintenance team?

When recurring response, preventive work, platform standards, and client reporting can no longer be reliably owned alongside project delivery.

### Should all client sites use the same monitoring frequency?

No. Use service class and acceptable detection delay. Standardise the decision rule, not every value.

### How do agencies avoid alert fatigue?

Confirm failures, group dependencies, route by severity, make every alert owned, measure repeated noise, and fix the monitoring system as a product.

## Sources and further reading

- [Google SRE: Managing Incidents](https://sre.google/sre-book/managing-incidents/)
- [Google SRE: Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)

Reviewed: **8 August 2026**.

Next: [Client website inventory template](https://pingvera.com/blog/client-website-inventory-template.html) and [monitoring as code](17-monitoring-as-code-web-agencies.md).

Pingvera is designed to centralise deep external checks across a client portfolio. The agency still needs service classes, owners, access governance, and a work queue around those checks.