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 in the inbox: open Inbox → Conversations in the sidebar and switch to the Tickets tab. It covers every source and channel in one place: the web widget, email, and messaging channels alike. Existing store-scoped /app/<storeId>/tickets links redirect to /app/<storeId>/inbox?view=tickets on the app host after sign-in. A bare /tickets URL on the marketing site is not a ticket queue.

When a ticket opens

Zubby mints a ticket from four handoff paths, and every path produces the same kind of record:

• Shopper request in the widget - the shopper asked for a human, or for a money action (refund, cancellation) the AI isn't allowed to perform. The flow is email-first: if no email is on file, the AI asks for one and records it before the ticket opens, so the case always has a follow-up address when the shopper is willing to share it. See human handoff.
• 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…) 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.

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

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 unless the creating path supplies another priority. Automatic low-confidence and widget shopper-request handoffs start high; ungrounded knowledge-gap handoffs explicitly start medium. Messaging-channel human requests start medium, while money-action and complaint requests start high. Failed order-action tickets also start high. Set priority from the row as you learn more; the source label alone does not establish urgency.

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.

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 merchant team members with ticket access, 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.

A simple daily routine that keeps the queue honest:

1. Set SLA targets once under Settings → SLA - without them, nothing tells you a ticket has waited too long.
2. Open the Open tab and work breached and soonest-due tickets first; the SLA indicator sorts that out visually.
3. Reply in the linked conversation or channel thread, then set the ticket to pending (waiting on the shopper) or resolved - an accurate status is what makes the dedupe and SLA math trustworthy.

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.created outbound 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 Conversations tab and manage the case state in the Tickets tab.

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