If It Isn’t in the Ticket, It Didn’t Happen

Every organisation has a secret ticketing system.

Sometimes it is Teams.
Sometimes it is email.
Sometimes it is someone appearing at a desk with the words, “Have you got two minutes?”
Sometimes it is a manager texting the one IT person they know by name because “it’s probably quicker this way.”

And sometimes, if we are being honest, it is all of the above.

This is usually where the phrase “if it isn’t in the ticket, it didn’t happen” gets introduced, often with the tone of voice people reserve for safety briefings and tax reminders.

On the surface, it can sound inflexible. Slightly bureaucratic. A bit joyless, even.

But underneath it is a very practical truth:

work that happens outside the system is work the organisation cannot properly see, measure, prioritise, learn from, or govern.

That is not an admin issue, that is an operational control issue.

How side-channel support starts

Usually with good intentions.

A user needs help quickly.
Someone from IT wants to be helpful.
A manager asks for “just a quick one”.
A request feels too small to bother logging.
An issue seems easier to fix immediately than to route properly.

And, to be fair, sometimes that instinct is entirely understandable.

If somebody is blocked, solving the problem in the moment can feel like the right thing to do. In many environments, it is the right thing to do in the short term.

The problem is what happens in the long term.

A single side conversation rarely stays a single side conversation. It becomes a pattern. Certain people become known as the fast route. Certain channels become the unofficial front door. The service desk continues to exist, but more as a concept than a control.

At that point, support is no longer flowing through a managed system.

It is just moving around the organisation in human form.

Why this matters more than people think

Informal support does not just create inconvenience. It creates blind spots.

When work happens outside the ticketing system:

1. There is no shared record

That means no clear history of:

• what was reported
• what was done
• what changed
• what the user was told
• whether the issue has happened before

Which is awkward enough on a good day and deeply irritating when the same issue comes back three weeks later.

2. There is no reliable trend data

If repeated issues are solved through side messages, hallway chats, or direct emails, then they do not show up as a pattern.

Which means the organisation cannot easily see:

• unstable services
• recurring incidents
• training gaps
• process failures
• demand hotspots

The issue still exists. It is just invisible to reporting.

3. Prioritisation becomes fiction

A proper service model should allow work to be assessed against urgency, impact, and capacity.

Side-channel work does not do that. It gets prioritised by:

• who asked
• how loud they were
• who they know
• who happened to see the message first
• how guilty somebody feels for not replying

That is not prioritisation. That is emotional traffic management.

4. Capacity is distorted

When work is not logged, it looks like the team is handling less than it really is.

This has predictable consequences:

• support effort is underestimated
• resourcing decisions are based on incomplete data
• recurring drain never gets challenged
• “quick fixes” quietly eat the day

Invisible work has a remarkable talent for being both exhausting and unprovable.

5. Knowledge is harder to reuse

A resolved ticket can become:

• a reference point
• a knowledge article
• a pattern
• evidence for process change

A Teams message rarely becomes any of those things. It just disappears into the scroll.

That means the organisation keeps paying for the same learning again and again.

Why organisations tolerate it

Because, just like Shadow IT, side-channel support often works.

At least in the moment.

The user gets a fast answer.
The technician feels helpful.
The manager feels looked after.
Nobody has to log anything.
No forms. No queue. No waiting.

That feels efficient.

But it is only efficient locally. At the level of the individual interaction.

At the level of the organisation, it creates:

• poor visibility
• uneven support
• weak evidence
• recurring effort
• and an operating model built around interruption rather than flow

It is the same reason many bad habits survive in IT. They solve the immediate problem while quietly making the overall system worse.

The phrase people hate hearing

“If it isn’t in the ticket, it didn’t happen.”

I understand why people bristle at it. It can sound dismissive or overly rigid. But the principle behind it is sound.

It does not mean:

• people cannot be helped quickly
• IT should hide behind process
• every interaction must become a ceremony

It does mean:

• work must become visible
• issues must have a record
• support must be governable
• important patterns must be capturable

A service desk is not just a support inbox with a ticket number attached. It is one of the main tools an organisation has for turning support into a managed service rather than a scattered collection of favours.

The signs this is already a problem

You probably do not need a maturity assessment to recognise this.

It usually sounds like:

• “Can you just sort this quickly?”
• “I didn’t raise a ticket because you were online”
• “I already messaged Ben directly”
• “I thought this was easier than logging it”
• “This keeps happening but I don’t think it’s ever been logged”
• “Can you do this one for me and I’ll raise the ticket later?”

That last one should be placed in a museum.

If you hear these often, the service desk is not really your front door. It is one entrance among many.

And that means your support model is not under control.

What a proper service desk actually does

A proper service desk does not just shuffle requests around.

It creates the conditions for control.

It allows the organisation to:

• see demand clearly
• prioritise consistently
• identify recurring issues
• route work properly
• define service expectations
• measure response and resolution
• improve support over time

It is one of the few ways IT becomes visible enough to manage like a service instead of a loose federation of interruptions.

That matters operationally, and it matters from a risk perspective too.

Because if incidents, requests, access changes, and recurring faults are not being captured properly, then the organisation loses the ability to:

• trace actions
• understand service health
• evidence response
• and learn from failure

How to tighten this up without becoming unbearable

This is the point where some teams make a tactical error and become aggressively ticket-shaped.

Do not do that.

You do not need to become the Department of Ticketing Misery, where nobody is allowed to breathe near IT without an incident reference number.

A better approach is this:

1. Make the service desk genuinely usable

If the official route is awkward, slow, or unclear, people will use side channels.

The service desk has to be easier than the workaround.

2. Log first, solve second where possible

If someone contacts IT directly, create the record there and then.

That keeps the interaction human without sacrificing visibility.

3. Be consistent

The fastest way to undermine a service model is to apply it selectively.

If some people can still skip the process, the process is no longer the process. It is just a suggestion for everyone else.

4. Use ticket data

Show the value of the system by using it:

• identify repeat issues
• publish trends
• improve services
• inform staffing and priorities

People are more willing to use systems that clearly lead to better outcomes.

5. Explain why it matters

Most people do not object to tickets because they hate order. They object because they think the ticket is bureaucracy.

Explain that the ticket is:

• the history
• the evidence
• the route to prioritisation
• the way recurring issues get fixed properly

That changes the conversation.

Final thought

The service desk is not just an operational convenience.

It is one of the main control surfaces of an IT function.

If work is not recorded, then support becomes harder to measure, harder to improve, and harder to trust. The organisation may still be getting help, but it is not getting a properly managed service.

And that matters.

Because once technology becomes critical to the business, “just message me” is no longer a support model.

It is a risk appetite statement.

Closing CTA

Next in the series: The Change Was “Low Risk”, Apparently.

Or start with a simpler question:

What percentage of your IT team’s work is currently happening in places the service desk will never see?