Working a ticket

You work a conversation in the Inbox's thread pane, or on its full page at /tickets/(id), reached from the thread header's overflow menu (Open full page) or from the details pane. The two show the same conversation; the full page adds time logs, to-dos, the activity trail and the customer rail.

Replying and internal notes

The composer is docked to the bottom of the conversation. Two tabs set what your text becomes:

• Reply goes to the customer, on the ticket's channel.
• Internal note stays in Auralis. The placeholder says it plainly: the customer never sees this. Notes render on a tinted ground in the thread so they cannot be mistaken for replies.

Press the send button, or Ctrl+Enter (Cmd+Enter on a Mac).

On a channel that cannot deliver replies, the Reply tab is withheld entirely and a notice explains which step on the Channels screen would enable it. Internal notes always work. See Channels.

Your first reply on a ticket stops the first-response clock. If the ticket is open and you send a plain reply, it also moves to pending automatically, once per ticket.

Send and set a status

When a reply could legally change the status, the send button becomes Send and set Pending (or Solved, On hold, Closed, in that preference order), with a chevron offering the other legal choices and Send only. "Send only" sets no status of its own, though the open-to-pending first-reply rule above still applies.

Drafting with Auralis

The sparkle button in the thread header, Draft with Auralis, opens the Copilot panel: the Auralis section pinned at the top of the details pane (on narrow windows it arrives as a drawer). Click Draft a reply and the panel writes a draft grounded in your knowledge, shows the sources it used, and lets you regenerate or insert the text into the composer as a reply or an internal note. On a channel that cannot send, only the internal-note insert is offered. An unsent draft survives collapsing the pane.

Applying macros

The Macros picker sits in the composer toolbar. Applying a macro runs its actions on the spot: a prepared reply, an internal note, a status change, a priority change, a tag, or several of those together. The thread refreshes to show what the macro did. Applying a macro needs editor or above. See Macros and SLA.

Statuses and transitions

A ticket is in exactly one status. Five are live or terminal states you set yourself; the rest are set by operations.

What is legal from where:

• From open, pending or on_hold you can move to any of the other statuses in the table. The three live states move freely between each other and into the terminal ones.
• From solved, closed, spam or merged you can move nowhere by editing. Terminal means terminal; the interface only offers legal moves, and the API refuses the rest.
• Reopen is the one exit: on a solved or closed ticket a Reopen button appears in the full-page header (for roles that may reopen). It moves the ticket back to open, clears the solved and first-response marks, and restarts both SLA clocks from that moment. Spam and merged tickets cannot be reopened.

Two automatic movements worth knowing:

• Your first plain reply moves an open ticket to pending (see above).
• A customer reply moves a pending ticket back to open. A solved ticket stays solved when the customer writes again.

In the Inbox thread header, Put on hold and Mark as solved are offered only when they are legal from the current status.

Priority

Four levels: low, normal, high, urgent. In the queue only urgent and high carry a coloured dot, so the column stays readable. Set priority from the thread header's dot menu, the full-page header, or in bulk from the list. Priority decides which SLA policy stamps the ticket, so set it early.

SLA chips and Overdue

If an SLA policy matches the ticket's priority, the ticket is stamped with a first-response deadline and a resolution deadline at creation. The header shows a chip only when it matters:

• Due in 1h 20m (amber) when the governing deadline is inside two hours.
• Overdue 3h 12m (red) when a deadline has passed or a breach is recorded.

A quieter deadline shows no chip at all; the exact due times are always in the details pane's Conversation attributes. Overdue in the Inbox sidebar filters to tickets with a recorded breach. When a breach is recorded, the assignee is notified (or the whole team, if the ticket has a team and no assignee). Deadlines are wall-clock: parking a ticket in pending or on_hold does not stop its resolution clock. See Macros and SLA.

CSAT

Marking a ticket solved sends the customer a satisfaction survey, once: the request is recorded on the ticket, and if the customer has an email address they receive a message asking them to rate the experience from 1 to 5. The response lands on the ticket as a csat_response event and the score shows in the details pane and the full-page rail as stars out of five. A solved ticket with no response gets one reminder after 48 hours.

The full-page ticket view

/tickets/(id) is the same conversation with everything around it:

• The crumb row, with an Activity button and count. It opens the activity drawer: the audit trail of status changes, priority changes, assignments, tag changes, merges, SLA breaches, CSAT events and logged time, each as one dated sentence with who did it.
• The header card: subject, status pill (offering only legal next states), Reopen on solved and closed tickets, priority, the SLA chip, and the assignee control.
• The thread and composer, as in the Inbox.
• The context rail, with tabs. A ticket handed off by the AI opens on Copilot and carries the handoff brief inline in the thread; every other ticket opens on Customer. The rail holds:
  • Customer: email, company, country, since, channel, and any captured session facts (location, device, referrer, time on page, visit count).
  • Recent tickets: up to five others from this customer.
  • Tags, Properties (custom metadata), and To-dos: a checklist on the ticket; add, retitle, tick off and delete items.
  • Time logged: entries in minutes with a description and a billable flag, plus the running total. Logging time needs editor or above.
  • Satisfaction and Reopened, when the ticket has those facts.

Merging

Merging one ticket into another is an API operation today; there is no merge control on the ticket screen. A merged ticket shows the merged status and a merge event in its activity.