The ops load stops being a queue the day incidents, changes and capacity decisions all need the same shared context and the same automation. At that point what is missing is not one more ticket in a silent backlog: it is a place where the real state of the platform, the runbooks and the name of the person accountable all exist before the request does.
What the ticket model does well
Opening with the case for the prosecution would teach nobody anything. A ticket queue is a good tool when a request is discrete, self-contained and traceable: an access to create, a certificate to renew, an alert to triage. It gives you a history, evidence the work was done, and a workload split several people can read. Plenty of estates live perfectly well that way, and nothing justifies changing while that holds.
The model also has a contractual merit: it makes the service countable. That is what makes it comfortable to buy — and it is also what turns against everybody as soon as the components start depending on one another. Within what an operational upkeep contract actually covers, corrective work splits into requests very neatly; preventive and upgrade work does not.
The three moments a queue becomes the problem
The incident that needs context. A full disk takes ten minutes. Latency that has been creeping up for three days on one user journey cannot be handled in a queue at all: you need to know what was deployed, what changed on the provider side, which service limits are close, and what the same failure looked like last year. None of that is in the ticket. If it is nowhere else either, every ticket turns back into an investigation, and the investigation starts from zero each time.
The change that touches more than one thing. A database engine upgrade is not a task, it is a sequence: check the application dependencies, rebuild a faithful test environment, run the cutover, know how to roll back. Cut into tickets, the sequence loses what made it valuable — the order of the steps, and the fact that one person holds it from start to finish.
The capacity decision. Resizing, committing to capacity, switching non-production environments off overnight: these are judgement calls, not requests. Nobody raises a ticket to make a judgement call. The outcome is predictable: the decision is never taken, the footprint stays whatever it was on go-live day, and the subject comes back later in a form nobody enjoys reading.
The operational upkeep does not go away: its unit of work changes. Instead of a request handled, the unit becomes a described environment, an executable runbook and a shared view of the real state. That is what BAM, our operations platform, is for: environments are provisioned as code, the repetitive run tasks — patching, backups, restarts, shutting non-production environments down — are automated, and cost, inventory, drift and configuration gaps are all read in one place.
The most useful consequence is not the time saved. It is that recovering from an incident becomes a rebuild rather than an improvisation: the target environment is described, therefore reproducible. And that a human steps in only when a decision is required, which is precisely the work a queue cannot schedule.
The four differences that matter
- The unit of work. Tickets count interventions; a platform counts environments under control. Both numbers can look good at once, but only one of them tells you whether the system is healthy.
- Where the knowledge lives. In the first model it lives in the head of whoever has seen the failure before. In the second it lives in the code that describes the environment and in the runbook that handles the case. The difference is measured the week that person is on holiday.
- What repeats. A queue handles each occurrence; automation removes the whole class. As long as the same request comes back every week, operations is organised to handle it, not to make it disappear.
- The name of the owner. A backlog has no owner, it has a depth. An operated estate has a named counterpart, who has to be able to decide within their scope without convening a committee.
It does not replace a written scope. The boundary between the infrastructure and the business code still has to be drawn, and that is exactly where badly written contracts produce ping-pong while production is down. Nor does it remove one-off requests: there will always be some, they will keep going through a queue, and a queue is the right tool for them.
Finally, it does not excuse you from reversibility. An operations platform that made leaving impossible would merely have swapped a dependency on a few people for a dependency on a tool. That is why the environments stay described in a format you keep, and documented so that somebody else can pick them up.
How to tell which side you are on
- The same three or four requests come back every month, and nobody has a mandate to make them stop.
- Resolution times are good, but the ticket count never falls.
- Rebuilding a production environment would require one specific person, and that person is the only one who knows.
- No capacity decision has been taken since go-live, because none of them fits the shape of a request.
- The real state of the estate — what runs, what it costs, what has drifted — is reassembled by hand before every steering meeting.
The right moment to change model
It is not a switchover. On the estates we take over, the order is almost always the same: describe what exists, automate what comes back most often first, and only then reopen the contract. A fixed fee priced on the scope — number of environments, criticality, hours of cover — rather than on a ticket count only makes sense once that first step is done. It is also the only one that aligns both interests, because the provider is no longer paid in proportion to the number of incidents.
If you are still unsure, the question to ask is not “how many tickets a month?” but “what will still be coming back next month, and who is allowed to delete it?”. The answer alone tells you which model you belong to.