Support
Working a ticket
Replying, internal notes, canned replies, who it goes to, merging two tickets about one problem, and escalating the fix.
One page, one conversation, and the two clocks along the top. Everything an agent does to a ticket writes an event in the same transaction as the change itself, which is what lets the clock be reconstructed rather than stored.
Replying, and internal notes
Two buttons under one box rather than a tick box you set and forget. The difference between a reply and an internal note is the difference between the customer hearing from you and not, and a setting that persists between replies is one somebody eventually sends a private note through.
| Reply | Internal note | |
|---|---|---|
| Sent to the customer | Yes | No |
| Shown on their link | Yes | No |
| Counts as the first response | Yes | No |
| Visible to colleagues | Yes | Yes |
Answering claims the ticket
Replying to an unassigned ticket assigns it to you. An explicit claim step is one nobody performs, and then every ticket is nobody's — the same call the chat inbox makes.
Canned replies
The paragraphs your agents type every day, saved once and picked from the reply box. They are inserted rather than replacing what is there: somebody has usually written a sentence of their own before reaching for the standard one, and replacing the box would throw it away with nothing to undo it.
They arrive already filled in — the requester's name, their company, the ticket number and subject, your own name — merged on the server so there is only ever one thing deciding what a filled reply looks like.
An unfilled field stays visible rather than blocking you
A ticket raised by somebody with no contact record has no name to put in, so {{firstName}} stays in the box and is called out. That is deliberately gentler than CRM email, which refuses to send: a marketing message is merged as it leaves and never read again, while this text lands in a box you are looking at and about to edit.
A canned reply carries no subject of its own. The ticket's subject holds the reference the customer's mail client threads on, and replacing it would split the conversation in their inbox.
Linking a help article
Search the help centre from inside the reply box and drop a link in. It inserts a full web address rather than a path, because the reply leaves this site — and a dead link in a support reply is worse than no link, since the customer concludes the answer does not exist.
Who it goes to
A new ticket is routed to the least-loaded agent who is actually present. Somebody on approved leave is skipped, because the desk can see the leave — that is the half a standalone help desk cannot do, and it needs no synchronising because it is the same database.
Where everybody is out, the ticket is left unassigned
Rather than handed to somebody on holiday. An unassigned ticket is a visible problem; one assigned to somebody away looks handled and is not, and looking handled is how it gets missed. An explicit assignment somebody made by hand is never overridden.
Least-loaded rather than round-robin, deliberately. Round-robin distributes tickets evenly and workload unevenly, because the agent stuck with three long-running problems keeps receiving new ones at the same rate as everybody else.
Separately, tickets whose target expires before their agent is back are flagged. Nobody is doing anything wrong in that case — the ticket is simply going to be missed, and somebody can move it now. It is narrow on purpose: one they will be back in time for is not stranded, and a register where everything is flagged is one nobody reads.
Moving it along
Pick any state. There is no matrix of permitted moves — every desk that has one produces an agent who cannot record what actually happened, and the workaround is always closing the ticket and opening another, which destroys the history. The only two refusals are on the service desk page, and both exist to stop a number being met by changing a dropdown.
Two tickets about one problem
Somebody writes in, does not hear back quickly enough, and writes again — from another address, or with a different subject. Two tickets, one problem, two clocks, and two agents answering the same person without knowing it. Merging puts the conversation back in one place.
The number the customer is holding keeps working
A merge is not a delete. The ticket you merged away stays as a record pointing at the survivor: its number still resolves, its link still opens, and a reply through it still reaches you. That number has already been quoted in an email somebody is holding, and a dead reference reads as your losing their report.
- The messages move; the clocks do not. Each ticket was measured against its own arrival, and folding one history into the other would restate a figure that has already been reported. The survivor's clock is exactly what it was.
- The merged ticket is closed, so its own clock stops. Left running, the desk would go on reporting a breach nobody is failing to answer. It is not surveyed either — asking somebody to rate a duplicate is asking them to rate silence.
- Recorded time follows the conversation, except where an invoice run has already locked it — that stays where it is, because moving it would change what a client was billed against. You are told how many.
- A chain never forms. Merge A into B and then B into C, and A points straight at C — always one step, never a trail to follow.
- You cannot merge into a finished ticket. A live conversation folded into a closed one stops being answered, and nothing on any screen would say so.
Nothing is ever suggested automatically
Candidates are the other open tickets from the same requester or their company, and that is as far as it goes. Two tickets that read alike are routinely two different problems described in the same words, and a desk confident enough to merge on a guess destroys one of them — found weeks later in a thread containing a conversation that never happened.
One more thing the merge is careful about: where the two tickets were raised by different people, the link you sent the first one no longer opens the conversation. It says the two were put together and that replies still reach you — because a link sent to one customer must never become a key to another's thread.
When it needs actual work
Escalation is a link, never a conversion
A reported bug points at a work item and the ticket stays open with its clock running while the fix enters a sprint. Turning one into the other would make *how long the customer waited* and *how long the fix took* the same number, and those are two different people's questions.
Search for the item from the ticket, or paste its key. Unlinking is one click, and the search runs the same ranking the global search box does rather than a second one — a picker with its own idea of relevance would disagree with the search on the next screen.
How long it took
Record time against the ticket as you go — 1h30, 90m or 1.5, typed the way people say it. The total is shown with the billable share beside it, never instead of it: showing only billable minutes makes internal work look like time nobody spent.
The desk records; the invoice prices
Hours recorded here reach a client through pricing work, which reads them via the ticket’s own company because a ticket belongs to no project. What a contract says an hour is worth — a retainer, block hours, an included allowance — is answered in contracts and allowances, where an agent can also see whether a ticket is covered before spending two hours on it. See Time tracking.