From a shared inbox to support tickets.

A shared inbox is fine until it starts losing replies. The moment to move to support tickets is when the inbox can no longer answer three questions: who is handling this email, has it been answered, and how long has the customer waited. Once those answers depend on someone remembering, you have outgrown the inbox.

A shared inbox is a single mailbox, such as support@ or info@, that several people open at the same time. It works because it is simple: everyone sees the same list, replies land in the same place, and there is nothing to learn. The trouble is that an email is either read or unread, and "read" tells you nothing about whether it was actually dealt with, who took it, or whether a colleague is already typing the same answer.

Support tickets keep the email feel but give each message an owner, a state and a history. The customer still emails the same address and still gets a normal reply. Behind the scenes, that email becomes a ticket somebody is responsible for, with a clear status and a timer, so nothing depends on memory or a flag a colleague might miss.

The biggest worry about leaving a shared inbox is breaking the address customers already use. Forwarding-first setup removes that risk. You keep support@ exactly as it is and point it at Solves, so customers email the same place and your team simply picks the work up as tickets.

In practice the move is small. You create a brand for the identity customers write to, add that mailbox, and follow plain-English steps to forward incoming mail and add the DNS records that let replies send correctly. Live sending from Solves stays blocked until the mailbox is verified or a founder override is recorded, so nothing goes out half-configured.

You do not have to migrate history to start

A common reason teams put the move off is the fear of a big, risky data transfer. You do not need one. You can go live by forwarding new mail and working it as tickets from day one, leaving your old inbox archive where it sits. Bringing historical tickets across from another helpdesk is a guided, pilot-stage step we help with during setup, not a self-serve bulk import you run today.

What changes for your team, and what does not

For customers, nothing changes: same address, normal replies. For your team, each email arrives as a ticket with a state such as New, Open, Waiting for Customer, Snoozed, Resolved or Closed, an assignee, a priority and tags. You work from saved queue views, reply in the customer thread or add a private note, and let the SLA timer track the wait. It is the inbox you know, with the ownership it never had.

Not every team should switch, and we will not pretend otherwise. If you are one or two people handling a light, predictable flow of email, and you rarely trip over each other, a shared inbox is simpler, cheaper and perfectly good. Adding ticket states before you need them is just overhead.

The honest test is the three questions again: can you still say who is handling each email, whether it has been answered, and roughly how long people wait? If the answer is yes most days, stay where you are. Tools should follow the problem, not lead it, and a shared inbox that is keeping up is not a problem.

Signs you have already crossed the line

You have probably crossed it when double replies stop being rare, when you find unanswered email from days ago, when nobody can answer "how fast do we reply" without guessing, or when a second brand or mailbox arrives. At that point a shared inbox is quietly costing you replies and trust, and tickets are the cheaper option, not the heavier one.

You do not have to leap to a contact centre

Switching to tickets does not mean buying a sprawling platform with chat, phone and social channels you will never staff. Solves is email-first on purpose: it adds ownership, states, SLAs and multi-brand to the support email you already run, and stops there. That is usually the right next step up from a shared inbox for a small UK team, not a leap into a contact-centre suite.