Triage by Channel: E-mail, Form, Chat, Walk-up and API

At 08:40 Kwame sits down to triage at Ashgrove Housing. The morning's intake is waiting in five different shapes. The support mailbox holds fourteen messages. Three are out-of-office auto-replies to yesterday's tickets, and one is a newsletter. Two are residents replying to tickets that were closed last week, and the other eight are new. The web form has produced six tickets overnight, each with a building and a flat number, because the form asks. The chat widget has two transcripts from the small hours, and the whole of one of them is "hi". On Kwame's monitor there is a sticky note in someone else's handwriting: "Dee came by 08:15, door entry panel Block C." And the monitoring system has created four tickets through the API since 06:00, all about the same switch in the Block C riser. Each one is word-for-word identical except the timestamp.

Every one of those is a ticket, and every one of them is missing something different. The e-mails have history and attachments and no idea which building. The form tickets have the building and no sense of how bad. The chat has a person who may already have gone. The sticky note has everything, in six words, on a square of paper that will fall behind the desk by lunchtime. The API tickets have perfect precision about a switch and no idea whether a human being is affected. The triager's job is to take all five shapes and send one shape into the queue.

Triage by channel is the recognition that where a ticket came in decides what it carries and what it lacks. It is also the habit of normalising it at the door so that whoever owns it next sees one kind of ticket. To normalise a ticket is to make it look like every other ticket in the queue, whatever door it came through. That means a one-line summary, the affected person as the requester, and the five facts present or asked for. It also means a priority set by the desk, an owner, and the channel recorded. This article is part of our Ticket Intake & Triage series. Which channels to offer at all, and how to retire one, is the subject of the Support Channel Strategy pillar. The case for all of them feeding one queue is made in One Queue, Many Doors. Here the doors are open, the tickets are arriving, and the question is what the triager does with each kind.

It covers why the door changes the ticket, then each of the five channels in turn: what it carries, what it lacks, and what to do at the door. Next come screening junk and auto-replies without screening out real people, and catching duplicates and merging or linking at intake. The single shape every ticket should have once inside, a short war story, and a per-channel intake table to copy finish the article.

Why the Door Changes the Ticket

A ticket is a report filtered through whatever the channel made easy. A web form with a building field produces tickets with buildings. A chat box that accepts one line at a time produces one line. An e-mail client that quotes the whole thread produces the whole thread, including the three colleagues who were asked first. A walk-up produces a conversation, which is the richest report of all and the only one with no record. Nobody is being careless. The channel shaped what they said.

The owner who picks the ticket up should not be able to tell which door it came through without looking at the source field. That is the standard, and it is a high one. It means the chat ticket has a proper summary line, not "hi". The e-mail ticket has a subject that describes the problem rather than "Re: Re: Fwd: question". The walk-up has been written down with the same five facts as a form ticket. The API storm has become one incident with one owner. The triager does all of this at the door, in the first touch, and the rest of the desk never has to think about channels again.

Most tools help with part of this and none of them do all of it. Many create tickets from every channel in one queue with one numbering scheme, which removes the worst problem, the separate pile per door. Some rewrite subjects, some thread e-mail replies onto the right ticket, some screen junk, some link duplicates. The triager's job is whatever is left, and the per-channel sections below are organised around the gap between what the channel delivers and what the queue needs.

E-mail: Rich, Rambling and Full of Junk

E-mail carries more than any other channel and arranges it worse. A typical e-mailed ticket has a sender, a subject that was true three replies ago, and a body written in a hurry. It also has a quoted history that may contain the real question, and an attachment that is often the only precise thing in it. What it lacks is almost always the where and the how bad. Nobody writes their building into an e-mail. Nobody writes "one person affected, no deadline" because from where they sit the e-mail is the deadline.

The first thing to normalise is the subject. "Re: Fwd: that thing from Tuesday" is not a summary, and the summary is what every list view, search and report will show. Rewrite it to the one line a stranger could triage from: "Block C, flat 14: heating controller offline since Monday". Thirty seconds, and the ticket is findable for the rest of its life. Most tools let the triager edit the subject; if yours does not, put the one-line summary as the first line of an internal note and search for it there.

The second is the requester. The sender is not always the affected person, and e-mail makes that mistake easier than any other channel, because managers forward things. When Fola the housing manager forwards a resident's complaint with "can you look at this?", the ticket's requester is Fola. The affected person is the resident, whose name is three replies down. Set the requester to the person who has the problem, or add them as a second contact if your tool allows it. Tell Fola in the first reply that the resident will hear from the desk directly. Otherwise every update goes to a manager who forwards it again, and the resident becomes a rumour.

The third is the thread. A reply to an old ticket should land in that ticket and not create a new one. Most tools do this by matching the ticket number in the subject or a hidden header. That works until a requester deletes the number from the subject or starts a fresh message about the same thing. The triager's check is a search by sender before treating any e-mailed ticket as new. If the same address has a ticket from last week about the same problem, this is either a reopen or a duplicate. Either way it belongs with its history. The two "closed last week" replies in Kwame's mailbox are reopens in disguise.

Then there is the junk, which deserves its own section below because it is the channel's special contribution. For now: a mailbox is a door anyone can walk through, including machines, and a desk that triages e-mail must also be screening it. (The mailbox will never tell you which of its fourteen messages are from people. It regards them all with the same warm indifference.)

Web Form: Complete, Structured and Sometimes Wrong

The form is the channel the desk designed, and its tickets arrive looking the way the desk wanted them to. They have a name, a building, a flat, a short list of what it is about, a free-text box, and often a priority the requester chose. Of the five channels it needs the least normalising. It is the one new desks should push people toward, which is a training and design subject for a later group. Its tickets still need a first touch, and the first touch has three specific checks.

The first is the priority. If the form lets the requester choose one, the triager reads it as a statement about how the requester feels. Then the triager sets the desk's own priority from how many are affected and how fast it grows. Form-set priorities skew high, because the problem is theirs and the list offered "Urgent". A lower priority is told to the requester in the first reply, with what it means in time, which is covered in First-Touch Discipline. The rare form-set priority that is too low is the one to watch for. A resident who ticked "Low" for a door that will not lock has been polite, not accurate.

The second is the department or the "what is this about?" choice. Requesters pick the first thing that looks close. On a form that serves repairs, IT and tenancy questions, a broken door entry panel is a coin toss between repairs and IT. The ticket arrives in the wrong department's queue, is first-touched by someone who recognises that it is not theirs, and is moved. The move is a normal part of triage, and the first reply should say where the ticket now is. How departments, forms and mailboxes route a ticket to a queue is the subject of Routing by Department, Form and Mailbox.

The third is the free-text box, which is where the form ticket keeps its surprises. The structured fields say "Block C, flat 14, Heating". The free text says "and also the intercom hasn't worked since the contractors were here in the spring and my neighbour says hers is the same". That is a second ticket and a hint of a wider problem, and only a triager who reads the whole box finds it. The form made the requester choose one thing. They told you the rest in the only place they could.

Chat: Fast, Thin and Half-Finished

Chat produces tickets one sentence at a time, and the first sentence is usually "hi". Some tools create a ticket on the visitor's first message; others only when the conversation ends; a few not at all unless an agent presses a button. Whichever yours does, the ticket that results is a transcript, and a transcript is not a summary. The triager's first job on a chat ticket is to write the one-line subject that the conversation never had.

Chat lacks the who more often than any channel except the walk-up. A visitor on a public widget may be anonymous until they type an e-mail address, and many leave before they do. A visitor on an internal widget may be identified by their login, or not. The five facts arrive in the order the visitor felt like typing them, interrupted by the agent's questions. The since-when and the how-bad are the ones most often lost, because the chat was about getting something fixed now. If the visitor is still there, the triager asks for the missing facts in one message, as a numbered list, exactly as described in Gathering the Right Information Up Front. Chat is the one channel where asking once with everything is possible in real time and still routinely done one question at a time.

If the visitor has gone, the ticket is either complete enough to work or it is not. Complete enough means the five facts are in the transcript and the visitor left an address. The triager writes the summary, sets the priority and owner, and the ticket joins the queue like any other. Not complete enough with an address means the missing-information reply goes out by e-mail and the ticket waits. Not complete enough and no address means there is nobody to ask and nothing to do. The honest action is to close the ticket with a note saying so. A ticket that cannot be worked or answered will sit in the queue making the oldest-ticket number worse for no one's benefit. "hi" at 02:14 from an anonymous visitor who left at 02:15 is such a ticket. It still gets the note. Nothing gets deleted.

The night-time chat tickets at Ashgrove are the common case. A resident reached the widget at midnight, typed a line, got the "an agent will reply in working hours" message, and typed their e-mail. That one is workable. The one that typed "hi" and nothing else is not, and Kwame closes it with a two-word note and moves on. Both took under a minute, which is the point of deciding at the door.

Walk-up and Phone: Everything, Briefly, in the Air

The walk-up and the phone call are the richest channels and the least recorded. They are grouped here because the triager treats them the same way. The person standing at the desk, or on the line, will answer all five questions in ninety seconds. They will show you the error on their phone and tell you about the contractor in the spring. Everything the owner could want is available, once, out loud. Then the person leaves and the information goes with them, unless someone writes it down before they do.

The rule is to open the ticket during the conversation, not after it. "I'm opening a ticket so this doesn't get lost" is the sentence, said out loud, as the triager types. In a decade of saying it nobody has ever objected. Typing while the person talks also shapes the conversation: the triager asks the five questions in order because the form or the template prompts them. The walk-up becomes a complete ticket with the five facts in the right places. That is more than the e-mail channel manages on a good day. The requester's e-mail address goes on the ticket so that they get the thread and can reply to it later. The channel field says "walk-up" or "phone", so that next month's report can count how much of the desk's work came through a door with no inbox.

The sticky note is what happens when the rule is skipped. It is why the untracked walk-up is one of the quiet failures described in The Seven Ways Support Quietly Fails. A note in someone else's handwriting on the triager's monitor is a ticket with no number, no requester address, no time of day beyond what was scribbled, and no owner. The triager's first job on finding one is to turn it into a ticket immediately, with "walk-up, reported by Dee at 08:15, logged by Kwame at 08:42" as the first line. The second job is to go and find Dee for the rest of the facts, because the note has two of the five. (The third job is to stop the desk taking walk-ups on sticky notes, which will take longer than the first two.)

A phone call that arrives while the triager is mid-sweep is logged as a ticket and joins the sweep. It does not jump it unless it is Urgent on the desk's own scale. In that case it is first-touched now and the sweep resumes. The caller is told the number and that they will hear by a time. A desk that lets the phone jump the queue by default has made loudness the priority scale. The people who phone are not reliably the people with the worst problems. They are the people who found the number.

API and Automated Sources: Precise, Repetitive and Blind

Tickets created by other systems through an API are the opposite of the walk-up: perfectly recorded and almost entirely without context. An API is an application programming interface, the route by which one program creates a ticket in another without a person typing. The monitoring system knows the exact switch, the exact port, and the exact second it stopped answering. It has no idea whether anyone in Block C has noticed. It also has no sense of proportion. A switch that flaps four times produces four tickets, each one as confident as the last.

The first thing to normalise is the count. Four tickets about one switch are one incident. The triager links them under a shared incident name if the tool can do that. If it cannot and they come from the same source account, the triager merges them. If it can do neither, the triager closes three with a note pointing at the fourth. One ticket, one owner, one summary line that a human wrote: "Block C riser switch flapping since 06:00; four alerts; residents not yet reporting". The three "is the wifi down?" e-mails that arrive at 09:00 are then linked to the same incident instead of triaged as three new problems. The first fifteen minutes of a real incident, and when to declare one, are in Declaring an Incident and the First Fifteen Minutes. The triager's part is to notice that four machine tickets and three human ones are the same thing.

The second is the priority, which a machine should never set alone. The monitoring tool may have been told that a switch alert is Urgent, and most of the time it is right. But a switch in an empty building at 03:00 and the same switch at 09:00 on a Monday are different priorities with the same alert text. The triager reads the machine's priority as evidence, exactly as a form-set priority is read, and sets the desk's own. Where a tool lets an API token be tied to one department, so that monitoring tickets land in the infrastructure queue rather than the general one, use that. It does the routing half of the first touch before a person looks.

The third is the human. An API ticket has no requester in the ordinary sense. The owner needs to know who is affected before they can say how bad it is. So the first touch on a machine ticket includes a glance at the other channels for the people. If residents are e-mailing, the e-mails are the impact and the machine ticket is the cause, and they belong together. If nobody is e-mailing, the machine ticket is a quiet morning's work for the network owner, and its priority says so. A machine never phones to say it has noticed something. A person usually does, about forty minutes after the machine.

Screening Junk and Auto-Replies

E-mail intake must be screened, because a mailbox accepts anything, and the things it accepts that are not tickets fall into three groups. Automatic replies include out-of-office messages, delivery failures, read receipts, and the "we have received your request" from another desk's tool. That last one can loop with yours forever if neither side is screened. Bulk mail: newsletters, vendor marketing, and the industry survey that has your support address on it. And spam, which needs no description. On a busy mailbox the three groups together can outnumber the real tickets. Every one of them that reaches the queue costs the triager a read and the reports a false ticket.

Most tools screen with two mechanisms, and the triager should know how both are set. The first is a set of rules on the sender, the subject, the domain, the body or an attachment name. Each rule can block a message, allow it through regardless of other rules, or hold it for a person to look at. The second is a built-in heuristic that recognises bounces, auto-replies and bulk mail by their headers and drops or holds them without a rule. The rules are the desk's; the heuristic is the tool's. The held messages sit in a review queue, in some tools for weeks, until someone approves or deletes them. If yours has no review queue, the rules should hold rather than block anything that might be a person. The held mail goes to a folder someone actually opens.

The danger is over-screening, and it is a real one. Consider a resident whose e-mail signature says "Automatic reply" in a language the heuristic recognises. Then consider a customer whose subject line begins "Out of office" because they are replying from a phone to an old thread. Or take a supplier whose domain was blocked after one marketing message and who now sends an invoice query. All of these are people, and a block rule has made them invisible. The weekly habit that catches this is ten minutes in the held-mail queue, looking for a human name. The design rule is that a block is for addresses that have never once sent a ticket, and everything else is held. A letterbox that eats the wrong letters is worse than one that lets in junk mail. The junk mail is at least visible.

Two details are worth checking in your own tool. First, check whether a held message that is approved becomes a ticket with the original timestamp or with the approval time. The first-response clock cares about the difference. Second, check whether an auto-reply that slips through can reopen a closed ticket. That is how a desk ends up with a ticket reopened every morning at 07:00 by a requester's out-of-office until someone notices in March. Both are a test ticket and a quiet afternoon away.

Catching Duplicates and Merging at Intake

The cheapest moment to catch a duplicate is the first touch, and the check is a glance plus a search. The glance is at the new-ticket view, sorted by time: three tickets in twenty minutes with "door" or "intercom" in the subject are one problem. The search is by the requester's address and by the obvious keyword, across open tickets. It takes ten seconds in any tool with a search box and finds the ticket the same person raised about the same thing last week. Both together take under a minute and they are the only reliable way to stop four tickets being worked by four people.

Once found, a duplicate is merged or linked, and the two are different. A merge folds one ticket into another, so that there is one ticket with one history and one requester. It is the right move when the same person raised the same thing twice, or when a reply to an old ticket arrived as a new one. A link connects two tickets that stay separate, each with its own requester, under a shared name. It is the right move when different people report the same underlying problem. Each of them must still be replied to and each of them will want to hear when it is fixed. Merging four different residents into one ticket produces one ticket with one requester and three people who never hear anything again.

Tools differ here more than almost anywhere, and the triager must know their own. Some tools merge only between tickets of the same requester and will not let you merge two people's tickets at all. Some merge anything. Some cannot undo a merge once it is done, so a wrong merge is permanent. Some can link under an incident name and some cannot. If they cannot, the convention is a line in each ticket's note saying "see ticket 7704" and a subject prefix so the related tickets sort together. Find out with two test tickets before the morning you need it. A merge that cannot be undone is not a reason not to merge; it is a reason to read both tickets first.

The one reply is the part that makes merging worth doing. When four tickets become one, or four are linked under one incident, every requester gets a reply that says the problem is known. The reply gives its number, its owner, and a time by which they will hear more. The second requester does not care that they were second; they care that they were heard. "This is the same as a problem already reported this morning; I have added your report to it, it is being handled by Priya as High, and you will hear from her by 11:00 either way" is four sentences and the whole of the courtesy. (The fourth person to report the wifi has, after all, done the desk a favour: they confirmed the first three.)

One Shape for Every Ticket

The standard, once a ticket is inside, is one shape, and the shape has six parts. A one-line summary a stranger could triage from, written or rewritten by a person. The affected person as the requester, with a working way to reach them. The five facts present, or asked for in one numbered reply. A priority set by the desk from its own scale, whatever the form, the caller or the machine said. An owner by name or a department whose own people will name one within the hour. And the channel recorded. That lets next month's report say how much work came by e-mail, how much by form, and how much walked up to the desk and would otherwise have been invisible.

The channel field is the one that desks forget, and it is the one that pays. Without it, the walk-up and the phone are uncounted. The case for a second person cannot be made with numbers. The decision to retire a channel or promote the form is taken on feel. With it, one report shows that the form produces complete tickets and the mailbox produces questions, and that the sticky note is a channel with its own volume. Most tools record the channel automatically for everything but the walk-up, which the triager sets by hand. That is one more reason the walk-up is logged during the conversation and not from memory at four o'clock.

Normalising at the door costs the triager thirty seconds to two minutes per ticket, depending on the channel. The rest of the desk gets a queue in which every ticket can be read, searched, prioritised and reported on the same way. It is the least glamorous part of intake and the part that makes everything downstream simpler. An owner who opens a chat ticket and finds a summary, a requester and five facts does not know or care that it began as "hi". That is the standard.

A Short War Story: The Sticky Note at Ashgrove Housing

The sticky note on Kwame's monitor at Ashgrove Housing fell behind the desk at about 10:30, when someone leaned over to borrow a charger. Dee's report about the Block C door entry panel ceased to exist as far as the desk was concerned. Dee, who had been told "I'll pass it on", assumed it had been. The panel stayed dead for three days. During that time, the residents of Block C propped the main door open with a fire extinguisher so that visitors and deliveries could get in. Fola, the housing manager, learned about it on the third evening from a resident's complaint about the open door rather than from anyone at the desk. The cost was a locksmith's emergency call-out for a panel that needed a reboot. There was also a fire-safety report that named the propped door and the desk's failure to log the fault. It also cost an hour of Fola's time explaining to a residents' meeting why a reported problem had not been fixed. The desk's review found no ticket, no e-mail and no record of any kind. There was only the memory of a conversation and a note that was recovered from behind the desk a week later. The rule that followed was the one in this article. A walk-up is a ticket before the person has left the desk, with their e-mail address on it, or it is not a report at all.

The Per-Channel Intake Table

The table below is the triager's reference for the first touch by channel. It covers what each door usually delivers, what it usually leaves out, and what to screen or catch. It also covers what the triager does before the ticket joins the queue. Pin it beside the triage card and adjust the "usually missing" column to match your own form and mailbox after a month of noticing. Under it is the one-line log format for walk-ups and phone calls, which is the part of the table most desks need in a form they can type from.

WALK-UP AND PHONE LOG LINE — TYPE IT WHILE THEY TALK
Channel: [ ] walk-up  [ ] phone     Reported at: ______   Logged at: ______
Requester (affected person): ____________________  E-mail: ________________
Summary (one line): ________________________________________________
Where: ____________________   Since when: ____________________
What they see / what should happen: __________________________________
Already tried: ______________________
Anyone else affected / deadline: ______________________
Priority set: ______   Owner: ______________   Ticket number told to them: [ ]

Two adjustments by desk. A desk with no chat widget and no API strikes those rows and keeps the other three. Those are where most of its tickets come from and where most of the normalising work is. A desk with several departments in one tool adds a column for which department each channel's tickets land in by default. The form, the mailbox and the API token each route somewhere, and the triager should know where without opening the settings. In both cases, the walk-up row stays as written. It is the row that was missing at Ashgrove.

Fourteen e-mails, six form tickets, two chats, a sticky note and four machine alerts. By 09:20 Kwame has sent eleven real tickets into the queue in one shape, and screened out five that were never tickets. Kwame has linked four alerts and three e-mails under one incident with Priya's name on it. Kwame has also closed a chat that said "hi", and walked to the housing office to find Dee. The owners who pick those eleven up will not know or care which door each came through. That is what the first hour of a triager's morning is for.

Frequently Asked Questions