Most web teams don’t have a support problem; they have a guessing problem.
A marketer spots a broken form. Someone on sales notices a 404 on a key proposal link. IT sees load spikes on the hosting dashboard. Everyone assumes someone else is “on it,” and nothing moves until a senior leader starts forwarding angry emails.
A useful web support runbook clearly maps owners, SLAs, and escalation paths for common website issues so your team stops guessing and starts working predictable support queues.
In support work, we often see the same 10–15 incidents repeat for years, each treated as a fresh fire drill because ownership and decision rights were never written down. This article shows you how to turn that chaos into a lean, living runbook your team actually uses.
To operationalize this decision, how our Ongoing Website Support work supports this decision explains the adjacent issue in more detail.
Why Your Team Keeps Guessing Who Owns What (and Why a Runbook Fixes It)
When a web issue appears today, your people probably follow some version of this pattern:
- Marketing posts in a general Slack channel or forwards a customer email.
- IT checks whether it’s “their” problem or a vendor’s.
- A freelancer or agency gets a vague ticket with no priority or deadline.
- The issue bounces around until the original requester chases an update.
Nothing in that flow is explicit. Ownership is social, not operational.
We have noticed that in many organizations, the unwritten rules are:
- The loudest person wins the resource.
- Whoever fixed it last time “sort of” owns it.
- Criticality is defined by who’s embarrassed, not business impact.
That’s Maintenance Maturity at its most reactive: heroics instead of a system.
A web support runbook fixes this by:
- Turning tribal knowledge into a shared, searchable artifact.
- Making first ownership, backup ownership, and escalation visible.
- Encoding realistic SLAs so stakeholders know what to expect.
- Giving leaders a handle to improve the system instead of chasing fires.
Rule of thumb: if two different people would take two different paths to handle the same incident, you need a runbook entry for it.
Decide What Your Web Support Runbook Is For (and What It Is Not)
If you treat the runbook as “document everything,” it will die on day three.
Your runbook is a management tool, not a documentation chore. Its job is to make recurring support work predictable across marketing, IT, and vendors.
Your runbook is for:
- Recurring incidents and small fixes (form failures, broken links, minor layout bugs, content updates).
- Operational checks (monthly plugin updates, uptime alarms, SSL renewals).
- Decision rights (who approves copy, who can hotfix production, who can call a rollback).
Your runbook is not for:
- Major projects and redesigns.
- One-off experiments that won’t repeat.
- Long policy essays that nobody will read under pressure.
Think of it as the “on-call brain” for your website support model.
A simple scoping decision keeps it lean:
If it happens more than twice a year and has real business impact, it gets a runbook entry; otherwise, it’s just a ticket.
This constraint is what keeps the runbook small enough that people actually open it instead of guessing.
Map the Core Support Domains Before You Assign Names
Most runbooks fail because they’re built as contact lists: “For X, ask Alex.” When Alex leaves, everything breaks.
Instead, start with domains: logical areas of responsibility that can outlive individual people.
For a typical B2B site, core domains might include:
- Content & UX – copy changes, images, on-page layout issues, navigation.
- CMS & templates – page types, components, content types, editor permissions.
- Forms & lead capture – forms, landing pages, thank-you flows, CRM connections.
- Integrations & APIs – CRM, marketing automation, product database, search.
- Hosting & performance – uptime, page speed, caching, CDN configuration.
- Security & access – SSL, user accounts, roles, backups, security updates.
- Analytics & tracking – tags, tracking pixels, goals, dashboards.
For each domain, define:
- Purpose (what this domain covers).
- Primary role (not name) responsible for triage.
- Backup role if the primary is unavailable.
- Primary vendor or platform involved.
Example:
- Domain: Forms & lead capture
Primary role: Marketing operations lead
Backup role: Digital marketing manager
Vendors/platforms: WordPress forms plugin, CRM, automation platform
Only after domains are clear should you map real people to those roles.
The decision here: organize your runbook by domain and role, not by today’s org chart or whoever shouted last on Slack.
Turn Common Incidents Into Clear Ownership Paths
Now translate your most frequent incidents into structured runbook entries.
Start with a working session: pull 3–6 months of support tickets, Slack threads, and “can someone fix this?” emails. List the top 10–20 recurring issues.
For each one, create a runbook row with at least:
- Incident name – short, recognizable phrase.
- Trigger / how it’s spotted – user report, alert, internal QA, etc.
- Business impact – leads blocked, revenue at risk, reputational impact.
- Domain – from your domain map.
- First owner (role) – who triages and owns progress.
- Backup owner (role) – who steps in if the first owner is out.
- Vendor touchpoints – which external partners may need to be engaged.
- Escalation condition – when this jumps to a higher tier.
A simple sample row (structure only):
| Incident | Trigger | Impact | Domain | First owner | Backup | Vendor | Escalate when |
|---|---|---|---|---|---|---|---|
| Lead form submissions not arriving | Sales reports “no new leads today” or daily form test fails | High – leads blocked on primary demo form | Forms & lead capture | Marketing operations lead | Digital marketing manager | CRM / forms plugin vendor | No fix within 2 business hours or repeated within 7 days |
Notice what’s not in this row: individual names, internal politics, or tool minutiae. You’re designing the path, not every step.
Bad vs good runbook in a real-seeming incident
Imagine it’s 8:30 a.m. on a Monday. Sales pings marketing: “We haven’t seen a demo lead in three days; is the site broken?”
Without a runbook:
- Marketing checks the site, fills out the form, waits to see if it hits the CRM.
- IT is looped in: “Is there an error log?”
- The freelancer who built the form is emailed and replies that they’re booked until tomorrow.
- No one knows who can approve a temporary backup form or landing page.
- By the time it’s fixed, the campaign has burned through budget with no leads.
With a runbook entry like the sample row:
- Any marketer can log a “Lead form submissions not arriving” incident.
- They see that Marketing operations triages, with a 2‑hour response SLA.
- Marketing operations runs a documented test, checks integrations, and, if blocked, engages the CRM vendor and escalates to IT after 2 hours.
- There’s a pre-approved fallback: switch traffic to a simpler form that emails leads directly to sales.
The hidden failure mode here is ignoring edge cases like “no one on the primary role is online” or “the vendor is slow.” Your runbook should explicitly name backups and escalation triggers so those edge cases are just another predictable path instead of weekend-long mysteries.
Decision: commit to capturing a small set of high-impact incidents first, with clear owners and escalation conditions, before you worry about exhaustive coverage.
Set SLAs and Expectations That Match Your Real Capacity
SLAs look impressive in a slide deck and dangerous in a runbook if they’re not grounded in reality.
A bad pattern we see: leadership promises 24/7 response for “anything website-related,” but there’s no actual on-call developer, and marketing sleeps at night like everyone else. The SLA quietly becomes a liability.
Instead, design SLAs around business impact and available capacity.
A simple three-tier model works for most teams:
-
Tier 1 – Critical (P1)
Examples: site down, checkout or primary lead form broken, security incident, widespread performance outage.
Target: response within 30–60 minutes during support hours; resolution or workaround same day. -
Tier 2 – High (P2)
Examples: key pages with broken layouts, secondary forms misrouting, analytics outage, issues impacting an active campaign.
Target: response within 4 business hours; resolution within 1–2 business days. -
Tier 3 – Standard (P3)
Examples: minor copy changes, low-traffic 404s, cosmetic layout issues, small UX tweaks.
Target: response within 1 business day; resolution within 3–5 business days.
For each incident type in your runbook, assign:
- Priority tier (P1–P3).
- Response time expectation.
- Resolution time expectation.
- Support hours the SLA applies to (e.g., 9–5 local time, weekdays only).
Then sanity-check your promises:
- Do we have people actually available during those hours?
- Who is on point if an incident hits at 4:45 p.m. on Friday?
- What happens on holidays and during big internal events?
If your SLA assumptions fall apart under those questions, revise them until they reflect how you truly operate today, not how you wish you operated.
One useful application of Maintenance Maturity here: revisit SLAs every quarter as you add capacity or complexity. Maturity means you tighten SLAs when you earn the capability, not by declaring them on paper.
Decision: write SLAs that your current people and vendors can actually honor; aspirational targets without capacity quietly increase risk instead of reducing it.
Design Escalation and Handoff Rules So Work Doesn’t Stall
Most of the pain in website support isn’t in starting work; it’s in handoffs.
A ticket leaves marketing, touches IT, pings a vendor, and then disappears into a shared inbox. Two weeks later, someone asks for an update and nobody can say who owns the next move.
Your runbook should answer two questions for every incident:
- How does this move between roles or teams?
- When is it officially “stuck,” and what happens then?
To design that, define:
- Primary communication channel – where incident updates live (ticketing system, dedicated Slack channel, etc.).
- Handoff checkpoints – e.g., “Marketing operations hands off to IT with X information when Y condition is met.”
- Time-bound escalation rules – e.g., “If no response from vendor within 1 business day, escalate to vendor success manager and inform business owner.”
- Decision rights at each stage – who can approve hotfixes, rollback deployments, or accept temporary workarounds.
Example of a clean escalation rule:
For P1 incidents, if the first owner cannot identify a fix or workaround within 60 minutes, they must escalate to the technical lead and the business owner for the impacted funnel, and both must be in the incident channel until resolved.
This removes the “hopefully someone notices” factor and replaces it with a predictable path.
If you suspect your current model is already too complex for your support capacity, it can help to contrast your runbook design work with a deeper look at risk signals in your model using resources like How to Tell When Your Website Support Model Is Quietly Increasing Risk (/blog/how-to-tell-when-your-website-support-model-is-quietly-increasing-risk/) as contrast material.
For a deeper treatment of this decision, related Website Support articles guidance explains the adjacent issue in more detail.
Decision: codify explicit, time-bound escalation and handoff rules for your top incident types so no ticket can sit in a shared inbox with everyone assuming someone else has it.
Build the Runbook Into Your Maintenance Maturity Cadence
A runbook that never changes is a runbook that slowly lies to you.
Every quarter, your site gains new integrations, new templates, new campaigns, and new people. If your runbook doesn’t keep pace, the guessing will creep back in at the edges.
Operationalize the runbook as part of your Maintenance Maturity cadence by:
- Owning a single source of truth – one URL or repository where the current runbook lives and is linked from tickets and onboarding docs.
- Reviewing quarterly – a 60–90 minute runbook review with marketing, IT, and any key vendors.
- Using incidents as input – during reviews, scan the last quarter of incidents: which ones didn’t map cleanly to the runbook, stalled, or generated confusion?
- Updating domains and roles – as the org chart changes, keep roles stable but update the mapping of people to roles and vendors to domains.
- Aligning with release processes – whenever you launch a new feature, integration, or campaign funnel, ask: “What’s the runbook entry if this breaks?”
This is where the runbook stops being a one-off project and becomes a governance practice.
If your team is still figuring out the right ownership and capacity model in the first place, it may help to use a prerequisite perspective like How to Decide Between Expanding Your WordPress Support Contract and Hiring In‑House (/blog/how-to-decide-between-expanding-your-wordpress-support-contract-and-hiring-in-house/) before you lock specific roles into your runbook.
As a prerequisite to this decision, How to Decide Between Expanding Your WordPress Support Contract and Hiring In‑House explains the adjacent issue in more detail.
Decision: schedule a recurring, cross-functional runbook review and tie it to your release and incident review cycles, so the document stays trusted enough that people rely on it instead of reverting to guesswork.
Who Should Own the Runbook and When to Get Outside Help
A runbook without an owner is just a shared spreadsheet slowly going stale.
Ownership here has two layers:
- Runbook product owner – the role accountable for the artifact itself. They don’t do all the work, but they own structure, updates, and adoption.
- Domain and incident owners – the roles embedded in the runbook that own specific types of work.
For many mid-market organizations, the runbook product owner sits in marketing operations or digital marketing, because they’re closest to both day-to-day site use and business impact. In more IT-led organizations, it may be a web platform owner or product owner.
What matters more than department label:
- They understand business priorities and impact.
- They can convene marketing, IT, and vendors without needing executive intervention.
- They have enough authority to say “no” to unrealistic SLAs.
You may be ready for outside help if:
- Internal teams are too close to legacy habits to design a clean model.
- There’s no shared view of what counts as “support” vs “project.”
- You don’t have the capacity to maintain the runbook alongside day jobs.
In those situations, a partner focused on operationalizing support can help you design the first version of the runbook, test it against real incidents, and then maintain it alongside the support function itself.
Decision: name a single runbook product owner and be honest about whether you have the internal capacity and neutrality to design and maintain this asset, or whether it’s time to bring in a partner.
Putting Your Web Support Runbook in Motion (Next 30–60 Days)
You don’t need a six-month governance initiative to start. In 30–60 days, you can move from “everyone guesses” to “most common incidents have clear paths.”
First 2 weeks: design the skeleton
- List your top incidents. Pull recent tickets and Slack threads; capture the 10–20 requests that keep coming up.
- Define core domains. Group those incidents into domains like content, forms, integrations, hosting, security, and analytics.
- Assign roles, not names. For each domain, pick a primary and backup role for triage and progress.
- Draft sample rows. Create runbook entries for your top 5–10 highest-impact incidents, including triggers, impact, owners, and escalation rules.
Weeks 3–4: add SLAs and test in real life
- Layer in realistic SLAs. Apply a simple P1–P3 matrix, calibrated to your actual capacity.
- Pilot with a subset of users. Ask a few marketers, IT staff, and support folks to use the runbook for new incidents for 2–3 weeks.
- Observe friction. Note where people still guess, escalate early, or bypass the document.
Weeks 5–8: turn it into governance
- Refine based on incidents. Adjust domains, owners, and SLAs based on what actually happened during the pilot.
- Formalize the quarterly review. Put a recurring runbook review on the calendar.
- Bake it into onboarding. Add “how to use the web support runbook” to onboarding for marketers, product managers, and IT.
If, while doing this, you realize the underlying complexity of your site is already stretching your support model, it may be worth using an escalation lens like How to Tell If Your Site Is Too Complex for Its Current Support Model (/blog/how-to-tell-if-your-site-is-too-complex-for-its-current-support-model/) to decide whether you’re trying to run enterprise-grade complexity with a part-time support structure.
At this point in the Buyer Maturity Path, you’re no longer just noticing recurring problems; you’re deciding how your organization will own the website long term.
If You Want the Runbook Without Owning All the Plumbing
If you’ve read this far, you probably recognize yourself in at least one of these patterns:
- Every incident starts with “Does anyone know who owns this?”
- SLAs live in someone’s head, not in agreements.
- Vendors, IT, and marketing all assume someone else is on point when things go wrong.
Leaving it that way has a predictable consequence chain:
No runbook → guessing and stalled incidents → delayed updates and hidden risk → eroded trust in the site → pressure to overbuy support or jump to a redesign that doesn’t fix the underlying ownership problem.
The decision in front of you is straightforward:
- Approve the effort to stand up a lean, role-based web support runbook in the next 60 days.
- Reject the idea if you’re comfortable with continued fire drills, unclear ownership, and opaque risk.
- Investigate outside help if you see the value but don’t have neutral capacity to design and run it.
For many teams, the most practical path is to pair a clear runbook with a support partner whose entire job is to operationalize it. That’s exactly what our Ongoing Website Support service is designed to do: we help you define domains, write incident paths, right-size SLAs, and then run and refine that system as your site evolves (/services/ongoing-website-support/).
If you want to sense-check whether your situation calls for more in-house capacity, a different vendor model, or a combined approach, a short conversation about your current support habits and incident patterns is often the fastest way to clarity; you can start that discussion through a focused outreach via our contact channel (/contact/).
Over time, you can deepen and broaden your governance beyond the initial runbook using the broader library of Website Support articles as expansion material (/blog/topics/website-support/), but the next move is simple: stop letting your team guess who owns what and give them a runbook that makes support feel like a service instead of a favor.