Automate adding a comment to a ticket

The comment field is not available in automations. We'd like it to be, and we'd also like the ability to automatically add the content of automated emails as a comment (rather than a notification).


  • -4

    Hi Dave,

    Automations are for batch administrative ticket operations or notifications - they are not for adding comments. Rules will generally never add a comment to a ticket, and we intend to keep it that way.

    Product Manager

  • 0

    When I read about 37 signals telling customers no, I think "what a brilliant idea." When I experience it firsthand, it stings a little. Would you condescend to explain the philosophy behind automations a little bit for a person who isn't part of your product team? Specifically, I'd like to understand what values you (ZenDesk) have that prescribes that approach.

    Much appreciated.

    "Love your help desk"


  • -3

    Hey Dave,

    Of course, I'd love to - sometimes people just don't want to hear me talk about helpdesk geek waffles though, hence I try and keep responses short :)

    There's a number of philosophies within Zendesk that need to be explained first, so I'll go through each of them as quickly as I can.

    • Audit Trail - You might refer to this as Events within a Ticket. You can see an Audit Trail when you click on 'All Events and Notifications' on a Ticket. It's a history of everything that's happened with a Ticket - each time something touches a Ticket, either Human or Computer, it will be logged in the Audit Trail.
    • *A Comment *- A comment is an exchange in communication, if the English language permitted it we would call it a 'Talk'. Due to a Computers lack of emotion, opinion or common sense it's unable to comment on things, it has no opinion. Therefore, a comment is made by Humans only, which in Zendesk is an Admin, Agent or End-User.
    • A Notification - A Notification isn't an exchange in communication - because it's one way. Notifications are sent by Computers, to alert Humans to a situation, or provide some information (of which was likely constructed by a Human). Notifications in Zendesk can be sent by Computers via Email, Txt or just about anything with Targets.

    When we consider these three things, we begin to understand why Humans and Computers are represented very differently within a Ticket. By allowing only Humans to comment on Tickets, we keep a level of sanity - i.e. only a Human can convey an opinion (solve a problem) because only they are qualified to do so. As a result, Comments are shown within a Ticket, that way you can 'sanity check' it; you know there's only humans in this conversation.

    However, we do allow Computers to use Notifications. This won't be included in a Comment because it makes no sense to include a Computer in a conversation, instead it should only really be prompting a Human to do something, "Hey, there's a new reply, you should check it out" or "This ticket hasn't received much love, maybe you should reply to the End-User".

    For these reasons, we don't allow Computers' to make comments in a Human's conversation.

    Hope that clears things up!

    _Jake Holman

  • 0

    Thanks Jake. That seems very sensible.

  • 0
  • 2

    Jake, I understand your position on this, but I think there's a way for you to give your users the legitimate feature they are asking for without compromising your communication philosophy. Your users are asking for automated comments because they want automated replies to be just as visible as agent comments. Currently, not only is the audit trail not visible by default, it doesn't show the body of email replies sent to users.

    Here's my use case: when a user attempts to download software from my company's website many times, a ticket is automatically filed on behalf of the user, indicating that they may be having trouble downloading the software. In response to this ticket, a trigger causes my agent account  to send them an email reply (authored by a human, but sent automatically according to a rule) prompting the user to elaborate on their potential issue. Unfortunately, other agents in my organization do not know that this automated prompt was sent, and even if they were to check the audit trail, they would still not be able to see what the automated reply contained. It would be really helpful if other agents at my organization could see that I automatically sent the user some information, so that they can continue the conversation appropriately and not bombard the user with redundant requests for information.


    This is the same dilemma that Dave is facing, and in the spirit of being helpful, he suggested a feature that would enable his apparently common use case. Your initial reply was stubborn and unsupportive, although you went on to provide a compelling and spirited justification. Dave and I simply want more visibility of automated correspondence for agents across the organization, which you could implement without compromising your philosophy.

  • 2

    Hi all,

    I completely understand both parties argument ... however I still haven't heard of any solution for the problem we (we = who would need this) face.

    I understand Jake's note ... but in the same time I feel like Zendesk trying to me more of a communication police. There are multiple use-cases for this functionality, and I don't agree with the "sanity" part of the comment. Because enabling this function doesn't mean that everybody will use it, but just the once who have the use-case for it. I think that is a very simple understanding.

    I agree with David that this function would increase transparency and visibility for all parties involved. Especially since the notifications (that Jake mentioned as a sort of workaround) are not able to notify CCd users.

    Our use-case: We found out that about 50% of some of our support level's backlog is due "awaiting resolution confirmation" - which means that we are waiting for the requester or anybody CCd to confirm that the issue reported has been fixed. Users tend to not follow up on the tickets after they received the resolution. To manage this part of the backlog we want to have some automations that listens to a certain set of tags. Based on which different automated comments are placed on the tickets - so that everybody involved in the ticket receives a notification and the comments are visible on the ticket so that our customers see when and what happened (we have some of our customers as agent as well). These comments would ask for a confirmation twice and if there were no updates on the ticket by the requester or CCd personnels then the ticket can be solved with a third comment. Since the solution has been provided earlier by a human these comments can be automated, and based on the set of tags we identify would place different comments with different messages to encourage the user to get back to us.

    So, we have here two sane use-cases - and I am sure that there are many more depending on the setup and business that we Zendesk customer's have.

    This topic has been submitted years ago and since then I guess Jake received more requests - comments on this ... would it be time to have this functionality reconsidered - debated?

    As a real workaround - I believe this can be solved by a script that access the zendesk API and places the comments automatically depending on some tags - but this would mean that we rebuild a function that is already there - automation.

    A personal note - please don't try to be a communication police ... it's not gonna work out well. Please let us decide what is sane and not sane, and how we use the product - since as mentioned there are multiple use-cases depending on the business we do and the setup we use.

  • 2

    I agree with David and Ferenc!

    I can't believe Jake as a Zendesk product manager would flat out refuse this request. I actually find it disturbing that 1 person makes this decision and not the Zendesk community. We develop software ourselves and you need to take your personal opinion out of it.

    What Jake says is completely wrong and is a personal opinion from someone not in touch with people that run a business and manage help desk staff to support their clients. A human writes an automation to save time and increase efficiency. Jake may call them a 'notification' but when the automation can also include an email response then this is personal, artificial intelligence is not generating the response. When it is sent it is no different from a user manually going in and sending a public comment or even inserting a macro and clicking send. Actually under Jake's logic Macros should not be made public either as it is a pre-determined response being sent...

    We have an automation that after 3 business days we remind the end-user we are still waiting for further information from them to best assist in solving their issue. Now this automation is designed to save time from checking all support issues and manually writing the same email or having to select a macro and click send every 3 days. Each method is the same action but just because you call it an 'automation' I can't have this email made public so our support staff can see another update to the conversation has taken place. Instead Zendesk hide all of this communication trail in an 'audit' where it can easily be missed and then you send a manual email response and piss off your clients by annoying them with the same question again. It defies logic to exclude an email from the conversation and not make it clearly visible as part of the history with your end-user. In saying that I can also understand someone who may in some cases want the automation not visible for certain responses or updates.

    To summarise I'm not sure how this is an issue at all. Why can't there be a variable so in the Automation/Trigger we can flag the email, text based, response to be displayed as a public comment? Then all users can decide for themselves to show this or not!

    I know this could be done if we pay for it, so why can't it be considered?

  • 0

    @Ben: I actually tend to keep my personal opinion out of comments, although that's a lesson learned. In regards to my response earlier in this thread, someone had asked why we (Zendesk, as a company, a product team, not me personally) wouldn't want to make notifications part of the comment stream of a ticket. I simply gave the answer of how we were thinking (again, as a product team) at the time.

    That comment was posted over 4 years ago, was made fairly early into my time with Zendesk, and this thread has been fairly dormant since then - though I do recognize it's flagged as "Not Planned". In that time, I've been able to talk to a lot of support agents, managers, and even end-users. I try to spend most of my time constantly reading the awesome contributions to this very forum, in tickets, at users groups, webinars, Twitter, you name it.

    As a result, we're starting to shift our thinking on this. While we still think notifications from Triggers and Automations are not human interactions, that doesn't necessarily mean they don't belong in the comment stream of a ticket. We've watched end-users become confused when they receive an email notification, go to the ticket in their browser, then can't find the "comment" they just received via email. We've seen agents getting confused when end-users respond to a notification which had some questions for the end-user to answer, only to be confused by the end-user's update because they lack the context to understand what the end-user is answering or why. There's lot of other examples, but I'm droning on here.

     Why can't there be a variable so in the Automation/Trigger we can flag the email, text based, response to be displayed as a public comment? Then all users can decide for themselves to show this or not!

    Interestingly, this is close to what we're thinking. While we're still not entirely sure if we want to treat the display of the notification as a real comment, we do want to open up the option of displaying certain notifications in the comment stream. Generally speaking, we'd like to move away from the current comment stream options - which are basically "Comment Only" or "Everything that's ever happened to this ticket",  there is no middle ground and we think there's some tremendous value in offering something "in-between".

    Unfortunately, though, I can't offer any ETA on this. I can say for sure there'll be no movement on it for at least the next 3 months or more. This is firmly on our radar, though.

  • 1

    Hi Jake,

    Thanks for your response. It's good to hear that over the years you have spoken to users and managers and are re-considering this stance. 

    An email is an email, I'm still not sure how the Zendesk team don't believe something that is text based and that *I* choose to send and forms part of a conversation with my end-user should not be visible as a public comment?

    It is a trigger/automation *I* have set and want to send to my end-user and for them to respond. It is just confusing to all for it to not be visible. Yes, some automatons/triggers I wouldn't add to the conversation as a public comment...but please leave that decision for me to make and not a programmer.

    I eagerly await the next 6 months as I have now turned off automatons that saved us time and have staff manually (read: wasting time) checking emails for responses that have not bee received from the end-user. 

  • 3

    Glad this is on the radar.  In fact, in other forums (https://support.zendesk.com/entries/37742207-About-automations-and-how-they-work), other zendesk employees are suggesting work-arounds with tags, views, and a macro where you can add comments in bulk.  This is the same thing, just inefficient and leaves room for error.

    We notify requesters after the ticket has been 10 days in pending and then close them after 14 days.  We don't notify the end-user when we close the ticket because we assume after the 10 day notification the requester's issue has been resolved.  Unfortunately, that is not always a safe assumption and when the end user logs into the HC to check on their request history they won't see any reason that their request was closed.  We'd like to have the automation add "This ticket was closed due to inactivity" or something more personal if it should sound more "human" to the ticket comments.

    We have to close these for metrics, etc. when the requester truly just leaves it in pending when their issue is resolved.  But for the times when that's not the case, the lack of visibility is a frustration to our customers.

  • 1
    • 1. We need triggers / automations to add internal comments for process guides for what to do when certain scenarios occur e.g. pending with no reply for 3 days, 1) call the client, 2) SMS the client, 3) email the client from regular email, 4) notify their account manager, etc. 

    Would be great to be able to have check boxes where the assignee can mark off which processes have been followed. 

  • 1


    I was wondering if you had any further thoughts on this as it would be a great feature to have.  We have calls generated that require a set list of instructions required to resolve them.  It was be great if we could identify these from the subject and add in a private comment with list of instructions\actions for the agent to take to resolve the issue.  I have looked at triggers and macros but you are unable to do this at present.

    Not sure if there is anyone out there that has found a workaround for this but be great to hear from you if so.



  • 1

    Computers always join "human" conversations. It might not fit your agenda but this is the product we want. This is the third time I hear such a response from Zendesk and frankly it just pushes me to shop the competition. Too bad.

  • 1

    hi Zendesk,

    It's been a while since your last update on this thread about Business Rules being able to added Comments.

    Do you have any update on production direction on this request?

    thanks, Mark

Please sign in to leave a comment.