Here is a story we hear in some form from almost every managed services team. The monthly report looks fantastic: tickets closed quickly, response times well inside the contract, a neat green chart on the front page. Then the client’s operations head joins the review call and says, politely but firmly, “None of this matches how it feels on our side.” The gap is rarely laziness or bad faith. Much more often, it is a disagreement about what one small word means. This fictional case study follows a support team through exactly that problem, and shows how agreeing on support ticket definitions turned a tense account into a steady one.<\/p>\n
Let us call the support provider “Harbour Ops”, a small managed DevOps team looking after cloud infrastructure, pipelines and monitoring for several mid-sized companies. One of their clients, a logistics software firm we will call “Northline”, had signed up for round-the-clock support with response commitments tied to ticket priority.<\/p>\n
The first few months went smoothly. Harbour Ops answered quickly, fixed what was broken and closed tickets. Their engineers were capable and keen. Northline paid on time. Everyone seemed happy, until the quarterly review.<\/p>\n
Harbour Ops presented a report showing that almost every ticket had been resolved within its target window. Northline’s operations head listened, then pulled up her own list: a dozen issues her team considered still open, several of which had come back two or three times.<\/p>\n
“Your report says these were resolved,” she said. “From where we sit, they keep happening.”<\/p>\n
The Harbour Ops account lead was genuinely confused. Every one of those tickets had been closed with a note explaining what was done. The engineers had followed the process. What had gone wrong?<\/p>\n
After the call, the account lead sat down with two of the engineers and the Northline operations head for an honest conversation. They went through the disputed tickets one by one. A pattern appeared quickly.<\/p>\n
To Harbour Ops engineers, a ticket was “resolved” when the immediate symptom stopped. A disk filled up? Clear space, confirm the service is back, close the ticket. A pipeline stuck? Restart the runner, confirm the build passes, close the ticket.<\/p>\n
To Northline, “resolved” meant the problem would not come back. Clearing a disk without understanding why it filled was, in their eyes, a temporary patch. Restarting a stuck runner without finding the cause was the same.<\/p>\n
Both meanings are reasonable. Neither had ever been written down. The contract simply said tickets would be “resolved” within certain windows, and each side had filled in the meaning from its own experience.<\/p>\n
Once they started looking, they found other mismatches:<\/p>\n
Each mismatch explained part of the frustration. Together, they explained almost all of it.<\/p>\n
The account lead suggested something simple: a one-page list of support terms, agreed by both sides, with a single meaning for each and a named owner. No new tooling, no contract renegotiation at first, just clarity.<\/p>\n
The biggest win came from admitting that one word was doing two jobs. They introduced two states:<\/p>\n
Tickets could now be mitigated quickly, which was what the response targets were really about, while staying visible until they were properly resolved. The monthly report showed both numbers.<\/p>\n
For “critical”, the two sides agreed that Northline would own the definition, because only they could judge business impact. Their wording focused on customer deliveries, not infrastructure state. Harbour Ops engineers got a short guide with examples so they could classify tickets consistently at three in the morning.<\/p>\n
An automated acknowledgement was useful, but it no longer counted as a response. The clock now stopped when a named engineer had looked at the issue and posted a first assessment. This made the numbers slightly less flattering, and far more trusted.<\/p>\n
For “out of scope”, the team listed specific examples on each side of the line. Application code: out. Application configuration files deployed through the pipeline Harbour Ops managed: in. Grey areas went to the account lead for a decision, which was then added to the list.<\/p>\n
A detail that made a big difference was naming owners. Northline owned “critical” and anything else describing business impact. Harbour Ops owned “mitigated”, “resolved” and “responded”, because those described how their team worked. Scope was jointly owned and could only change with both sides agreeing. Ownership meant that when someone wanted to adjust a meaning, they knew exactly whose call it was.<\/p>\n
This kind of clarity fits naturally with broader DevOps principles around shared responsibility and feedback<\/a>: both sides can only improve what they describe the same way.<\/p>\n It would be nice to say the change was effortless. It was not. In the first fortnight, two engineers kept closing tickets out of habit, and the old meaning of “resolved” crept back into a handful of notes. A night-shift engineer also struggled with the new priority guide, because one of Northline’s examples described a customer they had never heard of. The fixes were small: a reminder pinned in the team channel, a tweak to the ticket form so “resolved” could not be selected without a cause recorded, and a clearer example in the guide. None of these steps was clever. They simply made the agreed meanings easier to follow than the old habits.<\/p>\n The next quarterly review was a different conversation. The report showed fewer tickets “resolved” within the month, because more were honestly marked as mitigated and awaiting a lasting fix. That might sound like bad news. Northline’s operations head saw it the other way. For the first time, the report matched what her team experienced.<\/p>\n Repeat issues also dropped. Once engineers knew a ticket would stay open until the cause was found, they spent more time on root causes. The disk that kept filling up turned out to be a log rotation setting nobody had touched in years. The stuck runner was a network timeout that only showed under load.<\/p>\n The relationship warmed noticeably. Northline extended the contract and added another environment.<\/p>\n Engineers in support roles sometimes feel that definitions are a manager’s job. In practice, the people closing tickets are the first to notice when a word is stretched. Being the person who raises it, calmly and early, is a real skill, and one that shows up across many of the support, reliability and platform job titles<\/a> in this field.<\/p>\nA few bumps along the way<\/h2>\n
What happened next<\/h2>\n
What support engineers can take from this<\/h2>\n