Home › Topics › Channel Strategy › Phone Support

Phone Support in a Ticket World

The phone is ringing. Marcus knows this because he is on the phone. The desk handset has a second line that flashes while the first is in use. It has been flashing for forty seconds. The caller on line one is describing a spreadsheet. The caller on line two will get voicemail. The voicemail will be checked on Thursday, because Thursday is when someone remembers the desk has voicemail. It is Monday.

The phone is the oldest support channel and the one a ticket system handles worst. Nothing about a call creates a record unless a person makes one. This article is part of our Channel Strategy series. The series covers what each channel is good at, what it costs, and how to keep every one of them landing in a single queue. The subject here is the phone: a call the technician logs, or does not, and everything that follows from which.

It covers when the phone is the right channel and what it costs the desk. Next comes how to log a call as a ticket while the caller is still talking. Then it covers voicemail done honestly, the user who only ever phones, staffing a line on a small team and what to measure. A worked example and a war story follow. It ends with a call note template, a voicemail greeting and a one-page phone policy to copy.

When the Phone Is the Right Channel

The phone is the right channel when the user cannot type. The laptop will not start, the screen is black, the password expired over the weekend and the only machine they have is the one that is locked. A form is no use to someone who cannot reach it, and "e-mail us" is no use to someone whose complaint is that e-mail is down. The phone is the channel that works when the others are the problem.

The phone is the right channel when the problem is the network. The web form lives on a server, the ticket mailbox sits behind a mail server, and the chat widget is a page on the intranet. When the office cannot reach the server room, every one of those doors is on the wrong side of the outage. The phone is the one channel with no dependency on the thing that just broke.

The phone is the right channel when the user cannot judge the urgency. Someone who says "the box on the wall is beeping and there is a smell" should not be choosing from a priority drop-down. They should be talking to a person who can ask three questions and decide. A form asks the user to triage. A call lets the desk do it.

The phone is the right channel for accessibility. Some people cannot use a form or a chat window. The reason might be a disability, a language, a hand in a cast, or a job that keeps them away from a keyboard all day. A desk with no phone has told those people that support is for people who can type. Nobody would write that policy down, which is a good reason not to let it happen by accident.

What the Phone Costs the Desk

The phone costs the desk an interruption per call. A ticket waits; a call does not. Every call pulls a technician out of whatever they were doing, at a moment chosen by the caller. The thing they were doing takes several minutes to pick up again. Twenty calls a day is twenty interruptions, which is most of a day in pieces.

The phone costs the desk the record. A call leaves nothing behind unless the technician types something, and in the moment, with the caller waiting, typing feels rude. So the fix happens, the call ends, and the ticket is never opened. Three weeks later the same user calls about the same problem and the desk starts from zero. As far as the queue is concerned, a call that was not logged did not happen. The queue has a short memory and no imagination.

The phone costs the desk its attachments. A user describing an error by phone reads it aloud, approximately, and the technician writes it down, approximately, and neither approximation matches the actual text. The same user with a form pastes a screenshot. The phone cannot carry a screenshot, and most problems worth logging have one.

The phone costs the desk serial capacity. One technician can read three tickets at once and answer them in whatever order makes sense. One technician can take one call. On a two-person desk, two calls occupy the whole desk, and the third caller gets the voicemail from the introduction. Which will be checked on Thursday.

Logging the Call While the Caller Talks

Open the ticket while the caller is still talking. Not after the call, not when you get a minute: during. Say the caller's name back, type it, and ask the first question with the ticket form already open. The call note template below puts the fields in the order a caller tells the story, so the technician is filling in a form rather than taking dictation.

Read the number back before the call ends. "That's ticket 7415. You'll get an e-mail with the number in a minute, and I'll update you by three." The number does three jobs. It tells the caller the request exists. It gives them something to quote when they call again. And it stops the second call being logged as a new ticket. A request with a number is a ticket. A request without one is a rumor.

Type less than you think you need. Six lines written while the caller talks are worth more than a paragraph written from memory an hour later. The six lines are accurate and the paragraph is a reconstruction. The template asks for the symptom in the caller's words, the machine, what changed, what they already tried, and how urgent it is in their words. Everything else can be added after the call.

If the call ends with the problem fixed, open the ticket anyway, and resolve it in the same minute. The temptation is to skip it, since there is nothing left to do. Resist. A desk that logs only the calls needing follow-up will report that calls are rare and hard. In truth they are frequent and mostly easy, and the staffing case gets built on the wrong number. The rule that every request lands in one queue is the subject of One Queue, Many Doors. The phone is where the rule is hardest to keep and most worth keeping.

The Call Note Template

Put this in the ticket tool as a predefined note, or keep it on a card beside the handset. The fields are in the order a caller tells the story, and the whole thing takes under two minutes to fill in while listening. The boxes at the bottom are the part people forget.

CALL NOTE   (open the ticket before the caller's second sentence)
Caller: __________________  Dept: ________  Callback number: __________
Time of call: ______
Symptom, in their words:
  ___________________________________________________________________
Machine / location: __________________  (asset tag or hostname if known)
Since when, and what changed: ________________________________________
Already tried: _______________________________________________________
Urgent because (their words): ________________________________________
Can they work meanwhile?   [ ] yes   [ ] partly   [ ] no
Ticket number read back:   [ ]       Next update promised by: ______
Fixed on the call?  [ ] yes, resolve now    [ ] no, owner: __________

Voicemail Done Honestly

Voicemail is a channel only if someone turns it into tickets within the hour. Left to itself it is a mailbox nobody reads, with a greeting that promises a call back and a light that blinks at an empty desk. The rule is short: every voicemail becomes a ticket within sixty minutes during staffed hours. Whoever checks the box opens the ticket, with the caller's number and their words in the call note. Voicemail is intake. It is not storage.

Make the greeting do the redirect. A caller who reaches voicemail has already decided the phone was the right channel. The greeting is the one chance to offer a better one before they hang up. Say the staffed hours, say the form address, and say that the form gives a ticket number at once while a message gets one within the hour. Most callers with a non-urgent problem take the form once they know it exists. The ones who leave a message have chosen to, and that is fine as long as the message becomes a ticket.

VOICEMAIL GREETING   (read aloud; keep it under twenty seconds)
"You've reached the IT desk. We answer the phone from 09:00 to 12:00
and 13:30 to 16:30, Monday to Friday. If it isn't urgent, the quickest
route is the form at help.example.com/new, which gives you a ticket
number straight away. If you leave a message with your name, your
extension and what's wrong, we'll open a ticket within the hour and
e-mail you the number."

Check the box on a schedule, not when the light catches someone's eye. The person on phone rotation checks it at the top of every staffed hour, and the check takes two minutes when there is nothing in it. A blinking light is not a schedule. It is a reproach, and reproaches are easy to stop noticing.

The User Who Only Ever Phones

Every desk has a user who only ever phones, and the wrong response is to make them stop. They phone because the phone has worked for them for years, because it is nearer than a form they have never opened, and because somebody once answered. The desk made the phone the easy door. It cannot now object to someone walking through it.

Open the ticket for them, every time, and tell them the number. The ticket-on-their-behalf habit is what lets the phone stay a channel without becoming a shadow channel. The caller gets what they wanted, which is a person, and the desk gets what it needs, which is a record. Nobody has been redirected yet. The redirect arrives later, in the acknowledgment e-mail, which shows them the ticket exists somewhere they can see it.

Redirect by adding, not by refusing. "I've opened ticket 7416 for you. Next time, if it's not urgent, the form at help.example.com gets you the number straight away, without waiting for me to pick up." That sentence keeps the relationship and plants the alternative. Said once per call for a month, it moves about half of the habitual callers to the form on their own. The other half keep phoning, and that is fine. They are logged.

Do not take a direct line away without a plan. The user who phones a particular technician's extension is using a channel the desk never meant to offer. Retiring it is a project with its own communication plan, covered in Retiring a Support Channel Without a Revolt. Until then, whoever answers the direct line opens the ticket, like anyone else. The number on the ticket does not care which phone rang.

Staffing a Phone Line on a Small Team

Staff the phone with a rotation and a window. A rotation is the written schedule that says who answers in which hours; the window is those hours, published to users. One person on the phone at a time is enough for most internal desks under three hundred staff, and that person works tickets between calls. The rest of the desk does not answer the phone during the window. That is what the window is for.

Publish hours you can keep, and forward the line outside them. A two-person desk can hold a window of 09:00 to 12:00 and 13:30 to 16:30. Outside it, the line forwards to voicemail, the greeting points at the form, and nobody has been misled. "We answer the phone nine to five" from a desk of two means one person's entire week spent waiting for it to ring. The channel strategy template puts the window and the promise on one page beside the other channels.

On a one-person desk, the window is shorter and the forwarding rule is the whole policy. Two hours in the morning with the phone on, the rest of the day on voicemail with the sixty-minute rule, and the form always open. The solo administrator's version of all this lives in The One-Person IT Department. The short form is that a phone answered two hours a day and logged is a better channel than a phone answered all day and not.

Remember: a published window with voicemail outside it is a promise the desk can keep. An unpublished nine-to-five is a promise the desk cannot.

A Worked Example: A Morning on the Line at Kestrel Payroll

Kestrel Payroll runs a three-person desk for two hundred and forty staff, with a phone window of 09:00 to 12:00 and 13:30 to 16:30. Lena has the Monday morning rotation. The call note template is a predefined note in the ticket tool, and the new-ticket form opens with one key.

At 09:06 the first call: Sam in accounts cannot sign in, because his password expired on Friday. Lena opens the ticket as he gives his name, resets the password at 09:08, reads back ticket 7415 and resolves it on the call. Three minutes. At 09:31 the warehouse calls: every handheld scanner has stopped at once. Lena asks three questions and hears "all of them, since about quarter past nine". She opens ticket 7418 at the top priority, reads the number back and promises an update by ten. At 09:34 she hands it to Marcus, who finds the wireless controller rebooting after a power blip. The scanners are back by 09:52. At 10:00 the hourly voicemail check turns up one message from 08:50 about a laptop ordered last week. Lena opens ticket 7420 with the caller's words. She finds the existing ticket 7391 for the order, merges the two, and replies with the delivery date. At 11:05 Priya in HR phones to ask whether her ticket from Thursday has moved. Lena reads ticket 7402 from the queue. She says "it's with the vendor, I'll chase them today and update you by four", and adds that as a note. At 11:48 a call about a jammed printer becomes ticket 7424, fixed on the call, resolved at 11:52.

Six contacts in three hours, five calls and one voicemail, and six tickets. Two resolved on the call, one merged into an existing ticket, one escalated and fixed, two status checks against tickets that already existed. Lena spent about twenty-five minutes on the phone and the rest of the morning on the queue. The two status checks are the interesting number, and the war story below is about them.

Measuring the Phone

Measure the phone with three numbers a week. Calls per day, from the phone system's log or a tally sheet beside the handset. Calls logged as tickets, from the ticket tool, counted by channel. And calls that became tickets within ten minutes of the call, which tells you whether the ticket was opened during the call or reconstructed later. The gap between the first two numbers is the shadow channel. The third says whether the habit is real.

Most ticket tools do not know a call happened, so the first number comes from outside the tool. QuerySolv, for one, has no telephony; it is a help desk, not a phone system. A call becomes a ticket there the way it does almost everywhere, because a technician types it. The phone system's log, or a sheet with a mark per call, gives you the denominator. The ticket tool gives you the numerator.

Read the ratio, not the totals. Thirty calls a day and thirty tickets is a phone channel. Thirty calls and twelve tickets is a phone channel with eighteen unlogged requests a day. That is ninety a week that the staffing case has never heard of. Once those three numbers are steady, add a fourth: calls that were status checks on a ticket that already existed. It is usually larger than anyone expects, and the next section is about why.

A Short War Story: A Month of Logged Calls at Acme

Acme's desk, two technicians for a hundred and ninety staff, logged every phone call as a ticket for one month. That included the ones fixed on the call and the ones that were only questions. Dana tallied them at the end. There had been three hundred and twelve calls. A hundred and fifty-eight of them, half, were users asking about a ticket that already existed: had it been seen, who had it, when would it be done. The desk had not been sending an acknowledgment when a ticket was opened, and its update promises had been living in technicians' heads. They switched on the acknowledgment e-mail with the ticket number, added a next-update time to every first reply, and logged calls for a second month. The status-check calls fell to thirty-one, and the phone window got quieter without anyone being asked to stop calling.

I ran the same count on a desk I inherited, expecting the calls to be mostly emergencies. They were mostly "did you get my e-mail". I had, in fact, not.

The second-commonest reason to phone, after "did you get it", is "I can't remember my portal login". A requester portal that needs no account and no password removes that reason outright. QuerySolv's identifies requesters by e-mail address, so there is no login to forget. A status check the user can do without signing in is a status check that does not become a call.

The Phone Policy on One Page

The card below is the phone channel on one page: the line, the window, the rotation, what to call about, what happens to voicemail, and what is measured. It is deliberately short enough to tape to the handset. The hours are the part that changes; the rules underneath should not.

PHONE POLICY                       Desk: ____________  Reviewed: ________
Line: ____________   Staffed: ______ to ______ and ______ to ______, Mon-Fri
Rotation (who answers, by day): ______________________________________

Call when:   you can't sign in or can't type; the network is down;
             you can't tell how urgent it is; you can't use the form.
Use the form (help.example.com/new) for everything else: ticket number
             at once, attachments welcome, same response promise.

Every call:  ticket opened during the call; number read back;
             next update promised; fixed-on-call tickets still logged.
Voicemail:   checked at the top of every staffed hour by the person on
             rotation; every message becomes a ticket within sixty minutes.
Outside hours: the line forwards to voicemail; the greeting gives the
             hours and the form address.
Direct lines: whoever answers opens the ticket. No exceptions.

Measured weekly: calls per day; calls logged as tickets;
                 tickets opened within ten minutes of the call.

Fill it in, tape it up, and record the greeting. Then go and look at the voicemail light. If it is blinking, that is the first ticket of the new policy, and it is already older than sixty minutes. It was probably left on Monday.

Frequently Asked Questions

Should a small desk offer a phone number at all, or push everything to the form?
Offer one, with a published window. A desk with no phone cannot be reached when the network is down. It cannot be reached by people who cannot type, or by anyone whose problem is that the form will not load. The window, the rotation, and the rule that every call becomes a ticket keep the cost under control.
Is it rude to type while the caller is talking?
It is rude to type silently. Say what you are doing: "I'm opening a ticket for this while you talk, so bear with the keyboard." Callers accept it at once, and most are reassured that something is being written down.
What if the caller just wants it fixed and does not care about a ticket number?
Fix it, and open the ticket anyway. The number is for the desk's record as much as for the caller, and a caller who does not want it loses nothing by hearing it. Resolve the ticket on the call so that it costs the caller no further time.
Our ticket tool has no phone integration. How do we log calls?
The same way most desks do: the technician opens the ticket by hand during the call. They use a predefined call note so that it takes under two minutes. Count calls from the phone system's log or a tally sheet, and compare that number with tickets logged by phone each week. Integration saves a little typing; it does not create the habit.
What happens to a voicemail left at 17:30 on a Friday?
It becomes a ticket within the first staffed hour on Monday, with the time of the message recorded in the call note. The greeting should say that messages outside the window are picked up at the next staffed hour. If the desk has an out-of-hours emergency route, the greeting names it; if not, the greeting should not imply one.
Technicians have direct extensions that users call. Should we remove them?
Not abruptly. First make the rule that whoever answers a direct line opens the ticket, so the calls are at least logged. Then retire the direct lines with a communication plan and a forwarding rule, over a quarter, the same way as any other channel.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.