Service Management and Customer Management

Choose who reads it — internal note or customer reply

On a Jira Service Management or Customer Service Management request, a comment is one of two different things. An Internal note is seen by agents only. A Reply to customer reaches the customer and emails them. They are never the same sentence, and on a batch of twenty-five that difference is the whole job.

Every request starts on Reply to customer. That is the default because an agent bulk-commenting on a service project is usually answering customers, and an internal note is the exception. Switch a request to Internal and it stays there — the default is only ever applied to a request you have not decided on yet, so it cannot come back and undo your choice.

So every service-project composer carries the choice in its header. It is per request, not per send — one run can answer three customers and leave two notes for the team. Issues from Jira and Jira Product Discovery have no such distinction and show no control; their comments are simply comments.

Yellow means internal, everywhere — the toggle, the tint on a comment box, the badges in comment history and the badges on the results screen. The accent colour is anything the customer receives. It is Jira’s own convention in the service project issue view.

Put both on one request — a reply and a note

Answering a customer usually leaves something to record that the customer should not read: what actually caused it, what you tried, what to watch next time. One request can carry both.

Add a second comment sits at the foot of a service-project composer, naming the audience it will add — internal note on a composer set to reply to the customer, reply to customer on one set to internal. Press it and a second box opens beneath the first. Write them separately; they post together as one issue’s work.

The composer is stacked the way Jira will show it. Jira lists newest first, so the comment that posts last ends up on top. The upper box reads posted last · shows on top, the lower one posted first.

To swap them, use Move up on the lower box. Both still post — it only changes which one ends up on top.

The second box is always the opposite audience to the first, so a pair can never drift into two comments that both go to the customer. Close it with the × on its header and the composer goes back to a single comment.

On a composer carrying both, the Internal / Reply to customer toggle swaps the two comments, text and all — the same action as Move up, from the header. Your sentences travel with their audience; the toggle only decides which ends up on top.

A composer written only in its second box still sends — the note posts as that issue’s one comment, carrying its own audience.

This is why twenty-five issues can produce fifty comments. The cap the app enforces is on issues, not comments — see Limits.

Working across the whole batch

Two of the batch controls on the Comment step exist only for service projects, because only a request can carry a second, internal comment. Both name the number they will actually affect — on a mixed batch that is the service-project requests in it, not everything you picked.

Opening and removing internal notes

• Add internal note to n requests — opens a second, internal box on every request that can have one and does not already, ready to type into. It writes nothing for you; the boxes arrive empty so you can say something different on each.
• Delete all internal notes — the reverse. It takes the boxes away along with whatever is in them. It only asks twice when something is written in them — open a box on every request, change your mind, and one press closes them all, because there is nothing to lose.

Clearing is not the same as deleting. Clear all comments & status changes empties your internal notes but leaves the boxes open, because it names comments and status changes and a box is neither. If you want the boxes gone, Delete all internal notes is the one.

Copying with two audiences

A request can hold two comments and they are not interchangeable, so the ••• menu carries one entry per audience:

• Copy this comment to n issues (reply to customer only) — the label says so explicitly, so it can never drop your customer-facing wording into somebody’s internal note.
• Copy this comment to n internal notes — the same for the other half.

Neither action opens a box, and neither changes any composer’s audience. A reply copies onto replies and a note onto notes, so copying can never turn an internal note into a customer email. That is also why the two counts usually differ from each other, and from the size of the batch.

The rest of the Comment step — the editor, the details panel, status changes — works the same on a request as anywhere else: see Step 2 — Comment.