How Jira Service Management Reply-to-Customer Actually Works
A "Reply to customer" comment can end up in the wrong place two different ways, and it's easy to blame the wrong one. The visibility mistake is the one most people mean: an agent picks Comment internally when they meant Reply to customer, or the reverse, and internal-only and customer-visible sit one click apart in the comment box. The second failure has nothing to do with that tab. The comment is marked correctly and still doesn't reach the right person, because Jira Service Management doesn't send it to whoever emailed in. It sends it to whoever the ticket's Reporter field and request participants list say the customer is.
That second cause is the one that surprises people, because nothing about it looks like a mistake. The comment box worked exactly as designed. The ticket's data just didn't match reality.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe comment box itself: two modes, one click apart
Every comment on a Jira Service Management request carries a visibility flag. Atlassian's own documentation for the service-project comment view describes the choice as Comment internally, visible only to other agents and collaborators on the project, or Share with customer, visible to the reporter and any request participants, per Atlassian's editing-and-collaborating documentation. Cloud's issue view uses the more familiar labels Internal note and Reply to customer for the same split. "Reply to Customer" is the exact phrase a Jira Service Management admin used when describing her own confusion with the feature on the Atlassian Community forum.
The mechanism is simple on purpose. It's a toggle on the comment, not a rule about the content, and nothing scans what an agent types and reroutes it. If the wrong tab is selected when the comment is submitted, that's where it goes, full stop, and a fast-moving support queue produces exactly that mistake often enough for it to have its own name in most JSM admin's vocabulary.
The mistake that isn't a mistake: who counts as "the customer"
The less obvious failure sits one layer up. A correctly marked "Reply to customer" comment is delivered to the request's Reporter field and its request participants, and only those people. In the community thread cited above, an admin named Susan Merola asked what happens when her team's integration sets a shared account as the Reporter instead of the actual person who wrote in, wondering whether that would change who receives replies. Fellow community member Marc answered directly, explaining that JSM "take[s] the reporter as the customer. So when replying to customer to user set in the reporter field and request participants are sent the notification," and adding the sharper consequence, that "the initial reporter of the ticket can't see the ticket on the portal if the sender of the email is not the reporter."
In other words, "Reply to customer" doesn't mean reply to whoever this request is about. It means reply to whatever the Reporter field currently holds, plus anyone explicitly added as a request participant. Any integration, mail handler, or manual field edit that sets that field to something other than the real requester quietly breaks the loop, and it breaks it in a way that produces no error message. The reply sends. It just lands with the wrong recipient, or with someone who can't act on it.
What that looks like on a support queue
Instride Payroll sells payroll and benefits software to staffing agencies, and Naomi Castellano runs support operations there. Instride's support inbox forwards into Jira Service Management through a mail handler app, and for tickets that arrive that way, the app's own service account gets set as the Reporter, with the sender added as a request participant by a second automation rule, when that rule fires correctly.
A staffing coordinator named Deb Whitfield emails support asking why a terminated employee still shows active in the benefits sync. The mail handler creates JSM-2841, reporter set to the app's service account, and the participant rule that's supposed to add Deb as a request participant silently fails, because her email domain isn't on the allowed list the rule checks against.
Naomi (in the ticket, replying to customer): "Hi, I checked the sync log and found the issue, it should clear within the hour. Let me know if it's still showing after that."
Deb (an hour later, a new email to support): "Following up on my email from this morning, nobody's responded, and this employee is still showing as active in three places."
Naomi's reply went out exactly as marked, "Reply to customer," and it went nowhere Deb could see it, because Deb was never a request participant on JSM-2841 and isn't the Reporter. The ticket has a complete, correctly visible thread. The one person who needed to read it doesn't have portal access to it.
Once Naomi traced the cause, she pulled every ticket the mail handler had created that week, checked the request-participant list against the sender's email, and manually added anyone the rule had missed. She also flagged the domain allowlist gap to whoever owns the automation rule. It worked, and it was a one-off manual sweep, not something that scales past a handful of tickets a week.
The limits of catching it after the fact
Naomi's sweep is the same fix most teams eventually build by hand, comparing after the fact who the ticket says the customer is against who the customer actually is, then patching the gap. It holds up at low volume. It runs into the same three walls every manual reconciliation does:
- It's reactive. Someone has to notice a customer complained about silence before the participant gap gets found; there's no standing check that catches it at ticket creation.
- It doesn't cover comments made correctly. A perfectly good "Reply to customer" comment, sent to the right participant, still leaves no record outside JSM of what that customer was told. If the same customer also emailed a CSM directly or complained in a shared Slack channel, nothing connects the three.
- The Reporter/participant mismatch recurs by design. As long as tickets keep arriving through an integration that sets a service account as Reporter, the gap reopens on every new ticket unless the automation itself gets fixed, and most teams have more than one integration doing this.
That third point connects to a related failure mode worth checking directly. If your team routes JSM requests into a development project when engineering picks up the work, moving the original ticket breaks the same portal access this section is about, covered in how to convert a JSM ticket into a development issue without losing the thread.
Where we'd put Modem
This is the point where we build Modem. Modem's Jira Service Management integration reads a request's public replies and internal notes as they're written, and it identifies the person behind each request from whatever contact information JSM returns for that ticket, whether or not the Reporter field points at the right person. The customer-facing thread lands in a topic tied to that person and their company, so support, engineering, and CS can all see exactly what a customer was told and when, without depending on the request-participant list being correct at ticket creation. Modem is what we build and sell, so read this part as a pitch: the manual sweep above already covers a small queue running one or two well-behaved integrations, and there's no reason to build more than that until it stops holding up. The mechanics of pulling that thread out of a JSM ticket in the first place are covered in the best Jira Service Management feedback tools.
Run this against last month's tickets
Pull a sample of tickets your integrations created in the last month, and compare the Reporter field and request-participant list against who actually sent the original message. If more than a handful don't match, that's not an agent-training problem, and no amount of reminding people to pick the right comment tab will fix it. It's an automation rule quietly deciding who your customer is, and it's worth fixing at that rule before the next reply goes out to the wrong address.
