Running IT Support Tickets in Dynamics 365 Customer Service: Queues, SLA Timers, and Clean Resolutions

I opened my queue in Dynamics 365 Customer Service and it was a wall of red: forty cases marked noncompliant against the SLA, and my manager had already sent the dashboard screenshot. When I actually went through them, more than half were not late at all. They were waiting for a user to reply, a laptop to arrive, or a vendor to call back. The system just did not know that, because nobody had told it.

That morning taught me that the tool is rarely the problem. How the team feeds it is. I use Customer Service every day to run internal IT support tickets, and this is what I have learned about getting tickets in cleanly, keeping the SLA timers honest, and closing cases in a way that actually helps the next person.

HOW A TICKET GETS IN

Most of our tickets start as an email to the support mailbox. An automatic record creation and update rule turns each incoming email into a case, links it to the contact by email address, and puts it in the right queue. When it works, nobody touches it. When it does not, you get the two classic problems.

• Duplicates. A user replies to an old thread with a new subject, or forwards the original to three colleagues who all reply. Each one can become a new case. I check for duplicates before I start work and merge them, so the history ends up in one place instead of three.

• Orphans. An email from an address that matches no contact creates a case with no customer, which then falls out of every view filtered by department. Keep your contact list in sync with the directory and these mostly disappear.

My rule: a case that arrived badly gets fixed in the first two minutes, not when it is already late.

QUEUES: WHO OWNS WHAT

We run one queue per team: service desk, workplace, network, applications. The detail people miss is that being in a queue and being owned are two different things. A case sitting in the service desk queue belongs to the team; the moment I pick it, it is mine and it moves to my active work.

The wrong way is assigning cases to people as a reminder ("this is probably for you"). That hides them from the queue, and if that person is on holiday the case sits untouched while the timer runs. The right way is to leave it in the queue until someone actually picks it up, and to route it to another queue when it belongs to another team rather than assigning it to a person there. If your organisation uses unified routing, let the routing rules and capacity do the assignment and stop overriding them by hand.

THE SLA CLOCK, AND WHEN IT REALLY STOPS

Our SLA has two KPIs: first response and resolve by. Each case gets KPI instances with a status you can see on the form: in progress, nearing noncompliance, succeeded, noncompliant, or paused. The only thing that moves the clock forward is time inside the business hours calendar. The only thing that stops it, apart from resolving, is a status reason you have explicitly configured as a pause status.

That last point is what turned my Monday red. We had the On hold status set to pause the SLA, but the team had started using Waiting for details and a custom Waiting for vendor reason, which were never added to the pause list in the service configuration settings. To the SLA those cases were still being worked, every minute of every business day.

The fix took ten minutes: add the waiting reasons to the pause settings, then agree as a team which reason means what. A paused case is a promise that the ball is not in our court. If it is, it should not be paused.

WHY THE TIMER SAYS WHAT IT SAYS

Whenever someone tells me the SLA is broken, I check three things before anything else.

• Pause statuses. Is the status reason on the case actually in the pause list? Different teams invent their own waiting reasons, and each one has to be added.

• The calendar. Is the SLA item using the right customer service schedule? A schedule without the public holidays makes every case opened before a long weekend look late on Tuesday.

• Applicable when. Which SLA item did the case match? If priority is set after the case is created, or a user changes the case type, check in a test environment how your SLA behaves; I would rather know than guess when a manager asks why a P1 had a P3 timer.

Nine times out of ten, the answer is in one of those three places, and none of them is the agent's fault.

RESOLVING SO THE NEXT TICKET IS FASTER

Closing the case is where most of the long term value is created or lost. When I resolve, I write the resolution as if the next reader is a colleague with the same problem in six months: what the cause was, what fixed it, and anything that did not work. "Fixed" is not a resolution.

Before I write it, I search the knowledge base from the case form. If an article exists, I link it. If I had to work something out from scratch, I draft a short knowledge article from the case. After a few months the service desk resolves the common tickets in minutes because the answer is one search away.

For outages I use parent and child cases. When email goes down, the first case becomes the parent, every new report is created as a child of it, and we communicate once. Check the parent and child settings in the service configuration: we chose to close all child cases when the parent is resolved, so one resolution closes forty tickets and every user gets the update.

WHAT GOES WRONG

• Waiting statuses that do not pause. The SLA counts time the team could never use, and the dashboard punishes the wrong people.

• Pausing to look good. The opposite abuse: a case set to on hold while it is really stuck with us. Review paused cases weekly and ask who is actually waiting for whom.

• Assigning instead of routing. Cases owned by someone who is away, invisible in every queue.

• Duplicates left open. Two agents work the same problem, the user gets two different answers, and the SLA counts both.

• Empty resolutions. The knowledge stays in someone's head, and the same ticket costs the same time again next month.

• Calendars without holidays. A wave of false breaches after every long weekend, and a team that stops trusting the numbers.

MY ROUTINE AT THE START OF EVERY SHIFT

1. Open the queue view sorted by resolve by, not by created on.

2. Merge duplicates and fix orphans before picking anything.

3. Check every case nearing noncompliance: is it really ours, or should it be on hold?

4. Pick, do not assign. Route to another team's queue, not to a person.

5. Resolve with a real resolution and a knowledge link.

None of this needs customisation or a developer. It needs a team that agrees what each status means and a service configuration that matches that agreement. Once ours did, the Monday dashboard went from forty red cases to three, and those three were genuinely late. That is the point: an SLA you can trust tells you where to look.