Introducing a ticketing system that is still in use after three months

Why rollouts fail

In almost every case we have seen, the software was not the problem. The rollout failed because the old route stayed open. As long as customers keep writing to personal addresses and colleagues keep asking in the doorway, the ticketing system is additional work – not a replacement for existing work. The second common mistake is over-structuring: defining fifteen categories, four priorities and three escalation levels before the first ticket produces a model that has nothing to do with reality and that nobody maintains.

The first cut: mailboxes, not processes

Start with the structure that already exists – the departments. Support, engineering, accounts: each team its own mailbox with its own address. That answers the most important question, who is responsible, without anyone having to classify anything. Categories, priorities and deadlines come later, when real cases show which distinctions are actually needed. This order is the difference between a system that reflects the work and one the work is supposed to follow.

• One incoming address per team, communicated publicly
• Redirect personal addresses to the team mailbox – do not ask, redirect
• One view "my cases", one view "unanswered" – nothing more is needed at the start
• No mandatory fields at creation. Not one
• One person per team who looks in daily during the first weeks

The first four weeks

This is when the habits form that you cannot argue with later. In practice: ten minutes a day in the list of unanswered cases, every enquiry that bypassed the system politely brought back into it, and once a week a question about what got in the way. What surfaces in this phase is usually small – a signature with the wrong address, a form on the website still writing somewhere else. Those details decide the outcome.

What to measure – and what not to

The number of tickets says almost nothing: it rises when the system is accepted, and that is good. Three other figures are meaningful. First, the share of cases landing in the system rather than beside it – estimable from the mail still going to personal addresses. Second, time to first response, not time to resolution. Third, the number of cases that change ownership more than twice; that is the most reliable sign of an unclear structure.

When a rollout is genuinely hard

Two cases are honestly difficult. First, several sites with grown, differing routines. The only thing that works is converting one site completely and the second afterwards – in parallel it almost never goes well. Second, an existing knowledge base to be migrated. In our experience half of it is out of date; the migration is an editorial task, not a technical one, and it takes longer than the entire setup. Knowing that in advance means planning for it rather than being surprised.