When a conversation needs more than one reply.
Some questions are answered in ninety seconds. Others need a refund approved, a carrier chased and a person to own it until Thursday. Those need a ticket — attached to the same conversation, in the same inbox.
- Works inside the inbox
- SLA timers and warnings
- Email follow-up built in
One click, and the conversation gets a spine.
Nothing is retyped and nothing is lost. The transcript, the customer record, the order and the channel come across with it — the conversation simply gains an owner, a deadline and a status.
- Convert any conversation from website chat, WhatsApp, Instagram, Messenger or email.
- The thread stays live. Keep chatting in the same window while the ticket runs underneath it.
- Every change is logged — who reassigned it, who raised the priority, and when.
- Link related tickets so a recurring problem reads as one story rather than four separate complaints.
Enough structure to be useful. Not enough to be a project.
Six statuses and four priorities cover almost every support team we have met. You can rename them, and you can stop there.
Statuses
Where a ticket is right now
- Open — Received and waiting on your team. Everything starts here.
- In progress — Someone owns it and is working on it right now.
- Waiting on customer — The clock pauses. Nobody gets blamed for a reply that never came.
- Waiting on a third party — A carrier, a supplier, another department. Visible, so it is not forgotten.
- Resolved — Answered and closed, with the resolution written down.
- Reopened — The customer came back. Reported separately, because it matters.
Priorities
What it should push in front of
- Urgent — Something is broken or money is stuck. Short SLA, escalation on breach.
- High — Blocking the customer, but there is a workaround for today.
- Normal — The default. Most things live here and that is fine.
- Low — Requests, suggestions and questions with no deadline attached.
- Set by rule — Priority can be assigned automatically by tag, plan, channel or keyword.
- Changed by hand — Anyone with permission can raise or lower it, and the change is logged.
SLA timers · open tickets
3 policiesFirst response · Urgent
Target 15 minutes · started 09:21
Resolution · High
Target 8 hours · 6h 12m elapsed
First response · Normal
Target 4 hours · 4h 38m elapsed
Timers pause outside your business hours and while a ticket is waiting on the customer, so the number on the screen is one your team can actually be measured against.
A deadline is only useful if it warns you first.
A breach report tells you what you already failed to do. Chatdrill puts the timer in the queue while there is still time to act on it — and escalates before the deadline, not after.
- Separate targets for first response and full resolution, per priority and per team.
- Business-hours calendars per region, so a Friday evening ticket does not breach overnight.
- Warnings before the deadline — in the queue, in Slack, on mobile, or all three.
- Breaches recorded, not hidden, with the reason attached so the fix is a change rather than a scolding.
Received, triaged, assigned, resolved, confirmed.
Five states, in one direction, with a person responsible at every one of them.
Received
A chat, an email or an API call arrives. The customer record, the channel and the full transcript come with it.
Triaged
Tags, priority and an SLA target are applied — by rule where the rule is obvious, by hand where judgement is needed.
Assigned
It lands with a team or a named person. Round robin, by language, by plan, or by whoever is actually online.
Resolved
The answer is written into the ticket, not just said in a chat. Attachments and internal notes stay on the record.
Confirmed
The customer is told, and can reply. If they do, it reopens with everything still attached — and it is reported as a reopen.
Nothing sits in a queue with nobody's name on it.
Unassigned work is how tickets die quietly. Rules give every ticket an owner the moment it arrives, and take it somewhere else if that owner runs out of time.
- Route by team, language, plan or channel — or round robin across whoever is online.
- Load-aware assignment so the fastest agent does not silently absorb the whole queue.
- Escalate on time, not on temper — at a percentage of the SLA, on reopen, or on a low rating.
- Handover keeps the context, so Tier 2 never asks the customer to start again.
A ticket is a place for your team to think out loud.
Most of the work on a hard ticket happens between colleagues. If that conversation lives in private messages, the next person to open the ticket inherits nothing.
Internal notes and @mentions
Ask a colleague inside the ticket instead of in a private message the next person will never find. Notes are never visible to the customer.
Collision detection
See when someone else is typing on the same ticket, before you both send the same answer forty seconds apart.
Follow-up by email
Continue a chat by email when the customer has closed the tab. Their reply comes back into the same ticket rather than starting a new one.
Attachments and screenshots
Files sent in chat, added by an agent, or pulled from an email all live on the ticket, not in someone's downloads folder.
Escalation paths
Move a ticket to Tier 2, engineering or billing with the history intact, so the customer never repeats themselves.
History on the customer record
Every ticket is attached to the contact. Open a profile and you can see what they have asked before, and how it ended.
Everything else ticketing covers.
Views and queues
Filter by status, priority, team, tag or SLA state, and save the result as a queue people work from.
What teams ask before switching over.
No, and you should not. Most chats are answered and closed in a few minutes and never need a ticket. Convert the ones that will outlive the conversation — anything waiting on a refund, a carrier, a bug fix or another department.
The reply threads back into the same ticket, with the message history intact. Your team answers from the inbox as usual, and the customer keeps a normal email conversation on their side without ever seeing an inbox of ours.
Yes. Create one by hand, forward an email into it, or open one through the API when your own system detects a problem. A ticket created that way behaves identically — same statuses, same SLA timers, same reporting.
Each SLA policy is tied to a business-hours calendar, so timers pause when you are closed and resume when you open. You can run separate calendars per team or region, and you can set a policy that runs around the clock for urgent work.
You choose. Typically the ticket is flagged in the queue, priority is raised, the assignee and their lead are notified, and the breach is recorded for reporting. Warnings fire before the breach as well, which is the part that stops it happening.
They see what you tell them. Status changes can be sent as a chat message or an email, and the resolution is always sent when you close it. There is no separate portal to log into, because most people will not.
Give the hard conversations an owner and a deadline.
Ticketing sits inside the same inbox your team already works from — there is nothing new to log into.
No credit card required.