Tickets and Conversations

What is a ticket?

A ticket is a support request from a customer. It has:

• A subject (derived from the email subject or chat opening message)
• A status: processing, open, pending, snoozed, resolved, or closed
• An assignee (an operator or unassigned)
• A channel (email inbox or chat widget the ticket came through)
• Tags for categorisation
• A customer record linked automatically by email address

Status meanings

Ticket lifecycle (email)

This lifecycle describes email-originated tickets. Widget (chat) tickets follow a different, simpler path — see Widget tickets below.

Received → Processing (hidden from inbox)
            │
            ├─ AI can draft           → Open        → Pending → Resolved
            │  (operator reviews/sends)
            │
            ├─ AI auto-sent reply     → Pending     → Resolved
            │  (autoReply=on, high confidence — skips the inbox)
            │
            └─ AI escalated to human  → Open        → Pending → Resolved
               (autoReply=on, low confidence; canned ack sent)

1. Received — Ticket0 ingests the email via Resend's inbound webhook
2. Processing — Ticket is created but hidden from the inbox. In the background, a worker classifies the ticket, searches the knowledge base, and decides whether to draft, auto-send, or escalate. Typical duration is a few seconds; there's a safety sweep that promotes any ticket stuck here after 5 minutes.
3. Open — Ticket appears in the inbox. If the AI produced a draft, it's pre-populated in the composer. The operator edits and sends, or writes from scratch.
4. Pending — Set automatically after any reply. If the customer responds, the ticket flips back to processing so the AI pipeline re-runs against the new message, and ends up either back in the inbox as open with a fresh draft or — if autoReply is on and confidence clears the threshold — auto-answered and moved to pending again.
5. Resolved — Marked resolved, hidden from the main queue. If the customer replies within the auto-close window, the ticket re-enters processing so the AI takes a fresh look at the new message before it surfaces back to an operator.
6. Closed — Resolved tickets auto-close after the workspace's retention period, or an operator can close immediately. Closed tickets can't be replied to.

Auto-reply mode

When autoReply is enabled in AI Agent → Features, the Processing step diverges into two auto-send paths depending on what the AI decides:

• High-confidence draft — the AI sends the reply itself and the ticket goes straight to Pending. It never appears in the default inbox. Find these tickets by filtering the list to Pending, or watch the AI Activity reports. The outbound message is tagged with an AI attribution banner so the customer knows it wasn't reviewed by a human.
• Escalation (AI can't draft safely) — the AI sends a canned acknowledgement ("Thanks for reaching out. A member of our team will get back to you…") and the ticket stays in Open so a human can follow up. A handoff summary note is added internally with the AI's reasoning.

Auto-reply applies on every customer message, not just the first one. If a customer replies to an AI-sent answer, the follow-up re-enters processing and the AI can auto-send again as long as:

• No human has replied on the ticket (any operator reply permanently locks AI out of the thread),
• Confidence on the new draft still clears the threshold,
• The ticket hasn't produced more than 5 AI auto-sends in the last hour (runaway-loop guard for non-compliant auto-responders — if this trips, the ticket falls through to Open for human review),
• The ticket hasn't produced more than 20 AI auto-sends over its lifetime (hard ceiling — if the AI hasn't resolved the issue in 20 turns, an operator needs to take over).

With autoReply off, neither auto-send path fires: the AI may still pre-populate a draft in the composer, but nothing leaves Ticket0 until an operator clicks Send.

Auto-responder inbounds are ignored

When an inbound is detected as an auto-responder (RFC 3834 headers, vacation replies, non-delivery reports, mailing-list bots), Ticket0 threads the message into the conversation so you still have the full audit trail — but the ticket's status doesn't change and no operator notification fires. The ticket stays in whatever state it was in (usually pending) until the customer's real, human reply arrives, which transitions and notifies as normal.

This does two things: operators stop getting pinged by out-of-office bots, and any AI ↔ auto-responder loop is broken at the source (the ticket doesn't re-enter processing, so the proactive-reply worker never runs on the auto-reply). The per-hour and lifetime rate limits above are a defense-in-depth backup for bots that don't set proper RFC 3834 headers.

See AI feature toggles to turn autoReply on, and Confidence thresholds to tune when the AI is allowed to send.

Widget tickets

Tickets created by the chat widget take a shorter, synchronous path — the AI answers in-session, not via the email draft/auto-send pipeline:

• The ticket is created in status="open" immediately; there is no processing state and no proactive-reply worker job.
• AI generates a response synchronously inside the HTTP request that delivered the customer's message, so the customer gets an answer in the same round-trip.
• Widget is AI-only by design. Operators don't chat through the widget — if the conversation needs a human, the AI offers escalation in-chat and a follow-up email ticket is created on confirmation.
• None of the email-path gates apply here: no autoReply workspace flag, no confidence threshold on responses, no per-ticket rate-limit caps. HTTP-level rate limits (per-IP and per-session, in the widget message route) cap abuse but don't gate AI economy.
• Widget sessions are subject to separate widget quality monitoring — a nightly evaluator scores completed sessions for accuracy, completeness, hallucination, and circular responses so quality regressions surface even without operator involvement.

See Chat widget AI for the widget's response flow, identity verification, and escalation UX.

Conversations

Each ticket has a single conversation thread — a chronological list of messages between the customer and your team. Messages can be:

• Inbound — from the customer
• Outbound — replies from agents or AI
• Internal notes — visible only to your team, never sent to the customer

Snoozing

Snooze a ticket to hide it until a future time. This is useful for "follow up in 3 days" scenarios. Snoozed tickets reopen automatically at the scheduled time.

Tags

Tags are free-form labels you can apply to tickets for filtering and reporting. They can be applied manually or by AI classification rules.