Email-to-ticket: how it works and how to set it up
Email-to-ticket turns each message sent to a support address into a ticket, and adds later replies to the same ticket. The parts to get right are threading, unknown senders, automatic replies and the address that replies come from.
How it works
A ticketing system gives you a mailbox address. Mail sent to that address is read by the system, which creates a ticket from the first message and attaches the sender as the requester. When your team answers from the ticket, the reply goes out by email. When the requester answers that email, the system matches the reply to the original ticket instead of opening a new one.
The usual way to connect an existing support address, such as support@yourcompany, is forwarding. You keep publishing the address you already use, and your mail provider forwards a copy to the ticketing system's mailbox.
What a good setup handles
- Threading. A reply must land on the right ticket, so test that a requester's answer joins the conversation, and decide what should happen when they reply to a ticket that was already resolved or closed.
- Unknown senders. Decide whether a message from an address you have never seen becomes a ticket at once or waits for review. Review is safer for a public address that attracts junk.
- Automatic replies and loops. Out-of-office messages and bounces can create tickets or even bounce back and forth. A good system recognizes automatic mail, and you should test it once with an out-of-office reply.
- Reply address. Replies should come from an address people recognize. Sending from your own domain needs the domain to be verified, so that the mail passes the checks receiving servers make.
- Defaults for new tickets. The mailbox should be able to set the team, type and priority, and the client, so mail for one customer does not need manual sorting.
- Attachments and signatures. Attachments should arrive, and long signatures and quoted history should not make the thread unreadable.
A safe way to start
- Create the mailbox and send a test message from a personal address. Confirm that a ticket appears with the right sender and subject.
- Reply from the ticket and confirm the reply arrives, and that your answer to it lands back on the same ticket.
- Forward a copy of your real support address, and keep the original inbox working for a week while you compare.
- Once you trust it, tell your team to answer from the queue and retire the old inbox as a working place. The shared inbox guide covers the move in more detail.
Setting it up in ActiveQ
- Go to Settings, then Channels, then Mailboxes, and choose New mailbox. A workspace has a default mailbox and can have up to 20. ActiveQ gives each mailbox an address on its own mail domain.
- The New mailbox dialog explains how to forward your own support address from Google Workspace or Gmail, Microsoft 365 and other providers. ActiveQ does not log in to your inbox and read it.
- A mailbox can set the team, the organization, a default type and a default priority for new tickets.
- Unknown senders either get a contact created or are held in quarantine, where a person decides what to do with them. The Channels page also lists blocked and suppressed senders.
- Replies can come from the mailbox address or from an address at a sending domain you have verified.
- A new requester can get an optional automatic confirmation that their message arrived.
- When someone replies to an email ActiveQ sent, the reply joins the same ticket. If the ticket was resolved, the reply reopens it. If it was closed, the reply starts a new ticket.
Email is one of two channels, along with the client portal. Each ticket gets a live countdown to its response and resolution targets, as described in SLA management.
Before you forward mail
Mail reaches ActiveQ by forwarding to a mailbox address it gives you. ActiveQ can’t guarantee delivery to every provider, so verify your sending domain and test with a real address before you rely on it.