Voicemails

This module is about intake: taking a message somebody left, or a call you pick up, and turning it into a ticket another tech could work cold. Answering the phone itself, steering the call and closing it while the person is on the line, is Module 6, The phone.

The Voicemail Inbox is a Pro tool. On a free account the panel shows an upgrade prompt, so if that is you, read this module as teaching: the craft below is the same on any desk, and the hands-on drill in part three is there when you are on Pro.

On the phone you are conducting an interview, typing a record, and calming somebody down at the same time, while the person is still talking.

You can ask a follow-up question and get an answer in two seconds. Everything in the record is there because you typed it while they spoke, and when the caller hangs up, anything you did not ask is gone until you ring them back.

Write the call up so the next person to touch the ticket can work it without ringing the user back.

Learn this list in this order until you can run it without thinking, because you will be running it while somebody is shouting at you.

Three live-call habits sit around that list, and all three need a line that is still open. You confirm the list by saying it back and waiting for the yes, and you hand a caller on by staying with them until the next person has picked up: both are worked in The phone. Getting a real error string out of somebody who will only describe the screen is worked in Company Chat. A voicemail gives you one pass. The read-back, the handover and the follow-up question about what the certificate warning actually said all need somebody on the line, so a message leaves you whichever of the seven the caller thought to include.

The number is the second thing you take, after their name and before the problem. That is where The phone puts it too: the desk they have reached, your name, their number, then the fault. You can work around the rest: guess at the fault, look the person up, read their record. Without a number the message stops where it is, and the person believes they have logged a call that nobody can progress.

On your own outgoing message, follow the advice you give users: your name, your number, and the one-line reason you are calling, at the start and again at the end.

Here the sim clips the extension to every message, so the person is always reachable and you can drill the rest. On a real desk you ask for the number yourself, on every call.

A user reports what is on their own screen. The table below is what those reports usually turn out to be.

Four questions close the gap:

Who else

Is anybody near you seeing this? One person is a device or an account. A floor is infrastructure.

Since when

And what happened just before that. A patch, a password change, a new machine.

What else

Does anything else work? If one site loads and another does not, the line is up and the fault is on one machine or one address.

Somewhere else

Does it fail on a different machine, a different network, a different account? A fault that follows the account is in the record. One that stays with the desk is on the machine.

Then write both. The caller's words go in the ticket as the reported symptom, because that is what the next person will search for and what the user will recognize when they read the update. Your reading goes in as the diagnosis, clearly labeled as yours. Leave their description standing and put the theory beside it, so a wrong theory still leaves the original evidence on the ticket.

Voicemails sits in the header next to the call controls. It is a Pro tool: on a free account the panel shows an upgrade prompt, and the inbox behind it stays empty, because the incoming calls and the messages that fill it are part of Pro. Part three says what to practice instead.

The panel is a single list headed Voicemail Inbox with the count beside it. Empty, it says No voicemails yet, and under that, Voicemails arrive while you play. Pro only. Messages land on their own while you work the queue, so the list grows whether or not you ever miss a call. A message becomes work at the moment you raise the ticket. Until then the rest of the desk cannot see it.

A message arrives two ways: when you decline a call or let it ring out, and from the recurring callers, who drip messages in on their own while you work the queue. That drip is the one part with a limit.

Opening a message gives you the playback controls and the message itself. Play Message reads it out in that caller's voice; the speaker button next to it silences playback. On a text-only message the same control reads Mark as Read. Either way the words are underneath, in the Transcription block, which carries the whole message on its own.

Below that are three rows of metadata: Issue Type, Priority and Extension. All three were set before you opened the message. On a live desk you set priority yourself, from impact and urgency, which is the subject of The ticket queue.

Create Ticket at the bottom of the message opens a short ticket form, already filled in from the voicemail: the caller's words are sitting in the description, with the issue type and priority the message carried. You can edit any of it before you file. Submitting builds the ticket from what is on the form, drops it in your queue, archives the message and marks it heard, and credits you for logging it. Archive next to it clears a message and raises nothing, for the ones you have decided need no ticket.

The ticket is about the program he does not recognize, appearing right after a link he clicked. That pairing is a possible malware install, which is a security issue and the one thing here that outranks everything else. This is the case the virus row on page four was pointing at: "my computer has a virus" stops being adware the moment a clicked link and an unknown program turn up together. The account he is worried about is the consequence he fears, and the fault sits upstream of it. So file it as a security ticket, keep all three facts in the transcription so the whole sequence stays on the record, and make sure the link and the program are the part the next person reads first.

The ticket body has a fixed shape. It is stamped Created from voicemail and then carries Caller:, Extension:, Employee ID: and Department:, followed by Transcription: with the message in quotation marks. When a message arrives with no words attached, that last block reads Voicemail transcription unavailable, which is your cue that the only evidence is whatever the metadata gives you.

That layout is the intake list from part one: identity, contact, department, then the user's own words preserved exactly.

If a ticket already exists for that caller and that issue, the button refuses and names the ticket you already have, so one fault does not end up with two records.

The right-hand column is the one you will be working in at a real desk. Both rows about the callback number point the same way: you ask for the number, you read it back, and you write it down yourself, because the number in the ticket is what the next tech dials. Here the extension rides on every message, so the inbox is where you drill the reading.

Create Ticket is how the work leaves this panel. Ringing the caller back becomes a step somebody else can see, because the ticket says it is owed.