Shared inbox or ticketing system: which does your support need?
The question is not which tool is better. It is whether your mail is a conversation or a job to finish.
Use a shared inbox when your mail is a conversation: sales questions, partners, the odd reply from a customer. Use a ticketing system when each email is a job that has to reach done: a bug, a refund, an account fix. Many small teams need both, one for each kind of address.
Here is how to tell the two apart, and how to run them side by side.
What a shared inbox is
A shared inbox is email that a team reads together. Everyone sees the same threads. A thread can be assigned to one person, so two people do not answer the same customer. When it is handled, it is closed.
It feels like email, because it is. Nobody has to learn a new way of working. The cost is that a plain shared inbox knows little more than open and closed. Some tools add a “waiting” state, but priority and reply clocks are rare.
What a ticketing system is
A ticketing system turns each request into a ticket. A ticket has a status, such as open, in progress, waiting or closed. It has a priority. It can have a response target, so a late reply shows up as late.
The customer still just sends an email and gets email back. The difference is on your side. You can ask “what is waiting on us, oldest first?” and get a straight answer.
The cost is more structure. For a quick back-and-forth with a partner, a status and a priority get in the way.
Five questions that decide it
- Does each email ask you to do something? A bug report or a refund request is a job. A “thanks, that worked” is not. Jobs belong in tickets.
- Do you wait on the customer often? If replies stall for days while you wait for a screenshot, you need a “waiting” status. Otherwise those threads look open and clutter the queue.
- Do some requests matter more than others? A checkout that is broken beats a feature idea. Priority is a ticket feature.
- Have you promised a reply time? If your site says “we reply within one business day”, you need a clock on each request. That is a ticket feature too.
- Is the mail mostly people you know? Partners, suppliers and investors do not want to feel like a ticket number. That mail belongs in a shared inbox, or in a person’s own inbox.
Two or more yes answers to the first four: your support address wants tickets.
The mistake: one tool for every address
Most small teams pick one model and push all their mail through it. Sales mail becomes tickets with statuses nobody updates. Or bug reports sit in a shared inbox, closed and forgotten while the bug is still there.
The fix is to decide per address:
support@andbilling@: tickets, with status, priority and a reply target.hello@andpartners@: a shared inbox the team reads together.- Your own address: a private inbox nobody else sees.
If you run several products, the same split works for each one. Every product keeps its own support address, and all of them land in one place.
Running both in one place
PimiDesk lets you decide per address. Each address on your domain feeds tickets, the shared inbox, or one person’s private inbox. Tickets get a status, a priority and response targets. The shared inbox stays plain email with assignment and tags. Customers only ever see an email from your own address.
If you want the longer story on why tickets help, read support ticket management: what it is and why it matters. For the case for a team inbox, read why your team needs a unified inbox for support.
This post is about PimiDesk, part of Pimi.