Replacing a shared support inbox is an operating-model change, not an email migration. The safe path is to define request ownership, routing, priority, customer communication and service evidence before moving messages into a help desk.
Start with a limited queue and preserve a fallback. The first goal is not sophisticated automation; it is to ensure every request has a visible owner, status, next action and recoverable history.
Diagnose the inbox before replacing it
Sample several weeks of messages. Classify request types, volumes, arrival patterns, hand-offs, duplicates, sensitive content and unresolved conversations. Record how staff decide who responds, how they recognise urgency and where they keep context outside the mailbox.
Do not judge the inbox only by its visible backlog. Search sent folders, forwarded threads, private notes and spreadsheets. A queue that looks quiet may conceal work in personal mailboxes; a high message count may contain automated notifications that should never become tickets.
Define the service boundary
Write down which addresses and request types the new system will accept, which team owns each class, what remains outside scope and what constitutes completion. Distinguish incidents, service requests, questions, complaints and sales enquiries if their owners or response commitments differ.
Digital.gov's contact-center technology guidance highlights routing by source, destination, subject, content, availability, skills and business rules. Use only the routing signals that your team can maintain and explain.
Design a minimum ticket lifecycle
| State | Required evidence | Control question |
|---|---|---|
| New | request, requester, time and source | Was the request captured once? |
| Assigned | accountable queue or person | Who must act next? |
| Waiting | reason, dependency and follow-up date | Can waiting work disappear? |
| Resolved | response, action and resolution code | Did the outcome address the request? |
| Closed | closure rule and retained history | Can the case be reopened or audited? |
Keep the state model small. Add a state only when it changes ownership, customer expectation or measurement.
Set routing and escalation rules
Route first by a small number of stable attributes: recipient address, request type, customer segment or service. Define what happens when no rule matches, a team is unavailable or a request crosses boundaries. Every queue needs an owner who reviews unassigned and ageing work.
Escalation should identify a condition, clock, destination and expected action. A red label is not escalation if nobody has accepted responsibility. Test one urgent case, one ambiguous case and one request sent to the wrong address.
Protect customer continuity
Keep familiar email addresses during transition. Explain what changes in acknowledgements, reference numbers and replies. Make sure customers can continue a conversation without creating a new ticket, and test attachments, forwarding, out-of-office messages and copied recipients.
Avoid exposing internal notes or recipient lists in outbound mail. Review templates in plain text and on mobile, and make the route to a person clear when automation cannot resolve the request.
Prepare the data and migration boundary
Decide whether to migrate open conversations, a recent history window or only reference metadata. Full mailbox migration can import duplicates, personal content and obsolete threads. Whatever the scope, retain the original mailbox according to policy until reconciliation and rollback periods end.
For open requests, create a control total by queue and status, import them once, then reconcile counts and spot-check attachments, timestamps, requester identity and thread order. Give every exception an owner rather than hiding it in an import log.
Run a two-queue pilot
Select one request type with a clear owner and meaningful volume. For a short period, monitor both the new queue and the legacy inbox. Do not ask staff to process the same request in both places; define which is authoritative and use the other only as a safety monitor.
Measure lost or duplicated requests, time to first ownership, ageing, transfers, reopenings and customer follow-up. Interview agents about extra clicks and missing context. A pilot passes when the new process is more observable without creating unacceptable handling effort.
Include a daily reconciliation between messages received and tickets created. Investigate every difference while the evidence is fresh. This catches rejected attachments, mail loops, blocked senders and routing gaps that a successful browser test will not reveal.
Control cutover and rollback
- Freeze routing-rule changes and export the final open-request list.
- Switch mail flow at an agreed low-risk time.
- Verify inbound receipt, acknowledgements, replies and attachments.
- Reconcile the first hour and first day against mail logs.
- Keep named people watching unassigned and failed items.
- Use written thresholds for rollback, manual capture or continued operation.
Rollback must explain how tickets created after cutover will be preserved. Redirecting mail back is not enough if actions already occurred in the help desk.
Make management behaviour support the queue
Supervisors should review unassigned, ageing, breached and repeatedly transferred work, not simply total ticket counts. Team meetings should use the same queue evidence; parallel spreadsheets quickly recreate the visibility problem.
After stabilisation, improve categories, knowledge and automation one observed failure at a time. The transition is complete when work is owned and measurable, customers experience continuity, and the team can operate without reconstructing history from personal inboxes.