brily
← Back to blog
Agencies··7 min read

Running a digital agency without drowning in ten tool logins

Agencies maintain product health for clients using tools built for single-product teams. The result is ten logins per engineer and an operational tax that scales linearly. Here's a better shape.

B
The Brily team
Founders

Spend thirty minutes talking to any senior engineer at a digital agency and you'll hear the same complaint. "I have nine active clients. Each client has its own UptimeRobot account, its own Statuspage subscription, and nobody remembers the Delighted credentials. When something breaks at 11pm, I have to figure out which tab to open."

Monitoring tools are built for product teams who own one product. Agencies own ten. The mismatch shows up in four predictable ways — and the solutions aren't Zapier.

Failure mode 1: credential sprawl

Every client has either (a) its own vendor account paid by the client, or (b) the agency's shared vendor account with access roles that nobody configures correctly. Both are bad.

The client-owned account means every handover requires a credential dance, every new hire requires nine invites, and when a client offboards you still have their API token sitting in your tooling. The agency-shared account means any team member can see — or accidentally edit — every client's monitors. Your least-senior engineer has access to your highest-value client's NPS responses. This will blow up eventually.

Failure mode 2: inconsistent setup

Client A's status page is on Instatus, branded nicely. Client B's is on Statuspage.io, inherited from whoever set it up before you took over. Client C doesn't have one. Clients D and E have status pages you forgot to renew custom domains for. This is the steady-state of every agency bigger than three clients.

The problem isn't tools; it's that the cost of standardising across clients has always been higher than the cost of just running each client's existing setup. An agency-native platform inverts that: adding a new client to a consistent setup is cheaper than maintaining inconsistent ones.

Failure mode 3: billing chaos

If your vendor accounts are per-client, you have nine invoices to manage, reconcile, and mark up to the client. If your vendor accounts are shared, you have the reverse problem: apportioning a shared invoice across clients, which is accounting work nobody wants to own.

The only scalable answer is a consolidated bill to the agency, with per-client cost attribution handled automatically by the platform. That lets you mark up by a fixed percentage per client without a spreadsheet.

Failure mode 4: on-call routing

When a client's site goes down at 2am, which of your engineers gets paged? In a client-owned tool, the client's email is on the alert. In a shared tool, either one engineer's email is on every alert (and they burn out) or a distribution list is on everything (and nobody is accountable).

The right shape is per-client escalation policies inside one platform. Agency lead gets the first page. Client-dedicated engineer gets it if lead doesn't ack in 5 minutes. Nobody else in the agency gets woken up unnecessarily.

What the platform shape looks like

The data model that solves all four failure modes at once is nested workspaces:

  • One agency parent workspace. Owns the billing, the team roster, the global settings.
  • One client child workspace per client. Owns the monitors, status page, NPS data, and subscribers for that client. Has its own per-client SLA and reporting.
  • Agency team members can be granted access at the agency level (all clients) or the client level (specific clients only). Client stakeholders can be granted read-only access to their own workspace — useful for weekly reviews without giving them edit rights.

This is three or four years old as an idea; what's new is that it's now table-stakes for any monitoring platform that wants the agency segment.

White-label details that matter

"White-label" means different things to different vendors. For agency use, the minimum is:

  • Status page domain and branding— client logo, client colors, client domain. No vendor name in the footer, no "powered by".
  • Email from-address — status page subscriber emails come from status@client-domain.com, with SPF/DKIM you configure once per client.
  • NPS widget — no vendor branding in the survey or the thank-you page. Client sees their UI.

The flag-waving "white-label" feature that some vendors advertise is actually just hiding the vendor logo from the status page. That's the weakest definition. The strongest covers email deliverability, subscriber lists, and the widget surface.

The conversation with clients

A common agency worry: "won't my client feel cheated if they find out I use a shared platform?" In practice, no. Clients care about outcomes: is the site up, is the status page working, are we getting feedback. They don't care that you're running multiple clients on one back-end — they assume you are, because you're an agency.

What clients docare about is that you can answer questions quickly. "How was uptime last month?" in two clicks. "What were the NPS trends after the relaunch?" in four clicks. "Can you export all our data if we leave?" yes, within minutes. These are the moments when the unified platform pays off in client perception.

Migration cost, honestly

Moving an agency off nine vendor accounts onto one platform is real work — you cannot skip it. The part most vendors undersell is the value of the first migration, because once the first client is on, the second is 30% easier, and by the fifth you have a runbook. The pain is front-loaded.

If you're considering consolidation, the right way to start is with a single new client (greenfield) or a client whose current tooling is already falling apart. Do not migrate your biggest client first.