Tickets
A ticket follows work that does not end in the conversation.
A guest asks on Tuesday for a late check-out on her Friday stay. The conversation ends, everyone is happy. Friday comes and nobody did it. An inbox cannot hold that: a conversation is a thread, and a thread closes. The work, on the other hand, has a deadline, an owner, and a state that moves forward.
A ticket is not a second place to look. It is the conversation, promoted.
You do not leave the conversation to open a ticket, and replying from the ticket writes into the same thread your guest already knows. There is no path that opens a second discussion with the same person.
Five views, in the left column
The tickets page does not open on a raw list. The left column carries five views, each with its count:
| The view | The question it answers |
|---|---|
| My cases | What is on my plate? This is where a day starts |
| To handle | What is in progress across the team? |
| Unassigned | What has nobody picked up? |
| Overdue | What has passed its deadline? |
| All | Everything, including what is closed |
Status is not a view: it is one filter among others, next to type and priority. A status is not a question you ask yourself in the morning.
Opening a ticket
Three paths, depending on where you are.
| From where | How | What happens |
|---|---|---|
| From a conversation | The + button in the conversation header | The ticket opens immediately, its subject is filled from the conversation, and the button becomes the ticket number |
| From a conversation | The right-hand panel, ticket section, "open" | The same gesture, the same result |
| From the list | Tickets, then "New ticket" | A window asks for the subject, the type, the priority and the contact |
The two paths from a conversation ask no question: they open the ticket right away. That is intended. A form at the moment you only want to "not forget this" is a form you do not open. The subject, the priority and the owner are set afterwards, in the ticket, when you know them.
The title, and the AI that drafts it
A ticket opened from a conversation inherits your customer's first message, cut short. It is a good starting point and a bad title: "hi I have a small problem with my booking of the 14th and I..." does not read in a list and cannot be quoted out loud.
The wand button, next to the title, asks the AI to read the conversation and propose a title and a summary. It names the work to do, not what the customer said: "Move the booking from the 14th to the 16th".
It proposes, it does not write. You see the proposed title, the summary, and below it the title it would replace. Nothing changes until you accept. That is intended: the ticket's title reaches your customer when its state changes, and a text nobody has re-read must not be able to get there.
An AI key configured in Settings, AI models is required. Without it, the button tells you so instead of doing nothing.
What a ticket carries
The owner and the team. Both, and separately: a team answers for the queue, a person answers for this ticket.
The priority. Urgent, high, normal, low. It serves two purposes: sorting your list, and choosing the service commitment that applies.
The state. See the next section, it is the part that counts.
The deadlines. They are computed from the OPENING of the ticket, never from the last change. A ticket moved to urgent after six hours does not gain six more hours: it is the only way a service commitment can mean anything.
A description. One sentence written for a human, saying what it is about without having to re-read thirty messages. The thread tells the exchange; the description states the problem, and that is the difference between a ticket and a copy of the conversation.
The log. Every change of state, priority, owner and team is written there, with who did it and when. You will also find whether your customer was notified, or why they were not.
States, and the two audiences
This is the part of the model worth two minutes.
A state carries two labels: the one your team reads, and the one your customer reads. Your team sees "Waiting on supplier". Your customer reads "We are working on it". It is the same state. You do not show your kitchen, and you do not maintain two systems.
Every state belongs to a category, which is what the product reasons on: open, pending, resolved, closed. You can create as many states as your business needs inside a category, and name them in your own words.
This is set in Settings, Ticket states.
Notifying your customer automatically
Every state carries a "notify the customer" checkbox. When it is ticked and a ticket enters that state, your customer receives, in their conversation and in their language, a message giving them the customer label of the state.
What you should know before ticking it:
- The message goes into the existing conversation, not a new thread nor an email.
- Your customer cannot always be reached, and the product does not pretend. When the message cannot go out, the ticket's log records it, with the reason:
What the log says What happened the customer writes from the web widget, which has no return path The website widget is one-way: your AI agent answers there, nobody else can speak in it WhatsApp's 24-hour window is closed WhatsApp forbids free-form messages more than 24 hours after the customer's last message. An approved template is required the ticket is attached to no conversation The ticket was created from the list, without an originating conversation the inbox has no credentials for this channel The channel is not connected, or its connection has expired You see the line, and you decide. A message vanishing without a trace would let you believe your
customer informed.
- A bulk change notifies nobody. Selecting twenty tickets in the queue and resolving them at once says nothing to the twenty customers. That is deliberate: twenty sends in a row inside one action would break midway, and half the customers would be notified without anyone knowing which half. To notify, go through the state, ticket by ticket.
One ticket can cover several conversations
An outage makes thirty people write. Without grouping, that is thirty tickets: thirty states to move forward one by one, and no place that says where the outage stands.
In the ticket's Links section, Attach a conversation searches by customer name and adds the exchange to the ticket. Conversations already attached appear in the search, marked as such: they are not hidden, so you do not look for them in vain.
Two things to know:
- The originating conversation cannot be detached. It is what ties the ticket to its customer, and it is the one the product goes to in order to notify that customer of a state change. The others detach in one click, without confirmation, because the gesture can be redone.
- A ticket created from the list has no originating conversation. The first one you attach becomes it.
Every attachment and every detachment is written in the ticket's log, with who did it.
Replying to your customer from the ticket
The composer at the bottom of the ticket has two recipients, and you choose before writing.
Internal note: only your team sees it. It is the default, because a mistake in that direction costs nothing, while an internal note sent to the customer cannot be taken back.
Reply to the customer: the text goes into their conversation, exactly as if you had replied from the inbox. The composer changes its look when you are in that mode, so you see it while you type, not afterwards.
The same limits as above apply, in the same way: if the reply could not go out, the ticket's log says so, with the reason.
Closing a ticket
A ticket becomes resolved or closed through its state.
A rule will sometimes stop you: you do not close a refund without its transaction number. If the ticket type declares information required at resolution, it is demanded at that moment, not at opening. You fill in what you know when you know it, and the cause of an incident is not known the day the customer reports it.
It is also what keeps a queue from filling up with resolved tickets nobody can say anything about anymore.
When the AI opens a ticket
An agent can open a ticket by itself, without a team member stepping in. It is an agent automation, off by default: in the agent editor, Skills tab, Automations section, turn on Open a ticket. The switch exists for Messenger and Instagram agents as well as for the website agent, and it only appears if your workspace has the Tickets module.
What the agent knows about a ticket
It reads your ticket types and their fields (Settings, Ticket types): each type, its description, and for each field its key, its label, its shape (text, number, amount, date, choice from a list, yes or no), and whether it is required to open. That is how you "map" what the agent must collect: add a field to the type, tick required to open, and the agent asks the customer for it before opening. A field without a type applies to every type.
The rule that counts: no ticket while a required field is missing
This rule is held by the product, not by the agent's instructions. When the agent tries to open a ticket, the product checks the fields required to open for the chosen type:
- if one is missing, the ticket is not opened. The agent receives the list of what is missing, asks the customer, and tries again once it has it. It is instructed never to guess a value, and never to announce a ticket that does not exist;
- if a value is not acceptable (a choice outside the list, an amount that is not a number), the ticket is not opened either, and the agent corrects it with the customer;
- if everything is there, the ticket is opened with its fields filled, and the agent gives the customer its number.
One ticket per request: on Messenger and Instagram, a ticket already open in the conversation blocks the next one; on the website, a ticket opened in the last 24 hours for the same person and the same subject is reused.
What you see in the ticket
The ticket carries Opened by: AI, the chosen type, its fields filled in the fields section, the priority the agent judged, and its deadlines if a service commitment applies. On Messenger and Instagram it is linked to the conversation, and the thread shows "ticket opened by the AI" at the moment of the gesture. On the website, the conversation is not an inbox conversation: the ticket is attached to the visitor's contact card (the one the contact form created) and its description keeps the link to the exchange.
A ticket opened by the AI fires the same ticket.created event as a ticket opened by hand: your endpoints (Settings, Webhooks) receive it.
On the website, the contact card first
The website agent only opens a ticket for a known visitor: name and email at minimum, collected by the contact form. As long as the card is missing, it has no way to open a ticket; it is instructed to ask for contact details before promising a follow-up. A ticket without a requester would be a ticket nobody can call back.
What does not exist yet
Documentation that only says what works is not documentation, it is a brochure.
- There is no portal where your customer follows their tickets. They are informed in their conversation, and that is all.
- A ticket cannot be deleted. A ticket opened by mistake stays. It can be closed, never erased.
- Side conversations with a third party (writing to a supplier from the ticket) do not exist.