ITSM process problems are the real cause of most IT backlogs. Most IT leaders assume the issue is headcount. It almost never is.
According to Ivanti’s 2024 ITSM Trends Report, only 46% of organisations use service desk ticket automation, meaning the other half are manually processing requests that technology could handle in seconds. The backlog is not growing because the team is too small. It is growing because the process is working against them.
These problems are invisible until they compound. There is no red alert when change management breaks down. Instead, you notice the business keeps complaining, the team keeps firefighting, and nothing ever gets ahead. Below are the seven clearest signals and what to do about each one.
Not sure where your biggest process gaps are? Book a diagnostic call and we will map them in 30 minutes.
The 60-Second ITSM Process Diagnostic
Before the detail, score yourself. Check every statement that applies to your team right now.
- Your ticket backlog is roughly the same size week to week, despite the team working at capacity
- The same issues recur. You fix them, they come back.
- When leadership asks how IT is performing, you need 45 minutes and three data sources to answer
- End users regularly chase your team for ticket updates
- Changes to production systems cause unplanned incidents more than once a quarter
- New starters are still waiting on access or hardware on day two
- Your IT Director has not done strategic work in months
What your score means:
- 0 to 1 checked: Your process is reasonably healthy. Focus on optimisation.
- 2 to 3 checked: Specific gaps worth addressing before they compound.
- 4 to 5 checked: Your process is actively slowing the business. Prioritise a structured review.
- 6 to 7 checked: Your process is in crisis. This is costing more than you realise.
Sign 1: The Backlog Never Shrinks, No Matter How Hard the Team Works
Your team resolves 40 tickets. 42 new ones arrive. The queue barely moves.
This is a triage and automation problem, not a volume problem. Password resets, access requests, and standard software installs consume the same agent time as complex incidents. They land in the same queue and get handled the same way. As a result, low-complexity tickets need to be routed away from agents entirely.
Mid-market IT teams that automate their five most common ticket types typically see backlog volume drop by 20 to 30% within 30 days, with no additional headcount.
What to do:
- Categorise your last three months of tickets by type and resolution time
- Identify the five ticket types that appear most often and require the least skill to resolve
- Build self-service flows or automated responses for those five types first
- Reassess backlog size after 30 days
For example, if your platform does not support self-service automation without significant custom development, that is worth noting. It may be a configuration gap rather than a tool limitation. However, it needs to be resolved either way. Our ITSM platform optimisation service is designed specifically for teams in this position.
Sign 2: The Same Problems Keep Coming Back
You close a network incident ticket. Three weeks later, the same issue returns. You close it again. It comes back again.
Recurring incidents are expensive twice. First, you pay to resolve them. Then you pay again every time they return. More importantly, they erode leadership confidence in IT faster than almost anything else. When the same problem appears on the agenda for the third consecutive quarter, the conversation is no longer about the incident. It becomes a conversation about IT capability.
The root cause is almost always the same: incident management without problem management. Most mid-market teams restore service and close the ticket. However, almost none investigate why the incident happened in the first place.
Incident management restores service. Problem management prevents recurrence. Most mid-market IT teams do the first and skip the second entirely, which is why the same incidents keep appearing.
What to do:
- For any incident that recurs more than twice in a quarter, open a Problem Record, a separate investigation into root cause
- Assign a named individual (not a team) to own the Problem Record
- Set a deadline for root cause analysis, typically five business days
- Track Problem Records separately from incident volumes in your weekly reporting
In practice, this distinction between fixing symptoms and fixing causes is one of the most high-value changes a mid-market IT team can make. It requires no new tooling. Instead, it requires discipline and a named owner.
Sign 3: You Cannot Report on IT Performance Without Manual Assembly
Someone in leadership asks for your MTTR, SLA adherence, or first contact resolution rate. You spend 45 minutes pulling data from spreadsheets, email chains, and your help desk tool.
If your performance data is not visible in real time, you are managing in the dark. Problems escalate further than they should. Trends go undetected. As a result, when something goes wrong, you are reacting rather than anticipating.
This is either a configuration problem or a tooling problem. The distinction matters:
- If your platform has reporting capability that is not configured: a configuration problem, fixable without replacement
- If your platform genuinely cannot surface basic ITSM metrics without custom development: a tooling problem, worth a proper evaluation
Industry context
According to Ivanti’s 2024 research, only 46% of organisations have real-time visibility into their ITSM performance data. The remaining 54% are making decisions based on reports that are days or weeks out of date.
What to do:
- Define your five core ITSM KPIs: MTTR, FCR rate, SLA adherence, ticket volume by category, backlog trend
- Check whether your current tool surfaces these automatically
- If it does not, determine whether the gap is configuration or capability
Sign 4: Your Users Have Stopped Trusting the Process
How many of your agents spent time yesterday responding to “just checking in on my ticket” messages?
If the answer is more than a handful, users have already stopped trusting that IT will follow through. That is not an attitude problem. It is a process signal with a measurable cost.
According to Ivanti’s 2024 research, 62% of employees who bypass IT do so because they believe it is faster than raising a ticket. Therefore, when users route around your process, problems go untracked, shadow IT grows, and your team gets blamed for incidents they never knew about.
Three changes that fix this quickly:
- Automatic status notifications at every stage: submitted, in progress, resolved, closed
- A self-service portal where users can check ticket status without contacting IT
- SLA timeframes stated clearly on the submission confirmation
When users consistently bypass the IT ticketing process, it is not a communication problem. It is a signal that the process has already lost their confidence.
Teams that implement all three typically see chaser messages drop by 40 to 60% within 30 days. No additional headcount required. In most cases, this is a configuration change on your existing platform.
Sign 5: Your Changes Keep Breaking Things
A patch gets pushed. Something breaks. The team scrambles. Two weeks later, the same story.
Unplanned incidents caused by poorly managed changes are the most avoidable form of IT downtime. ITIC’s 2024 research found that 97% of large enterprises report a single hour of downtime costs over $100,000. However, when that downtime is caused by a change your team initiated, the cost is compounded by the loss of business trust that follows.
The most common root cause in mid-market teams: a change management process that is either non-existent or so burdensome that engineers bypass it entirely. As a result, governance breaks down at the point where it matters most.
Implement a three-tier change model:
| Change Type | Description | Approval Required |
|---|---|---|
| Standard | Pre-approved, low-risk, repeatable | None, log it and proceed |
| Normal | Requires review before implementation | Lightweight CAB sign-off |
| Emergency | Fast-track with post-implementation review | Named approver only |
Most mid-market teams apply a full CAB process to everything. In practice, this means engineers route around it to get work done. Instead, tiering changes gives you governance without adding friction to routine work.
Sign 6: New Starters Are Still Waiting for Access on Day Two
A new hire starts Monday. By Wednesday they are still waiting on system access, hardware, or software licences.
Slow onboarding communicates one thing clearly: IT is a blocker, not an enabler. That perception forms in the first 48 hours. It is harder to undo than most IT leaders realise.
The onboarding gap
According to InvGate’s 2025 ITSM research, only 41% of organisations automate their employee onboarding process. That means 59% are manually rebuilding the same provisioning workflow every time someone joins, regardless of how many times they have done it before.
What to do:
- Build role-based onboarding templates in your service catalogue, defining exactly what access, hardware, and software each role type requires at day one
- Automate the provisioning trigger from your HR system to your ITSM tool where possible
- Add onboarding completion time as a tracked KPI. The target is full provisioning before the new starter’s first morning.
For example, if your current platform does not support service catalogue templates or HR system integration without custom development, that is a capability gap worth reviewing. Our ITSM platform selection service helps mid-market teams evaluate whether their current tool can meet these requirements, or what a better-fit alternative looks like.
Sign 7: Your IT Team Has Not Done Strategic Work in Months
This is the most expensive sign on the list. It is also the hardest to quantify, which is why it tends to persist longest.
If your IT Director is spending most of their week on operational firefighting, they are not working on security uplift, cloud strategy, or modernisation. That work does not disappear because it is deferred. Instead, it becomes a significantly larger and more expensive problem 12 to 18 months later.
Deferred strategic work is the hidden cost of broken ITSM process. In other words, every week spent firefighting is a week not spent reducing the risk that creates the fires.
What to do:
- Track how the team’s time is actually being spent across four weeks. Categorise every task as operational, tactical, or strategic.
- If the split is worse than 70/20/10, you have a process problem that needs addressing before any strategic agenda item can make meaningful progress.
- Use that time data to build the business case for ITSM improvement. Finance and leadership respond to hours and cost data, not abstract process arguments.
Broken vs Healthy ITSM: What Each Sign Looks Like in Practice
| Signal | Broken ITSM | Healthy ITSM |
|---|---|---|
| Backlog | Growing week on week | Stable or shrinking via automation |
| Recurring incidents | Common and untracked | Owned through Problem Management |
| Reporting | Manual, slow, assembled from multiple sources | Real-time dashboards, available on demand |
| User trust | Users bypassing the process | Confidence via auto-notifications and self-service |
| Change management | Ad hoc or over-engineered, both get bypassed | Tiered by risk, proportionate to impact |
| Onboarding | Manual, inconsistent, slow | Role-templated, partially automated |
| Strategic work | Deferred indefinitely | Protected time in every sprint or cycle |
The Pattern Underneath All 7 Signs
None of these ITSM process problems require a bigger team to fix.
Instead, they require clearer processes, better use of tools the organisation likely already has, and a plan that addresses the right problems in the right sequence. Not everything at once.
What the research shows
According to Freshworks’ 2024 ITSM Benchmark Report, teams using workflow automation achieve a 27% reduction in average resolution time and a first contact resolution rate of 77%. Teams using AI-assisted self-service see ticket deflection rates of 53%. These outcomes do not require new headcount. They require process design and platform configuration decisions that most mid-market teams have not yet made.
If you recognised four or more of these signs, the most valuable next step is understanding exactly which gaps are costing you the most, and in what order to address them.
Book a 30-minute diagnostic call. We will tell you honestly what is broken, what is not, and what to fix first.
Frequently Asked Questions
The clearest indicator is whether the same problems existed before your current tool was implemented. If they did, the tool is unlikely to be the root cause. Most ITSM process failures come from how work is categorised, owned, and escalated, not from platform limitations. A structured process review typically reveals the answer within one session. If genuine platform limitations emerge from that review, a tool evaluation is the logical next step.
If the team is busy but the backlog is not shrinking and the same incidents keep recurring, the issue is almost always process rather than capacity. Adding headcount to a broken process makes the process faster at producing the wrong outcomes. Therefore, fix the process first, then assess whether additional people are genuinely needed.
Incident management is about restoring service as quickly as possible after something breaks. Problem management, by contrast, is about investigating why it broke so it does not happen again. Most mid-market teams do the first and skip the second entirely, which is why the same incidents keep recurring month after month. Problem management requires no additional tooling in most cases. It requires a named owner and a structured root cause process.
Meaningful improvement is typically visible within 30 to 90 days when the right issues are prioritised. For example, automating common ticket types, adding status notifications, and tiering change management can show results within weeks. Deeper structural changes such as implementing problem management or integrating HR provisioning take 60 to 90 days but deliver more sustained improvement.
Usually not. Most ITSM process problems can be addressed through better configuration and process design on an existing platform. However, if a genuine capability limitation emerges during a structured review, that is when a tool evaluation makes sense. It is rarely the right first step without a process review preceding it.