The Internal Note: What the Requester Never Sees
One checkbox on a support comment decides whether it reaches your customer, stops the first-response clock, notifies anybody, or leaves your server. Get the mental model right and your ticket threads become an audit trail. Get it wrong and you send an internal opinion to the person it was about.
Every support team has two conversations running about the same problem. There is the one with the customer, which is careful, and there is the one with each other, which is frank. On WhatsApp and email those two conversations live in different places, which is why they eventually collide: a reply-all, a forwarded thread, a screenshot pasted into the wrong window, and something that was true but not diplomatic arrives in front of the person it was about.
A ticketing system puts both conversations in one thread and separates them with a single boolean. That is a genuinely good design and it is also a sharp edge, because the entire protection is one checkbox that a tired agent ticks or does not tick at half past five. This article is about that boolean: what it controls, what it does not, and the four consequences that follow from it.
One flag, four consequences
A comment on a ticket is stored with a flag marking it internal or not. The flag does four separate jobs, and people usually know about the first one only.
A public reply
- Visible to the requester on every one of their surfaces — the self-service ticket page, the signed no-login tracking page for external customers.
- Stamps the first-response time if it is the first one. That single stamp is what your first-response SLA is measured against.
- Notifies the requester in-app if they have a login, or by email with a fresh signed link if they are an external customer.
- Notifies the watchers on the ticket.
- Confirmed back to the agent as Reply sent to requester — the wording is deliberate.
An internal note
- Never visible to the requester. Their views filter internal comments out at the query, not in the template, so there is no CSS accident that can expose one.
- Does not stamp the first-response time. Ten notes among yourselves leave the clock exactly where it was.
- Notifies nobody. Not the requester, not the assignee, not the watchers.
- Readable by every login with permission to see all tickets — it is internal, not private.
- Confirmed back to the agent as Internal note added.
The second consequence is the one worth pausing on, because it is the difference between an SLA that measures something and an SLA that measures typing.
Talking amongst yourselves does not count as responding. That is not a limitation — it is the only honest definition of a first response.
Why internal notes leave the clock alone
Who can see what, exactly
Four audiences, three surfaces, one rule. Being precise here is the whole point of the article.
| Who is looking | Where they look | Public replies | Internal notes |
|---|---|---|---|
| Agent with ticket permissions | The agent ticket view | Yes | Yes — the full thread |
| Requester with a login | Their own ticket page | Yes | No — filtered at the query |
| External customer | The signed tracking link | Yes | No — filtered at the query |
| Employee with no login | The tokenized support portal | No thread at all | No |
That last row is a real limitation and worth stating plainly rather than burying: the tokenized portal an employee without a login uses is submit and track only. They can raise a ticket, see its status, reference and category, and watch it move — but there is no conversation on that page. If a technician needs to answer a clarifying question, somebody has to reach them another way and paste the answer in on their behalf, which is honest work but it is manual work.
The internal thread as an [audit trail](/glossary/audit-trail)
Internal notes are usually described as a place to be candid. That undersells them. Because a comment cannot be edited or deleted once posted — there is no route in the application that does either — the internal side of a thread becomes the closest thing a support desk has to a contemporaneous record.
The system writes to it too. When an agent escalates a ticket into a project task, the escalation is recorded as an internal note naming the task it created. So the thread reads as a sequence: what the customer said, what we said back, what we thought, and where the work went when it turned out to be bigger than a ticket.
-
Write the note as though it will be read later, by someone who was not there
It will be. Six weeks on, when the same customer raises the same complaint, the internal thread is the only source that says what you actually tried. "Rang the supplier, no answer" is worth ten times "escalated".
-
Put facts in the note and judgements in your head
Not because internal notes leak — they do not — but because internal means every colleague with ticket permissions, today and in two years, including the ones who will be discussing this account with the customer.
-
Never put a credential, a PIN or an ID number in either kind of comment
A comment is plain text in your database and is included in an AI draft request if you use one. Reset the credential instead of recording it; see what leaves your server for exactly where a thread can travel.
-
Post the note before you change the status
A status change notifies the requester and the watchers. If the note explaining why comes after, anyone who follows the notification arrives at a thread that does not yet explain itself.
-
When the work leaves the desk, escalate rather than narrate
Escalating creates a linked project task and stamps its own internal note. That link is what lets you answer, three weeks later, "what happened to that?" without asking anybody.
Where teams sit on the candour spectrum
There is a real trade-off here and no single right answer. The more freely a desk uses internal notes, the better its record and the worse its exposure to a subject-access request or a discovery process. Kenyan organizations handling personal data have a duty to disclose what they hold about a person on request, and internal notes on a ticket raised by that person are data they hold about that person.
How candid should the internal thread be?
Everything, unfiltered
Fast, honest, useful in the moment. Also the version you would least like read aloud. One frustrated sentence about a customer becomes a document you are obliged to produce.
Facts and actions only
Where we think most desks should sit. What was tried, what was found, who was called, what is next. Dull to read and impossible to regret.
Nothing internal at all
Some regulated desks land here deliberately. The cost is real: the thread stops explaining itself, and the next agent starts from nothing.
Pick a position deliberately and write it into your desk's one-page working agreement, because the default position is not "facts only" — the default is whatever your most tired agent types at the end of a long shift. Read data protection duties for Kenyan business systems alongside this if you handle consumer data.
The two ways this goes wrong
In practice there are exactly two failure modes, and they pull in opposite directions.
The note that was meant to be a reply. An agent writes a careful answer, ticks internal by habit, and the customer hears nothing. The thread looks answered from the inside and silent from the outside. This one is common, invisible from the agent view, and the reason it matters is that nothing else in the system flags it: no notification was sent, so nobody is expecting one, and the first-response clock is still running with no badge yet to show it.
The reply that was meant to be a note. Rarer, worse, unfixable. There is no delete. The comment is now in the customer's thread, in the email they were sent, and in the record permanently. The mitigation is procedural rather than technical: on any ticket where the internal discussion is sensitive, decide as a team that the sensitive material goes in a note before anybody starts drafting a reply, so the two never share a text box in the same minute.
The control that actually helps
Make the reply-versus-note choice a visible part of your review, not a checkbox nobody looks at twice. Once a week, filter the queue to tickets that are open with no first response recorded, and read them. A ticket where the agent clearly answered but the clock never started is a note that should have been a reply — you will find them in seconds, and each one is a customer who is still waiting.
What we do and do not do
What AWRA OpsHub does today
- A per-comment internal flag, chosen by the agent, with different confirmation wording so the choice is visible at the moment it is made.
- Internal notes filtered out of every requester-facing surface at the query level — the self-service page and the signed no-login tracking page — so exposure cannot happen through a template mistake.
- First-response time stamped only by the first public reply, so internal discussion cannot flatter the SLA.
- Notification asymmetry that follows the flag: a public reply reaches the requester and the watchers, an internal note reaches nobody.
- Permanent comments — no edit, no delete — which makes the thread usable as a contemporaneous record.
- An automatic internal note whenever a ticket is escalated into a project task, naming the task, so the trail continues past the desk.
- Requester replies are always public by construction: no requester surface offers an internal option.
What it does not do
- No conversation on the tokenized portal. An employee without a login can raise and track a ticket but cannot see or add replies. Someone has to relay both directions by hand.
- No per-note visibility beyond the internal flag. Internal means every login with ticket permissions. There is no note visible to only the assignee, only a manager, or only one department.
- No canned responses or reply templates. Every reply is typed from scratch, or drafted by the AI copilot and then edited.
- No @mention of a colleague inside a comment, and therefore no mention notification — tickets use watchers for this, unlike project tasks which do have mentions.
- No warning when a public reply looks like it was meant to be internal, or vice versa. The flag is trusted absolutely.
- No attachment on a comment. Files attach to the ticket rather than to a message in the thread, so the connection between a file and the reply that discusses it is one you make in words.
The portal conversation gap is the one that costs real time on desks with a lot of field staff, and it is a contained piece of work — the tracking surface for external customers already does exactly this with signed links. If most of your requests come from people without logins, that is worth telling us.
A working agreement you can copy
Six lines to agree once, then hold each other to
- Anything the customer needs to know goes in a public reply. If you find yourself explaining something in a note, ask why they should not be told.
- Notes carry facts and actions, not opinions about people. Write what you did and what you found.
- No credentials, PINs, ID numbers or card details in any comment, internal or public. Reset, do not record.
- Note first, then status. The explanation should already be there when the notification lands.
- When work leaves the desk, escalate it rather than describing it, so the link is in the thread.
- Weekly: read every open ticket with no first response recorded. That list is where notes-that-should-have-been-replies hide.
Our take
The internal note is the most useful feature in a helpdesk and the least discussed, because it looks like a checkbox and behaves like a policy. It decides visibility, the SLA clock, who gets notified, and — if you use the AI copilot — what leaves your infrastructure. Treat it as a policy: agree in one paragraph what belongs on each side, write notes that you would be content to have read back to you, and audit weekly for the answer that never actually reached anyone. Those habits cost nothing and they are the difference between a thread that explains itself and a thread that merely records that something happened.
Read alongside this: who gets told maps every notification the flag controls, SLAs that mean something covers the first-response clock the flag starts, the support copilot explains how a drafted reply reads your internal notes, and a support portal people will actually use covers the customer side of the thread.
One thread, two conversations, no accidents
Internal notes filtered out of every customer surface at the query, a first-response clock only a real reply can start, and a permanent record you can read back six weeks later.
See tickets & queuesFrequently asked questions
Can a customer ever see an internal note?
Not through the product. Both customer-facing surfaces — the logged-in self-service ticket page and the signed no-login tracking page — filter internal comments out in the database query that fetches the thread, not in the page template. That distinction matters: a filter in the query means the internal text never reaches the rendered page at all, so there is no styling mistake, no view-source trick and no template regression that can expose one. What is not protected is anything you paste elsewhere: a screenshot of the agent view, or a copied thread in an email, carries whatever you copied.
Does an internal note stop the first-response clock?
No, and that is deliberate. Only the first public reply stamps the first-response time. Ten internal notes over two days leave the clock exactly where it was, because talking amongst yourselves is not responding to the customer. The practical consequence is worth knowing: a desk that discusses thoroughly and replies late will see that in its first-response figures, which is the correct outcome even though it is the uncomfortable one.
Can we edit or delete a comment after posting it?
No. There is no route in the application that edits or deletes a ticket comment, by design — a thread you can rewrite is not a record. The consequence is that a public reply sent in error cannot be withdrawn, only followed by another reply. If your desk handles sensitive matters, decide as a team that the candid material goes into a note before anyone drafts the customer-facing reply, so the two never get typed in the same minute.
Who exactly can read our internal notes?
Every login with permission to view all tickets — which on most desks means every agent and every supervisor, today and in future. The flag is *internal*, not *private*. There is no note restricted to the assignee, to a manager, or to one department, and we have not built one. Write accordingly: facts and actions rather than opinions about people, on the assumption that a colleague who will be dealing with this customer next month will read it.
Do internal notes get sent to an AI provider?
If you use the copilot, yes, and you should know it. The drafted-reply and summarise actions deliberately include internal notes in the prompt, because a draft written without the internal context is a draft that repeats questions you have already answered among yourselves. The suggested-triage action does not include them. All three only run when an agent presses the button — nothing is sent in the background — and nothing reaches a provider at all unless the deployment has enabled one. The detail is in [what leaves your server](/blog/ai-what-leaves-your-server-kenya).
Can an employee without a login reply to a ticket?
Not today. The tokenized support portal an employee without a login uses is submit-and-track: they raise a request and follow its status, reference and category, but there is no conversation on that page. Anything you need from them has to be collected another way and pasted into the thread on their behalf. External customers, by contrast, do get a full reply loop by email with a signed link, so the mechanism exists — it has simply not been extended to the staff portal yet. On a desk that runs mostly on field staff, this is the gap worth telling us about.
Is there a way to reuse a standard answer?
Not as canned responses, no — there is no template library and every reply is typed. What exists is the AI copilot, which drafts a reply from the thread you are looking at and hands it to you to edit, which covers some of the same ground but is not the same thing: a canned response is deterministic and reviewed once, a drafted reply is different every time and must be reviewed every time. If your desk answers the same six questions all day, a template library is a fair thing to ask us for and a small thing to build.
