This article looks at the value of IT service desk boards in the context of closure. Most IT service desks can tell you, almost to the minute, how long it took to resolve each service request last month. Ask how long it took to really close one, and the room goes quiet, because this metric typically gets little attention. That gap between resolved and closed is where I keep finding the waste nobody reports on.
In my previous article for ITSM.tools, on why SLA compliance doesn’t tell you how healthy your service is, I admitted that I didn’t have a clean framework for measuring hidden wait states. The best proxy I had was comparing time-in-status distributions. The closure stage is where that proxy becomes practical, and a well-designed board is how you use it.
Resolved vs. Closed: Two Events, Only One of Them Takes the Majority of Attention (It’s Not Closure)
Resolution means the service team has done the work. Closure means the client confirms the outcome, the request is categorized, whatever is needed is recorded, and the record is shut. In a healthy process, the two sit hours apart. In most IT service desks I’ve worked with, they drift days or weeks apart, and nobody notices because the standard reports stop looking at resolution.
Some tools close a service request automatically when its last fulfillment task is done, with no separate “resolved” state. The gap doesn’t disappear there. It moves to the space between “the last task was ticked off” and “the requester actually has what they asked for.”
Why the Closure Stage Is Underestimated in Service Request Management
There are three structural reasons, and none of them requires anyone to behave badly.
The SLA clock stops at resolution
After that, the request drops out of the report management actually reads. Last time, I called service level agreement (SLA) dashboards autopsy reports. The closure stage happens after the autopsy has been signed off.
Waiting states pause the clock
Waiting for customer, Pending vendor, and On hold are legitimate states. They’re also the easiest place to park a request, because parking protects the metric instead of hurting it.
Closure work is real work that nobody plans
Confirming the outcome, choosing a closure category, writing a resolution note, and updating the knowledge base all happen at the exit. None of it is estimated, and it always gets done last, if it gets done at all.
Show Inefficiency on your Service Management Board
An inefficiency board is an ordinary Kanban board built around a different question. A typical IT service desk board asks, “What are we working on?” but often it doesn’t answer, “Where is work sitting still, and for how long?”
Work in progress becomes a set of aging items, and columns become states with exit criteria. A queue tells you what exists. A board shows you movement, and a stalled closure is a movement problem.
It isn’t a league table of slow service desk agents. The board shows where work is stuck, not who is to blame. Once it starts ranking people, statuses get gamed, and the board stops telling you the truth.
Six Closure-Stage Patterns Your Board Should Surface
If your board can’t show each of these at a glance, it isn’t doing its job yet.
1. Closure-Stage Pattern: Zombie Backlog
These are requests resolved weeks or months ago that were never closed. They’re invisible in SLA reporting, and they are building a typically invisible backlog of tasks “Waiting to be closed.”
2. Closure-Stage Pattern: Verification Bottlenecks
When a single approver or team holds the permission to close, a board shows the pile in one column, while a queue hides it completely. Rising closure lag usually means the verification step has no clear owner.
3. Closure-Stage Pattern: Parked Requests
These requests spend most of their lifetime waiting on a customer or a supplier. With customers, the cause is often a clarifying question that nobody asked at intake. With suppliers, vendor time gets mixed in with internal work time, because the workflow doesn’t separate the two.
4. Closure-Stage Pattern: Ping-Pong at the Exit
Last time, I wrote about reassignment counts as a signal of ownership gaps. At the closure stage, the cause is specific: nobody has written down what “done” means, so the request bounces between the resolver group and whoever is supposed to confirm the outcome.
5. Closure-Stage Pattern: Missing Closure Data
Requests closed without a category or a resolution note look harmless one by one. Together, they starve problem management and knowledge management of the inputs they depend on. Proper analysis of similar requests or frequently asked questions helps identify gaps in product and documentation, and build a solid continuous improvement process.
6. Closure-Stage Pattern: Calendar-Driven Closing
If closures spike in the last two days of every month, the reporting calendar is managing the process, not flow. The work didn’t finish on the 30th; the tidying did.
IT Service Desk Metrics That Help to Spot Inefficiencies
Keep the list short. A board that shows everything shows nothing.
Work in progress (WIP) age is the most useful measure here, because it describes the present: how long the items in front of you have already been alive. Reports on closed requests only know about work that has already left.
Time in status, broken out per waiting state, turns “things feel slow” into a specific claim about where they’re slow.
Closure lag, the time from resolution to closure, deserves its own line. Track it as a distribution, not a single figure.
Blocker categorization: Every blocked item requires a documented root cause. Monthly blocker reviews and targeted action plans help us systematically eliminate process bottlenecks and improve delivery throughput.
Reopen rate measures the quality of the closure step itself. Calculate it by cohort: of the requests closed in a given period, what share were reopened within, say, 14 days?
Flow Efficiency: Calculated as active working time divided by the total time taken to complete a request, expressed as a percentage. Flow efficiency often drops during final delivery phases, where items accumulate in waiting states like QA, code review, or deployment, compared to earlier stages of the workflow.
I made the case against averages last time, so here’s the next step: pick a percentile and use it as a promise. If 85% of your requests close within six days, that’s a commitment you can actually make to requesters. Kanban calls this a service level expectation, and it starts a far more honest conversation with the business than an average ever did.
How to Design a Right Board for Service Requests
Split the Done column
Break a single Done or Resolved column (if you have such) into the states that actually exist in your process, such as resolved, awaiting verification, awaiting closure information, root cause documenting, and closed. Map states, not teams. If you can’t name those states, you’ve found your first problem.
Write explicit exit criteria
Every column needs a short, visible policy stating what must be true before a card leaves it. If these policies are buried in your company documentation, nobody will read them. Use information radiators concepts. Most of the ping-pong at the exit disappears once you write this down.
Limit work in progress at the exit
Teams routinely cap In progress and leave the closing columns unbounded. The point isn’t to slow down resolution; it’s to finish closing what’s already resolved before pulling in more. Little’s Law is strictly about averages in a stable system, but the lesson holds: Unbounded WIP at the exit means unpredictable time to close.
Separate the state from the reason
Waiting is a state; customers, vendors, and approvals are reasons. Where you can, model the reason as a field or a swimlane rather than as extra statuses. Many tools pause SLA clocks and report time in status only, though, and if yours does, two or three well-defined waiting statuses are a fair compromise. This will also give you extra information on how much time the team has wasted waiting for a specific reason. Invaluable data for retrospectives.
Show aging on the card
A color change or a simple day counter is the cheapest change on this list and, in my experience, the one that changes behavior fastest. To make it more advanced, in addition to aging, show the total time in the status, the time since the last entry to this status (in case of reopening or rework), and the total time the request was blocked.
Show reopening counter
Seeing the reopening counter on the card can help you take immediate corrective action without waiting for a weekly or monthly report. To make it more advanced, add a reopening reason field so you can apply corrective action during the retrospective.
Auto-Closure Isn’t the Problem. Blind Auto-Closure Is.
Auto-closing requests after a few silent days is reasonable. Nobody wants thousands of resolved requests sitting open because a requester ignored a confirmation link. The trouble starts when auto-closure counts the same as a confirmed closure. It then closes requests that were never fulfilled and turns a requester’s silence into a success. SLA attainment will never show you these silent failures.
To keep auto-closure honest, report auto-closed requests as their own class, review a small sample every month, and treat a new request from the same person on the same topic within two weeks as a likely reopen. And resist tuning the timer until closure lag looks acceptable. That fixes the metric, not the flow.
It is also wise to apply the auto-closing rule when the customer ignores clarification questions. In this case, reopen the item if the customer returns to the same topic in the future.
How to Run the Board: Read It Right to Left
You don’t need a new meeting for this. Take 15 minutes of an operations review or standup you already hold, walk the board strictly from right to left, and ask three questions:
- What’s the oldest item on the board, and what is it waiting for?
- Which closing column is over its limit, and why?
- What did we reopen this week, and what would have prevented it?
Reading a board from the left always drifts back into status reporting. Reading it from the right keeps the conversation on finishing work.
Before redesigning anything, query every request that has been resolved but not closed for more than a few days, and look at the oldest ten. If you traced ten tickets end to end after my last article, this is the same habit aimed at a different stage.
Your SLA dashboard tells you the clock stopped on time. The board tells you whether anyone actually finished the job.
Key Takeaways for Service Desk Leaders
- Resolved and closed are two different events, and many teams don’t pay enough attention to the second.
- Waste concentrates at the closure stage because the SLA clock has already stopped there.
- Aging WIP and time in status describe the present; resolution reports describe the past.
- Split the Done column, write exit criteria, and limit work in progress at the exit.
- Build immediate awareness of the stuck requests and reopened ones
- Always specify a reason for “Waiting for…” as well as the return reason
- Report auto-closures separately, and use a percentile as a service level expectation instead of an average.
Release Management Apps is an Atlassian Gold Marketplace Partner building Jira-native tools for release orchestration and service delivery.
IT Service Desk Board FAQs
Resolution means the service team has finished the work. Closure means the requester has confirmed the outcome, the request is categorized, and the record is properly documented before it’s shut. In a healthy process, the two happen hours apart; in most IT service desks, they drift days or weeks apart, largely unnoticed.
Three structural reasons. The SLA clock stops at resolution, so the request drops out of the reports management reads. Legitimate waiting states like “waiting for customer” or “pending vendor” are also the easiest place to park a request, since parking protects the metric rather than hurting it. And closure work – confirming outcomes, writing resolution notes, updating the knowledge base – is real work that nobody plans for, so it gets done last if at all.
Zombie backlog (requests resolved but never closed), verification bottlenecks (a single approver holding up closure), parked requests (stuck waiting on a customer or vendor), ping-pong at the exit (no agreed definition of “done”), missing closure data (closures with no category or resolution note), and calendar-driven closing (a spike in closures at month-end that reflects reporting pressure, not real completion).
Work in progress age, time in status broken out by waiting state, closure lag tracked as a distribution rather than an average, documented blocker categorization, cohort-based reopen rate, and flow efficiency (active working time divided by total time to complete a request).
Split a single Done or Resolved column into the states that actually exist, such as resolved, awaiting verification, awaiting closure information, and closed. Write explicit exit criteria for every column, cap work in progress at the exit rather than only at intake, separate the waiting state from its reason, and show aging and a reopening counter directly on the card.
Not inherently. The problem is treating auto-closure as equivalent to a confirmed closure, since that turns a requester’s silence into an apparent success that SLA attainment won’t reveal. The fix is to report auto-closed requests as their own category, sample a portion each month, and treat a repeat request on the same topic within two weeks as a likely reopen.
Yuri Kudyn
Yuri Kudyn co-founded Release Management Apps in 2018 – an Atlassian Gold Marketplace Partner building Jira-native tools for release orchestration and service delivery. He’s spoken at Kanban University events and consults on flow management in Atlassian ITSM environments. He believes in information radiators, not information refrigerators.
LinkedIn - https://linkedin.com/in/yuri-kudyn-5408223
Atlassian Marketplace - https://marketplace.atlassian.com/vendors/1216961/release-management
