Assigning tickets without losing requests
Who assigns, at what moment, and what happens to the requests nobody picks up: three rules that hold even in a busy week.
Published by Oglut Srl, publisher of OglutTicket.
Requests are rarely lost because nobody read them. They are lost because everybody read them and each person assumed someone else had it. That is an assignment problem, not an attention problem, and you can hear it in a sentence every small team says about once a week: “I thought you had picked that one up.”
This guide is about three decisions: who assigns, at what moment, and what happens to requests nobody has taken yet. You make them once, and they matter precisely in the weeks when everything else is going badly.
Who assigns, and at what moment
There are three ways a request reaches a person, and none of them is wrong in itself. What is wrong is not having picked one.
- One person distributes. Somebody reads what came in and hands it out. This works well up to a few dozen requests a day, and it has one real virtue: every request is read by someone whose job is to read it.
- People pick up their own. Requests sit in a shared list and each agent takes what they can solve. It is the fastest arrangement while the team is small and close; it becomes dangerous the moment somebody is on holiday, because the hard requests stay in the list looking like nobody’s.
- The type of request decides. By department, by product, by customer: the request lands in a group of people and is assigned inside that group. It is the only arrangement that survives past five or six agents, because it stops requiring anyone to know everything.
The moment, by contrast, is always the same: on reading, not on solving. Assigning says who answers for a request, not who has time to work on it right now. Waiting until you know who will solve it is how a request spends three days with no owner and then becomes a complaint.
One request, one person
This is the rule that meets the most resistance, and the one worth defending: the owner is one person. Not a group, not a department, not two colleagues following it together.
It is not about hierarchy. A collective owner is exactly the shared inbox with a label on top: if two people answer, usually nobody does — and when they really do both answer, the customer gets two messages that say slightly different things. Three people working on a request is fine; one of them replies to the customer, and the others write in the internal notes.
None of this means the owner must solve it alone. It means that when someone asks “where is this?” tomorrow morning, there is a person to ask, and that person cannot answer “I don’t know, it wasn’t mine.”
Three rules that hold over time
Distribution rules that work are few and unsophisticated. The elaborate ones — workload scores, rotas, automatic round-robins — last a month and are then worked around.
- Whoever already spoke to that customer goes first. Not out of account loyalty: re-reading a conversation is cheaper than reconstructing one. It matters most on requests that come back.
- A cap on open requests per person. One number, guessed at first and corrected after a month. Its job is to make visible that giving a fourteenth request to someone holding thirteen is not a decision, it is a postponement.
- Whoever distributes does not serve themselves last. The classic failure of the person who hands out work: they keep what they know how to do and pass on the rest. Two months later they are the bottleneck and they are the last to notice.
A fourth rule is often assumed and should not be: urgent requests are reassigned out loud. Changing the owner of something due today deserves a sentence spoken or a direct message, not only a notification among the others.
Where requests are lost: nobody picked them up
Assigned requests are rarely lost. They have a name on them, and sooner or later that name comes back to them. The ones that vanish are the others: arrived, read by three people, attributed to none.
So the measurement you want is not “how many requests does each person have”, which is the one everybody reaches for first, but how many open requests have no owner at all. It is a single number, it takes two seconds to read, and it should return to zero every day. If it stays above zero for a week, the distribution rule you chose is not working — the people are.
The second useful measurement is the age of the oldest request without a reply. Not the average: an average hides exactly the cases that lose you a customer, because it mixes them with the twenty requests closed in ten minutes.
Reassigning without starting over
Reassignment is normal and should be cheap: holidays exist, people change jobs, and a request that looked simple turns out to belong to somebody else. What must not happen is that changing the name on top forces the new owner to ask the old one what had been going on.
Three things make a handover free, in any tool: the conversation with the customer lives in one place; what the team said internally lives in the same place, marked as internal; and the change of owner stays on the record, with a date. The first two remove the verbal handover, the third removes the argument about who had it.
One thing not to do: reassign silently. If the new owner gets no notice, you have moved the responsibility without moving the attention, which is the most elegant way to lose a request.
When assigning is not the answer
If there are two of you and you sit in the same room all day, formal assignment adds a step without removing confusion: you remove it by talking. The same is true when every request goes to the one specialist who can handle it — there is a single owner, and writing it down each time changes nothing.
And it actively hurts when it is used to hide a staffing problem. Distributing requests that are too many to begin with produces a tidier list of things nobody has time to do. That is useful information for a hiring decision, but nothing has been solved.
How assignment works in OglutTicket
Every request has exactly one owner, chosen among the people enabled on the project the request belongs to: the picker offers those people and nobody else, so a request cannot be assigned to someone who could not even open it. There are no collaborators to add and no labels: what the team says to itself stays in internal notes, which the customer never sees.
When a request arrives, everyone enabled on that project is notified; when it is assigned, only the owner is. That is the difference between “someone deal with this” and “you deal with this”, and it stays in the request’s history along with the date and the person who assigned it.
The “To assign” counter on the dashboard is the measurement described above: open requests with no owner, as a single number, next to “New”, “Mine” and the ones stuck for more than three days. Reassignment is always available, and removing a person’s access to a project clears their open assignments there instead of leaving requests in the name of someone who can no longer open them.
What the product does not do: it does not distribute by itself. There are no routing rules, rotas or round-robins, and no alert reassigns a request on your behalf. The complete journey of a request, assignment included, is on how it works; if priorities are still unagreed, start from organising customer support in a small business, and response times have a guide of their own.