Support
Where tickets come from
A shared email address, the chat widget, the customer's own link — and why an out-of-office reply must never open a ticket.
A ticket is the same record whatever way it arrived, and the channel it came in on is kept because it changes how you answer. What differs between the channels is only how the first message gets here and how a reply gets back.
Email at a shared address
Point the desk at a connected mailbox — see setting up the desk — and writing to it opens a ticket. Somebody's reply threads back onto the ticket it belongs to, and an agent replying here sends from that address, so the customer sees one conversation rather than two.
The default for an unrecognised message is the opposite of the CRM's
On somebody's personal mailbox, a message the CRM does not recognise is ignored — logging everything would put a dentist appointment on a client record. At a support address it becomes a new ticket, because that is what writing to support@ means. Same plumbing, one inverted default, and it is the difference between the two features.
Threading is on the message identifiers the mail itself carries, not on the subject line, so a customer who edits the subject still lands on their own ticket. The subject is used as a fallback: the reference in [#412] … is the belt to the headers' braces, for the mail clients that strip them.
Reply prefixes are stripped when a subject becomes a ticket title — Re:, Fwd:, and the localised ones your customers actually send: AW:, RV:, TR:, Re[2]:. Stripped by a bounded loop, because a mail loop can prepend hundreds of them and unbounded work on text a stranger controls does not belong on an inbound path.
A message with no subject at all is a real thing people send. It becomes a ticket called *(no subject)* — which is what every mail client shows for it — rather than a blank row somebody has to open to find out what it is.
Out-of-office replies and bounces do not open tickets
This is not politeness. Their automatic reply answers your acknowledgement, yours answers theirs, and by morning the queue has four hundred tickets in it and is unusable. The standard autoresponder headers, the no-reply and bounce address conventions, and the usual subject prefixes are all recognised and ignored. It is the one place on the inbound path where erring towards ignoring is right: a missed bounce costs nothing and a loop costs you the desk.
The mailbox is checked every three minutes rather than every ten like the CRM's. A reply nobody sees for ten minutes is a note on a timeline; here it is a customer waiting, and the clock has been running since the message reached the provider.
Sending, and what happens when it fails
A reply that could not be sent does not fail the reply
The message is recorded, the clock has moved, and the agent has done their part — so the reply stands. But the failure comes straight back to the screen rather than being swallowed, because believing a customer has been answered when they have not is the exact thing this whole path exists to prevent.
The chat widget
A conversation on your website can be handed to the desk when it turns out to need a clock and a queue — from the chat inbox, with one action. The visitor's address becomes the requester where they left one.
The transcript is not copied
The ticket points at the conversation and the conversation points back. Two copies of one exchange drift the moment somebody adds to either, and then nobody can say which is the record. It is also why the chat inbox was built narrow: it folds in rather than needing to be unpicked.
The customer's own link
Every ticket carries a link the requester can open without an account, and anything they add there arrives as a message from them — see what the customer sees.
Any message from the customer reopens a finished ticket
Whether it came by email, through their link, or from chat. Their writing again is the reason to reopen, and the alternative is a message filed against a resolved ticket that is in nobody's queue. There is one place that decision is made rather than one per channel, so the three cannot drift apart about whether the clock started again.
By hand
For anything that arrived another way — a phone call, a conversation in a corridor. The ticket carries the customer's words where they were relayed, attributed to whoever actually said them.
Raise a ticket on the queue asks for the subject, what they said, how it arrived and who asked. The requester is optional — a ticket for somebody you have no record of is still worth having — and where you name one, their company is resolved here rather than taken from the form, because the company is what decides which SLA policy applies and the two must not be able to disagree.
The channel is asked for and never assumed
How something arrived changes how it is answered and is the first thing anybody counts. A form that quietly filed everything as *raised here* would make that number a lie.
From a form on your website
A hosted form can open a ticket as well as creating a contact — per form, and off by default, because most forms are not support requests. A newsletter sign-up raising a ticket would put a response-time promise on somebody who asked for a PDF.
- The ticket's subject is the form's own title, because that is what the visitor thought they were filling in. Taking the first line of their message and calling it a summary is how tickets end up named after half a sentence.
- Every answer becomes the message, labelled — which product, which version, which office. An agent who had to open the CRM to read the other half would answer without the details.
- A held spam submission never raises one. That would put an SLA clock on a robot and fill the queue with exactly what the spam check exists to keep out.
- A form that opens a ticket is refused unless it collects an email address. A ticket is answered by replying, and one whose requester left only a mobile number is one an agent can answer nowhere.
- A ticket that could not be raised — no states configured, say — never fails the submission. The visitor has done their part and their answers are stored either way.