Home › Blog › How to Manage 10, 50, or 100 Client Websites

How to Manage 10, 50, or 100 Client Websites

August 8, 2026 · 8 min read

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:

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

The operating model changes with scale

Portfolio	Main risk	Minimum operating model
1–10 sites	Knowledge stays in one person's head	checklist, named owner, password manager, basic monitoring
11–50 sites	Alert and configuration inconsistency	service classes, central inventory, templates, help-desk routing, rota
51–100 sites	Manual toil and shared blast radius	platform owner, configuration as code/API, exception governance, capacity planning
100+ sites	Portfolio behaves like a managed platform	dedicated operations function, automation testing, reliability/product management

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:

Class	Typical service	Coverage	Required journeys	Recovery expectation	Review
A Critical	ecommerce, booking, account	24/7 option	2–5	tested RTO/RPO	monthly
B Business	lead generation, active marketing	extended/business hours	1–3	documented restore	quarterly
C Standard	brochure/content	business hours	1	documented backup	twice yearly
D Observe only	legacy/out-of-scope	alerts only	agreed minimum	explicitly limited	annual

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. 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

Role	Portfolio responsibility
Client service owner	scope, client priorities, approvals, reporting
Site technical owner	architecture, changes, risks, runbooks
On-call responder	incident acknowledgement and escalation
Monitoring/platform owner	templates, integrations, alert quality, tooling
Access owner	accounts, privilege reviews, offboarding
Operations lead	capacity, portfolio review, standards, exceptions

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

Question	Useful indicator
Do we know our responsibility?	sites without owner/scope
Are critical journeys observed?	required checks missing by class
Can we recover?	overdue/failed restore tests
Are alerts useful?	actionable rate, repeated noise, unowned alerts
Are renewals controlled?	domain/TLS/licence risk by horizon
Is risk ageing?	accepted exceptions past expiry
Are we learning?	overdue incident actions/repeat incidents
Is workload sustainable?	interruption load and queue age

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

Reviewed: 8 August 2026.

Next: Client website inventory template and monitoring as code.

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.

Know about problems before your customers do

Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.

Start free

← All articles · Privacy policy · pingvera.com