In our recent article on the IT support standards, I touched on the number of support requests that never get logged: the Teams message to a favourite technician, the phone call, the conversation in the corridor. I also suggested that one of the main reasons it persists is the IT team’s own desire to be helpful. That point generated more conversation than anything else in the article, so it seemed worth exploring properly.
Let me be clear from the start. A helpful IT team is a good thing. Most of the IT staff I’ve worked with in colleges and academy trusts, whether in-house or contracted out, care a great deal about the people they support, and they go out of their way to sort problems quickly. The issue isn’t the helpfulness. It’s what happens when helpful becomes “yes to everything, by any route, straight away”, and nobody, including senior leaders, steps in to shape it.
What it looks like
Most people working in education IT will recognise one, many or all of these:
- The “while you’re here” request when a technician is in a classroom for something else.
- Teams messages sent directly to one person, because “they always sort it”.
- The senior leader who rings the IT manager’s mobile rather than logging a ticket.
- Small projects agreed in passing, with no record and no thought about what they displace.
- The phrase “can you just have a quick look at…”. We all know “quick” is doing a lot of heavy lifting in that sentence, especially when it is preceded by “I know you are eating your lunch but….”.
Individually, each of these seems harmless, and the person asking usually gets a faster answer than they would have done otherwise. That is exactly why the habit is so hard to break.
Why it happens
There are usually several reasons, and they reinforce each other.
Genuine care. IT staff in education often know the people they support personally, sometimes for many years. Saying “please log a ticket” to a colleague you’ve known for a decade can feel cold, even rude.
Fear of being seen as obstructive. Nobody wants to be the “computer says no” department. In my experience, many IT teams worry, often with good reason, that pushing back will be reported upwards as poor service, and that senior leaders won’t support them.
History. In some organisations, people started going direct because the formal route didn’t work. If tickets used to disappear without trace, going straight to a person was a rational response. The service may have improved since, but the habit remains.
Leadership behaviour. Senior leaders are often among the most frequent users of informal routes. It’s rarely deliberate, and it’s usually because they are busy and need something fixed quickly. But it sends a clear message to everyone else about how things really work.
No visible consequence. When a direct request gets dealt with quickly and nobody comments, it is rewarded. When a ticket waits in a queue behind those direct requests, the person who followed the process is the one who loses out.
The hidden cost
The cost of all this is real, but it’s spread thinly enough that it rarely gets noticed.
The workload becomes invisible. Work that isn’t logged doesn’t appear in any report. The team feels stretched, and they are, but the data shows a manageable ticket volume. When the IT manager asks for more resources, there is no evidence to support the case. In effect, the team’s helpfulness is used against them.
The service becomes unfair. People who know who to ask, or who are senior enough to call directly, get served first. Those who follow the process, those who understand the importance of process, staff on the far flung other campuses or simply quieter colleagues, wait longer. That isn’t anyone’s intention, but it is the outcome.
Prioritisation breaks down. If the service operates with SLAs and service priority matrices, calls logged via the process will be done in the order the priority requires. As soon as the drop-in jobs get done there and then this breaks down and can lead to higher priority tasks going unhandled at the expense of something that would be scored much lower.
Interruptions are expensive. Every unplanned request breaks someone’s concentration. For technical staff working on complex problems, constant interruptions add up to a significant loss of productive time, and they are a major contributor to the feeling of being busy all day without finishing anything.
Recurring problems never get fixed. If the same issue is solved informally twenty times, nobody sees the pattern. The underlying cause is never addressed, so the problem keeps coming back.
Single points of knowledge grow. The person everyone goes to becomes indispensable, often without anyone recognising it. They carry knowledge nobody else has, they can’t easily take leave, and they are at real risk of burning out. When they eventually leave, the gap is far bigger than anyone expected.
Security risks increase. This one is often overlooked. A verbal request to reset a password, add someone to a shared mailbox or grant access to a system bypasses the checks a ticket would usually include. Social engineering relies on exactly this kind of helpfulness, and attackers know that education IT teams are generally keen to help.
The goal isn’t to say no
Changing this doesn’t mean the IT team should start turning people away. Done well, the message is “yes, and here’s how”, not “no”.
Log it for them, then show them. In the early stages, the most effective approach is for the technician to log the request on the person’s behalf, there and then, and explain that this is how it will be handled in future. It’s helpful, it’s polite and it still gets the work recorded.
Make the right route the easiest route. If logging a ticket is harder than sending a Teams message, people will send the Teams message. Self-service password reset, a simple portal with as few mandatory fields as possible, a Teams-based form and a clearly published phone number for urgent issues all lower the barrier. People will use the formal route when it’s genuinely easier.
Define what “urgent” really means. There are genuine emergencies, and a classroom without working technology in the middle of a lesson is one of them. Agree a fast route for these, such as a dedicated phone line, but make sure the request is still logged, even if IT logs it afterwards.
Close the loop. If a ticket is resolved with a meaningful note and the person is kept informed, they learn that the system works. If tickets disappear into silence, they go back to their favourite technician.
Publish the data. Show the workings. Publish the data showing how many tickets are closed within SLA. Demonstrate that the process works most of the time. Be sure to explain why things didn’t work if the process didn’t work and what the team will do differently to resolve that in the future.
What senior leaders need to do
This is where most attempts to change the culture succeed or fail. IT teams cannot change it on their own.
Model the behaviour. If SLT log tickets like everyone else, the message lands. If they don’t, nothing else will make much difference. Personally, I think this is the single most important factor.
Back the team when they redirect. When a member of staff complains that IT asked them to log a ticket, the response from senior leaders needs to be supportive of the process, not an apology on IT’s behalf. The first question should be, “What did <person who should be dealing with any issues> say when you asked them>”, next would be “Do you have the ticket number so I can investigate?”. These two simple responses will send a powerful signal and stop a lot of escalations right there.
Publish service levels and escalation routes. Everyone should know what to expect and what to do if it isn’t met. That also means supporting the team when a complaint is about something that was dealt with within the agreed service level. Escalation is for when the service fails, not for jumping the queue.
Judge IT on data, not anecdote. If the only way senior leaders hear about IT performance is through complaints and compliments in corridors, they will get a distorted picture. Regular reporting, based on properly logged requests, gives them something fair and objective to work from.
Agree priorities centrally. Requests for new work, as opposed to fixing things, should go through an agreed route. Otherwise the IT team’s priorities are set by whoever asks most persuasively, and that is rarely aligned with what the organisation actually needs.
What the IT team needs to do
The team has its part to play as well.
Be consistent. If one person always says yes to direct requests, everyone will go to them, and the change will fail. The whole team needs to agree the approach and stick to it, including the IT manager.
Log everything, including your own work. Even when a request arrives informally and gets dealt with on the spot, log it afterwards. The data matters more than the route it arrived by.
Show the results. Publish the data regularly, and use it. A monthly summary showing volumes, response times and the top recurring issues helps people understand the demand on the team. Over time, it also shows that logging requests leads to better outcomes.
Stay visible. Moving to a more structured service shouldn’t mean disappearing behind a ticketing system. Bookable time slots for appointments, regular walk-rounds, floor walking during busy periods and time spent with departments all keep relationships strong. The difference is that the work is captured, not that the contact stops.
Making the change stick
In my experience, the organisations that manage this well treat it as a culture change, not a process change:
- They explain the reasons openly, emphasising fairness and faster fixes for everyone, rather than presenting it as IT protecting its time.
- They set a clear start date, with a transition period where IT logs requests on people’s behalf.
- They expect some pushback and plan for it, rather than being surprised by it.
- They review progress after a term, share what has improved and adjust where needed.
It won’t change overnight, and there will be relapses, particularly during busy periods like enrolment, when old habits tend to return.
Final thoughts
Helpfulness is one of the best qualities an IT team can have, and nobody should want to lose it. The aim is to channel it into a service that works well for everyone, not just for those who know who to ask. That needs a consistent approach from the IT team and, crucially, visible support from senior leaders. The most helpful thing an IT team can offer is a service that is fair, reliable and able to show what it delivers.
If you’d like help reviewing how your IT support service works in practice or support with changing the culture around how requests are made and handled, please get in touch.
0 Comments