Implementing Four Types in an Ordinary Help Desk Tool

Dana took over the two-person desk at Fenwick Timber, a merchant with three branches and a yard, on a Monday. By Wednesday she had read about incidents, requests, problems and changes and wanted to use them. She opened the settings of the ticketing tool. Statuses: New, Open, Pending, Resolved, Closed, and no button to add one. Priorities: Low, Normal, High, Urgent. Departments: IT, Facilities. Forms: a general one and a new-starter one. Categories: a tree about twenty entries deep, planted by her predecessor. Custom fields: three, all unused. A tab for problems: no. A tab for changes: no. A field called type: no. The vendor's knowledge base, asked whether a problem module existed, said it was "on the roadmap". That is the way vendors say no with hope in it.

This is the normal condition of a small-team help desk tool, and it is fine. A full ITSM suite is the kind of tool built around the whole of IT service management rather than the queue. It has a module for each of the four types, with its own fields, workflow and reports. Most small-team tools have none of them, and the desks running on those tools do not need them. That is because a convention carries the type just as well for a desk of ten. A convention is an agreed way of using a field the tool already has. The four types are defined in The Four Work Types in Plain Words. This article is part of our Incidents, Requests, Problems & Changes series. It is about where to put the word when the tool has no box for it.

It covers what an ordinary tool gives you to work with and what it does not, then the three tests any convention must pass. The four conventions follow in turn: a form per type, a department per type, a category branch and a subject prefix. Each comes with where it works and where it breaks. Next come problems and changes without a module, as linked tickets and a list. The article ends with the conventions table to copy, choosing one and writing it down, and a short war story, in that order.

What an Ordinary Tool Gives You

Before choosing a convention, take an inventory of your tool, because the right convention is the one that uses something the tool already does well. Open the settings and write down, in a column, which of the following exist and whether you can add to them. The inventory takes ten minutes and saves a month of trying to make the wrong field do the job.

• Statuses: fixed, or can you add and rename them?
• Priorities: fixed, or editable, and do targets hang off them?
• Departments, groups or queues: can a ticket be routed to one, and can each carry its own targets?
• Web forms: one, or several, and can a form pre-set a department, category or field?
• Categories: a tree, a flat list, or none; set by the requester, the triager or both?
• Custom fields: can you add a drop-down, and does it show in the ticket list and the export?
• Tags or labels: free text, searchable, filterable?
• Linking: can one ticket reference another, and is the link visible from both?
• E-mail intake: where does an e-mailed ticket land, and with what defaults?
• Reports and export: which fields can you group by, and what can you export to a spreadsheet?

Most tools have most of the first list. What most small-team tools do not have is a field called type, a problem record, a change record, or an approval step with its own state. Those four absences are the reason this article exists, and the honest position on each is the same. The tool will not do it for you. The convention will, and the convention needs to be written down somewhere the next person will read it. (The next person is the one who matters. You will remember the convention. They were not there when it was agreed.)

The Three Tests a Convention Must Pass

A convention carries the type, and it must carry it through three places: the door, the list and the report. At the door, the type must be set when the ticket is logged, by the form or the triager, without anyone having to remember to type something. In the list, the type must be visible or filterable. That lets the triager see the incidents without opening each ticket. It also means the daily call in Incident or Request? The Daily Call has somewhere to record its answer. In the report, the type must be something the tool can group by or export. That lets the monthly page be built without reading three hundred subject lines.

A convention that fails the door test depends on memory, and memory is the first thing that goes on a busy Tuesday. A convention that fails the list test is invisible to the people working the queue, which means it will drift, because nobody sees the drift. A convention that fails the report test produces a desk that has carefully typed every ticket and cannot say how many of each it had. Each of the four conventions below passes all three tests in some tools and fails one of them in others, which is why the inventory comes first.

There is a fourth test, quieter than the others: the convention must survive a change of people. If the type is carried by a thing only the current triager knows to do, it will stop being carried the week they are on leave. The conventions that survive are the ones built into the door. That way, the type is set by the form or the routing rule rather than by a person remembering. Build it into the door wherever the tool allows. Where it does not, write the rule on the card above the triage screen, and expect to re-explain it twice a year.

Convention One: A Form per Type

The cleanest convention is a web form for each type that people raise, which in practice means two. Those are a "something is broken" form and a "I need something" form. Each form sets the type at the door, because the requester chose the door, and each can carry its own questions. The broken form asks "What stopped working, and when?" and "How many people are affected?", which are the incident questions. The need form asks "What do you need?" and "Who is your manager?", which are the request questions. The second one is the start of the approval step. The forms themselves can be plain; the point is that they are two.

It works where the tool supports several forms and lets a form pre-set something the list and the report can read. That can be a department, a category, a custom field or a tag. In those tools the type is set by the form and shown in the list by whichever thing the form set. It is grouped in the report by the same thing. All three tests pass without anyone typing. It works best when most tickets arrive through the web, which on most desks they do not. That is the weakness: e-mailed tickets arrive through no form at all and land with the tool's default. Decide the default deliberately. Request is the safer default, because an incident misfiled as a request is found by the triager at first touch. By contrast, a request misfiled as an incident runs an incident clock nobody is watching.

Do not build four forms. Problems and changes are raised by the desk about its own work, and the desk does not need a public form for them. A requester shown a form called "Report a problem" will use it for a broken mouse, because in ordinary English that is what a problem is. You will have a very well-labelled pile of incidents. Two public forms, broken and needed, and the other two types handled by the desk from the inside.

Convention Two: A Department per Type

The second convention routes each type to its own department, group or queue. It works in tools where routing is by department and where each department can carry its own targets. "Service Desk" holds incidents and runs the incident clock; "Requests" holds requests and runs the longer expectation. The type is then set by whichever department the ticket lands in and visible in the list as the department column. It is grouped in the report by department, which most tools can do. Where the tool hangs targets off departments rather than priorities, this is the only convention that gives requests their own clock. It does so without inventing a priority band for them.

The weakness is that departments are usually also teams. A tool with one department field cannot use it for both "which team" and "which type". Suppose a desk with an IT department and a Facilities department adds a Requests department. It has to decide whether a request for a desk lamp goes to Requests or Facilities. Whichever it chooses, one of the two meanings is lost. The convention works cleanly on a desk with one team, where the department field is free to mean type. On a desk with several teams it works only if every team's requests can live in one Requests department and be claimed from there. Some desks find that natural and others find it a second queue to forget about. The routing mechanics, and the hiding places a second queue creates, are in Routing Tickets by Department, Form and Mailbox.

If you use it, give the Requests department a named owner who reads its unassigned view daily. A department nobody owns is a department where requests go to wait for approvals that nobody is chasing. The first sign is a requester asking in week three whether anybody received the form. They did. It was received by a department.

Convention Three: A Category Branch

The third convention makes the type the top level of the category tree. Incident, Request, Problem, Change are four branches, with the existing categories hung under the first two. A ticket categorised "Incident, Hardware, Printer" carries its type in the first word. The list can filter by category, and the report groups by the top of the tree. It works in tools with a tree-shaped category field, and it has one strong advantage over the first two conventions. The type is set by the triager at first touch, where the daily call is made anyway. It is not set by a requester choosing a form or a rule choosing a department.

The weakness is that the category field is already doing a job, which is saying what the ticket is about. Making it also say what kind of work it is doubles the tree. Every "what" now appears twice, once under Incident and once under Request, and a desk with twenty categories has forty. That is survivable at twenty and a swamp at sixty. The pruning discipline for a tree that has grown is in Avoiding the 400-Category Monster. The other weakness is that categories are often set at close rather than at open. That fails the door test unless the desk makes "type branch at triage, leaf at close" an explicit rule.

Where the tool has a flat category list rather than a tree, the branch becomes a prefix on each category name: "INC Printer", "REQ Printer". That is the same idea with less structure and more scrolling. It works. It is also the point at which a custom drop-down field called Type becomes the better choice. That applies if the tool offers one and shows it in the list and the export. In that case, the category tree goes back to doing one job.

Convention Four: A Subject Prefix or Tag

The fourth convention puts the type in the subject line, as a prefix such as INC, REQ, PRB or CHG. Or it puts the type in a tag or label where the tool has them. It works in every tool, including one whose only fields are subject, body and status. It even works in a shared mailbox being used as a desk while a tool is chosen. It is searchable. It is visible in the list because the subject is always visible. The report can be built by exporting subjects to a spreadsheet and counting the first word. All three tests pass, at a cost.

The cost is that a prefix is typed, and a thing that is typed is a thing that is forgotten. The door test is passed only if the tool adds the prefix itself. That can be by a form that sets the subject, a rule that prefixes tickets arriving at a particular address, or a tag applied by routing. Where a person has to type it, the convention lasts until the first busy week. Then it becomes a report in which the number of changes is whatever fraction of changes somebody remembered to label. That is the Caldera Brewing story, below, and it is the commonest way this convention fails.

Use the prefix as the fallback where nothing else is available, and as an addition where it is. That is because a visible INC or REQ at the front of the subject helps the triager. It helps even when a form or department is carrying the real type. Tags are better than prefixes where the tool has them, since they can be filtered and are harder to mistype. Tags are also quieter than prefixes. A subject that begins with four capital letters is read; a tag in a side panel is read by people who already know it is there.

Problems and Changes Without a Module

Problems and changes are raised by the desk, about its own work. The convention for them is a ticket with the desk as requester plus a list where somebody will read it. A problem record without a module is a ticket, subject "PRB: dispatch printer fails weekly", requester set to the desk's own address. The incidents it explains are linked to it or listed by number in its first line. A review date is in the body. The problem ticket sits in the queue with a type everyone can see and a status that says it is being investigated. It will not move at incident speed. The desk needs to have agreed that this is fine, because the queue will show it as old and old looks like neglected.

A change record without a module is the same shape: a ticket, subject "CHG: swap dispatch printer, Sat 07:00", requester the desk. The body holds the one-page record with the date, what will be done, and who was told. It also holds how the change will be checked and how it will be put back if it fails. The record itself, kept to a page, is in The One-Page Change Record. The convention of keeping it as a ticket, with a calendar beside it, is worked through in Tracking Changes Without a Change Module. When an incident arrives on Monday, the triager searches for CHG tickets closed in the last week before diagnosing anything. That search is most of what a change module would have given them.

The list is the part people skip, and it is the part that works. A ticket in a queue is read when it is worked; a problem ticket is worked rarely, so it is rarely read. A page in the knowledge base called "Open problems" has one line per problem with the ticket number, the review date and the current workaround. The desk lead reads it every Friday in five minutes. That reading is problem management on a small desk. The same page, or a second one, called "Changes this month" with a line per change and a date, is the change calendar. A suite would give the desk a module for each. The page gives it the same five-minute Friday for free. (Suites also give you a dashboard for it, which is read about as often as the ticket.)

The Conventions Table

The table below is the four conventions side by side. It shows where the type lives, who sets it, where it works, what to watch for, and how the monthly report gets at it. Use it with the inventory from the first section. Strike out the rows your tool cannot do, and what is left is usually one obvious choice and one fallback. Keep the table in the knowledge base next to the page that says which one you chose.

Most desks end up with two rows: one convention for incidents and requests, and the linked-ticket row for problems and changes. A few add the prefix as a visible extra. Nobody needs all five, and a desk running three conventions for the same type has three places for them to disagree.

Choosing One and Writing It Down

Choose in this order. If the tool has several web forms and most tickets arrive by web, use a form per type and set the e-mail default to request. If not, and the desk is one team whose tool routes by department, use a department per type. If neither, and the tool has a category tree or a custom drop-down the list and the report can read, use the branch or the field. Use the prefix on its own only when none of those exist. Use it as an addition whenever it helps the triager see the type at a glance. Then handle problems and changes as linked tickets plus a list, whichever of the above you chose. That is because no small-team convention for incidents and requests carries those two.

Write the choice on one page, in the knowledge base, with four things on it. Say which field carries the type and what each value means. Say what an e-mailed ticket gets by default and who corrects it. Explain how a problem or change ticket is raised, prefixed and linked. Say where the weekly list lives and who reads it. Add the date and the name of the person who decided, and the date of the next review. That page is the implementation. The settings in the tool are just where the page points.

Do not change tools to get a type field. A desk that moves tools for a drop-down loses a year of history and three months of habit. It gains a thing a form or a department was already carrying. The time to care about modules is when the desk is large enough that the Friday list takes longer than an hour to read. That desk is usually also large enough to be choosing a suite for other reasons. Until then, the convention is not a workaround for the missing module. For a desk of ten, it is the better design, because it fits on a page and the module does not.

Test the page on a new starter. Hand it to them on their first morning, with the definition card from the first article in this series. Ask them to triage ten tickets. Where they hesitate, the page is unclear. Where they get one wrong, the page is wrong or the form default is. I have handed that page to four new starters on three desks. Every one of them found a sentence I thought was obvious and was not. That is the page working, before the busy week finds the same sentence for you.

A Short War Story: Zero Changes at Caldera Brewing

Caldera Brewing, a brewery with a bottling line and a desk of three, agreed to record changes by typing CHG at the front of a ticket's subject. The ticket was to be raised before any change was made. For a month everyone followed that convention. The quarterly report, built by counting subjects, showed four changes in the first month, one in the second and none in the third. The operations manager congratulated the desk on a stable quarter. In the third month a technician called Ravi made a Saturday firmware update to the bottling-line's label printer as a favour to the line supervisor. It was recorded nowhere. The update stopped the line for a Monday morning. Three people spent four hours diagnosing from scratch a thing one of them had done two days earlier. Afterwards the desk counted properly and found about forty changes made in the quarter, of which five had the prefix. That was because the prefix was something a person typed and the person was busy. Caldera moved the convention from the hand to the door. It used a change form that set the subject, a tag applied by the form, and a calendar page in the knowledge base. It also used a rule that the Monday triager searched closed CHG tickets before diagnosing anything. A convention that lives in somebody's typing lives nowhere; put it in the door.

Dana, at Fenwick Timber, chose two forms, "Something is broken" and "I need something". Each set one of the three unused custom fields to Incident or Request, with the e-mail default set to Request. A line on the triage card told whoever had the queue to check every e-mailed ticket against the one question. Problems and changes became tickets raised from her own address with PRB or CHG at the front and a knowledge-base page for each. She reads those pages on Fridays. The tool is the same tool. The settings page still has no tab for problems. It does not need one, because the page in the knowledge base has three lines on it, and she read them this morning.

Frequently Asked Questions