Support coverage is where good intentions turn into expensive habits. A company decides to “take operations seriously”, and within a month every service has a round-the-clock rota, a four-tier escalation ladder and a response target written by someone who has never carried a pager. The first quarter’s invoice or overtime bill arrives, the rota burns out its best people, and the original aim, fewer painful outages, is no closer. The root of the trouble is almost always the same: coverage requirements were never sorted into those that are essential and those that are merely attractive.

Six myths in particular keep teams stuck. Each is common, each sounds responsible, and each falls apart when you ask what would genuinely go wrong if the item were absent. Dispelling them is the quickest route to a support model that is both sturdier and cheaper to run.

Myth 1: “Every service needs the same level of coverage”

Reality: Services differ in consequence, so coverage should differ too. A payment path that halts revenue within minutes is not the same as an internal reporting tool that can sit idle over a weekend. Treating them identically wastes effort on the second and dilutes attention on the first. The honest approach is to list, per service, the failure that would be unacceptable and the time within which it must be addressed. Those entries are your essentials. Everything above that line, such as faster acknowledgement for low-impact tools, is a bonus that can be priced separately.

Myth 2: “A longer list of requirements produces safer support”

It is tempting to believe that more clauses mean more protection. In practice, a sprawling requirements document hides the handful of clauses that matter. When a team is asked to honour sixty obligations, it satisfies the easy ones and quietly lets the hard ones slide. A short list of non-negotiables, perhaps five or six, gets monitored. A long list gets filed.

• Write the essentials first, each with a plain statement of who is affected if it fails.
• Move every other wish into a clearly labelled “preferred” section.
• Review the essentials monthly; review preferences quarterly.

Myth 3: “Preferences are free to include, so include them all”

Reality: Every preference carries a cost, even if the cost is only dilution. Add twenty “nice-to-have” items to a support scope and two things happen. Costs rise, because someone must build and maintain the process behind each. And priorities blur, because on a bad night nobody can tell which expectations are fixed. Preferences belong in the plan, but as tie-breakers: they matter when two designs both meet the essentials, and they never justify compromising one.

Myth 4: “Principles alone will keep things steady”

Teams sometimes assume that having adopted sound engineering principles is a substitute for deciding what must be covered. Principles shape how you work; they do not tell you which service to protect first. Our overview of the guiding ideas that keep software releases dependable is a good grounding, but it assumes you have already identified the conditions that your operation cannot trade away. Sort those first, then let the principles shape how you meet them.

Myth 5: “Automation will cover whatever we did not prioritise”

Automation amplifies decisions; it does not replace them. A script that restarts a failing service is invaluable for an essential service and a distraction for a minor one. Teams that automate in the absence of ranking tend to automate what was easiest, not what was most important. If you are moving from manual operations toward code-driven infrastructure, a piece on how operations engineers grow into reliability roles through infrastructure as code traces the path, and it fits best once the essentials list is in place to tell you where to start.

Myth 6: “Only technical requirements belong on the essentials list”

Practical conditions are routinely left off because they feel administrative: language and time zone of the responding engineer, who may approve an emergency change, how data is handled during an incident, how handover notes travel between shifts. Yet these are exactly the items that decide whether support works at 3 a.m. They qualify as essentials whenever their absence would block a response. The same logic applies far beyond IT. For instance, BestCardiacHospitals, an educational website for international patients, spells out how to compare care options and states that it provides education rather than medical advice, which is a reminder that practical, non-technical needs often decide how smoothly any complicated service is used.

What a corrected support model looks like

When teams drop the myths, their support documents start to look remarkably similar. The pattern is a single page with three parts.

1. Essentials. Five or six conditions, each tied to a named service and a stated consequence.
2. Preferences, ranked. A queue of improvements ordered by impact and effort, to be adopted as capacity allows.
3. Review dates. One for the essentials, a less frequent one for the queue, with an owner for each.

Notice that nothing here is exotic. The discipline lies in refusing to let preferences masquerade as essentials, particularly when someone senior is advocating for them.

An example of the correction in practice

Take a small online retailer with five supported services: checkout, product search, an admin console, a nightly stock sync and an internal wiki. Under the old model, all five carried the same pager rota and a fifteen-minute acknowledgement target. Under the corrected model, the team writes essentials only for checkout and the stock sync, since a checkout outage stops revenue and a failed sync leads to overselling by morning. Both get round-the-clock cover with a clear owner for emergency changes. Search and the admin console become business-hours services with a next-morning review. The wiki drops to best effort.

The rota shrinks from five services to two for overnight duty, which is a noticeable relief for the people carrying it. The preferences, such as faster search recovery at weekends, sit in a ranked queue and get funded when capacity allows. Nobody lost anything that mattered, and the essentials received more attention, not less, because they were no longer competing with three lesser services for the same engineer’s focus.

If the example feels too tidy, remember that the first draft is never this clean. Expect a debate about whether the admin console is truly a business-hours service, and settle it with the consequence question: what happens if it is down until nine the next morning? When the answer is merely irritation, the classification holds.

A quick self-test

Pick one service your team supports and answer three questions in writing.

• What single failure would force us to apologise to a customer or regulator?
• Which coverage feature exists mainly because someone liked the idea?
• If our budget fell by a fifth tomorrow, which item would go first, and does that answer match our current priority labels?

If the third answer contradicts your labels, your documents and your instincts disagree, and the documents need to change. Repeat the test for your three most critical services. By the end, you will have the skeleton of an essentials list, and you will probably have found at least one expensive habit that no longer earns its keep.