Conversations

A conversation is a record with a status, an assignee, and optional links to the customer, product and campaign it came from.

Each message inside it carries an author kind and an ordered list of structured parts. That second part is the design decision worth understanding: a reply can attach a product, an order or a coupon as a real thing, instead of pasting a URL into the text.

The inbox lives at:

Messages
/admin/messages

It requires the tickets:view permission.

Status and assignment

A conversation is in one of three statuses:

• Open
• Resolved
• Archived

It can be assigned to a staff member, and it stores the time of its last activity.

That timestamp is written in the same transaction as the message, so inbox sorting cannot fall out of step with the messages themselves. A thread cannot show at the top of the queue with nothing new in it, or sink out of sight while carrying an unanswered question.

Only a message from the customer reopens a resolved or archived thread.

A staff reply or a system event bumps the last-activity time without resurrecting a closed ticket. This is the difference between a queue you can trust and one that fills back up every time a shipping webhook fires against an order you already dealt with.

Five kinds of author

Every message declares who wrote it:

1. Customer
2. Staff
3. System
4. Assistant
5. Note

The last one is not a person. note is an author kind in its own right, which is what makes internal notes behave correctly rather than being a styling choice.

Internal notes

A note is internal, and two separate rules keep it that way.

The customer-facing resolver drops notes before it builds the customer's payload. The note is removed at the point the customer's view is assembled, not hidden by the interface that displays it.

A note also does not count as a reply. Jotting one leaves the thread showing as still waiting on you — which is right, because it is. The customer has not heard anything.

Nine kinds of part

Beyond the text body, a message can carry any of these:

• Text
• Product
• Order
• Coupon
• Suggestion
• Image
• Event
• Quote — an earlier message, quoted
• Campaign application

Parts are stored as an ordered JSON array on the message itself rather than in a separate table, and are resolved for display on the server.

The consequence for you is that an order attached to a reply is the order, not a snapshot of it. The customer sees its real state when they open the thread.

Approvals inside the thread

A campaign application part shows approve and reject to staff while it is pending, and shows the live status to the collab.

There is no separate review page. The application is reviewed where the conversation about it is already happening, and the collab watching the thread sees the decision without being emailed a link to somewhere else.

One conversation, two views

The admin inbox and the customer's view read the same conversation and the same messages.

The records behind it are Conversation and Message. There is not a support-side copy and a customer-side copy to reconcile — there is one thread, resolved differently for each audience, with notes dropped on the way out.

A thread loads its most recent 30 messages and pulls older ones in as you scroll up.

Sending twice

A message can carry an idempotency key.

When a send is repeated — a double click, a flaky connection, a retried request — the original message is returned instead of a second one being posted.

Replies email the customer. Inbound messages email your staff. So a duplicate send is not a cosmetic problem: without the key, it is a second email into somebody's inbox.

The AI draft

With an AI provider key set, the inbox offers two extra controls:

• A drafted reply, grounded in the customer's profile and the real state of any order attached to the thread
• A task assistant chat

With no key set, neither control is rendered. There is no disabled button advertising a feature you have not configured.

The draft's grounding is the point. It is not writing from the message text alone — it is reading the actual order attached to the thread, so it does not confidently tell a customer their parcel shipped when it did not.

Working the inbox

A question arrives from a product page, an order, or a campaign application.

The thread opens with the customer, the linked record and the conversation history already attached, so the context is not something you assemble by searching for their email address.

Reply with text plus a product, coupon or order part where a link would otherwise do — or leave an internal note that the customer never sees.

Then resolve or archive. A new customer message reopens it; nothing else will.

When deciding between a note and a reply, use the rule the system already applies:

A note is for the next person on your side of the conversation. If what you have to say changes what the customer should do, it is a reply — and until you send one, the thread is still yours.

Related