Changes to transition screen comment behaviour in Jira Service Management

[#1]

Hello Community! 

This is Jehan from Jira Service Management.

We recently changed the default behavior of transition screens, where comments now default to “Internal note” rather than “Reply to the customer.”

Why did we make this change?

There were several reasons for this change:

1. Users accidentally making customer comments: Prior to implementing this change, we heard complaints from customers that they were accidentally making external comments to end users when the comments were intended for their team only because they weren’t aware they were the comments were external by default.

2. Matching behavior to issue view comments: The issue view defaults comments to “Internal note,” and we want the experience to be consistent with reducing confusion.

We spoke to our users, and the feedback was clear: most customers prefer these comments to be internal only by default. This reduces the chance of an agent accidentally sending internal notes to end users.

We rolled out the change slowly and received feedback from many customers who weren’t expecting the change. They were, understandably, unhappy that this change had gone through without any prior warning. We also found that many customers wanted to be able to specify whether the comments defaulted to internal or external.

This feedback is very understandable. We heard about agents leaving customer comments that were accidentally set as internal given that this was the default. These comments would not reach the end users, leading to frustration.

We absolutely accept that we should have rolled this change out with more care. Our goal with this change was to improve consistency and reduce confusion around internal vs. external customers. However, we failed to properly communicate the reasons behind it and give you advanced notice. This was wrong of us, and we’re sorry for the frustration and inconvenience it has caused.

But what are we doing to solve the problem at hand?

Effective immediately, we are creating a temporary feature that enables us to change the default comment back to “Reply to customer” for all transition screens across your Jira Service Management instance. We will keep this in place for the next 3 months while we assess a more permanent solution.

In the meantime, if you would like us to enable this for your instance, please click here to leave a ticket, and we will revert the behaviour within the next week. Your feedback and partnership are essential as we work to resolve this issue.

Going forward, we commit to providing ample advance notice and clear communication before making any changes that could impact your workflows and customer experience. Transparency and putting your needs first are our top priorities.

Again, we sincerely apologies for the poor rollout and are here to make this right. We are ready to act on any raised ticket and resolve any disruption this may have caused.

Best regards,

Jehan Gonsalkorale

Principal Product Manager, Jira Service Management

[Ian Barrow]

Thanks for the post Jehan. Appreciate your understanding.

Ian

[Tyler Schmidt]

I appreciate the willingness to acknowledge the mistake, but what I can’t understand is why this can’t be permanently resolved. When we close a ticket, we send the customer vital information regarding their issue. Yet, time and time again, the system defaults to an internal reply, leaving the customer with no response and creating unnecessary confusion.

It is completely reasonable to expect an option to change the default reply setting. Our team has consistently used one method to communicate with customers, and this unexpected, unnecessary change is actively making things worse. It’s frustrating to see a process that worked well be disrupted without a clear benefit. This needs to be addressed permanently.

[Ted Hewitt]

"Derp derp derp, {EXPLAIN THE S* SHOW WE JUST FORCED ON EVERYONE} {JUSTIFY WHY WE DID X} {INSERT WE CARE STATEMENTS} {SOMETHING SOMETHING FEEDBACK IS IMPORTANT} {SORRY STATEMENT FOR SOME RANDOM TECHNICAL OVERSIGHT} {DO NOT APOLOGIZE FOR ANYTHING ELSE} {ENSURE THEM WE ARE WORKING ON A SOLUTION} {BE SURE THAT THE SOLUTION YOU DISCUSS IS NOT WHAT THEY ACTUALLY WANT} {PROVIDE MEANS FOR SUBMITTING OTHER GREAT IDEAS THEY MIGHT HAVE BY POINTING TO TICKET SYSTEM} {COMPLIMENT THEM AGAIN} {APOLOGIZE ONE FINAL TIME FOR THE TECHNICAL OR OVERSIGHT ISSUE}"

Jehan, you nailed this post!

No, not really...

"We absolutely accept that we should have rolled this change out with more care. Our goal with this change was to improve consistency and reduce confusion around internal vs. external customers. However, we failed to properly communicate the reasons behind it and give you advanced notice. This was wrong of us, and we’re sorry for the frustration and inconvenience it has caused."

WHAT!?!?!

There is so much wrong with your company's through process if what you just said here makes sense, and that you think this is comforting. You didn't communicate well enough, the reasons why we want this? You didn't think that a detailed explanation of the two roles (internal vs external) would have helped? or that this is a simple concept that if your using Jira and cannot grasp this, then you shouldn't even be on a computer.. jokes. I think what you really should mean here is that "We are sorry we did not ask first, and then provide an update that grants all of our users the power to manager their teams the way that works best for them". 

[James Nelson]

You "failed to properly communicate the reasons" behind the unwanted change.  So in this post you do that better?  I don't see it.  You say you have "several reasons" for the change but you list only one that makes any sense.  Atlassian needs a dislike button.

Your solution, after a huge blowback, is to temporarily fix the issue and require customers to create a ticket if they want help?? You already created a temp fix with the whole 8 week thing that is displayed after you make the change on a per agent level. 

What's the real reason for the baby steps, support ticket, wasted development time, and reassessment?

Again, how do we get in the "Valued" column in your customer database?

Are you aware that your behavior is contributing to your customers' perception of the Atlassian culture?  

[Brendon]

3 Months?   This issue has existed for 5 (7) months already and has negatively impacted organizations across this platform?   This does not seem very Agile in the face of all the responses we've seen.   I'm appreciative of the acknowledgement of the issue (step 1), but this provides no reassurance that we are going to get a satisfactory resolution within any reasonable timeframe.

For all the capabilities to design workflows, and customize the platform to OUR business needs, this feels like a complete 180 to force users to align to YOUR business needs.    For all the time that could be spent on more important new features, this feels like such a nothing-burger that could be fixed in an afternoon with any of the previously proposed ideas that would allow admins to customize the workflow as their organization requires.  ANOTHER 3 month delay just serves to kick the can down the road and provide continued uncertainty with how we as the customers will be expected to use the platform going forward.

This issue's temporary work around was discovered over a month ago in this thread here by engaged users:

(Unable to Post Link)

In December a response was provided to this thread which was created in September, and we were told we'd get a response in January but saw nothing until today.  Now we're being told it will be at LEAST MAY?   Add another month just in case of Delay. 

How in the world does it take 9 months to get a resolution on this?

But it gets better:
This interest topic was opened in JULY 2024
(Unable to Post Link)

So I'll rephrase my previous question:
How in the world does it take 11 months to get a resolution on this?

[Joe]

I don't believe "most customers prefer these comments to be internal only by default".  Where is the discussion or poll that would support that statement?  90% or more of our comments are meat for the person that submitted the ticket, and it was pretty easy to remember to toggle over to internal note when needed.

Please change the default behavior back or at least give customers the ability to choose their own default.

[Ted Hewitt]

Sorry there Joe, you are late to the party. There is another topic here where @Jehan Gonsalkorale told us that they already did this with their "preferred customers" and if you were not in that meeting.. then I hate to be the one that breaks this to you, but you are not preferred, and they simply don't care.

[James Rickards _Spark-Nel_]

Looking through this, Atlassian (and @Jehan Gonsalkorale  ) are in a damned if they do, and damned if they don't situation.

We are all asking for the wrong solution to this problem.  The issue is that asking for any default for internal or external comments is short sighted. People will have developed a muscle memory to do it one way or the other, and any change to the default (either way) will screw this this muscle memory, and there will be upset users.
 

The only change that I can see where Atlassian does not end up with egg on their face is the ability to add both internal and external comments at the same time. Display both fields at once, and highlight the internal one with the same yellow as shown when viewing comments, so it is intuitive about what is public and what is internal.  Nobody's muscle memory will be screwed with.  I doubt they will do this any time soon, as it would mess with automations, workflows and a bunch of other code that assumes only one comment during a transition.

As Henry Ford once said, "If I had asked the people what they wanted, they would have said stronger horses".   In this case the majority of the people asked for stronger horses (i.e. default to internal/external) and that is what Atlassian delivered.  Hopefully Atlassian can apply a little more creativity and UX testing in building what we actually need.

[Chrissy Clements]

@Jehan Gonsalkorale, 

Thanks for sharing this update and for the transparency around the decision-making process. The change itself makes a lot of sense; I can’t count how many times I’ve posted something meant for internal eyes only!  This shift helps reinforce intentional engagement with customers rather than defaulting to an external comment by accident.

That said, communication is everything. Even those of us who champion continuous improvement can be resistant to unexpected changes, so I appreciate you acknowledging the impact and committing to better communication in the future.

I’ve been a bit disappointed by some of the feedback in the thread.  One of the things I’ve always valued about the Atlassian Community is the constructive and collaborative nature of discussions. Change can trigger strong reactions, but directing frustration personally isn’t helpful.

I appreciate how you and the team handle this, and I look forward to seeing how the solution evolves.

[Ted Hewitt]

@Chrissy Clements You a bot? what? There was nothing constructive about this change. And since the change there has been zero, in fact less than zero effort from @Jehan Gonsalkorale or Atlassian to hear our feedback. The shades just get lower, and the response gets louder "Deal with it dawg". 

You want Constructive? They should try to innovate and deploy in the same way maybe? As for feedback? There has been plenty, you just missed it. 

But I can clarify everyones request / feedback once again and to make it really clear...

"Atlassian made an extremely poor choice forcing this new feature on every single customer, with absolutely no regard to how it would impact us all. There is only one way back from this, In short, a full reversal of this new 'feature' or an update to allow us to toggle it."

Done, thats it. There is no discussion or "right" way to roll this out. Is a configuration toggle, nothing more. Anything else, is Atlassian attempting to dictate how their customers are to do business. 

"I appreciate how you and the team handle this, and I look forward to seeing how the solution evolves." - What? Please be careful boot polish is known to be toxic. 

[Greg D]

I was thinking that once the new transition screen came, the commenting would match the full issue view with a collapsed bar:

Similar to what James mentioned, that is, in a way, showing both at once... also saves real estate and allows focus to be on other field values you may be capturing across different transitions. If visibility cannot be configurable by transitions, wondering if that would be a good a starting point? Then you can tab between the two before expanding and hit enter on the one you want to expand without even clicking too.

Then, if not immediately, maybe at some point the below would help?

• The internal side could have the yellow background color while editing
• The tool-tip from legacy transitions that says it is locked or visible to the customer when you are on each tab can be added
• Maybe a separate keyboard shortcut to expand the customer comment side

All of that would also make sense on the full issue view as upgrades.

I don't think Jehan mentioned this above, but across different sites I have managed, we have seen people/apps utilizing the platform API to post internal notes that would default to a public comment by mistake (have seen that cause some problems and maybe this will help with that).

To offer some workarounds of things us admins can control right now:

• You can turn off the notifications for when customer-visible status changes and when things are resolved in the project
  • That way it is not confusing when agents are just transitioning things around and not publicly commenting (either by mistake from the new default or on purpose because they need to change the status without a proactive notification)
    • I think it would be beneficial for all of these default notifications to be configurable by site admins as starting points for new projects too
• If you have a substantial amount of automation rules available in your limit, you can set up checks to look for comment visibility
  • So you could check if internal = true and at-mention that person that wrote it to double-check it or showcase it in some way or even flip it to public if everything written matching certain criteria should be public
• You could have many agents work the requests from the portal side with transitions added there
  • This one probably isn't feasible with how queues and dashboards are utilized, but just as an option for some subsets of agents

Hopefully some of those ideas are helpful to some reading.

[Celina Kincaid]

We actually do prefer the new internal comment default on issue view, but it's the transition of a ticket that still defaults to public that is a big nuance...and quite frankly, risky! 

[Ian Barrow]

Whereas we hate it. As 99%of our resolutions are reply to customer.

[Ted Hewitt]

Again though, the issue is not the action at any point of the flow, its the ability for teams to control the behavior. You have the right to run your teams the best way that makes the most sense for your work flow. Some teams keep everything internal and no need to communicated externally, heck, our team did that originally as well for about 6 months. Now we manage way more end user Help Desk tickets and need regular communications back and forth. I have a Dev project that links help desk tickets and I DO NOT want my developers messaging customers, so that project would be defaulted to internal only. Actually having a full public block for my users would be nice also. Or even permissions to give the ability to communicate publicly for certain users and not for others.. 

The whole point of this backlash is not what the options are for communications, its the fact that they will not give us the control to set them up the way we want them to be used. Just give us a setting to select how it works, why is this so hard a concept to understand. We get so man other controls and abilities to set defaults, why is something so trivial like this setting locked down?

100% agree with any and all situations people keep posting. Ideas on how to make each method stand out are amazing. But at the end of the day just give us the ability to change it!!

Another way to think about this.. what if Atlassian dictated the workflow of our card statuses? As in we didn't get to choose our own statuses or where a card starts or how it can flow from one to the next? That would be dictating our work flows, just as this is dictating our communication flows.

[Greg D]

@Ted Hewitt agreed, we have always wanted it fully configurable where we can control by instance, project, issue type (work), workflow transition, and user on whether they should be writing internal or public at any given moment. For every setting in Jira, it seems to make sense to have an Atlassian starting point as a default that site admins can change, that then project admins can change from there, that users can then change from there (if site admins allow the user to change it). We customize everything, but for orgs that don't, it provides a good out-of-the-box starting point (some of those starting point defaults could be better too). In absence of that, which is a need for other settings on top of comment visibility, trying to think through what can help as a quick change.

Maybe there is a big blocker to providing that control to admins right now, so would be great to make this iterative with quick deliveries of smaller steps.

• Simple start - tool tip to show which tab you are actually on... for Internal - (red lock) Your comments will not be visible to customers.
• Next - take full issue view code and put both as collapsed to start
  • If the transition screen just has a comment and no other fields, first keyboard tab highlights Add internal with ability to tab to Reply to customer
  • With it collapsed, it becomes more conscious of which one you are picking via keyboard or mouse
• Next - add yellow background highlight while composing an internal note
• Next - allow site admins to control the defaults for notifications in new projects and for which visibility is default
• Next - add in more granular controls

In my opinion, Many More Much Smaller Steps will help make progress here and searching for the perfect/best solution to avoid rework will be a long road with more pain.

[Md Sumon007]

Hi 

[Ted Hewitt]

@Jehan Gonsalkorale You are making people sad...