Why it works at first
Everyone knows how to use it, there is nobody to train and there is no project. With two people and thirty emails a day, it is a reasonable answer.
The five signs it has broken
1. Two people answer the same email. Or worse: they tell the same customer different things.
2. A read email disappears. Someone opens it by accident, closes it and it is no longer bold. That request no longer exists.
3. Nobody knows what is in progress. To find out the status of anything, someone has to ask out loud.
4. Nothing can be measured. How many requests came in last month? How long did replies take? Nobody knows.
5. Vacations take the context with them. What was discussed with a customer is in someone’s head and in a buried thread.
What you lose, specifically
- Traceability. When a complaint comes in, you do not have the sequence of events, just fragments.
- Priority. In an inbox everything weighs the same, and urgent requests compete with newsletters.
- Knowledge. How that case was solved is in a thread nobody will ever find.
- The full conversation. What was said over the phone or on WhatsApp is not there.
How to switch without stopping service
Week 1. Change nothing
Connect the mailbox to the new system and let it turn emails into tickets, while the team keeps working as usual. It shows you the real volume, which almost always comes as a surprise.
Week 2. Classify
Define four or five ticket types, not fifteen, and two or three priorities. A complicated classification does not get used.
Week 3. Run both in parallel
The team replies from the system, but the inbox stays open. This is the week to learn and adjust.
Week 4. Switch over
Nobody opens the inbox directly anymore. Do this in one go: keeping both channels open forever guarantees nobody adopts the new one.
The start-of-shift check
Once the system is running, every shift starts with three lists: new tickets, tickets with no owner and unclassified tickets. If all three are empty by mid-morning, nothing gets lost.
And the queue of pending emails is cleared from the list, without opening them one by one. Every email ends up in one of three places: it opens a new ticket, joins one that already exists, or gets flagged and archived. None is left read and going nowhere.
The three migration mistakes
- Bringing over the whole history. 12 or 24 months is enough. Ten years slows everything down, and nobody looks at them.
- Creating twenty ticket types on day one. Start with five. Adding is easy; removing is almost impossible.
- Not switching over. If the inbox is still there, half the team will stay in it and nothing will have changed.
What you gain in the first month
No lost requests. Knowing how many come in and how long they take. And when someone is out, anyone can pick up a ticket by reading its history in two minutes.
If you recognized three of the five signs, your inbox is no longer a system: it is a risk. The switch takes four weeks, and half the work is deciding on five ticket types.
Last updated: