When the Agent Leaves: Orphaned Tickets & the Reassignment Queue
Somebody resigns on Friday. On Monday, forty open tickets still have their name on them, their login is disabled, and every notification about those tickets is being written to an account nobody will ever open. Here is what the system does about that, what it does not, and the twenty minutes of handover that prevent the whole problem.
Support and field roles turn over faster than almost anything else in a Kenyan organization. The technician who knew which building had the old switchgear, the agent who handled the difficult distributor, the intern who had quietly become the person everybody called — they leave, and the institutional memory leaves with them. That much is normal and unavoidable. What is avoidable is the second loss: the open work that was assigned to them and stays assigned to them, silently, for weeks.
This is a boring operational problem with an unusually high cost, because an orphaned ticket has all the appearance of being handled. It has an owner. It is in progress. It is off the unassigned list. The queue looks healthy. The only thing missing is a person.
Why a ticket can be assigned to nobody
The root of it is a design choice we made deliberately and would make again: an assignee is an employee, not a login. Most of the people who resolve requests in a Kenyan organization — technicians, drivers, storekeepers, site supervisors, security — have no reason to hold a system login, and a helpdesk that can only assign work to licensed users has quietly excluded most of its own workforce.
So a ticket carries two references to its owner: the employee record, which is who is responsible, and the login, which is where notifications go. The second is filled from the first at the moment of assignment, and may legitimately be empty.
The two halves of an assignee, and what each one governs
The employee reference
Who is accountable for the work.
- Drives the reassignment queue: a ticket is flagged as orphaned when this employee is terminated or suspended.
- Drives escalation on an SLA breach, by resolving this employee's manager.
- Appears as the owner everywhere in the queue, on the dashboard and in the support report.
- Can point to somebody with no login at all — which is the whole point.
The login reference
Where the notification is delivered.
- Receives the assignment notice, replies from the requester, and the breach warning.
- Copied from the employee record when the assignment is made, and not re-synced afterwards.
- Empty when the employee has no login, in which case nothing about the ticket is ever pushed to anyone.
- Used by the assigned to me filter, so a ticket owned by a login-less employee appears on nobody's personal list.
What this means in a departure
- Disabling the login does not clear the employee reference, so the ticket keeps its owner.
- Marking the employee as terminated is what surfaces the ticket in the reassignment queue.
- Do the HR step and the ticket becomes visible. Do only the IT step and it does not.
That last line is the sentence to take away. In most organizations, IT disables the account on the last day and HR updates the employment status whenever the paperwork completes — sometimes weeks later. During that window the tickets are unreachable and invisible at the same time.
What the system does for you
There is a purpose-built queue for exactly this. It lists every open ticket whose assignee is terminated or suspended, sorted by resolution due date so the most urgent orphan is first, with the assignee picker on each row so reassignment is one action rather than a hunt through the main queue.
Three details make it more useful than it first looks.
- It reads employment status, not login status — so it works even if the account was never disabled, and it does not fire for someone merely on leave.
- It includes suspended as well as terminated, which is the case people forget. A suspension is exactly when you least want tickets sitting with that person.
- The assignee picker anywhere in the module offers only employees who are on probation or active, so you cannot reassign an orphan to another leaver by accident.
And the bulk action on the main queue accepts an assignee, so forty tickets can be moved to a named successor in one submission — each one notifying the new owner individually, which is the correct behaviour even though it means forty notices land at once.
A gap we found while writing this, and fixed
A ticket category can name a default assignee, and new tickets in that category are routed to them automatically. Until now that routing did not check whether the person was still employed — so a category whose default had left kept auto-assigning fresh tickets to them, and because the ticket arrived already assigned, the department queue was never notified either. New work arrived owned by someone who would never see it, and nobody else was told. Routing now skips a default assignee who is terminated or suspended, which leaves the ticket unassigned so the whole department queue hears about it. When somebody leaves, still update the category defaults — but a missed one now degrades to a visible queue item instead of a silent one.
The twenty minutes that prevent all of it
Software can surface an orphaned ticket. It cannot tell you who should own it, and it should not guess. Here is the sequence that works, in the order that matters.
-
Before the last day: filter the queue to their open tickets
The main queue filters by assignee. Do this while the person is still in the building and can tell you what each ticket actually is, which is information no system holds.
-
Have them write one internal note per ticket
Not a status — a state of play. What was tried, who was called, what is next, what the customer was last told. Comments are permanent and cannot be edited, so this note is the handover document and it lives exactly where the next person will look.
-
Reassign in bulk, then adjust the exceptions
Move the whole set to the supervisor first. It is easier to redistribute from one owner than to make forty individual decisions on a Friday afternoon, and it guarantees nothing is left behind.
-
Update the ticket categories they were the default for
Open the category settings and check every default assignee. A missed one no longer assigns to a leaver, but it does now drop that work into the department queue, which is only useful if someone is watching that queue.
-
Then let HR mark them terminated, and IT disable the login
In that order if you can. Marking them terminated is what makes any tickets you missed appear in the reassignment queue — so do it deliberately, on a day someone is going to look, rather than a month later when the file closes.
-
Check the reassignment queue the following Monday
It is the backstop for everything the handover missed. If it is empty, the handover was complete. If it is not, you have found the exceptions in ten seconds.
What an orphaned ticket actually costs
One agent leaves; the handover is skipped; HR closes the file three weeks later
Illustrative, and every line is a real consequence of the same omission. Note which control actually worked: because a breach escalates to the assignee's manager as well as the assignee, the manager received thirty-three warnings about a person who no longer worked there. That is the signal a desk usually notices first — a manager asking why they keep getting alerts about someone who left. The reassignment queue would have caught it in one look, but only after HR did the step that nobody had scheduled.
Who should inherit the work
There is no automatic answer to this and we have deliberately not invented one, because every plausible rule is wrong somewhere. Choose by the shape of your desk.
If you have a supervisor over the desk
Move everything to the supervisor, then redistribute
The safest default. One person now owns all of it, nothing is orphaned for a second time, and the redistribution decisions get made with the tickets open in front of you rather than from a spreadsheet.
If the work is genuinely specialised
Reassign by category, one category at a time
Filter the queue by category and assignee together, and move each block to whoever now holds that skill. Slower, but it puts the electrical tickets with the electrician rather than with whoever had capacity.
If nobody has yet been hired to replace them
Unassign deliberately and rely on the department queue
Clearing the assignee puts the work back on the unassigned list where the daily sweep will see it. Better an honest unassigned ticket that somebody picks up than a fictional owner. Confirm the department is set, or the ticket becomes invisible instead.
If the ticket has stopped being a ticket
Escalate it into a project task and close the loop
Some of what sits in a departing agent's queue was never support work — it was a small project nobody scheduled. Escalating creates a linked task, writes an internal note naming it, and gets the item out of a queue measured in hours and into one measured in weeks.
What we do and do not do
What AWRA OpsHub does today
- A dedicated reassignment queue listing every open ticket whose assignee is terminated or suspended, ordered by resolution due date, with an assignee picker on each row.
- An orphan test that reads employment status rather than login status, so it works whether or not the account was ever disabled — and covers suspension, not only termination.
- Assignee pickers throughout the module that offer only employees on probation or active, so an orphan cannot be reassigned to another leaver.
- Bulk reassignment of any selection from the main queue, notifying each new owner.
- Category default routing that now skips a terminated or suspended default assignee, dropping the ticket to the department queue instead of assigning it to somebody who left.
- SLA breach escalation to the assignee's manager, which in practice is the alarm that most often reveals an orphaned queue.
- A complete surviving record: the thread, the internal notes and the author of each comment are untouched by a departure.
What it does not do
- No automatic reassignment. Marking an employee terminated surfaces their tickets; it does not move them. That is deliberate — the system does not know who should inherit a ticket — but it does mean the queue is worthless if nobody opens it.
- No notification when tickets become orphaned. The reassignment queue is a screen you visit, not an alert that finds you. There is no notice to a supervisor saying "eleven open tickets just lost their owner".
- No re-sync between the employee and the login on a ticket. The login is copied at assignment. If a person's account is later removed or replaced, the ticket keeps the old reference and notifications go nowhere.
- Watcher rows survive a departure. A departed colleague stays a watcher on whatever they were watching, and notices continue to be written to their account. Harmless, untidy, and not cleaned up.
- No workload view or round-robin. There is no screen ranking agents by open ticket count, and no automatic balancing when you redistribute a leaver's queue — you are choosing by judgement, not by capacity.
- No handover template or checklist inside the product. The sequence above is a working practice, not a feature.
The gap we would close first is the missing alert. Everything else on that list is a judgement call we think belongs to a human, but "eleven tickets just lost their owner" is a fact, and a fact that arrives on its own is worth more than a screen somebody has to remember. If turnover is a live problem on your desk, that is the request to make.
The habit, not the feature
Everything in this article reduces to one practice: tie the ticket handover to the exit process, not to the helpdesk. Support software cannot know that someone is leaving until an HR record says so, and HR records are updated on a legal timetable rather than an operational one. The gap between the last working day and the closed file is where orphaned work lives, and no amount of product will close it for you.
So put one line on your exit checklist, next to the laptop and the ID card: open tickets reassigned, with a handover note on each. It takes twenty minutes, it happens while the person who understands the work is still available to explain it, and it makes every mechanism described above a backstop rather than a rescue.
Our take
Orphaned tickets are not a software failure, they are a sequencing failure — the operational handover happens on the last working day and the record that would reveal a missed one is updated weeks later. Use the reassignment queue as your Monday backstop, keep your category defaults current, and put ticket handover on the exit checklist so it happens while the departing person can still tell you what each ticket really is. The product will find the ones you missed. It cannot find the ones nobody has yet been told to look for.
Read alongside this: who gets told explains why a login-less assignee is never notified, the internal note covers the handover note that lives in the thread, routing and escalation covers the category defaults you need to update, and MFA and leavers covers the access half of the same departure.
Find the tickets that lost their owner
A reassignment queue that reads employment status rather than login status, bulk reassignment to a named successor, and pickers that will not hand work to another leaver.
See the agent dashboardFrequently asked questions
Does disabling someone's login move their tickets?
No, and this catches almost everybody. A ticket records its owner as an employee, and separately records the login where notifications are delivered. Disabling the account leaves the employee reference untouched, so the ticket keeps its owner and does not appear anywhere as a problem. What surfaces it is marking the **employee** as terminated or suspended, which is an HR action rather than an IT one. If your two processes run on different timetables — and in most organizations they do — that gap is exactly where orphaned tickets live.
Are tickets reassigned automatically when an employee is terminated?
No. Termination makes their open tickets appear in the reassignment queue, sorted with the most urgent first, and gives you an assignee picker on each row — but a human decides who inherits each one. We have deliberately not automated it, because every rule we could write is wrong somewhere: "give it to the manager" buries a supervisor, "give it to whoever has fewest tickets" ignores skill, and "unassign everything" only works if somebody sweeps the unassigned list daily. The queue plus a Monday habit is the honest answer.
What happens to new tickets in a category whose default assignee has left?
They are no longer assigned to that person. Routing checks the default assignee is still on probation or active, and skips them otherwise, so the ticket stays unassigned and the whole department queue is notified. This changed while we were writing this article — previously a departed default kept collecting new tickets, and because they arrived pre-assigned the department queue was never told, so the work was owned by someone who would never see it and invisible to everyone else. You should still update your category defaults when someone leaves; the difference is that a missed one is now noisy rather than silent.
Can I see how many open tickets each agent has?
Not as a workload screen. You can filter the queue by assignee and read the count off the result, which answers the question one agent at a time, and the support report groups activity by department. There is no ranked view of agents by open ticket count and no automatic balancing when you redistribute somebody's queue. If capacity balancing matters to your desk, that is a reasonable and small thing to ask for — the data is all there, it is a view that is missing.
Why do managers keep getting SLA alerts about someone who left?
Because breach escalation resolves the assignee's manager from the employee record, and the assignee is still the departed person. The assignee half of the alert is going to a disabled account and the escalation half is reaching the manager — which is untidy but is also, in practice, the signal that most often reveals an orphaned queue. Treat a manager asking "why am I getting these?" as a prompt to open the reassignment queue rather than as a bug.
Does the ticket history survive when an agent leaves?
Completely. Comments cannot be edited or deleted by anyone, the author on each comment is retained, and internal notes stay readable to the rest of the desk. Nothing about a departure rewrites the thread. This is why the handover note matters so much: a note written on the last day by the person who did the work sits permanently in exactly the place the next person will look, and it is the only part of the handover that no system can reconstruct afterwards.
