White-Label Drupal Support and Maintenance

Our support operates around the clock, and our engineering day runs on Indochina Time, UTC+7, which overlaps the European morning and the whole Australian working day.

The numbers in an SLA are set per contract rather than published as a tier, because a response target you cannot meet is worse than an honest one. What the agreement fixes in writing before you sign:

• Severity definitions. What counts as site-down, as degraded and as routine, agreed in advance so nobody argues about classification during an incident.
• Response and update targets per severity. Time to first response, and how often you are updated while it is open. Response is separate from resolution: nobody can honestly quote a resolution time for a bug no one has seen yet.
• Coverage hours per severity. Which severities are covered out of hours and at weekends.
• The escalation path. Named people, in order, with the route to a manager rather than to a queue.
• What is excluded. Third-party outages, client-side changes, and anything neither of us controls.

You are free to publish those terms to your client under your own brand. Many agencies do, because an SLA is easier to sell than an assurance.

Every month you get a written report: advisories applied and what each one closed, tickets opened and resolved, uptime, anything found that is worth knowing before it becomes urgent, and the risks we think are accumulating.

It is written to be forwarded. No internal jargon, no ticket identifiers from a system your client cannot see, no mention of us. It is the part that turns "everything is fine" into evidence in the client conversation.

This is the normal case, not the exception, and we do not price a retainer until we know what is in the codebase.

Takeover runs as a short paid engagement before the retainer starts: a security and code audit, a dependency and module inventory, a look at the deployment path and the backup position, and a written list of what we would fix first. You get that document whether or not the retainer goes ahead, including the case where our recommendation is that the site needs an upgrade or a rebuild rather than a support contract.

Quoting a monthly fee on a codebase nobody has read is how support contracts end badly for both sides. We would rather find out first.

Maintenance and support runs from $100 to $5K and above per month, per project, sized to the system. The published band is on our pricing page, and it is the same band our direct clients pay. There is no lock-in period.

What moves a site within that band: traffic and uptime expectations, how many contributed and custom modules are carried, how many integrations have to keep working, whether out-of-hours coverage is needed, and the ticket volume the site actually generates. The takeover audit turns those into a number, and the number is fixed for the term once agreed.

Agency terms are agreed before you commit, never after. That has been the position on every partner engagement since 2012.

A development project we build carries a warranty, held by the party that signs the project with us, which for agency work is your agency: one year by default, up to three. It covers defects in what we delivered against what was agreed. It is not a support contract, it does not cover a change of requirement, and it does not cover a site somebody else built. The warranty policy sets out the boundary.

A support retainer is the other thing: continuous care of a running system, including one we did not write, including changes nobody anticipated. Agencies routinely hold both: the warranty on the build, and a retainer for everything the warranty was never meant to cover.