Ask ten customers of a managed DevOps support service what they thought they were buying, and you will hear ten versions of the answer. Some expected an engineer to be on the phone within seconds. Some expected every problem, in every system, to be covered. Some expected the support team to know their architecture by heart on day one. Reality is more modest and, once understood, more useful. This article takes six common beliefs about DevOps support expectations and checks each against how support work actually runs.
The approach is analytical. For each myth we state the belief, look at what usually happens, and suggest the plain sentence that should be said at the start so the belief never takes hold.
Myth 1: “Round-the-clock support means round-the-clock fixes”
The belief: if a service is available at all hours, any problem will be solved at any hour.
The evidence: availability and resolution are different things. A team that answers at three in the morning can acknowledge the issue, gather information and apply a known remedy. It may not be able to repair a deep fault in the middle of the night, especially when the cause sits in a system it cannot change without approvals.
What to say up front: describe what the night shift can do, what it cannot, and what happens to unresolved issues in the morning. A customer who has read that sentence will be reassured by an acknowledgement rather than furious at a delay.
Myth 2: “A fast first reply means a fast solution”
The belief: response time and resolution time are the same.
The evidence: a quick reply is a courtesy and a first step. Resolution depends on diagnosis, access, dependencies and sometimes on the customer’s own availability to approve a change. Support reports that blend the two figures hide the truth and leave customers puzzled.
What to say up front: explain the difference, give typical ranges for both, and say which parts of resolution depend on the customer. For background on how delivery practices shape these outcomes, a piece on core DevOps tenets for shipping effectively gives a handy backdrop.
Myth 3: “Support covers everything we run”
The belief: once a contract is signed, the support team looks after the entire estate.
The evidence: in most arrangements, coverage is scoped to named systems, versions and environments. A legacy server nobody mentioned, a third-party tool with its own vendor or a staging area used only occasionally can all fall outside the line. The first time a customer discovers this is usually during an incident.
What to say up front: share a plain list of what is covered and what is not, and invite the customer to flag anything missing. An honest “not included” list prevents the worst arguments.
Myth 4: “The support team already knows our systems”
The belief: engineers arrive on day one with full knowledge of the customer’s setup.
The evidence: knowledge is built through onboarding, documentation and time. In the early weeks, responses may be slower because the team is learning where things live and which quirks matter. Even later, staff rotations mean that not every engineer has seen every part of your environment.
What to say up front: describe the onboarding period, what the customer must supply, and how the support team will keep notes so knowledge does not sit in one head. Customers who help during onboarding usually get faster, better answers later.
Myth 5: “If it breaks, support will prevent it from breaking again”
The belief: every incident ends with a permanent cure.
The evidence: some incidents do, but many end with a workaround while a proper fix waits for a change window, a budget decision or a development cycle. Prevention often involves work that sits outside support itself, such as changes to application code or design choices made years ago. The thinking in why operations engineers benefit from adopting reliability practices explains why durable fixes tend to involve both sides of the table.
What to say up front: distinguish between restoring service and removing the cause. Make clear who decides when the second task is scheduled and who pays for it.
Myth 6: “Good support means never hearing about problems”
The belief: a quiet inbox is the sign of excellent support.
The evidence: silence can mean health. It can also mean that nobody is watching, or that a problem is brewing unseen. Customers who expect to hear nothing are more alarmed by a real incident than those who have been told to expect regular summaries, even uneventful ones.
What to say up front: agree on a rhythm of routine reports, and describe what a normal week looks like. Then a quiet week is recognised as quiet, not forgotten.
The thread running through all six
Taken as a group, the six beliefs share a shape. None concerns technical skill. Each is a gap between a customer’s mental picture and the actual terms of service. That is why the same remedy works for all of them: a short, plain expectations note, delivered at the beginning and reissued when circumstances change. It should cover response and resolution, coverage, onboarding, preventive work and reporting rhythm.
A good test is to ask a customer, after the first month, to describe in their own words what they believe the service includes. Compare it with the contract. The differences are the next items to put in the note.
A lesson borrowed from public events
Event organisers fight the same myths every week. Guests assume the ticket covers everything, that the doors open exactly on time and that the organiser controls the weather. The clearer organisers publish plain details beforehand. A platform such as BhopalOrbit, which Bhopal organisers use to publish events and customers use to discover them and buy tickets, makes it easy to state those details in the listing itself. Support providers can follow the same habit with a short service summary.
One practical tip for providers: keep a running list of every surprised remark a customer makes in the first quarter. Phrases such as “I thought you would handle that” or “I assumed it was included” are raw material. Each one points to a sentence missing from your note. After a few customers, the list stabilises, and you will find that a handful of lines cover most of the confusion. Customers, for their part, can do the mirror exercise: write down what they assume before signing, and ask the provider to confirm or correct each assumption.
Writing the note: a short outline
- What we will do when you contact us, and in what order.
- How quickly we reply, and how that differs from how quickly we resolve.
- What is covered, what is not and what is unclear.
- How we learn your systems and what we need from you.
- Where permanent fixes fit and who decides.
- How and when you will hear from us in quiet weeks.
Conclusion
The six myths cost providers and customers a great deal in frustration and renegotiation, yet each one can be addressed in a single sentence. If you offer support, write those sentences today. If you buy it, ask for them. Either way, the relationship starts on firmer ground when both parties have said out loud what will and will not happen. Disappointment is, after all, largely a measurement of the distance between expectation and experience. Shorten the distance at the beginning, and most of the rest takes care of itself.
