Internal Note or Customer Reply? Set the Audience Before Building a Shared Inbox
A shared inbox needs an explicit audience for every message: staff only, or the customer and the people included in that conversation. Do not treat an internal note as an ordinary reply with a different colour. Its recipients, attachments, notifications and export rules need their own controls.
For a small team, a useful default is to keep staff discussion internal and create a separate, deliberately reviewed customer reply. This guide helps specify that boundary. It is not a complete security design or a guarantee that an inbox product prevents every disclosure.
Name the audience where people write
The person composing a message should know its audience before typing and again before sending. Use clear wording such as “Internal note” and “Reply to customer”, not colour alone. Decide which mode opens by default and whether a new draft remembers the previous mode. Remembering a mode is convenient only if the next user understands what it means.
If someone switches an existing draft from internal to customer-facing, require a deliberate review of the text, recipients and attachments. Consider creating a separate reply draft rather than changing the original note's audience. That keeps an internal discussion from becoming an accidental outbound message.
Intercom's official reply-conversation documentation gives a concrete example of the underlying distinction: it describes replying with an admin message, on behalf of a contact, or with a note for admins. That supports treating notes and replies as different operations. It does not demonstrate every recipient or disclosure control your custom inbox will need.
Define who counts as “the customer”
A conversation can involve more than one person. Decide whether replies go only to the requester or also to copied recipients, other contacts at the same company or newly invited participants. Show the actual recipients instead of relying on a broad customer label.
In a hypothetical repair portal, the requester and a purchasing contact may both receive updates. That does not mean every employee at the customer's company should see the conversation. Define membership and access separately from which company the request belongs to.
Also decide whether adding someone gives them earlier customer-facing messages or only future replies. Do not assume that access to the next message should expose the entire history.
Attachments and previews follow the same boundary
An internal note can contain a screenshot, a cost calculation or a document link that should not leave the team. Require attachments to retain the intended access restriction when the note is reopened, searched or exported. A private-looking message is not enough if its file can be opened through an unrestricted link.
Notifications are another output. Specify which text can appear in emails, mobile previews and activity summaries. A staff-only note should not appear in a customer notification subject or snippet. A customer-facing reply that quotes an earlier internal passage needs review of the quoted text, not merely a correct audience setting on the new reply.
These are requirements for implementation and testing, not a claim that Intercom automatically enforces the proposed behaviour.
Make corrections honest about what has already left
Decide whether sent replies can be edited, replaced by a correction or only supplemented by another message. Whatever the interface permits, do not promise that editing the portal recalls a copy already delivered by email or saved by a recipient.
If a note was sent to the wrong audience, the team needs a named incident owner and a procedure appropriate to the information involved. Hiding the message afterwards is not proof that the disclosure was undone. Record the action taken without reproducing sensitive content in another widely visible log.
For ordinary text corrections, distinguish the current wording from any retained history according to your agreed policy. Keep staff accountability and customer communication clear without creating an unnecessary duplicate archive of private information.
Test the boundary from both sides
Write the following into your acceptance criteria and use fictitious accounts and harmless sample documents:
- Staff can identify the audience before entering and sending a message.
- Switching an internal draft to a customer reply triggers the agreed review.
- An internal note is absent from the customer's conversation, notifications, search and permitted exports.
- Its attachment cannot be opened by the test customer through a copied direct link.
- Adding a recipient exposes only the history the specification permits.
- Customer replies show the intended recipients and do not quote internal material inadvertently.
- A correction follows the stated policy without claiming delivered copies were recalled.
Those checks cover specific paths, not the whole security of an inbox. Ask the developer to review the remaining interfaces and integrations as part of the access-control scope.
When discussing a customer portal or workflow app, bring a redacted example of an internal discussion and the short reply a customer should receive. The useful feature is not simply two message colours. It is a reliable boundary between those two conversations.
Source and limits
Intercom, Reply to a conversation: https://developers.intercom.com/docs/references/rest-api/api.intercom.io/conversations/replyconversation
The source supports the distinction between reply types and notes for admins. Default modes, audience changes, attachments, historical access and correction handling above are proposed product requirements, not verified promises about Intercom or a statement of legal compliance.