Helpdesk & Tickets

The Helpdesk is where asynchronous work lives. When a conversation can't be resolved while the visitor is on the page — a refund that needs approval, a bug someone has to reproduce, a question that needs a person who isn't online — the agent raises a ticket, and your team works it later from /helpdesk.

Helpdesk

Work asynchronous tickets from a shared queue

Open in TIA

Choose a queue and narrow the ticket list

Start with active, assigned, unassigned, mentioned, or solved work, then filter by agent and priority.

Search for and open the right ticket

Find a subject, requester, or ticket number in the middle column, then open it to see the full thread.

This is a different job from Live Handoff, and the two are deliberately separate surfaces:

Use Live Handoff when a human should join the conversation happening now. Use the Helpdesk when the answer will take longer than the visitor is willing to wait.

Turning it on

Helpdesk is a concierge module, included from the Growth plan.

1. Open the agent's Modules tab and enable Helpdesk.
2. Configure it in the module's settings card:

With the module enabled the agent gets a create_ticket tool. It calls it on its own when the conversation matches your When to use text — there's no "open a ticket" button in the widget.

Ticket statuses

Replying to a requester moves a ticket to on_customer automatically, so "who is this waiting on" stays accurate without anyone maintaining it by hand.

Where tickets come from

Every ticket records a source, which is worth filtering on when you want to know how much of your queue the agent is generating:

• ai_escalation — the agent called create_ticket mid-conversation.
• widget — raised from the widget directly.
• api — pushed in from another system via POST /api/v1/tickets or a Zap.
• email — inbound mail. Reserved; not yet delivered.
• manual — created by a teammate in the dashboard.

Replying to a requester

Open a ticket and reply from the detail view. The reply is emailed to the requester, not just stored.

A few properties of that email matter when you're setting expectations with your team:

• It threads. Each ticket has a synthetic root Message-ID, and every reply sets In-Reply-To and References against it. Gmail and Outlook collapse the ticket into one conversation rather than a pile of unrelated mails. This is built on RFC 5322 headers rather than a provider feature, so it works on whatever SMTP host you're configured against.
• The ticket number is in the subject, last: Re: Cannot log in [TKT-1042]. Trailing position is deliberate — mail clients truncate long subjects from the right in list views but preserve the full string, and putting the token at the end keeps the human-readable part visible.
• Delivery state is recorded on the message. A reply shows as pending, sent, or failed. A failure is rendered as Not delivered in red in the ticket view.

That last point is the one to brief your team on. A reply that was written, saved, and never delivered is worse than no reply at all, because everyone involved believes the customer has been answered. If you see Not delivered, the customer has not seen it.

Replies are sent after the response returns, so writing one never blocks on your mail host being slow.

Contact history

Every ticket with a requester email is linked to a Contact. The ticket detail view shows that contact's previous tickets, so you can see whether this is the third time someone has asked about the same order before you answer.

Working the queue

The /helpdesk queue is org-wide. Filter by agent, status, priority, category, or assignee, and save any combination as a Saved View.

Assignment is manual on Growth: pick the ticket, pick the owner. Automatic routing across teams — balanced or round-robin, with capacity caps — unlocks on Scale. See Teams & Routing.

Reacting to tickets elsewhere

Four ticket events fire to webhooks and to Zapier:

ticket.created · ticket.assigned · ticket.status_changed · ticket.replied

Use them to post new tickets into Slack, mirror urgent ones into Linear or Jira, or start an NPS survey when a ticket closes.

Best practices

• Write "When to use" as instructions, not a description. "Raise a ticket when the customer reports a damaged item, asks for a refund over $200, or reports something that looks like a bug" beats "raise tickets for support issues."
• Require an email if you intend to reply. Without one the ticket is a note to yourselves, since the reply path is email.
• Keep the category list short. Categories the agent has to choose between are useful; twenty of them are guesswork.
• Watch the "Not delivered" flag. Set up a ticket.replied webhook if you want that surfaced somewhere your team already looks.

Limits & notes

• Requires the Helpdesk module (Growth and up). POST /api/v1/tickets returns 402 on a plan without it.
• Inbound email — parsing customer replies back into tickets — isn't shipped yet. The [TKT-####] subject token is the hook it will use.
• Ticket replies go out over your configured SMTP transport.

Next steps

• Teams & Routing — auto-assignment, capacity caps, saved views.
• Contacts — the identity every ticket links to.
• Procedures — enforce the steps that must happen before a ticket is filed.
• Webhooks — push tickets into the rest of your stack.