Email Help Desk Ticketing: Turn a Shared Inbox Into a Ticket System

How an email help desk turns a shared support inbox into tickets with owners, statuses and history, plus a six-step setup and the mistakes that make email tickets messy.

By Suhep Team · 29 October 2026 · 7 min read

Most small teams start support the same way: a shared inbox such as support@ or help@, a few people with access, and a habit of replying when someone has time. It works until the first week it does not. Two people answer the same message, a customer waits four days because everyone thought someone else had it, and nobody can say how many requests came in last month.

An email help desk fixes that without asking customers to change anything. They still write an email. Behind the scenes, every message becomes a ticket with an owner, a status and a history. This guide explains what changes when you move from a shared inbox to email ticketing, what to set up first, and the mistakes that make email tickets messy.

Shared inbox vs email help desk: what actually changes

None of this requires a large team. A single founder benefits from the first two points on day one, because a ticket list is a to-do list that cannot lose a message.

How email becomes a ticket

The mechanics are simple. Customers write to your public support address. That address is connected to the help desk, usually by forwarding the mailbox to the help desk's inbound address. The help desk creates a ticket from the sender, the subject and the body. When your team replies from the ticket, the customer receives the reply by email, and in a typical help desk the customer's answer is matched back to the same ticket.

In Suhep, email is one of the ways a ticket can be created. Tickets can also come from the support form at suhep.com/tickets, from the chat widget when the AI cannot resolve a question, or from an agent creating a ticket on a customer's behalf. Suhep's help article on setting up your first ticket notes that the Email channel is included on every plan, Free included, and that forwarded emails become tickets where inbound forwarding is enabled for your workspace. If you want email tickets, confirm that inbound forwarding is switched on for your workspace before you point your support address at it.

Set up your email ticketing in six steps

You can do all of this in an afternoon.

1. Choose one public address. Pick a single address, such as support@yourdomain, and publish only that. Every extra address (sales@, info@, a founder's personal inbox) is another place where requests can hide. If you must keep others, forward them into the same help desk.

2. Decide your categories. Keep them few and tied to who will act on them. A typical set is general, billing, technical, feature request and bug report, which is the default list in Suhep's ticket settings. Start with fewer categories than you think you need; you can always split one later.

3. Decide your priorities. Suhep uses low, medium, high and urgent. Write one sentence for each that a new teammate could apply without asking. For example, "urgent: the customer cannot use the product or has been charged incorrectly." Our guide to P1 to P4 priority levels and SLA targets has worked examples you can adapt.

4. Choose who gets what. Suhep's ticket settings include auto-assignment, which routes tickets to agents by category. Even if you use it, agree on a fallback owner for anything that does not match, so no ticket sits unassigned.

5. Set the customer emails. Customers should know you received their request, and they should hear when you reply and when the ticket is resolved. In Suhep, customers receive email when a ticket is created, when an agent replies, when the status changes to resolved or closed, and when a ticket is escalated. You can turn each type on or off under Settings, and customise the sender name and reply-to address. See ticket email notifications for the details.

6. Send a test. Email your support address from a personal account, watch the ticket arrive, reply from the ticket, check that the answer reaches your inbox, then answer it and see where your reply lands. Know how your setup behaves before customers find out. Do this before announcing the address anywhere.

The daily routine for an email ticket queue

Writing replies that work in email

If you use AI suggestions, treat them as a draft. In Suhep, when the AI has analysed a ticket you can see its suggested reply and confidence score, use the suggestion to fill the reply box, edit it, and then send. A person stays in charge of what the customer receives.

Six mistakes that make email tickets messy

1. Several public addresses with no owner. Requests arrive in places nobody checks.
2. No fallback assignee. Tickets that match no rule stay invisible.
3. Replying from a personal mailbox. The conversation leaves the ticket, and the history is lost. Always reply from the ticket.
4. Never closing tickets. A list full of finished work hides the real queue. Resolve when the problem is fixed.
5. Ignoring spam and automated mail. Out-of-office replies, newsletters and bot messages inflate the count. Our guide to stopping spam tickets without losing real customers explains how to filter safely.
6. No target for the first reply. Without a number, nobody notices slow replies. See what first response time is and how to measure it.

Moving from your shared inbox without losing anything

You do not have to migrate old mail. Pick a day, point your public support address at the help desk, and keep the old inbox open for a week for stragglers. Reply to any old threads from the ticket system when customers write back. Tell your team that from that day, nothing is answered outside the ticket. After two weeks, review the first numbers: how many tickets came in, how long the first reply took, and which category was largest. If you are new to the whole idea, how a ticketing system works is a good companion read.