How to introduce a help desk

Start with the mailbox, not with the process

The temptation is to design the workflow first. Resist it. Connect the support mailbox, let a week of real requests arrive, and look at what actually turned up. Almost every category anyone invents in advance turns out to be wrong.

Decide four things, not forty

• Which statuses. Three is usually right: open, waiting, done. Add more only when a real case does not fit.
• Who owns an unassigned ticket. Someone has to, or nobody does.
• What "done" means. Customer answered, or problem solved – they are not the same, and the team should agree which.
• One deadline. A first-response target. Resolution targets can wait – see setting up SLAs.

Bring the team along, or it will not happen

The single most common failure is not technical: the team keeps answering from the old mailbox because it is faster for them personally. The fix is to close the old route – not on day one, but on a date everybody knows in advance.

Help is in giving people a reason rather than an instruction: show them the search, the history and the fact that a colleague on holiday no longer means a lost thread.

The first two weeks

1. Week one: mailbox connected, everyone answering from the system, nothing else configured.
2. End of week one: half an hour together – what was annoying, what was missing.
3. Week two: add the categories that actually appeared, set the first-response target, write down two answers you send constantly.
4. End of week two: close the old route.

What to leave until later

Automation rules, elaborate reporting, a public knowledge base and integrations. All of them are easier to get right once you know how the work actually behaves – and all of them are a good way to spend three weeks not launching.

What usually goes wrong

• Too many statuses. Nobody agrees what they mean and the list becomes decorative.
• Nobody owns the queue. Unassigned tickets are everyone's problem and therefore no one's.
• The old mailbox stays open. Two systems means neither is trusted.
• Migration paralysis. Old tickets almost never need importing. Keep the old system readable and start clean.

How long it really takes

Technically, an afternoon. Culturally, two to three weeks before the team stops thinking about it. Anyone quoting three months is describing a configuration project, not an introduction.