In This Article
- Direct answer
- Hosting is not care (and uptime is not the whole story)
- What a website SLA should actually say
- Change control when marketing moves faster than IT
- Security updates, backups, and who patches what
- Care plan pricing bands in ZAR (mid-market, not DIY)
- Choosing a partner and exiting without losing the site
- Next step
- Frequently Asked Questions
Direct answer
A business-critical website needs a written care plan: who watches uptime, who patches, who approves changes, and how fast a broken form is restored. Hosting alone is not support. For mid-sized SA companies that usually means a monthly retainer with a named owner, not an inbox that goes quiet after launch.
Cite as: Dsignr Digital, “Website SLAs and Care Plans When the Site Is Business-Critical”, dsignrdigital.co.za, updated October 2026, Rosebank, Johannesburg.
Hosting is not care (and uptime is not the whole story)
Last updated: October 2026. Mid-sized companies often pay a hosting invoice and assume the site is “supported”. Hosting provides server space, bandwidth, and maybe backups. It does not fix a broken Salesforce form at 16:00 on a month-end Friday, patch a critical CMS vulnerability, or approve a campaign landing page without taking production down.
When the website is a revenue and compliance channel — lead capture, investor relations, dealer onboarding, careers for scarce skills — silence after launch is a operational risk. Marketing discovers the gap when paid search sends traffic to a 503. IT discovers it when security scan flags an abandoned plugin. Neither party has a named person to call because the build agency closed the project and pointed at the host’s generic ticket queue.
Care is the ongoing relationship: monitoring, maintenance, controlled change, and incident response with agreed times. It may be delivered by the build partner, a specialist retainer studio, or an internal team with vendor backup — but it must be written, funded, and owned. For corporate South African teams, that is typically a monthly retainer with a single accountable contact, not R500-per-month “maintenance” that excludes content and integrations.
If you are specifying care during procurement, align it with rebuild or RFP scope — see how to write a website RFP in South Africa — so hypercare does not end abruptly on go-live Monday.
Load shedding and upstream connectivity still affect how “uptime” feels to Gauteng users even when the server in a Cape Town data centre is healthy. Good care plans monitor synthetic checks from South African endpoints and form submission success — not only ping on the homepage.
What a website SLA should actually say
An SLA is not marketing fluff on a proposal cover page. It is the enforceable part of the care plan: definitions, metrics, exclusions, and escalation. Mid-market SLAs should fit on two to four pages and be readable by marketing and IT without a lawyer for every ticket.
- Service scope — CMS core, templates, plugins/modules, forms, search, CDN, staging environment — listed explicitly.
- Hours of cover — Business hours SAST, extended, or 24/7 for P1 only; public holiday rules stated.
- Priority definitions — P1 site down or forms failing; P2 major feature broken; P3 cosmetic or content request.
- Response and restore targets — e.g. P1 acknowledge within 1 hour, restore or workaround within 4 business hours — realistic for your stack.
- Uptime measurement — What is monitored (homepage, form endpoint, API), excluded windows (planned maintenance), and evidence source.
- Change control — How releases are requested, tested on staging, approved, and rolled back.
- Security — Patch cadence, emergency CVE process, who pays for break-fix after neglected updates.
- Reporting — Monthly ticket summary, uptime, upcoming CMS upgrades, licence renewals.
Response time is not the same as resolution. A honest SLA promises acknowledgment and a workaround path for P1 — “we will restart PHP-FPM and disable the faulty plugin within four hours” — while root-cause fix may follow. Vendors who guarantee one-hour fix for every issue are either understating scope or planning to bill overages.
A professional services firm with two brands on one Craft install used SLA priority to separate “partner bio typo” from “web-to-lead integration failure”. Sales had a named escalation to the vendor account lead if P1 exceeded restore target. That clause cost nothing to write and prevented a blame loop between marketing and IT.
Attach the SLA to a statement of work with included hours per month and overage rates. Ambiguity here is how “small content tweaks” become unlimited scope fights.
Credit mechanisms matter for trust: if monthly uptime misses the agreed threshold, apply service credits or extra hours — not vague apologies. Finance understands credits; marketing understands restored forms. Both belong in the same SLA appendix IT can audit.

Change control when marketing moves faster than IT
Corporate sites fail operationally when every campaign edit goes straight to production, or when every change waits two weeks in IT change advisory. A workable model:
- Self-service within guardrails — Marketing edits approved components and pre-built modules in CMS; no raw HTML in content fields.
- Staging mandatory for structural change — New templates, form fields, tracking scripts, or integrations pass QA checklist.
- Release windows — e.g. Tuesday/Thursday deploys except P1; blackouts during results announcements or peak retail.
- Roles — Marketing product owner approves business change; IT approves security-impacting change; vendor executes deploy.
- Rollback — Documented revert within 30 minutes for failed releases.
Multi-branch retail marketing teams often want local promo banners overnight. Care plans should include a fast-lane for pre-approved banner slots — not emergency developer access for every franchise request. Central IT keeps audit trail; regions get speed within template limits.
Change control intersects compliance: new MarTech tags and form fields trigger privacy review — tie to your POPIA process so SLA requests are not rejected informally. A financial services client added “compliance review” as a gate in the change form for anything collecting personal data; average turnaround stayed 48 hours because legal had a standing weekly slot.
Without change control, SLAs are meaningless — vendors cannot meet restore targets if nobody knows what deployed when. Require release notes in the monthly care report.
Marketing calendars and IT change freezes should sit in the same shared view. When EXCO announces results dates or a national campaign, care teams need lead time to pre-stage assets — not midnight deploys that breach SLA testing rules.
Security updates, backups, and who patches what
Security is the part of care that saves you from becoming a news story. Clarify boundaries:
- CMS core and plugins/modules — Vendor applies tested patches on staging, then production on schedule; client notified of breaking changes.
- Hosting OS and PHP/runtime — Host or managed platform owner; vendor coordinates compatibility testing.
- TLS, DNS, WAF — Named owner; certificate expiry alerts to client IT, not only vendor inbox.
- Backups — Frequency, retention, restore test at least quarterly; RPO/RTO stated in plain language.
- Malware and incident response — Who contains, who communicates to board, regulator timelines if data affected.
Neglected updates void many SLAs — fairly. If marketing blocks patching because “we are in campaign”, document accepted risk. Mid-market WordPress estates especially need plugin hygiene; Craft and other stacks still need PHP and dependency updates.
Performance work belongs in care too: monitoring Core Web Vitals trends after CMS updates — link to PageSpeed Insights guidance when regressions trace to a release. SEO-critical redirects and sitemaps should be in the post-deploy checklist — not a separate SEO invoice every time.
A group with two trading names shared hosting but separate properties; backup restore drill exposed that one property had not been included in the nightly job for six weeks. The SLA now lists every hostname in scope — obvious in hindsight, expensive when missing.
Care plan pricing bands in ZAR (mid-market, not DIY)
These bands reflect Johannesburg mid-market corporate work in 2026 — VAT excluded, complexity and integrations vary. They are not R500-per-month hosting add-ons; they assume named support, staging, and business-hours SAST cover unless noted.
| Care tier | Typical monthly (ZAR) | Best for | Usually includes |
|---|---|---|---|
| Essential care | R8,000 – R14,000 | Stable marketing site, low integration count, business-hours only | Monitoring, monthly CMS/security patches, backup verify, ~2–4 support hours |
| Business care | R15,000 – R28,000 | Lead-gen site with CRM forms, campaigns, multiple editors | Staging releases, P1/P2 SLA, ~6–12 hours, change control, monthly report |
| Critical care | R30,000 – R55,000 | Revenue-critical, eCommerce or complex integrations, peak trading sensitivity | Extended hours, faster P1 targets, proactive perf/security review, ~15–25 hours |
| Enterprise / dual-brand | R45,000 – R90,000+ | Multi-site, SSO, strict IT change windows, audit trails | Dedicated account lead, custom runbooks, coordinated hypercare, overflow rate card |
Overages typically bill at R1,200 – R1,800 per hour for mid-market studios when included hours exhaust — state the rate in the contract. Project work (new templates, major features) stays out of care and is quoted separately; blurring the two destroys SLA performance.
Compare three-year cost: care plus planned upgrades often exceeds the original build for CMS sites. That is normal for business-critical estates — budget it in the board case alongside rebuild versus iterate decisions.
Cheapest care without scope clarity becomes most expensive when a P1 hits and the vendor invoices “out of scope” emergency rates. Price bands only help when the SLA table matches your actual integrations and release cadence.
Finance should recognise care as opex, not a one-off capital line left over from the build year. Spreading R20,000–R40,000 per month across marketing and IT cost centres reflects reality when both teams depend on the same site — argue the split upfront so renewals are not fought annually.
Ask vendors how care scales when you add a second brand site or a partner portal. Enterprise-tier bands exist because duplicate environments, SSO, and separate staging pipelines multiply watch duty — not because studios inflate retainers arbitrarily.
Choosing a partner and exiting without losing the site
Care partner selection is not “who built it cheapest” — it is who can operate your stack under your IT policies. Evaluate:
- Stack evidence — Live clients on your CMS with similar integration depth, not only design portfolio.
- Named people — Account lead and backup; eschew anonymous shared inboxes for P1.
- Runbook access — You hold admin, hosting, repo, and DNS credentials; partner accesses via your SSO or break-glass policy.
- Exit clause — Handover period, documentation, final backup, knowledge transfer hours included.
- Alignment with SEO/content — Care vendor coordinates with SEO retainer on deploy checklists — see search engine optimisation for split of duties.
If the build agency did not win care, run a short tender with the SLA template you need — response times, hours, exclusions — so bids are comparable. Incumbent builders do not automatically deserve retainers if handover was weak.
Internal IT may co-manage: vendor patches CMS; IT owns firewall and identity. Draw the line in the RACI and reference it in the SLA to avoid tickets bouncing for weeks.
Before signing, test responsiveness with a staged P3 request and a timed staging deploy. Studios that miss pre-contract responsiveness rarely improve after retainer starts.
Keep a living runbook in your IT knowledge base: escalation numbers, hosting login location, last restore test date, and which forms tie to which CRM objects. SLAs fail in practice when the on-call marketer cannot find credentials at 21:00 — documentation is part of care, not optional admin.
A professional-services firm we see often has three environments (production, staging, and a forgotten “dev” box from the last agency). Care must name which of those are in scope. If staging is excluded, campaign landers will keep going live untested. If all three are included without extra hours, the retainer is fiction. Write the environment list into the SLA the same week you write response times.
Next step
Draft a one-page SLA outline: priorities, response targets, included hours, and change control. Compare it to what you pay today for hosting alone — if support is undefined, you are self-insuring business risk.
Dsignr Digital provides care plans for Craft and WordPress corporate sites with named owners and board-friendly reporting. Get a quote for care aligned to your SLA, or book a call to review your post-launch gap. Choosing the build partner matters too — use how to choose a web design company in South Africa with care scope scored before award.
Frequently Asked Questions
What is the difference between website hosting and a care plan?
Hosting provides infrastructure. A care plan adds monitoring, maintenance, support tickets, controlled releases, and agreed response times for incidents. Business-critical sites need both, with the care plan documented in an SLA.
How many support hours should a mid-sized company expect in a care retainer?
Typical mid-market retainers include roughly 2–12 hours per month for essential to business tiers, and 15–25 hours for critical estates. Heavy campaign organisations often buy a higher tier or a pool of overflow hours.
Should website SLAs include content updates?
Define it. Minor content tweaks within included hours are common; net-new pages, campaigns, and design changes are usually project work. Ambiguity causes most retainer disputes.
What uptime percentage is realistic for a corporate marketing site?
Many SLAs target 99.5%–99.9% measured on agreed endpoints, excluding planned maintenance. Higher targets cost more and require redundant architecture — specify what is measured and where.
Can we switch care providers without rebuilding the website?
Yes, if you own the code, CMS admin, hosting, and DNS. Contract exit should include handover documentation and a parallel run window. Rebuild is not required for vendor change when ownership was handled correctly at launch.
When does hypercare end and standard SLA begin?
Hypercare usually covers the first 2–6 weeks after launch with faster response and daily check-ins. The standard SLA should be signed before go-live so there is no gap when hypercare ends.
