Uploaded image for project: 'Jira Service Management Cloud'
  1. Jira Service Management Cloud
  2. JSDCLOUD-14319

Need customisation option to set default for comments (Internal Comment and Reply to Customer)

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • Issue View
    • None
    • 5,091
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Issue Summary

      Currently, there is no customisation option for making comments (Internal Comment and Reply to Customer) as default.

      The problem is that in the old issue transition experience, "Reply to Customer" is the default option; however, in the new issue transition experience, "Internal Comment" is the default option.

      New Issue transition experience:

      Old issue transition experience:

      The customer wants to have a configuring option based on their use case.

      Workaround

      Currently there is no known workaround for this behavior. A workaround will be added here when available

          Form Name

            [JSDCLOUD-14319] Need customisation option to set default for comments (Internal Comment and Reply to Customer)

            Pinned comments

            Hi all,

            After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards. 

            To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done. 

            Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly. 

            Thanks again for your patience and apologies for the inconvenience this change caused. 

             

            Best regards,

             

            Jehan Gonsalkorale

            Principal Product Manager, Jira Service Management

            Jehan Gonsalkorale added a comment - Hi all, After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards.  To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done.  Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly.  Thanks again for your patience and apologies for the inconvenience this change caused.    Best regards,   Jehan Gonsalkorale Principal Product Manager, Jira Service Management

            All comments

            Hi all,

            After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards. 

            To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done. 

            Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly. 

            Thanks again for your patience and apologies for the inconvenience this change caused. 

             

            Best regards,

             

            Jehan Gonsalkorale

            Principal Product Manager, Jira Service Management

            Jehan Gonsalkorale added a comment - Hi all, After reviewing the feedback here and on Community, we will be building a global setting for transition screen comments next quarter which we will aim to deliver either by the end of the financial year or soon afterwards.  To everyone who provided feedback, thank you for taking the time. We reviewed every piece of feedback when making this decision. Apologies if this took more time than you hoped, but we needed to understand the work involved and work to find a team to get the work done.  Given that the new setting will not be available for several months, please sign up here to have the default behaviour changed and we will enable it for you shortly.  Thanks again for your patience and apologies for the inconvenience this change caused.    Best regards,   Jehan Gonsalkorale Principal Product Manager, Jira Service Management

            Greg D added a comment -

            I think the majority of us have always wanted this to be configurable and the people that are now mad are experiencing the pain that other Atlassian customers had when public comments leaked unintentionally before this change. Both groups desire a way to configure it and in both cases it seems like it should be more obvious which type of comment you are writing.

            Not sure if anyone watching here is not already watching the article where I posted on recommending Many More Much Smaller Steps to get this to a better place, but just in case the below workarounds help anyone only here, some things Admins can implement 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 (customer-visible status changing and defaulting a canceled resolution to message the customer is not preferred)
            • 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

             

            Greg D added a comment - I think the majority of us have always wanted this to be configurable and the people that are now mad are experiencing the pain that other Atlassian customers had when public comments leaked unintentionally before this change. Both groups desire a way to configure it and in both cases it seems like it should be more obvious which type of comment you are writing. Not sure if anyone watching here is not already watching the article where I posted on recommending Many More Much Smaller Steps to get this to a better place , but just in case the below workarounds help anyone only here, some things Admins can implement 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 (customer-visible status changing and defaulting a canceled resolution to message the customer is not preferred) 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  

            Evaldas added a comment -

            a620038e6229 , thank you for commenting - at least we have SOME KIND of answer after MONTHS of ignoring this really painful issue.

            HOWEVER, I agree with others - this should NOT be a temporary solution for 3 months, but a PERMANENT!

            Why? I think we are quite typical JSM users - we have 10 TIMES more Customers than Agents, and that alone should indicate, that we could write 10X more “replies to customer” rather than “internal comments”…

            And it's particularly frustrating when closing (resolving) the tickets, because from 20+k tickets we already have, MOST of them (90-95%) were closed (or should have been closed) with “Response to Customer”, while only very few with “internal comments”.

            To sum up, we use “Respond to customer” at least 100 TIMES more than “Comment Internally” - so why the hell YOU made such a headstrong decision on our behalf, without letting us choose (or consulting us in first place)?

            Really mad with you for such pooor planning...

            Evaldas added a comment - a620038e6229 , thank you for commenting - at least we have SOME KIND of answer after MONTHS of ignoring this really painful issue. HOWEVER, I agree with others - this should NOT be a temporary solution for 3 months, but a PERMANENT! Why? I think we are quite typical JSM users - we have 10 TIMES more Customers than Agents, and that alone should indicate, that we could write 10X more “replies to customer” rather than “internal comments”… And it's particularly frustrating when closing (resolving) the tickets, because from 20+k tickets we already have, MOST of them (90-95%) were closed (or should have been closed) with “Response to Customer”, while only very few with “internal comments”. To sum up, we use “Respond to customer” at least 100 TIMES more than “Comment Internally” - so why the hell YOU made such a headstrong decision on our behalf, without letting us choose (or consulting us in first place)? Really mad with you for such pooor planning...

            Our cases are all internal facing, so Internal Note is hardly used. I really don't understand that Atlassian implemented a change with this impact with giving Administrators the option to select a default of their own choice. Yet another reason to start using ServiceNow.

            Christophe Veuskens added a comment - Our cases are all internal facing, so Internal Note is hardly used. I really don't understand that Atlassian implemented a change with this impact with giving Administrators the option to select a default of their own choice. Yet another reason to start using ServiceNow.

            Doug Johnston added a comment - - edited

            I'm yet another manager whose team has been stung by this in recent months. Giving teams longer to transition to the new paradigm is not an adequate response.

            I have no doubt that there are teams who want the majority of their messages to be "internal". For those teams, the new approach is a better fit.

            But for teams like ours, where 90% of our messages are directly to "customers" and "internal" messages are the rare exception, the new approach is awful. It causes us to think we have sent a message to customers only to realize (sometimes days later) that it was an internal note. This is both embarrassing and frustrating.

            Jira and Service Desk are incredibly configurable in nearly every other way (sometimes annoyingly so). It seems like a small ask to give team members the choice of defaulting to "internal" or "customer". Please reconsider.

            Doug Johnston added a comment - - edited I'm yet another manager whose team has been stung by this in recent months. Giving teams longer to transition to the new paradigm is not an adequate response. I have no doubt that there are teams who want the majority of their messages to be "internal". For those teams, the new approach is a better fit. But for teams like ours, where 90% of our messages are directly to "customers" and "internal" messages are the rare exception, the new approach is awful. It causes us to think we have sent a message to customers only to realize (sometimes days later) that it was an internal note. This is both embarrassing and frustrating. Jira and Service Desk are incredibly configurable in nearly every other way (sometimes annoyingly so). It seems like a small ask to give team members the choice of defaulting to "internal" or "customer". Please reconsider.

            Gambit added a comment -

            Making it like full issue view? Internal / Reply shows before click? Better visual indicators seem necessary when you are on one or the other.

            For those saying agents are making a lot of mistakes, that seems to prove that internal is a better default since they do not seem to be paying close attention. How many times before the change were they emailing nonsense to customers or hitting ctrl+enter and sending half-typed information?

            But with that said, it definitely needs a better visual indicator (muscle memory & no differing the tabs makes it tough). Being able to configure would be helpful for sure.

            Could you launch full issue view style to the screen quickly and then investigate other options?

            Gambit added a comment - Making it like full issue view? Internal / Reply shows before click? Better visual indicators seem necessary when you are on one or the other. For those saying agents are making a lot of mistakes, that seems to prove that internal is a better default since they do not seem to be paying close attention. How many times before the change were they emailing nonsense to customers or hitting ctrl+enter and sending half-typed information? But with that said, it definitely needs a better visual indicator (muscle memory & no differing the tabs makes it tough). Being able to configure would be helpful for sure. Could you launch full issue view style to the screen quickly and then investigate other options?

            Hi,

            Appreciate that Atlassian is recognizing this major mistake and owning it.  However this is the WRONG response:

            "The goal is for this to give you more time to manage the change on your end."

            We're NEVER going to get used to a Jira SERVICE management system defaulting to an internal comment.   Please revert this terrible change.

            Susan

            Susan Hauth [Jira Queen] added a comment - Hi, Appreciate that Atlassian is recognizing this major mistake and owning it.  However this is the WRONG response: "The goal is for this to give you more time to manage the change on your end." We're NEVER going to get used to a Jira SERVICE management system defaulting to an internal comment.   Please revert this terrible change. Susan

            I'm reverting it back for my team, we internally built a Chrome extension to flip it over for our small department - but there needs to be customization to this experience before it is strictly enforced as it goes against itsm workflows that I assume a lot of service desks built with JSM.

            Nicholas Wirth added a comment - I'm reverting it back for my team, we internally built a Chrome extension to flip it over for our small department - but there needs to be customization to this experience before it is strictly enforced as it goes against itsm workflows that I assume a lot of service desks built with JSM.

            "The goal is for this to give you more time to manage the change on your end."

            This is an incorrect response.

            The goal should be for your team to review all the negative feedback and provide a solution that works for everyone.  It was said that customers asked for the resolution to be internal, but I was never polled or asked, and clearly many people here were not.

            Please continue to allow us to opt out until you have a better solution for those who use Service Desk to communicate with CUSTOMERS.
            When we want to have internal notes, such as all the details and steps for how we resolved something, we purposefully make an internal note for our team.

            Why not revert the change and let the orgs who don't use it for customer communication figure out how to manage the process on THEIR end?

            Dena Campasano added a comment - "The goal is for this to give you more time to manage the change on your end." This is an incorrect response. The goal should be for your team to review all the negative feedback and provide a solution that works for everyone.  It was said that customers asked for the resolution to be internal, but I was never polled or asked, and clearly many people here were not. Please continue to allow us to opt out until you have a better solution for those who use Service Desk to communicate with CUSTOMERS. When we want to have internal notes, such as all the details and steps for how we resolved something, we purposefully make an internal note for our team. Why not revert the change and let the orgs who don't use it for customer communication figure out how to manage the process on THEIR end?

            a620038e6229 displaying both fields would technically solve the problem, but being able to set it on a Site, Project, or User level would be preferred.

            Based on that I have reacted with the fire emoji, but I would prefer the option to set it ourselves.
            That would, to me, be the difference between a good enough solution and a good solution.

            Rune Rasmussen added a comment - a620038e6229 displaying both fields would technically solve the problem, but being able to set it on a Site, Project, or User level would be preferred. Based on that I have reacted with the fire emoji, but I would prefer the option to set it ourselves. That would, to me, be the difference between a good enough solution and a good solution.

              a620038e6229 Jehan Gonsalkorale
              dcf888be292f Tanmay Tandon
              Votes:
              448 Vote for this issue
              Watchers:
              248 Start watching this issue

                Created:
                Updated: