Moving from a shared inbox to a ticketing system

This guide assumes the decision is already made: the shared inbox is no longer enough and you have chosen a ticketing system. The comparison between the two lives in another guide. What follows is the move itself — about four weeks of work that tends to fail for the same three reasons.

The most common one: the new tool is switched on and the old mailbox is left open “just in case”. A month later the team is working in two places, twice as much as before, and somebody proposes going back — not because the tool was wrong, but because the move never finished.

What to decide before you start

Four decisions, all of them before configuring anything:

• Who leads the move. One person, with the authority to say “from Monday, this is how we work”. A move with shared ownership stops at the first reasonable objection.
• The date the mailbox stops being a channel. Written in the calendar, not “when we are ready”.
• How the work is divided. By customer, by product, by department: this decides who sees what, and it is the most expensive choice to change later.
• What happens to the history. See below — the right answer is almost always “nothing”.

The move, week by week

Week 1 — configure behind closed doors. Create the workspace, the agent accounts, the division of work you decided above and the priorities. No customer knows yet. At the end of the week, open three fake requests and take them all the way to closure: that is how you find the missing step while it is still cheap.

Week 2 — internal team only. Requests still arrive in the mailbox, but nobody answers from there: whoever picks one up reopens it in the system and replies from inside. It is a tiring week, and that is the point — every friction you feel now is friction your customers would feel next week.

Week 3 — customers come in. Publish the new form or address and announce it where customers actually look: a short email, signatures, the website. The old mailbox stays open only for conversations already in progress.

Week 4 — close the door. The old mailbox auto-replies with the new address and is no longer read to start work. This is the week teams usually skip, and it is the only one that makes the move irreversible.

What to do with the old history

The temptation is to import years of email. It is almost always wasted work: closed conversations are rarely consulted, and imported without an owner, a status or a priority they fill the new list with rows nobody will read — making the tool you bought to create order look disordered.

The practical rule is that you carry over only what is open. Live requests are reopened by hand in the new system; in most small companies that is a few dozen, and half a day is enough. The rest stays where it is: a read-only archived mailbox is a perfectly respectable archive.

One warning that is about privacy rather than tidiness. Importing old conversations moves personal data into a new processing arrangement with a new supplier. If you decide to do it, look at it first — the GDPR checklist lists the questions.

What changes for your customers

Less than you fear, if you choose well. For a customer there is exactly one acceptable change: the address they write to. Everything else — creating an account, choosing a password, learning a portal — is a request that some of your customers simply will not fulfil, and they will go on writing to the engineer in their address book.

If the system you picked forces customers to register, know it now: you will pay that cost in week 3, and it will present itself as “customers are not using the portal”.

The mistakes that send a team back

• Keeping two channels. The most common one, and the only one that is enough on its own to sink the move.
• Configuring too much. Eight statuses, six priorities and four departments in week one describe the company you would like to be. Start with the minimum and add when something is actually missing.
• Not telling customers. Announcing it once, in an email sent on a Friday afternoon, does not count as telling them.
• Not deciding who checks unowned requests. In the first month somebody has to do it every morning, or the shared mailbox reappears inside the new tool.

When to postpone the move

Do not do it in your industry's peak month, and do not do it while the company is already changing another tool: week 2 needs attention, and in those weeks attention is not available. Postpone it too if you cannot name the person who will lead it — without one, four weeks become six months of two coexisting channels, which is the worst outcome of all.

And if the volume really is low, revisit the original decision: below a handful of requests a week, a shared inbox remains an honest tool.

How the move works in OglutTicket

Week 1 is short: create the workspace, invite the agents — who sign in with their email address and a code, without choosing a password — and split the projects. Week 3 is the lightest, because customers do not register: they open a request from a public form, verify their email address and reply from a protected link. Week 4 needs nothing from us at all: it is an auto-reply configured on the old mailbox.

There is no automatic import for the history, and it is better to know that up front: open requests are reopened by hand. The three-month free trial covers the four weeks with room to spare, so the move does not happen against a stopwatch — terms and figures are on pricing, and security and privacy says where the data lives. If the organisation is still missing before the move, start from organising support in a small business.