Ownership: The Ticket Is Yours Until It Is Someone Else's

Wednesday, 10:15, at Redbrook Engineering. Priya, a design engineer, rings the desk and asks a question that no desk ever wants to hear: "Who has my ticket?" It is ticket 2231, about the drawing tool's licence dropping out twice a day. It was raised nine days ago. Ben, who picks up the phone, looks it up. The ticket is assigned to "Networks", which is a group of three people. The last entry is from day two. Somebody wrote "passing to networks to check the licence server" and moved on. Ben asks the three. Dana says she thought Marcus had it. Marcus says he thought it was Dana's. Omar was on leave. Nine days, four people, and nobody has owned ticket 2231 for a single one of them. Ben says to Priya, "I have it now, and I will ring you back before twelve with what I have found." In that sentence the ticket acquires its first owner.

Ownership, on a help desk, means that one named person is responsible for a ticket's progress. That responsibility lasts from the moment they take it until it is resolved or until another named person has accepted it. Ownership also means that the user always knows who that person is. It is not the same as doing the work. The owner may do none of the technical fixing. They are the person who makes sure the fixing happens, who tells the user what is going on, and who the user can ask. A ticket assigned to a group is owned by nobody, however many people are in the group. This is the single most common way a small desk loses a ticket. This article is part of our Soft Skills for Technicians series. Ownership is the third skill, the one that turns the other three into something the user can rely on.

It starts with what ownership means, claiming the ticket, updating it, and handing it over properly. Next come never saying "not my job", the follow-through after the fix, and the ticket you forgot. Then it covers ownership as a mechanism in the tool and as a habit in the person. A short war story and the ownership standard to copy finish the article.

What Ownership Means on a Help Desk

Ownership answers one question for the user: who do I ask? If the answer is a name, the ticket is owned. If the answer is a group, a queue, a department or "the desk", it is not, whatever the ticket's status field says. The user does not experience statuses. They experience the presence or absence of a person who knows about their problem and will tell them things without being chased. The desk that supplies that person for every ticket is trusted even when it is slow. The desk that does not is distrusted even when it is fast.

Ownership is separate from doing the work, and keeping the two apart is what makes it possible on a small desk. Ben may never touch the licence server. The person who does is on the second line, and Ben may never understand what they did. Ben's job as owner is to know that it is being done, and to know roughly when. He must tell Priya both of those things before she has to ask, and be the name she rings. Ownership is a communication role with a technical ticket attached. That is why it belongs in a series about soft skills rather than about licensing.

The group queue is where ownership goes to die, and it dies of good intentions. "Passing to networks" felt like progress. The ticket moved, the status changed, and the technician's own list got shorter. But a group is a place, not a person, and a ticket in a place waits for someone to walk past. Each of the three people in the group assumed one of the others had it. That is the normal and correct assumption in a group. The result was nine days. Where tickets fall between the cracks maps the gaps. Nearly all of them are a ticket that belonged to a group at the moment it needed to belong to a person.

Claim It

The first act of ownership is the claim. The technician puts their own name on the ticket, rather than waiting for a name to be put on it. Claim-based ownership is the arrangement where tickets sit unowned until a technician takes one. A claim is a stronger thing than an assignment because the person who claimed meant it. An assignment is something that happened to you. A claim is something you did. People keep promises they made more readily than promises made on their behalf. On a desk where the tool shows who holds what, as QuerySolv's queue does, a claim also makes the load visible to the whole team without anybody counting anybody. That is a quieter benefit than it sounds.

Claiming has a rhythm, and the rhythm is the first thing a new technician should learn. The unclaimed list is the first look of the day and the first look after lunch. The question is never "which of these do I fancy?" but "which of these is oldest, and which has a person waiting on it right now?" Claim what you will touch today. The failure on the other side is claiming everything in sight. That feels like diligence and is the same as a group queue with one name on it. Twenty tickets claimed and three touched is seventeen tickets that have an owner in name and nobody in fact. Claim what you can carry. Leave the rest visible so somebody else can.

Ben's claim on 2231 was the sentence to Priya. The sentence had three parts that every claim should have: I have it, here is when you will hear from me, here is what you will hear. "I have it now, and I will ring you back before twelve with what I have found." The time is the important part. A claim without a time is a status change. A claim with a time is a promise, and the user can tell the difference instantly. (So can the technician, around half past eleven.)

Update It

The owner updates the user before the user has to ask, and "before" is the whole discipline. An update that arrives after "any news?" is an answer; an update that arrives before it is ownership. The test is simple: on any open ticket, who sent the last message, the desk or the requester? If the requester's "any update?" is sitting at the bottom of the ticket, the owner has been outrun. In that case, the ticket is now being chased, which is the state every owner is trying to avoid.

The update has to say something. "Still looking into it" is not an update; it is a receipt for the chase. A real update says what has been done since the last one, what is happening next, and when the user will hear again. It says those things even when the answer is "nothing has moved, because the vendor has not replied, and I will chase them tomorrow at nine and tell you what they say". The content of an honest nothing is still content. The thinking behind cadence, and what a status message has to contain to stop the next chase, is in status updates that prevent the angry follow-up. This article's contribution is only that sending it is the owner's job and nobody else's.

The public update and the internal note are different documents, and the owner writes both. The update is for Priya: short, plain, with a time. The note is for the next technician: what was checked, what was found, what is being waited on, and who was asked. A ticket with good public updates and no internal notes is a ticket that will be re-investigated from the beginning when the owner goes on leave. A ticket with good notes and no updates is a well-documented silence. Both are needed, and the working note habit covers the second one so this article does not have to.

Hand It Over Properly

Ownership moves only when the receiver accepts it. This is the rule that would have saved ticket 2231 on day two. Reassigning a ticket is not handing it over; it is putting it down somewhere else. A handover is complete when a named person has said, in the ticket or out loud, "I have this". Until that happens the original owner still has it, however the assignment field reads. The technician who wrote "passing to networks" believed the ticket had left them. It had not. It had left the user.

There are three kinds of handover and each has its own article, so this one only names them. Escalation moves the ticket to someone with more skill or authority. The article who owns the ticket after escalation settles the question most desks never settle. Usually the first line keeps the user relationship while the second line does the work, and the user is told which. Transfer moves the ticket to a different team or department because the fault lives there. The article transferring a ticket between people or departments is the discipline. A handoff moves it because of time, a shift ending or a holiday beginning. The shift handover owns that. The common thread is acceptance: in all three, the ticket is still yours until somebody has said it is theirs.

The handover note is what makes acceptance possible, because nobody accepts a ticket they would have to re-read from the start. It says what the user reported, what has been tried and ruled out, and what is being waited on and from whom. It also says what the user has been promised and when, and what the receiver is being asked to do. Then the user is told: "Dana on the second line is looking at the licence server; I am still your contact and I will update you by Friday." Where the tool keeps an escalation flag separate from priority, as QuerySolv does, the flag says "this needs someone else" without inflating the urgency. Where it does not, the note says it. Either way the user should never discover a handover by noticing a different name on an e-mail.

Never "Not My Job"

"That's not my job" is the sentence that ends ownership, and it is almost always said by someone who is, in a narrow sense, right. The ticket is about a thing they do not support, or do not know, or are not allowed to touch. The problem is not the fact; it is that the sentence leaves the user holding a problem and no route. The honest replacement is "that isn't something I can fix, and here is what I will do about it", followed by doing it. That means finding the person or team who can, telling the user who that is, and staying the owner until the other party has accepted. Routing is ownership. It ends when the route is confirmed, not when the route is named.

The out-of-scope request gets the same treatment, which surprises some technicians. If the desk does not support personal phones, the answer to a personal phone ticket is not silence or a one-line refusal. In that case, it is the owner saying what the desk does not do, pointing to where help exists if anywhere, and closing the ticket with that written down. Scope boundaries covers what is in and out. Ownership covers how the "out" is delivered. That is by a named person, with a reason, and with the user knowing where to go next. A no with a route is still ownership. A no without one is the same as a group queue.

The reasons people say "not my job" are worth understanding because none of them is laziness. Sometimes the technician genuinely does not know who does own it, and saying so feels like admitting ignorance. Sometimes they are afraid of claiming something they cannot finish. Sometimes the desk has punished people for touching things outside their lane, and they have learned. The cure in each case is the same sentence: "I will find out who can, and I will tell you by three." It commits the technician to a phone call, not to a fix. Nobody has ever been out of their depth making a phone call. Nearly nobody.

The Follow-Through After the Fix

Ownership does not end at "resolved"; it ends when the user has confirmed the fix, or when the desk's agreed silence rule has run its course. The technician who fixes a fault and closes the ticket in the same breath has done the technical work and skipped the last act of ownership. That last act is checking that the thing they fixed was the thing that was broken. The licence that stopped dropping out on Wednesday afternoon has not been tested until Thursday morning. That is when Priya opens the drawing tool and it either stays licensed or does not. Resolving the ticket on Wednesday is a claim. Priya's Thursday is the evidence.

The follow-through has two forms and the owner picks based on confidence. For a fix you are sure of, the resolving message asks for confirmation and the ticket waits. The article user confirmation without chasing forever is how to do that without the ticket living for a month. For a fix you are not sure of, or a fault that only shows under certain conditions, the owner puts a check in their own calendar. The check might say: "ring Priya Thursday 10:00, ask if it dropped overnight". The second kind is rare and it is the one users remember, because almost nobody does it. A technician who rings the next day to ask whether the fix held has told the user that the problem mattered to someone after the ticket stopped counting against anybody.

The follow-through is also where the owner finds out whether they fixed the symptom or the cause. A licence that dropped because the server was restarted will come back if the server is restarted again. The owner who asked "has it happened since?" on Thursday is the one who finds out before the user has to raise ticket 2298 about the same thing. Reopens and repeats are the desk's honesty metric, and the owner's follow-through is where most of them are prevented. The ticket counter does not reward it. The user does.

The Ticket You Forgot

Every technician forgets a ticket, and the measure of ownership is not whether it happens but what happens next. The discovery is usually unpleasant. The ticket is twelve days old, and the last message is the user's. The fix would have taken twenty minutes, and the owner's name is on it. The temptations at that moment are all bad. Quietly closing it. Backdating a note. Replying as though the delay were normal. Blaming the vendor, the queue, the group, the leave. Each of those protects the technician for about a day and costs the desk a user.

The recovery message has three parts and takes two minutes to write. Own the lapse in one sentence, with no excuse attached: "This ticket has sat with me for twelve days without an update, and that is my fault." Give the new time, and make it close: "I am working on it now and will have an answer for you by four today." Then do the thing, and hit the time. That is because a second missed promise after an apology is a desk the user will not use again. Nothing in the message explains why. The user does not want the why, and the why is for the desk lead and the internal note. An apology that arrives with reasons is an apology asking to be forgiven. The user has not got time.

The desk's side of the forgotten ticket is the sweep. The weekly look at tickets whose last message is the requester's, or whose owner has not touched them in a set number of days, catches the forgotten ticket before the user has to. The article the stale-ticket sweep describes it. For the lead reading the sweep, one forgotten ticket is a lapse. The same technician forgetting three in a month is a load signal, not a character flaw. In that case, the right response is to look at what else they are carrying. People forget tickets when they have too many to hold in their head. The fix for that is fewer tickets per head, not a sterner talk.

Ownership as a Mechanism and as a Habit

The tool can make ownership visible and it cannot make it happen. A desk needs both halves. The mechanism is a ticket that always shows one named owner and a list of unclaimed tickets that somebody looks at. It includes a history that records every change of hands. It also includes a way of marking "this needs someone else" that does not pretend the ticket is more urgent than it is. Most help desk tools have most of those. The habit is the person who looks at the unclaimed list, claims with a time, and updates before the chase. That person hands over only to a person who has said yes, and rings the next day. No tool has ever rung the next day.

The habit comes down to three looks a day and one question. The three looks: my tickets, in age order; the unclaimed list; and the oldest open ticket on the desk, whoever owns it. The question, asked of each of mine: who sent the last message? If it was the requester, that ticket is first. The table below sets out the moments at which ownership is tested, and what the owner does at each. It also sets out what the user should be able to see from their side. It is the article in one table, and the standard at the end is the table turned into promises.

A Short War Story: The Ticket With Four Owners at Bellweather Logistics

At Bellweather Logistics the dispatch office's manifest printer began dropping jobs on a Monday. The ticket a dispatcher called Hamid raised that morning passed through four technicians in sixteen days. Each reassigned it to the next with a one-line note: "over to you, printer stuff", "think this is a driver issue, passing on", "networks to look at the print server". Not one of them was ever asked, or ever said, "I have this". For those sixteen days the depot printed its driver manifests at the sister depot across town and sent a van for them each morning. The operations director later costed that at a driver and a vehicle for two hours a day for two and a half weeks. That cost also included the morning the manifests were late and six deliveries missed their slots. The fault was a faulty network cable behind the printer, found in four minutes by the fifth technician. That technician happened to be the first to ring Hamid and ask what the printer did when it dropped a job. The desk lead's review found that the ticket had been assigned on every one of the sixteen days and owned on none of them. The desk's new rule, written that week, was that a reassignment without a named acceptance in the ticket does not count as a handover. Without that acceptance, the ticket stays with whoever moved it.

The Ownership Standard

The standard below is a one-page set of promises a desk makes to itself. It is meant to be agreed by the whole team, printed, and referred to when a ticket has gone wrong. That is when standards earn their keep. The blanks are for the desk's own numbers: the first-reply time, the update cadence, the handover acceptance window and the silence rule after a fix. Those numbers depend on the desk's service levels and are not this article's to set. Everything that is not a blank is a behaviour the user can see from their side. That is the test of whether a line belongs on the page.

THE OWNERSHIP STANDARD — ONE PAGE
Desk: ______________________   Agreed by the team on: ____________

1. EVERY TICKET HAS ONE NAMED OWNER
   [ ] No ticket is left assigned to a group, queue or department for more than ______
   [ ] The owner is the person the requester can ask; the owner need not do the technical work

2. CLAIMING
   [ ] Unclaimed tickets are looked at first thing and after lunch, oldest first
   [ ] A claim is a first reply with a time: "I have this; you will hear from me by ______"
   [ ] Claim what you will touch today; leave the rest visible for others

3. UPDATING
   [ ] The requester hears from the owner before they have to ask, at least every ______
   [ ] Every update says: what was done, what is next, when they will hear again
   [ ] "Still looking into it" is not an update
   [ ] Public update for the requester; internal note for the next technician; both

4. HANDING OVER
   [ ] A reassignment is not a handover; the ticket moves only when the receiver writes "I have this"
   [ ] Acceptance is confirmed within ______; until then the ticket stays with the sender
   [ ] The handover note says: reported, tried, waiting on, promised, asked of you
   [ ] The requester is told who is working it and who remains their contact

5. NEVER "NOT MY JOB"
   [ ] If you cannot fix it: "here is what I will do", then find the owner and confirm acceptance
   [ ] Out of scope: say so by name, give the reason and the route, close with it written down

6. AFTER THE FIX
   [ ] Ask the requester to confirm; close on confirmation or after the silence rule of ______
   [ ] Uncertain fix: book a next-day check and make the call

7. THE FORGOTTEN TICKET
   [ ] Own it in one sentence, no excuses; give a new time the same day; hit it
   [ ] Never backdate, never quietly close
   [ ] Lead's rule: three forgotten tickets in a month is a load problem, not a discipline problem

8. GOING ON LEAVE
   [ ] Every open ticket handed to a named person who accepts, and every requester told

Ben rang Priya back at 11:40, twenty minutes inside the time he had given. The licence server had been restarting nightly since a patch nine days earlier. Dana on the second line found that in about a quarter of an hour once somebody had actually asked her to look. The restart was moved. Ben rang again on Thursday morning, unprompted, to ask whether the drawing tool had dropped overnight. It had not. Priya, who had rung the desk on Wednesday to ask who had her ticket, now knew. She told the rest of the design office. That is how a desk's reputation is made: one ticket at a time, by whoever has it.

Frequently Asked Questions