Transferring a Ticket Between People or Departments

Tuesday, 09:00, at Northgate Retail. Carla, who manages store 14, phones the desk. "I've had three e-mails saying my ticket has been updated. What's been updated?" Sam opens 3382, the card terminal that will not pair with the till, and reads his own day back. 11:05 yesterday: moved to Facilities, note "socket?". 15:40: moved back by Facilities, note "not ours, socket fine". 16:00: moved to the payments team, no note, because it was four o'clock and card terminals were plainly the payments team's. The payments team reads its queue on Tuesday afternoons. Three moves, three automatic notifications to Carla, and not one sentence written by a human being to another.

A transfer is moving a ticket to a different owner or department because the work belongs there. It is the most ordinary handoff on the desk, and it should be. The socket is Facilities' job, the account is the directory team's, and the terminal is the payments team's. And a desk that is reluctant to transfer ends up doing everyone's work badly. The move is not the problem. The arrival is. This article is part of our Handoffs & Coverage Transitions series, and it is about making a transferred ticket arrive.

It covers the difference between a transfer, an escalation and a dump, then the three questions to answer before moving anything. We cover the transfer note, written for a stranger, then the acceptance and who owns the ticket until it happens. Next come telling the requester, in one line, and the trap of transferring to a person who is away. We cover ping-pong and who settles it, then transfers to teams that are not in the tool. A short war story and the transfer note to copy follow, in that order.

A Transfer Is Not a Dump

There are three ways a ticket leaves one person for another, and they look identical in the tool. A transfer moves the ticket because the work belongs elsewhere: a different team, a different skill set, a different building. An escalation moves it upward because the current owner cannot finish it, to someone with more skill or more authority. The reasons and the paths for that are in The Handoff That Does Not Dump, and this article leaves them there. A dump is either of the first two done badly. It is a move with no note, no acceptance and no word to the requester, which makes the ticket somebody else's problem and nobody's work.

The tool cannot tell a transfer from a dump, because both are a change to the department or owner field. Sam's 16:00 move to the payments team was a dump. The payments team was the right team. But the ticket arrived with no note, nobody accepted it, and Carla heard about it from a machine. The field changed correctly. Nothing else happened. A transfer is a transfer when the receiver can start in two minutes and the requester knows who has it. Until both are true, it is a dump with good intentions.

Transfers should be frequent and cheap, and the point of the discipline below is to keep them that way. A desk that makes transfers hard, with forms and approvals, gets technicians who hold on to tickets they cannot fix. A desk that makes transfers thoughtless gets Carla's Tuesday. The middle is a five-line note and a one-line reply, which is less work than either.

Before You Move It: Three Questions

Answer three questions before touching the department field. The first is whether the work belongs there, and the way to answer it is to ask, not to guess. A message to the receiving team, "Is a card terminal that won't pair yours or ours?", takes a minute and saves a bounce. The routing rules that say which team owns what are in Routing by Department, Form and Mailbox. If the rules do not say, that is a finding for the rules. The ticket still needs an answer today, so ask.

The second is what you have already done that the receiver should not do again. Every transfer without this answer costs the receiver the time it takes to repeat the sender's first twenty minutes. If you have restarted the terminal, checked the socket, confirmed the till can see the network and tried a second cable, say so. The receiver's first instinct will be to restart the terminal. Nothing is more quietly expensive than a ticket where three people have each done the same first step.

The third is what the receiver needs in order to start in under two minutes. They need to know which store, which terminal, which till, and the serial number if you have it. They need the name and number of the person on site, when the site is open, and what you told the requester. The receiver should be able to read the note and pick up the phone. If they have to read the whole history first, they will read it later, and later is where tickets go to wait.

Writing the Transfer Note

The transfer note is written for a stranger: someone who has never seen the ticket, does not know the requester, and has forty other things to do. Five lines, as an internal note, written at the moment of the move. Why it is coming to you. What has been done and tried. What the requester has been told, with any time promised. What I suggest you do first. Anything urgent or unusual. The last line is often "nothing", and writing "nothing" is better than leaving the receiver to wonder.

Here is the note Sam should have written at 16:00. "To payments: terminal at store 14, till 2, will not pair with the till. Facilities confirmed socket and cable are fine. I restarted terminal and till, re-ran pairing twice, same error. Carla (store manager, extension in ticket) told at 11:00 that someone would look today; store is open till 20:00. Suggest you check whether the terminal is still registered to till 2 on your side; serial is in the first message. Nothing else urgent." Six sentences. The payments technician can act on it without opening the history, and the next thing they do is phone Carla.

Write "what the requester was told" every time, even when it is "nothing". This is the line that transfers the promise along with the ticket. Carla was told "today" at 11:00, and that promise moved to Facilities without the words, came back without them, and went to payments without them. By 16:00 three teams had owned the ticket and none had owned the promise. The note is where the promise travels, and it is the only place it can.

Keep the note internal and check that it is. Most tools distinguish internal notes from replies and show only replies to the requester; some show both in a portal. Before you write "Carla has phoned twice and is getting cross", confirm which kind yours is. Raise a test ticket from a personal address and read what arrives. Then write every internal note as though she might read it anyway, which is a good habit and a surprising one to need.

The Acceptance

A transfer is complete when the receiver accepts it, and until then the sender still owns the ticket. Acceptance means a named person on the receiving side has taken ownership, read the note, and either replied to the requester or declined the transfer with a reason. The field changing is the tool's record that a transfer was requested. The acceptance is the receiver's confirmation that it was delivered. And the two are different events, separated on most desks by hours and on some by days.

A transfer to a department lands unassigned, which is where the acceptance most often fails to happen. The receiving team's queue has an unassigned view. Somebody in that team has to read it at least once a day with the question "is this ours and who is taking it?" If nobody has that job, a transferred ticket waits until someone looking for work happens to scroll to the bottom. Give one person per department, by name, the job of reading the unassigned view by a fixed time each morning and claiming or returning everything in it. That person is the acceptor, and the time is the longest a transfer should ever wait.

Some tools have an explicit accept-or-decline step on transfers; most small-team tools do not. The convention that works in any tool is that the acceptor assigns the ticket to themselves and adds a one-line internal note, "Accepted, phoning Carla now". The sender, who has kept the ticket on a watch list, sees the owner change and can stop watching. On a desk where the sender and receiver sit in the same room, the acceptance can be spoken, "I've got 3382". But the note is still written, because the person who asks about it on Thursday was not in the room.

Set a time limit and write it down. A transfer within the desk is accepted the same working day. A transfer to another department is accepted within one working day. Anything that has not been accepted by then goes back to the sender's list to chase. The sender chasing is not an insult to the receiver. It is the sender doing what owning a ticket means until somebody else does.

Telling the Requester

The requester hears about a transfer from a person, in one line, and the line says what has changed for them. "Your terminal ticket is now with our payments team; Jo has it and will phone you before 15:00." Who has it, what happens next, by when. It comes from the new owner where possible, because that is the name the requester will want to use. It comes from the sender where the acceptance is going to take a while, because the requester should not wait for the acceptance to hear anything.

The automatic notification is not that line. Most tools can send something when a ticket changes department or owner. What they send is a template sentence with a ticket number in it, which tells the requester that a field changed and nothing about what to expect. Carla got three. Find out what your tool sends on a transfer by transferring a test ticket you raised yourself and reading the e-mail. Then decide whether to keep it on at all. A notification that says "updated" and means "moved" trains requesters to ignore notifications, which is a cost the desk pays on every ticket afterwards.

Never let the requester see the argument. If a ticket is being declined, bounced or disputed between teams, the requester hears one thing, from one person, with a time: "We are sorting out who looks at this; I will come back to you by 11:00 either way." The internal disagreement is internal. A requester who receives three "updated" notifications in an afternoon has been shown the argument without the words, and it looks exactly like nobody wanting their problem.

The Assigned-to-Someone-Away Trap

The quickest way to lose a transferred ticket is to transfer it to a person rather than a team, and for the person to be away. The field says Jo. Jo is on leave until the 14th. The ticket has arrived, been assigned and been notified. And it will do nothing for nine working days, visibly, with Jo's name on it, in a list only Jo reads. The sender has stopped watching, because the ticket has an owner. The owner is on a beach.

Before assigning to a name, check the name is in. Most desks keep an absence list somewhere, on a shared calendar or a whiteboard, and thirty seconds of looking at it before a transfer saves a fortnight. If the person's status is uncertain, transfer to the department unassigned with the note, so that whoever reads the unassigned view that morning picks it up. A ticket that is unassigned in the right queue will be found within a day. A ticket assigned to the wrong absent person can wait until they return and ask what it is. The daily check for tickets held by absent people, which catches the ones that slip through, is in Keeping Tickets From Hiding.

Watch for the leaver's account. A person who has left the organisation and whose account still exists in the tool can still be chosen in the owner field, and in most tools nothing stops you. Tickets assigned to a leaver are the most reliably lost tickets on any desk, because nobody filters by a name that is no longer on the rota. If your tool lets you disable accounts, disable leavers on their last day. If it lets you hide them from the assignment list, hide them. If it does neither, keep a list of names not to pick, which is an undignified solution and works.

Ping-Pong and Who Settles It

Ping-pong is a ticket that bounces between teams, each of which correctly decides it is not theirs. Facilities says the socket is fine. The desk says the terminal is not its hardware. Payments says pairing is a till problem. Every decline is reasonable, and the ticket spends a week being reasonably declined, while Carla's store takes cash. A bounce is a transfer that was not accepted, and one bounce is normal. Two is a dispute, and a dispute has to be settled by someone who is not one of the parties.

The rule is two bounces and the lead decides, the same day. The lead reads the ticket and picks a team. The lead tells it to work the problem until it is solved or until it can show, with evidence, whose it is. The chosen team may be wrong. That is fine. A wrong team working a ticket finds the right team faster than three right teams declining it, because the wrong team is motivated to. The decision is written in the ticket as an internal note, "Lead decision: payments to own this to resolution". The requester hears one line with a name and a time.

Every settled dispute is a routing rule that was missing. Write it down: card terminals that will not pair go to payments first, and payments calls the desk if the till is at fault. The next ticket of that kind goes to the right team without a bounce. And the lead never has to decide the same thing twice. A desk that settles ping-pong without writing the rule will settle the same ping-pong every month. I know a desk that settled the printer-versus-network dispute eleven times before anyone wrote it down. (The twelfth time, someone did.)

Transfers to a Team Outside the Tool

Some of the teams that own work are not in the ticketing tool at all: the facilities contractor, the payroll bureau, the building's landlord, the software supplier. A ticket cannot be transferred to them, because there is nowhere for it to land. What happens instead is that the ticket stays with the sender, in a waiting status, and the sender becomes the person who chases. The requester's ticket is never "with the landlord". It is with the desk, and the desk is waiting on the landlord, which is a different sentence with a different owner.

Record three things when the work goes outside. Record who has it, with a reference if they gave one. Record what they promised and when. Record when you will chase if nothing has happened. Put the chase date in the ticket as a follow-up or a "PROMISED" note, so that the ticket surfaces on the day rather than when the requester phones. The requester hears one line: "The door reader is with the building contractor, reference 4471, who have promised Thursday; I will chase them Thursday afternoon if it is not done and update you either way." The detail of working with suppliers and other teams, including what to do when they do not answer, is in the article on escalating to vendors and other teams.

A Short War Story: The Badge Reader at Acme

At Acme, a new starter called Yusuf could not get through the staff entrance on his first Monday because his badge had never been enrolled on the door reader. The ticket he raised from reception spent eight working days moving between the desk, Facilities, and the building landlord's access-control contractor. Each moved it on with a one-word note, and none told Yusuf anything. He stood in reception every morning until someone let him in, for a week and a half. His manager eventually walked him round to the loading bay, which was quicker. The desk had transferred the ticket to Facilities as a department. The ticket sat there unassigned for two days because nobody in Facilities had the job of reading the unassigned view. Facilities had transferred it to a named person who was on leave. The contractor had been "told" by a voicemail with no reference and no date. Eight days, three transfers, zero acceptances, and a new starter whose first impression of the company was its car park. Acme wrote a five-line transfer note, named an acceptor in every department, and put "check the absence list before assigning to a person" on the desk's wall. A transfer with no acceptance is a ticket that has been thrown over a wall, and the wall does not reply.

The Transfer Note

The note below is the five lines plus the acceptance and the requester line, in the order they happen. Write the top half as an internal note at the moment of the move; the receiver fills in the bottom half when they accept. It is short on purpose. A transfer note that runs to a page is a history, and the receiver has the history already.

TRANSFER NOTE — INTERNAL NOTE AT THE MOMENT OF THE MOVE
Ticket #______   From: ______________   To (person or department): ______________

WHY IT IS COMING TO YOU
  __________________________________________________________________

DONE AND TRIED (not to be repeated)
  __________________________________________________________________
  __________________________________________________________________

WHAT THE REQUESTER WAS TOLD
  Told ______________ at ____:____ that: ____________________________
  Site / contact / hours: ___________________________________________

SUGGESTED FIRST STEP
  __________________________________________________________________

URGENT OR UNUSUAL
  [ ] nothing   [ ] yes: ____________________________________________

Absence list checked before assigning to a person: [ ]
Sender keeps watching until accepted: [ ]

ACCEPTANCE (receiver fills in)
  Accepted by ______________ at ____:____    [ ] declined, reason: ______________
  Requester told who has it and next step by ____:____   [ ] done
  First action taken: ______________________________________________

Two lines matter most. One is "what the requester was told", because it is where the promise travels. The other is "accepted by", because until it is filled in the ticket has not arrived anywhere. Sam used the note for the first time on 3382's successor, a terminal at store 9 three weeks later. The payments team accepted it at 09:40, phoned the store at 09:45, and had it paired by lunch. The store manager got one e-mail, from a person, and did not need to phone to ask what had been updated.

Frequently Asked Questions