Support Tickets

When an AI agent receives a customer support request, Zeiko creates or links a durable support ticket. The ticket tracks the customer, source channel, priority, SLA state, email thread, internal notes, Shopify context, and any human handoff activity.

Ticket linking is conversation-scoped, not customer-email scoped. If the same customer starts a new support conversation later, Zeiko creates a new ticket for that new conversation instead of reviving an older resolved handoff thread just because the email matches.

Human handoff events still exist, but the ticket is now the primary support record. Humans use the inbox as an exception and audit console while support agents continue managing most replies and closures automatically.

What Creates a Ticket

• A customer starts a support conversation in the website widget
• An agent requests human handoff from a live conversation
• A customer emails a tenant support alias
• A customer replies to an existing ticket email alias
• A Shopify support scenario needs durable follow-up, such as an order issue or policy exception

Viewing Tickets

1. Go to Agents → Handoff Inbox in your workspace.
2. You'll see a tickets-first split pane:
   • left queue led by customer, intent, latest message, escalation reason, waiting time, and reply/SLA state; ticket number and channel remain available as secondary context
   • center conversation with grouped customer, agent, and teammate messages; dates, unread customer activity, and compact system events separate the thread without repeating metadata on every message
   • right facts rail with compact ticket metadata, SLA dates, Shopify order context, and a link to the original handoff thread when one exists

The Operator brief stays immediately above the composer. It summarizes what the customer wants, why the AI escalated, the recommended next action, verified facts, missing information, and the work the AI already attempted. Detailed AI evidence remains expandable so the conversation stays primary.

Ticket statuses are:

• open
• waiting_on_customer
• waiting_on_team
• resolved
• closed

Ticket priorities are:

• low
• normal
• high
• urgent

Responding to Tickets

1. Click on a ticket to view the full conversation history.
2. Review what the customer asked and what the agent attempted.
3. Reply to the customer by email, add a private internal note, take over, reopen, close, or force close.
4. Open the linked handoff context if the case originated from a live widget handoff.

The composer is pinned to the conversation and keeps one clear send action. Macros, attachments, follow-up timing, and draft review appear progressively when they are relevant. Replies appear optimistically with Sending, Delivered, or Failed state; failed sends can be retried without rewriting the message.

Choosing Join live chat from the ticket console writes the same live handoff state as the dedicated handoff thread before opening the transcript, so the customer immediately sees that a human has joined and normal bot replies stay muted.

The ticket thread supports:

• customer-visible email replies
• internal notes that stay private to operators
• agent-authored replies and audit events
• human takeover and closure controls
• Shopify order context when available

The legacy live handoff conversation page is preserved for linked handoff context during migration. It still refreshes from both realtime events and a fallback live refresh path, so it stays current even if a realtime insert is delayed or missed.

Live Mode

Live Mode is the support team's routing state. An operator selects Go live in the Handoff Inbox and chooses one of four states:

• Available — receive new escalations until the configured capacity is reached
• Busy — stay online without receiving new escalations
• Wrap-up — finish active conversations without receiving new escalations
• Offline — stop receiving live escalations

Available status is heartbeat-backed and expires when the operator leaves unexpectedly. An operator at capacity is treated as busy for routing even if Available was selected. If every operator is offline, busy, wrapping up, or at capacity, new requests stay in the durable queue instead of being assigned to a nominal team member.

The queue routes available operators by urgency, SLA, required skills, language, routing strategy, and capacity. Claiming is atomic: if two people try to join the same conversation, only one receives ownership. The customer sees the teammate's name when the claim becomes an active live chat.

While an operator is online, the Live Mode shelf shows active conversations against capacity, the current queue wait estimate, and shortcuts back to assigned conversations. A newly routed escalation appears in context with the customer, reason, and time already waiting, so the operator can enter the thread without leaving the inbox.

During human ownership, the AI is muted in the public conversation and remains available privately for summaries, verified context, resolution planning, and reply drafts. The assigned operator can either resolve the ticket or choose Hand back to AI. Hand-back ends human ownership without closing the customer conversation.

Customers remain in the same widget conversation throughout. When the team is live, Zeiko may show a capacity-based estimated wait. It never promises an exact queue position because priority routing can reorder the queue. When nobody can route, the widget honestly explains the team's availability, preserves the request, and shows the configured response window.

Fast Switching and Mobile

Selecting another ticket updates the inbox URL without replacing the inbox shell. Queue filters, selected view, drafts, queue width, and per-thread scroll position stay in place while uncached messages and details load. Zeiko keeps a small thread cache and prefetches likely next tickets so normal queue work feels immediate. Browser back and forward restore the selected ticket.

On mobile, the inbox is a stack instead of three compressed columns: Tickets → Conversation → Details. The header always provides the appropriate back step, Live Mode status remains visible, and the composer stays reachable at thumb height in the conversation view.

Email Aliases

Zeiko uses Resend inbound email aliases for support automation:

• support+{accountSlug}@{RESEND_INBOUND_DOMAIN} creates a new support ticket for the tenant
• ticket+{ticketKey}@{RESEND_INBOUND_DOMAIN} appends a reply to an existing ticket

Ticket emails include reply-to aliases, ticket headers, Resend tags, and idempotency keys so customer replies stay threaded to the right case.

Outbound ticket email uses RESEND_SUPPORT_FROM_EMAIL when it is configured, then falls back to RESEND_FROM_EMAIL and the shared EMAIL_SENDER value. React Email ticket templates send both HTML and a plain-text alternative when both are available.

Configuring Handoff Settings

When creating an agent (via the Support Wizard), you can configure:

• Strategy — How handoffs are assigned:
  • Round Robin — Distribute evenly across team members
  • First Available — Assign to whoever picks it up first
• Assignee Emails — Team members who receive handoff notifications
• Max Open Assignments — Limit how many active handoffs each person handles
• Skill Keywords — Route handoffs based on topic (e.g., billing, shopify, integrations)

Support-team member skills can also declare language coverage with normalized tokens such as language:en, language:es, or language:nl. Live routing prefers an available operator with the customer's base language and then applies the topic skill and configured workload strategy. If no matching language specialist is online, the request remains eligible for the general live team instead of being stranded.

Those assignee emails are also used by the ticket-backed handoff flow so routed owners receive a notification even when the case began as a new durable support ticket.

At the moment, the Support Wizard's handoff routing config applies to Website Widget conversations. Treat the widget as the canonical live-chat handoff surface, and treat support tickets as the canonical cross-channel case surface.

Customer Experience During a Live Handoff

When a human teammate has joined a Website Widget conversation:

• the customer stays on the same chat thread
• the customer sees the live-human state immediately after the operator joins
• follow-up customer messages continue to persist into that thread
• operator replies and customer follow-up messages stay visible in both the widget and operator thread
• the system does not add fake bot queue/offline replies on top of a live human-owned thread
• CSAT is shown only after the handoff is resolved
• the handoff is linked to a support ticket for SLA tracking, email follow-up, and audit history

The public widget and the internal support bubble now use the same underlying conversation client, so refreshes and human replies stay in sync more reliably.

That shared client also handles:

• stable request IDs and canonical snapshot refreshes so fast multi-turn chats stay in order
• a labeled internal support launcher that does not claim the whole app document theme or lock page scrolling
• local offline queueing and automatic replay for customer messages when connectivity drops
• delayed assistant typing indicators so the interface feels responsive instead of blocked
• the same markdown/rich-text rendering path used by the public widget, including guardrails for very large streamed replies
• a shared history model between the widget and bubble, which keeps operator and visitor views aligned across refreshes

Best Practices

• Check the ticket queue during your team's normal response windows
• Configure Resend inbound and support-team notification emails so ticket replies and handoffs do not go unnoticed
• Use internal notes for audit context instead of sending operational details to customers
• Review the AI Learning Inbox instead of copying raw conversations into agent instructions

AI Learning Inbox

Every completed, human-handled thread is eligible to become a tenant-scoped learning observation after Zeiko verifies that the human response was customer-visible. The learning pipeline redacts PII before clustering repeated questions and proposing a knowledge article, procedure, or routing change.

Raw human replies are audit evidence, not authoritative policy. A one-time concession stays ticket-specific, and a policy claim cannot be promoted without an approved business source. Managers review each evidence-backed proposal in the AI Learning Inbox before it can progress through evaluation, approval, shadow testing, canary, and promotion. Promoted learning remains versioned and can be rolled back.