Chapter 01
Your queue is four problems arriving in different clothes
Take a group with nine properties and something like 180 tickets a month. Read the list top to bottom and it looks like 180 separate problems. Sort it by cause and most of it collapses into four themes: somebody cannot log in, somebody is joining or leaving and their access has to change, a device has lost the system it talks to, one room says the connection is bad. The same four, every month, in different clothes.
Individually trivial, collectively expensive
No single one of those tickets is hard. That is exactly why they get underestimated. A locked account is four minutes of real work, and the four minutes are not the cost. The cost is the twenty-five minutes of elapsed time before the person can work again, the interruption to the technician and the second interruption when they go back.
Multiply that by 180 and you are not looking at a nuisance. You are looking at most of a full-time role, spent on work that is neither difficult nor optional, by people you hired for the work that is.
Small tickets set the response time for the large ones
Queues behave badly when they fill with small items. One big incident occupies a technician for an afternoon and everybody can see it. Sixty small ones occupy the whole team all week and nobody can point at them afterwards. The second is the expensive one, because the incident that genuinely threatens a property waits behind six items that needed no judgement.
That is the argument for automating the recurring themes. Not that any one of them is expensive, but that clearing them changes what the queue can do for everything else.
The tickets that hurt you are not the difficult ones. They are the easy ones that never stop arriving.
Chapter 02
A Thursday, read as a queue rather than as a day
Take one ordinary Thursday across those nine properties. 24 tickets between 7am and 7pm, none of them an emergency, and by the end of it two technicians have finished nothing either would put in a report.
The shape of the day
7:10am, a night auditor cannot get into the reporting tool after a password change. 8:40am, a key encoder at the second property has stopped seeing the property management system. 10:15am, a housekeeping tablet will not join the network. 11:30am, the same reporting tool, a different person, the same cause. Lunchtime brings two connection complaints, and neither guest is in the room when anybody calls back. 2pm, a label printer in a back office. 3:20pm, an account locked for the third time this month. Ten more between 4pm and 7pm, eight of them versions of something already on the list.
What the technician was actually doing
Look at where that day went and very little went on repairs. The encoder took nine minutes to fix and ninety minutes to reach, because the first hour went on establishing which encoder, on which segment, patched when and whether anybody had touched the property management system that morning. The two connection complaints took four calls to establish that one was a room and one was a laptop.
That is the shape of nearly all of them. The repair is short and known. Everything in front of it is assembly, and assembly is where the week goes. It is also the part nobody writes down, which is why the queue looks cheap on paper.
The four tickets you keep buying
Somebody cannot log in
A password change, a lockout, an expired session, a shared account nobody owns. The repair is under five minutes and the cost sits everywhere else: the elapsed time before that person can work, the interruption at both ends and a third repeat this month from a colleague with the same problem for the same reason.
Somebody is joining or leaving
Six systems, a start date that has already moved once, a manager on a day off and a leaver whose licence is still being paid for. None of it is difficult and none of it can be skipped, which is why it slides down the queue until it becomes urgent at 11pm on a Friday.
A device has lost the system it talks to
A key encoder, a label printer, a payment terminal, a tablet. The remedy is usually known and usually short. Working out which device, on which segment, patched when and what changed that morning is neither, and that is the part that consumes the afternoon.
One room says the connection is bad
The only real work is establishing whether the problem is the room, the device or the expectation, and that answer normally costs three calls to a guest who is not in the room. Gather the evidence automatically and the human conversation gets shorter and much better informed.
The one that is not a fault at all
One ticket that Thursday is different in kind. It opened on Tuesday, no alert sits behind it and nothing is broken. A new duty manager starts on Saturday at 7am and has to exist in six systems before she does. It is the ticket most likely to be finished late on Friday by somebody tired, copying the last starter they can remember.
Chapter 03
The ticket that had been open since Tuesday
Pick that one up at 4:05pm on Thursday and run it with an agent in front of it. From approval to finished is ninety seconds. The ninety seconds are the least remarkable part, because the provisioning was never what made this ticket take three days.
What the agent assembles before anybody looks
By the time a person sees anything, the chasing is done. The agent holds the start date and contract type from the joiner record, the property and the cost centre, the shift pattern that decides whether she needs remote access and the licence position, which matters because one of the six systems has no spare seat at that property. It also holds the last three duty-manager starters at comparable properties, the permission set each was given and which of those permissions were quietly removed afterwards.
That is ten emails, two phone calls and three days of waiting, compressed into the part nobody bills for. Nothing has been created yet and no permission has been granted.
The approval is about entitlement, not about breakage
Then it stops, and where it stops is the whole design. Four of the six systems are unambiguous: a mailbox, the rota tool, the internal wiki and the incident channel. The other two carry money. The property management system can be given the override role, which allows a rate change, a comp and a void. The payment back office can be given a refund role. Those are not technical decisions, and IT is the wrong department to make them from memory on a Friday evening.
So the proposal goes to the head of department rather than the service desk. She sees six systems, four marked routine and two marked for her decision, with the permission history of the previous three duty managers underneath. She grants the override role, withholds the refund role until the new manager has finished her first month and approves at 4:07pm. That is the entire human contribution, and it is a judgement about what a person should be allowed to do rather than about what a machine might break.
Ninety seconds, and what exists at the end of them
Provisioning runs. Six accounts, group membership, licence assignment, a device enrolment waiting for Saturday morning and the withheld permission recorded as withheld rather than simply absent. Ninety seconds, and every step written down as it happens: what was created, who authorised it and what was deliberately not granted.
That last line is the one that pays for itself. A refund role withheld on purpose looks identical, inside any system you own, to a refund role nobody thought about. Six months later, when somebody asks why a duty manager can void a folio, that is the difference between a decision and an accident.
Chapter 04
What comes back when the queue stops eating the week
Speed is the easiest benefit to describe and the least interesting. A guest not waiting at a counter is worth something. A duty manager who can log in on her first shift is worth something. Neither changes the shape of your IT function. The hours do.
The arithmetic over a month
Return to the 180. Suppose two thirds are versions of the four themes, and suppose the assembly in front of each is absorbed while a person keeps every step that carries judgement. What comes back is not only technician minutes. It is the interruptions, which cost more than the tickets did, and the queue position they held in front of work that mattered more.
Which is why the honest measure is not tickets closed per hour. It is how much of your team’s month is available for work that genuinely needs a person, and whether that work is finally getting done.
What the returned hours are for
The migration deferred four times. The property whose network was built for a smaller hotel than the one now standing on it. The access review nobody has had a clear week to run, the one that would have found the three leavers still holding a licence. The opening in eleven weeks that needs somebody thinking about it now rather than in week ten. None of that is automatable, and a queue full of the same four tickets has been quietly cancelling all of it.
Chapter 05
Service levels stop being a promise and start being a product
The commercial consequence is the part most groups miss. When resolution is consistent and evidenced rather than dependent on who is on shift, a service level stops being a sentence in a contract you hope is never tested. It becomes something you can measure and tier.
Tiering by how critical the property is
Not every property deserves the same response. A 400-room conference hotel in a congress week and a 60-room seasonal property in February have different tolerances for the same broken thing, and pretending otherwise is how a group overpays everywhere and underserves where it counts. Handling the four themes the same way everywhere makes the distinction practical. The response commitments, the approval thresholds and the escalation paths differ by tier.
Evidence you can hand to somebody else
The record earns its keep a second time here. It lets you report what was resolved, how quickly and on whose authority, without anybody reconstructing a month from memory. That matters internally, where a board asks what Managed IT Support is actually buying. It matters externally too, because corporate customers increasingly sit inside NIS2 scope, and Article 21(2)(d) requires them to manage security in their relationships with direct suppliers and service providers. You are a direct supplier, and the question of who holds access to what arrives whether or not you have an answer.
None of this is an argument that the four tickets do not matter. They matter enormously to the night auditor locked out at 7:10am and to the duty manager who cannot open her first shift. The argument is that they should stop costing what they cost, and that the part worth keeping a person for was never the repair. It is the moment somebody decides what another person is allowed to do.