Ticket categories, priorities and statuses

When a help desk rollout goes sideways, the tool is rarely to blame. More often it is three lists that somebody put together on the last day before launch: categories, priorities and statuses. If they are poor, requests land with the wrong person, everything is marked urgent, and the monthly report tells you nothing useful.

Here is how we set up those three lists with clients, and which parts of it can be configured in UnitLook.

Categories answer the question “what is this about”

A category should not answer “who will fix it”. That is what the department and the assignee fields are for. As soon as categories start carrying people’s or departments’ names, you maintain everything twice, and every staff change means editing the list.

A few rules that have held up well:

• Six to twelve categories. At thirty, people pick the first one or “Other”, and the report turns into noise.
• The client’s words, not IT’s. “Printer not working” is found in a second. “Hardware, peripherals” is not.
• Parent categories only if you really use them. UnitLook supports them, but two levels are enough for almost every company.
• Deactivate, do not delete. An inactive category disappears from the dropdown, while old requests still remember it. The history stays readable.

In UnitLook, categories are managed in Reference data, in the Requests group. For each one you can decide whether the client may pick it. That keeps internal categories such as “Quality control” hidden from customers.

Priorities should mean consequence, not volume

UnitLook has four priorities: critical, high, normal and low. The trouble is not the number. It is that everybody has a different idea of “urgent”. A client whose printer stops before an important visit honestly believes it is critical.

So write the rule down once, in terms of what it does to the business:

Priority	When we use it
Critical	Work stops for the whole company or a whole department
High	One person cannot work and there is no workaround
Normal	It is annoying, but work can continue
Low	A wish, a question or an improvement

New requests default to normal. In the form the priority is chosen with one tap on four colored segments, so the difference is visible in the request list and on the dashboard as well.

Statuses: whose turn is it

The statuses in UnitLook are open, in progress, resolved, confirmed and closed, plus cancelled and rejected. The list itself is not the important part. What matters is what the system remembers next to the status: who is being waited on.

When the assignee marks a request as resolved, the system waits for the client. When the client confirms, the request goes back to the assignee to close. If the client rejects the solution, it returns to work. The request always shows whose turn it is, so nobody has to guess whether the ball is “with us or with them”.

The usual flow looks like this:

1. Comment for messages, without changing the status.
2. Resolved when the work is done.
3. Confirm or Reject on the client side.
4. Close when everything is finished.
5. Reopen if the problem comes back.

The first step is always assignment. A request without an assignee counts as unassigned and has its own counter on the dashboard, because that is exactly where requests tend to sit for weeks.

Three mistakes we see most often

Category as department. “IT”, “Accounting”, “Purchasing”. A request for a new invoice in accounting is not “accounting”, it is “access and permissions”. The department decides who works on it, the category says what the problem is.

Everything is critical. When that happens, critical means nothing. If after a month more than a fifth of requests carry the highest priority, the problem is not your clients, it is the definition.

Closing without confirmation. The assignee closes a request the client never confirmed, and the same request comes back a week later. Keep resolved and closed as two separate steps.

How to set it up in UnitLook

1. Open Reference data and add categories in the Requests group. Decide whether the client may choose them.
2. Agree on the definitions of the four priorities and publish them next to the request form.
3. Check the billing types (internal, warranty, hourly, by quote). That way it is clear who pays from the moment the request is opened.
4. Try the whole flow on one test request: assignment, comment, resolved, confirmation, closing.

If you are only starting with a help desk, help desk implementation step by step is worth reading too. For the difference between tasks and requests, see task management or request management. An overview of everything the product can do is on the ticketing system page.

FAQ

How many request categories are enough?

For most teams six to twelve. If you need more, it is usually two levels in disguise: a few larger groups with details inside. In that case use parent categories.

Can the client see all categories?

They do not have to. You can mark each category as selectable by the client or not, so internal ones stay visible to staff only.

What should I do with a category nobody uses any more?

Deactivate it. It disappears from the dropdown for new requests, while existing requests keep the old category, so reports stay accurate.

Who closes a request, the assignee or the client?

The assignee marks it resolved, the client confirms, and the assignee closes it. That way a closed request does not come back over something the client never accepted.

If you want to see how this looks on your own requests, get in touch for a demo at unitlook.com. It takes 45 minutes and needs no preparation.