Replies and internal notes

Everything that happens to a ticket is recorded on one timeline, in order. That includes the messages, but it also includes every status change, priority change, assignment, tag change, time log, to-do, SLA breach, merge, split, snooze and reopen. When you open a ticket you are reading its whole history, not just the correspondence.

Of everything on that timeline, exactly two entries are things you write.

Replies and internal notes

A reply goes to the customer. It is the public half of the conversation and it is what the person who wrote in will receive.

An internal note does not. It is visible only to people inside your workspace, and it is where you put the context that helps the next agent: what you have already checked, what the customer said on the phone, why this one is unusual, who you are waiting on.

These are the only two kinds of message you can add, and the distinction between them is a property of the entry itself rather than a setting on the ticket. When you compose, you choose which one you are writing before you send it. Get into the habit of checking that control before you press send, because the difference between the two is the difference between a colleague reading your working notes and a customer reading them.

There are two safeguards worth knowing about, and one of them is a hard limit:

An internal note can be deleted. A reply cannot. If you write a note and think better of it, you can remove it from the timeline. A reply has already gone to the customer, so removing it from your view would only make your record disagree with theirs. If you send something you regret, the remedy is another reply, not a deletion.

Replies also have a side effect on your service levels: the first reply on a ticket stops the first-response clock. An internal note does not, no matter how much work went into it. If a ticket looks like it has breached its first-response target despite plenty of activity, the usual explanation is that the activity was all notes.

Replying and changing the ticket together

A reply can carry a status change with it, so that answering the customer and moving the ticket to pending is one action rather than two. The same transition rules apply as anywhere else, so a reply cannot push a ticket into a state it is not allowed to reach. Setting the status to what it already is does nothing rather than failing.

Who else appears on the timeline

Not every entry is written by a member of your team. Entries record what kind of actor produced them, distinguishing a member of staff, a customer, an AI agent and the system itself. This is why automatic assignments show up as system actions rather than as something a colleague did, and why an AI agent's replies are attributable as such rather than being mixed in with your team's.

Inbound messages that arrive from a channel — an email reply, a message from a connected messaging channel — land on the timeline in their own right, so a customer replying to your email appears in the thread rather than starting a new ticket.

Macros and canned responses

Two tools cut down the repetition.

A macro is a saved set of actions applied to a ticket in one step. A macro can send a reply and change the ticket at the same time — setting a status or priority, adding a tag, assigning a person, or routing to a team — and can also be set to fire automatically when a ticket is created or updated. Macros are covered in full in their own article.

A canned response is the simpler tool: saved text with no actions attached. Where a macro is "do these five things", a canned response is "here is the paragraph I always write".

The practical rule is to reach for a canned response first. It is easier to keep a library of good wording accurate than a library of macros whose side effects nobody remembers. Promote a canned response to a macro when you notice that everybody who sends that text also makes the same ticket changes immediately afterwards — that is the point at which the actions are genuinely part of the response rather than a coincidence.

For both, editors create and edit, and admins delete.