First, second and third line: who does what so a ticket does not drift

Many service desks have first, second and third line written down on paper, but in practice nobody notices the difference. A ticket gets escalated, disappears into a queue, and nobody feels responsible for following it up anymore. The user calls back after a few days and nobody can say exactly where the ticket stands. This article shows how to set up the lines so a ticket always has an owner, even after it has been handed off.

Why tickets keep drifting

The problem rarely sits in the structure itself. Almost every organization knows that the first line handles the simple tickets, the second line the more complex ones and the third line the specialist work. It goes wrong at the moment of handoff. If "escalating" means a ticket disappears into another queue without anyone explicitly becoming its owner, the ticket belongs to nobody from that point on.

That happens more often than you would think, precisely because the handoff looks so simple: a few clicks and the ticket is "somewhere else". The question of who is watching it now goes unanswered.

Making each line's role clear

First line: owner until proven otherwise

The first line resolves what it can, and escalates what it cannot. The key point is that the first line stays the owner of contact with the user, even after escalating. That means the user hears about the status from the first line, not from the second line, which rarely has time for that.

Second and third line: resolve and report back

The second and third line resolve the technical problem, but their task does not stop at the fix. They report back to whoever escalated the ticket, with enough information to inform the user. Without that feedback loop, exactly the problem this article is about appears: a ticket that is technically resolved, but the user hears nothing. Clear impact and urgency criteria also help here: when the receiving line immediately knows the business priority, they can set the right pace instead of treating everything the same.

Escalating is not saying goodbye

Escalating a ticket feels, for many people, like being done with it. That is the mistake. Escalating a ticket means handing over the resolution, not the responsibility for progress. As long as the ticket is open, someone should be actively tracking whether it is moving forward.

Agreements that stop a ticket getting lost

A few clear agreements prevent most of the drifting tickets:

• Every ticket has one visible owner. Even after escalation, it is clear who is responsible for progress toward the user.
• Escalation happens with context. A ticket without a clear description of what has already been tried costs the receiving line extra time and slows down the fix. Shift-left and self-service can reduce the volume that needs escalating in the first place, by resolving more at the point of contact.
• Feedback is mandatory, not optional. The line that resolves the ticket actively reports back to whoever escalated it, so the user stays informed.
• There is a moment when a stalled ticket gets flagged. A ticket sitting without action for too long should surface automatically, not only when the user calls about it.

What it delivers

When the lines connect properly, nobody has to search for who is actually responsible for a ticket. The user gets an honest answer about the status faster, and teams lose less time to tickets that fall between the cracks. That is exactly the point: achieving more with the same people, by taking the handoff between lines as seriously as the fix itself. When multiple lines need to coordinate on a major outage, a major incident playbook keeps communication from getting tangled. For practical support: see our service management services.

Frequently asked questions

Does every organization need three lines? No. Smaller organizations often work with two lines, or even one with clear specialisms inside it. The number of lines matters less than clarity about ownership at every handoff.

Who is responsible when a ticket gets stuck between two lines? The line that received the ticket last, until it explicitly confirms the next line has taken it over. Without that confirmation, the previous line remains the owner.

How do you stop feedback from being skipped? Build it into the process itself, for example by only marking a ticket resolved once feedback to the user has actually happened.

Want tickets at your service desk to stop getting lost between the lines? book a call and we will map out together where the handoff currently breaks down.

Further reading

• Incident management (Wikipedia)
• IT service management (Wikipedia)