How to move from a shared inbox to a help desk without dropping a ticket

The shared inbox doesn’t fail all at once

Most small IT service providers and MSPs don’t start with a help desk. They start with a Gmail group or an Outlook shared mailbox called something like support@ or help@, forwarded to whichever two or three people happen to be on shift. For a while it works fine.

Then it starts failing in small ways that are each individually excusable: a client email sits unread for two days because everyone assumed someone else grabbed it. Two techs reply to the same thread with conflicting instructions. A client calls about a server outage, someone takes the call, promises a fix “this afternoon,” and never writes it down anywhere — so when a different tech picks up the follow-up call, they’re starting from zero.

None of those is a crisis on its own. But they compound, and the trigger moment is usually the same: a call gets missed, or a client asks “didn’t someone already tell you about this?” and nobody can produce a record. That’s the point where a shared inbox has stopped being a process and started being a liability.

First, don’t just upgrade to a nicer inbox

The obvious next step feels like buying a “shared inbox tool” — something like Front, which markets itself as email built for teams, with shared drafts, assignment, and collision detection. Checked live on Front’s pricing page today, 2026-09-09: Starter runs $25/seat/mo for up to 10 seats, and phone is not a native feature at any tier — the product page says calls are handled “with integrations like Aircall and Dialpad,” which means a second subscription and a second vendor relationship on top of the seat price.

That’s worth naming plainly: a nicer shared inbox is still a shared inbox. It fixes “who replied to what” but it doesn’t give you ticket types, SLA tracking, a CMDB, or a phone channel that’s actually part of the product instead of wired in from outside. If the plan is to spend real migration effort anyway, it’s worth spending it moving to something that solves the actual problem — voice included, ticket structure included — rather than a better-organized version of the same inbox.

Step 1: audit what’s actually flowing through the inbox

Before touching any settings, spend a week (or pull two weeks of history) and tag every message and call by type:

• Incidents — something is broken right now (a server down, a printer offline, a login failure blocking work).
• Requests — someone wants something provisioned or changed that isn’t broken (new laptop, software install, access grant).
• Problems — a recurring or underlying issue behind repeat incidents (a flaky switch causing weekly outages).
• Changes — planned work that could affect service (a patch window, a migration).

This matters because a flat inbox treats all four the same, and that’s exactly the mindset shift a real ITSM tool asks you to make. If you skip this step and import everything as one generic “ticket,” you’ll just have a searchable shared inbox, not a help desk.

While you’re auditing, count the phone volume separately

Pull call logs for the same window if you have them (or estimate from memory if you don’t — most small teams don’t log calls anywhere, which is itself a sign of the gap). You need this number to decide whether phone support is a checkbox or a core requirement for whatever you migrate to. For the ICP this content is written for — teams whose clients call when something’s down — it’s almost always core.

Step 2: pick ticket categories and don’t over-engineer them

Map the four categories above onto whatever the new tool calls them, set default SLAs per category (a P1 incident might get a 1-hour response target; a routine request might get 1 business day), and resist the urge to build twenty custom fields before you’ve processed a single real ticket. You can add structure later once you know what you actually need; you can’t easily walk back an overbuilt taxonomy that nobody on the team remembers how to use.

Step 3: set up email-to-ticket before you touch the old inbox

Point your existing support@ address at the new system’s email-to-ticket ingestion (most tools, including ITSM, support this natively) rather than asking clients to learn a new address. This is the single highest-leverage step: clients keep doing exactly what they already do, and the change is invisible to them.

Run both systems in parallel for at least a week. New mail lands as tickets in the new tool; the old inbox stays live as a read-only archive so nothing already in flight gets lost mid- migration.

Step 4: don’t let phone continuity become the thing that breaks

If clients call a specific number today, that number needs to keep working through the migration, full stop. Two ways to handle it:

1. Port or forward the existing number into the new system before cutover, so calls start landing as tickets (or getting answered by an AI phone agent, if the new tool has one) on day one.
2. Run a temporary answering script for the first week — “if you’re calling about an existing issue, reference your ticket number; new issues will be logged as usual” — so the team isn’t relying on memory to reconnect a call to prior email history.

This is where a shared-inbox upgrade like Front falls short even after migration: voice still lives in a separate vendor, so “did we already handle this caller’s issue” means checking two systems, not one.

Step 5: migrate history selectively, not exhaustively

Don’t try to import every email from the old inbox as a historical ticket. Most of it is closed, resolved, and not useful data going forward. Instead:

• Export and keep the raw mailbox as a searchable archive (most email clients support this natively) for the handful of times someone needs to look something up.
• Manually re-create only the open threads as tickets in the new system, with a note on each summarizing what’s already been promised to the client.
• Rebuild your knowledge base from scratch rather than copy-pasting old canned replies — this is a good moment to prune advice that’s out of date.

Step 6: pilot with one tech before the whole team cuts over

Have one person run entirely through the new system for a few days while everyone else stays on the old inbox for new mail. This surfaces the gaps in your ticket taxonomy and SLA defaults while the blast radius is one person’s mistakes, not the whole team’s.

Step 7: cut over and retire the old inbox on a fixed date

Pick a date, tell clients (a one-line email is enough: “we’ve moved to a new support system, same address, same phone number”), and stop monitoring the old inbox except as a read-only archive. Leaving it half-alive indefinitely is how teams end up running two support channels forever instead of one.

What actually changes once you’re through it

The point of doing this isn’t just organization — it’s that a ticket now carries structure a shared inbox never had: an owner, a type, an SLA clock, and (if the phone is wired in properly) a record of what was said on a call, not just what was typed in an email. We’ve covered what that voice piece specifically requires in what to look for in a help desk with a browser softphone, and what a small MSP should check for beyond just ticketing in how to choose IT help desk software for a small MSP.

Where ITSM fits

ITSM is built so this migration lands on a system that already does incidents, requests, problems, changes, a CMDB, and SLA tracking out of the box — plus an AI phone agent that answers calls from live ticket data and a browser softphone for techs, so voice doesn’t become the one piece you still have to bolt on separately. Email-to-ticket works the way described above: point your existing address at it and clients never notice the switch. There’s a free tier (2 seats, $0, instant signup) if you want to run the pilot step above without committing to anything first — see it at itsupport.aramagio.com.

Honest note: ITSM is a small product, not an enterprise platform, and the free tier exists so you can test a real migration before deciding it’s worth paying for.