Support tickets
Tickets are first-class case records — a status, priority, assignee, and SLA — minted whenever a shopper needs a human. They turn a one-off handoff into something your team can track, triage, and close. The queue lives at Dashboard → Tickets and covers every source and channel in one place: the web widget, email, and messaging channels alike.
When a ticket opens
Zubby mints a ticket from three handoff paths, and every path produces the same kind of record:
- AI low confidence — the agent hit its confidence threshold on a non-trivial question and escalated rather than guess. These default to high priority.
- Merchant manual escalation — a teammate escalated a conversation from the inbox detail view.
- Channel handoff — a shopper on an async channel (WhatsApp, SMS, Instagram, Messenger, Telegram…) asked to “talk to a human,” detected by intent.
A QC gate on AI answers can also open a ticket when a reply fails a quality check. Whatever the source, the ticket carries a per-store ticket number, the originating channel, the requester (name, email, or channel handle), and a subject derived from the conversation summary or intent.
One open ticket per conversation or thread
The AI does not move money
The queue
Tickets are grouped under four status tabs — Open, Pending, Resolved, Closed — newest first, up to 100 per tab. Each row shows the ticket number and subject, status / priority / channel / source badges, an SLA indicator, the requester, when it was created, and who it is assigned to. If the ticket came from a web conversation, the row links straight to that transcript.
Statuses
| Status | Meaning |
|---|---|
| Open | New, needs attention. The default landing tab. |
| Pending | In progress — waiting on the shopper or an internal step. |
| Resolved | Answered. Stamps a resolved timestamp. |
| Closed | Done and filed. Also stamps the resolved timestamp. |
Moving a ticket to resolved or closed records when it was resolved; reopening it (back to open or pending) clears that. Open and pending are the “still active” states used for dedupe and SLA tracking.
Priorities
Four levels — low, medium, high, urgent. New tickets default to medium, except AI low-confidence escalations which start at high. Set priority per ticket from the row, or adjust it as you learn more.
SLA timers
Each ticket can carry two deadlines derived from your per-store SLA targets: a first-response due time and a resolution due time. The row shows the earliest still-relevant one — first-response while the ticket is unanswered, otherwise resolution while it is unresolved. A deadline in the past that has not been met shows as a breach with a warning marker; an upcoming deadline shows the hours remaining.
Set your SLA targets
Settings → SLA (first-response minutes and resolution minutes). Without targets, tickets simply carry no SLA badge. Business- hours math is applied by the weekly digest rather than the live timer.Triage and assignment
Every row has inline controls — no separate detail screen needed:
- Status — pick a status and click Set.
- Priority — pick a level and click Set.
- Assignee — assign to any teammate with access to the store, or leave it unassigned, then click Assign.
- Bulk status — the bar above the list sets a status across every ticket shown in the current tab at once (handy for clearing a backlog to resolved).
Triage actions are limited to owner, admin, support, and super-admin roles, and every status, priority, assignment, and bulk change is written to the audit log. Tenancy is enforced on every action — a ticket from another store cannot be mutated even with a forged ID.
Notifications
Opening a ticket fans out two side effects so the right people know:
- An in-app notification(“New support ticket #N”) that links back to the ticket.
- A
ticket.createdoutbound webhook carrying the ticket ID, number, source, channel, and originating conversation — wire it to Slack, your helpdesk, or anything custom.
Tickets vs. the inbox
The two surfaces are complementary. The inbox is where you read and reply to the live conversation; the ticket is the durable case record wrapped around it (status, SLA, assignee) so nothing falls through the cracks across channels and sessions. A widget ticket links to its transcript; you reply in the inbox and manage the case state here.
Gotchas
- Ticket numbers are per store and allocated atomically, so they are sequential within a store but not globally unique.
- Channel-handoff dedupe is keyed on the requester handle — a shopper who messages from two different numbers will get two tickets.
- No SLA targets means no SLA badge. If you expect timers and don't see them, set targets under
Settings → SLA. - Tickets are created best-effort: if a ticket fails to mint, the conversation still escalates and is handled — the case record just won't appear.
Related
- Human handoff — what triggers a ticket and how the rep takes over
- Inbox — replying to the conversation behind a ticket
- Conversations
- Audit log — where triage actions are recorded