Public Reply or Internal Note? Decide Who Needs the Message Before You Write It.

A customer waiting through a sign-in outage doesn't need every detail of the technical investigation. They need to know that the team understands the problem, whether they should do anything, and when they will hear more.

The engineer working on the same incident needs a different message: what has been observed, which cause is still only suspected, and what comparison could test it. Sending both readers the same paragraph may overload one while leaving the other unable to act.

Jira Service Management provides a public reply for the customer-facing conversation and an internal note for the team's work. The choice is about purpose as well as visibility. Two messages can tell the same truth without containing the same detail. [1][2]

The team knows enough to communicate before it knows the cause

Consider a hypothetical outage. The sign-in failure has been reproduced. An engineer suspects the morning deployment because the timing matches, but the team hasn't established causation. The customer has been waiting since the first report.

Waiting for a complete diagnosis would keep an important confirmed fact from them: the team can reproduce their problem and is investigating it. Conversely, calling the deployment the cause would turn a hypothesis into an explanation too early.

Here is a public reply that keeps those distinctions intact. The 14:00 checkpoint is illustrative, not a real service commitment:

We've reproduced the sign-in problem and are investigating it. You don't need to repeat the steps you've already sent. We'll update this request by 14:00, even if the investigation is still in progress.

The customer now has something useful. The issue is recognized, earlier effort won't be repeated unnecessarily, and another update has a time. Nothing in the message promises a fix by 14:00.

An internal note could support the investigation behind that update:

The failure began after this morning's deployment, but we haven't established causation. Please compare the affected sign-in path before and after the change. Record the result before the 14:00 customer update so the next message reflects what we've learned.

This draft asks for a specific comparison. It doesn't require the engineer to infer what “please investigate” means, and it doesn't let the tentative explanation become a fact simply because the note is internal.

The channel is a separate check

The wording cannot correct a message posted to the wrong audience. Mentioning a colleague doesn't make a public reply private. An internal note addressed warmly to the customer still doesn't become a public update. In JSM, the selected response type matters independently of whom the prose appears to address. [2]

Internal notes also need restraint. A new resolver benefits from the relevant hypothesis and supporting evidence; credentials or unnecessary personal information don't belong there merely because the requester cannot see the note. Copying a large collection of unrelated logs can make the essential comparison harder to find.

For the outage, I would keep the two accounts connected rather than identical. When a technical finding changes the customer's next action, available workaround, or expected timing, it should reach the public conversation in language that helps them. The team may know a usable workaround before it knows the full cause.

A promised update has to survive an unfinished investigation

The hardest part of the public draft may be the last sentence. Somebody has to send the 14:00 update even if the comparison is inconclusive. Otherwise a message intended to reduce uncertainty creates another missed expectation.

A later shift should be able to see that commitment and the current state without asking the customer to start again. The record is doing useful communication work when it preserves both what the person already supplied and what the team has promised to return.

The next update might simply explain that the suspected cause remains under investigation and identify the next agreed contact. That is less dramatic than announcing a fix, but it can still be dependable. The customer should not need to wait for perfect technical certainty to receive an honest account of what happens next.