White-Label Website Hosting & SLAs for Australian Agencies

This page is for agency owners and account directors who win website retainers their team cannot technically service: it explains what clients actually expect from a managed website arrangement, why uptime and response commitments are hard to underwrite without infrastructure, and how white-label and referral fulfilment models let an agency sell those commitments safely.

The retainer problem: winning work you cannot technically service

Most agencies are very good at one part of the lifecycle. You research, position, design, write, build the campaign, launch the site. Then the client asks the reasonable follow-up question: who looks after this now?

At that point three things usually happen. The agency says yes because the retainer is worth more than the project, then quietly discovers it has committed to CMS core upgrades, PHP version migrations, TLS renewals, WAF tuning and after-hours incident response. Or the agency says no, and the client hands the ongoing relationship to a hosting company that will not touch the application, which means the agency loses visibility and eventually loses the account. Or the agency subcontracts to whoever built the site last, with no contract, no defined response times and no idea who is on call at 11pm on a Saturday.

None of these are failures of talent. Hosting is a different discipline with a different cost structure. Running production infrastructure means monitoring, patching, backup verification, incident escalation and someone awake when a site goes down. That is a permanent operational overhead, and it does not pay for itself across a handful of client sites.

What clients ask for that most agencies cannot sign

The gap shows up in procurement documents and in the fine print of retainer agreements. Enterprise and government buyers, and increasingly mid-market ones, ask for commitments that are meaningless unless somebody controls the stack:

• A stated uptime percentage, measured externally, with service credits if it is missed
• Response and resolution targets by severity, including a P1 path that runs outside business hours
• Backup frequency, retention period and a tested restore procedure with a stated recovery time objective
• Data residency in Australia, and named sub-processors
• Patching cadence for the CMS, its modules and the underlying operating system
• Vulnerability scanning, WAF and DDoS protection, and evidence for annual penetration tests
• Cyber liability insurance at a stated cover level, and named-insured provisions
• An exit clause requiring a full data and configuration handover within a set number of days

An agency without infrastructure capability can write those clauses into a proposal, but it cannot honour them. Signing a document you cannot operationally satisfy is a commercial risk, not a sales win. A properly constructed website support SLA for enterprise and government is an operational commitment backed by monitoring and rostering, not a marketing paragraph.

Uptime commitments, response times and why they are hard to underwrite

The arithmetic of a percentage

Uptime figures look similar on a page and are wildly different in practice. The difference between 99.5% and 99.99% is the difference between a quiet afternoon of outage and a coffee break.

Note that maintenance windows, DNS propagation and third-party outages all have to be defined as in or out of scope, otherwise the number is unenforceable in either direction.

Response is not resolution

The most common drafting error in agency retainers is promising a resolution time. Resolution depends on the fault. A misconfigured redirect is fifteen minutes; a corrupted database on a site with no verified backup is a very different afternoon. What can be committed to is time to acknowledge, time to triage, time to first meaningful update and update frequency thereafter. Severity definitions need to be written against business impact, not technical symptom: a checkout that fails for 8% of card types is a P1 even though the site is up.

Out-of-hours cover, escalation and on-call reality

Twenty-four hour cover is a rostering problem before it is a technical one. To genuinely answer a P1 at 2am you need more than one person who can log into production, documented runbooks so the person on call is not reverse-engineering a build they have never seen, alerting that pages a human rather than sending an email nobody reads, and a defined escalation path when the first responder cannot resolve it within a set window.

Agencies rarely have the headcount to sustain that across a small portfolio, and the informal version, where the lead developer's mobile number is the escalation path, fails the first time that person is on annual leave. It also fails at review time, when the client asks for the incident log. Unplanned faults still need a home, which is why break/fix and emergency website support has to be scoped explicitly rather than assumed to sit inside a monthly hours bucket.

White-label versus referral: how each model works

White-label

You buy hosting, monitoring, patching and SLA cover at a wholesale rate and resell it under your own brand at your own margin. The client contracts with you, is invoiced by you, and raises tickets through your channel. The fulfilment partner is invisible and works under your name. You keep the account, the relationship and the pricing control, and you take on the commercial relationship with the client for that line item.

Referral

You introduce the client, the fulfilment partner contracts and invoices directly, and you receive a recurring share of the revenue for as long as the client stays. You carry no delivery obligation and no invoicing overhead, but you also do not set the price and the technical relationship sits with the partner.

Commercial structures compared

What sits with the agency and what sits with the fulfilment partner

The arrangement only works if the boundary is written down before the first ticket, not negotiated during an incident.

Migrating an existing client portfolio without downtime

Most agencies coming into a program like this arrive with an inherited mess: a few sites on a reseller account, one on a client's own AWS bill nobody has audited, one on a platform the original developer chose in 2018. Moving them is routine, but only in a defined order.

1. Audit each site: platform and version, PHP or Node runtime, database engine, cron jobs, third-party integrations, mail sending, DNS registrar and current TTL values
2. Identify the risks before the move: unsupported CMS versions, hardcoded absolute URLs, licence keys tied to an IP, or file storage outside the web root
3. Build the target environment and deploy a full copy, then test against a hosts-file override so real users are unaffected
4. Lower DNS TTLs 24 to 48 hours ahead of the cutover
5. Cut over during a low-traffic window with a final content and database sync, then verify SSL, redirects, forms, payment callbacks and analytics tracking
6. Keep the origin environment running read-only for a defined rollback period

Where the incumbent is uncooperative, credentials are incomplete or the relationship has already broken down, the sequence needs more care. That situation is common enough to be its own discipline, covered in website migration to a new vendor.

Reporting your client sees, and reporting you see

Retainers are renewed on evidence. A monthly report that reads "maintenance performed" invites the client to question the line item. A useful client-facing report states measured uptime against the target, the number of incidents by severity with time to acknowledge and resolve, patches applied with version numbers, backup success rate and the date of the last verified restore, blocked malicious requests, and core performance metrics.

Behind that, the agency needs its own view: which sites are approaching end-of-life on their CMS or runtime, which have accumulated overdue module updates, where the resource ceiling is close, and which clients are consuming disproportionate support hours. That internal view is what turns a hosting line item into an upgrade conversation. It is also the raw material for website governance, compliance and risk management, which is increasingly what larger clients are actually buying.

Security, compliance and government client requirements

Once an agency's client list includes a council, a department, a listed company or anyone with a procurement function, security questions arrive in writing. Expect requests for Australian data residency, MFA on all administrative access, a documented patching SLA, evidence of vulnerability scanning, Content Security Policy headers, incident notification timeframes under the Notifiable Data Breaches scheme, and remediation of findings from an annual penetration test.

These are answerable, but only by whoever holds the infrastructure. An agency reselling under a white-label arrangement should be able to request the underlying evidence rather than compose reassuring prose, which means the fulfilment partner needs continuous website security management and monitoring in place already rather than assembled on request.

How to evaluate a fulfilment partner before you put your brand on it

You are lending your reputation to someone else's operations. Ask for specifics, and be suspicious of answers that avoid numbers:

• Where is the infrastructure physically located, and who is the underlying provider?
• What is the monitoring interval, what triggers a page, and who receives it at 3am?
• How often are backups taken, how long are they retained, and when was a restore last tested end to end?
• Which platforms do they genuinely operate, and can they perform major version upgrades rather than only patch releases?
• Do they have developers, or only systems administrators? An infrastructure-only partner will not fix an application fault.
• What are the severity definitions and response targets, in writing?
• Will they attend a client call under your brand if you need them to, and will they stay silent about their own?
• What is the exit process, and who owns the client relationship if the partnership ends?
• What is the minimum commitment, and does the rate change if you only ever send two sites?

Frequently asked questions

What is white-label website hosting for agencies?

White-label website hosting is an arrangement where a specialist provider supplies infrastructure, monitoring, patching and support under another agency's brand. The agency buys at a wholesale rate, sets its own retail price, holds the client contract and invoices directly. The fulfilment partner does the technical work and does not appear to the end client.

Can a marketing or branding agency offer an uptime SLA without hosting anything itself?

Yes, provided the commitment is backed by a fulfilment partner who operates the infrastructure and contractually offers the agency the same or better terms. The agency should never promise a client a target it has not secured on the back end, including response times, backup frequency and out-of-hours cover. The safe approach is to mirror the partner's SLA rather than write an aspirational one.

What is the difference between the white-label and referral models?

Under white-label the agency owns the contract, the invoice and the pricing, and earns the margin between wholesale and retail. Under referral the fulfilment partner contracts and invoices the client directly and pays the agency a recurring share of the revenue. White-label gives more control and more margin; referral gives less administration and no delivery obligation.

How many websites do we need before a white-label arrangement makes sense?

There is no technical minimum. Some agencies start with a single high-value client whose procurement requirements they cannot otherwise meet, then move the rest of the portfolio over time. The commercial case usually appears at the first site, because the alternative is either declining the retainer or absorbing an operational cost that has no ceiling.

What happens to our clients if the partnership ends?

Under a properly written agreement the agency retains the client relationship and the partner provides a full handover: server configuration, database dumps, file archives, DNS records, certificates and documentation within a defined period. Confirm this before signing rather than after. The absence of a clear exit clause is the strongest signal to walk away.

Does the client ever find out a third party is involved?

Under a white-label arrangement, only if the agency chooses to disclose it, and some government and enterprise procurement processes require sub-processors to be named. The fulfilment partner works under the agency's brand in tickets, reports and, where needed, on client calls. Where disclosure is required, having a named Australian partner with documented controls is usually an advantage rather than a problem.

The UnDigital Agency Hosting Program

UnDigital runs managed hosting and website management for enterprise, government and ecommerce clients, and provides the same capability to agencies under their own brand. We are both the infrastructure and the development capability, which is the point: when an application fault takes a site down, there is no argument about whether it is a server problem or a code problem.

The Agency Hosting Program operates on the two models above, white-label or referral, with no minimum number of sites and no requirement that your clients sit on any particular platform. We handle provisioning, monitoring, patching, backups, WAF and CDN configuration, incident response and reporting. You keep the client, the strategy and the creative work.

Wholesale rates are not published, because they depend on the architecture each site actually needs. The starting point is a call and an audit of what you currently have running.