Using side conversations in tickets (add-on) Follow

Comments

67 comments

  • Avatar
    Mikael Johannessen

    I'm looking forward to this feature being enabled for our instance of Zendesk, but I am wondering about the following statement:

    • When someone replies to a side conversation through an email notification, the reply becomes a public reply on the ticket, not a reply to the side conversation. This means that they are replying to everyone on the ticket, including any customers on the ticket, instead of a limited subset of people in a side conversation.

     

    If I understand this correctly, if I open a side conversation with an internal party, I need to explicitly ask them to not respond to my email, as any internal discussion will thus be sent to the customer/requester. 

    If this is correct, are there any plans to improve this? With such behavior, it will be tough for me to implement it knowing we're only one simple human error away from leaking confidential information to customers.

  • Avatar
    Toby Sterrett

    Hi Mikael – that statement only refers to notification emails that are sent via a trigger that you would set up to notify the assignee of the ticket. This trigger does not exist by default and is unnecessary unless you really want the assignee of the ticket to get an email to let them know a side conversation has been replied to. We recommend changing the status of the ticket for views and using the in-product notifications instead.

    Replies to the regular emails that Side Conversations send to recipients will not add any comments to the ticket or send emails to the ticket requester. So the internal use case should work just fine for you.

    Thanks for bringing this up. We'll likely revise the wording on this to make my above explanation more clear!

  • Avatar
    Ola Thoresen

    Side conversations looks great, and is a feature that I have been missing.

    However one thing that would help us a lot is if the From (and maybe the Reply-To) addres would use our domain name instead of zendesk.com

    I would often like to send emails to internal systems that only accepts emails from our domain, or which behaves like Zendesk, and using the sender domain to identify which organisation-entity the email should be mapped to.   So I can not simply add zendesk.com as "our" domain in those systems.

    So by using the default support address (as configured in Settings) in some <UID>+email@domain format would help a lot.

  • Avatar
    Sebastian Kochanowski

    I would rather prefer to have Threads using a email address applicable for the ticket than the 'default email address set in Settings'.

    That would be beneficial for wide teams having multiple mailboxes linked with Zendesk.

  • Avatar
    Ola Thoresen

    The actual implementation can of course be discussed. The main point is that the sender domain should be our domain, not zendesk.com.  "Default email address" was just a simple way to not introduce any new complex settings.

  • Avatar
    Sebastian Kochanowski

    Yup, makes sense in general :)

  • Will side conversations also be enabled for customers already on a plan which includes the 'old' light agent add on? 

  • Avatar
    Nicole - Community Manager

    Hi Jalle - 

    Yes, if you already have the "Light Agent" add-on, you'll be moved to the "Collaborations" add-on automatically. For more info, see the official Announcement for the Collaborations add-on, where this is specified. 

  • Avatar
    Toby Sterrett

    @Ola @Sebastian – the From: address is something we're investigating. There are a few things we're thinking of as possibilities:

    It sounds like most of the concern is around the From: address being from the right domain vs. zendesk.com, right?

  • Avatar
    Ola Thoresen

    Hi, and thanks for the explanation.
    Yes, it's the domain-part that is of concern.
    But it is also important to ensure that replies are handled correctly. And I know there are clients out there that do not behave correctly when it comes to Reply-to, so I think it would be best if From and Reply-to are the same address. Eg. support+1234@acme.com

  • Avatar
    Maurits Vos

    Thanks for enabling this feature widely! I was part of the EAP and really like the feature

    I agree with Ola and Sebastian. 

    Selecting an email address or setting a default address per brand/agent would be beneficial. Also, would it be possible to add the agent's signature to the email by default?

  • Avatar
    Toby Sterrett

    @Ola – thanks for the follow-up. We'll have to look into the deliverability of emails with a From that includes the +identifier.

    @Maurits – glad to hear you're enjoying the feature! Signature support is something we're looking into. Would the same signature that agents have for ticket replies be good for side conversations or do you think they would need a different template?

  • Avatar
    Maurits Vos

    Hello Toby,

    Thanks for the response!

     

    I see no issues in using the default agent signature for our cases at least.

  • Avatar
    Sonia Radaelli

    Is possible to measure the side conversations in the reports?

    Is there an example?

    regards

    Sonia

  • Avatar
    Gal Zohar

    This a feature we have been waiting for for a while, but there's one thing that does not make much sense to us:

    "Keep in mind that the creator of the side conversation doesn't automatically receive email replies to side conversations. That’s not the default behavior.

    We recommend that only the assignee of the ticket creates side conversations."

    Why? The creator of the side conversation is the person interested in the response, sometimes more than the assignee. That could be a light agent (for example) that manages this account, or any other person that is not directly handling the ticket. This almost cancels the value of side conversations for us. Are there plans to change this behavior?

  • Avatar
    Toby Sterrett

    @Sonia – not at this time, but we're investigating the best way to make reporting available on side conversation activity. We definitely know it's important.

    @Gal – there are a few different approaches to this we've considered:

    • Hard coding an email to be sent to the creator of side conversations when side conversations are replied to. The main issue with this is that the emails would be notifications, and outside of the main email thread everyone else is in. Also, not everyone wants more emails and would rather manage everything in Support, so it would likely need to be an option of some sort.
    • Augmenting triggers so email notifications can contain the content of the side conversation reply and be sent to the creator. Again, though, these are notifications and not the actual email thread, so it adds a layer of complexity, especially when replying to them.
    • Optionally including the creator of the side conversation as a recipient so that they'll also receive email replies to the thread on reply-all responses. This would allow them to reply back to the conversation from their email like any other participant, and the side conversation in the ticket would also be updated as part of the reply-all chain. However, this could be a bit weird to have "two" of the agent involved in the email thread (the initial email and then as recipients), and it also "leaks" the creator's email address into the email recipients chain.

    I'd love to hear your thoughts on these ideas (or if you have a different approach in mind).

    Also, how often do you anticipate side conversations being created by people who aren't the assignee of the ticket they'd be in? And would they always want to reply via regular email, or would they log into Support to reply?

    Thanks for bringing this up, it's something we've been thinking about a lot, and real world scenarios will help us move this in the right direction.

  • Avatar
    Gal Zohar

    Hi @Toby,

     

    Thank you for replying so quickly!

    Totally understand the approaches and why none of them is a slam dunk.

    For us - out of the three, the third option makes most sense. We intend to use side conversations for internal teams communication, so the email leaking is not an issue. Getting an email on an update you yourself made is a bit ugly but e can live with that.

    To give some background - side conversations for us is a solution for Light Agents to talk to each other about a ticket. All company employees who are not agents are light agents, and we try to keep communication recorded in tickets.

    For example, agent A is handling a ticket for an large client. The client's Customer Success Director sees his ticket, and may open a side conversion with her team to say "Please all note that this is going on when you get to their office tomorrow!". Or escalate to her manager and say "This is the issue I mentioned yesterday that puts this client at risk". 

    Generally speaking, side conversations for us are more for collaboration of all the client-facing teams around the implications of this ticket, than for the agent to find resources to resolve the ticket (which is something we have pretty much solved with some dedicated Slack channels). It is this communication that we do want to have in the support platform, documented and searchable, but not visible to end users.

    BTW - another solution to our challenge is for light agents to (a) 'Follow' a ticket and (b) @Mention other users in private comments. I know those are not on the roadmap currently but that's the basic functionality/use-case we are in need of. When I saw side conversations are available for light agents it made sense for this use case, and I do like it a lot for it not being a part of the main ticket conversation and causing clutter.

    I hope this feedback helps!

    Gal

  • Avatar
    Jonathan March (Edited )

    > Replies to the regular emails that Side Conversations send to recipients will not add any comments to the ticket or send emails to the ticket requester

    What will such email replies do? I do not see any mention of this; did I miss it? 

    Our light agents generally will not use the ZD Support web interface. When they get an email, they want to reply to it. This is understandable and logical. I would hope that replies to Side Conversation emails would be posted to the side conversation. are they?

    UPDATE: Just started a short trial of this add-on. Yes, email replies do get added to the side conversation. Other questions / uncertainties to follow.

  • Avatar
    Jonathan March

    >> When someone replies to a side conversation through an email notification, the reply becomes a public reply on the ticket, not a reply to the side conversation. 

     >  that statement only refers to notification emails that are sent via a trigger that you would set up to notify the assignee of the ticket. This trigger does not exist by default and is unnecessary unless you really want the assignee of the ticket to get an email to let them know a side conversation has been replied to. 

    Just to check -- for us, agent email replies are private by default, not public. That would still be the case here, right?

    Thanks!

  • Avatar
    Jonathan March

    Just started a short trial of this add-on. Nicely done, folks!

    I'm surprised to see that there's no event log / audit trail. Is that because the conversation itself fully describes everything that happened when a side conversation is updated in any way? I would still think it useful to preserve these updates in the ticket's event log, in part because otherwise it could be quite painstaking to re-assemble a complex sequence of updates in multiple side conversations and on the ticket. "What happened" is an important question when things go wrong, and event sequence is a crucial part of that question.

    Thanks!

     

  • Avatar
    Jonathan March

    Here's an edge-case that seems undesireable:

    1) I am the requester of an internal ticket [I doubt if that is a necessary condition for this issue, but do not know]. I also start a side conversation on the ticket. I want to get responses to the side conversation by email, so I include myself in the recipient list of the side conversation.

    2) One of the primary recipients replies. I am on the "TO" list of their reply, so I get their email (great) but I decide to reply in the web interface.

    3) But even though I'm on the "TO" list of their reply, I'm not on the TO list of my next reply.

    4) Therefore, unless I manually add myself back to the TO list of this web-based reply, I won't be on the TO list of any other recipient's next reply, so I won't see it by email.

  • Avatar
    Toby Sterrett

    @Gal — awesome, thanks for the detailed example and explaining your overall workflow, that’s really informative. It’s an interesting use case to is it just for internal discussion of a ticket rather than reaching out to folks, but it does make sense. It’s kind of like a cleaner, more organized internal notes that enable internal discussions with specific subjects and people.

    As for including the creator of the side conversation as a participant in the recipients, we’ll look into how that could work and how it could be approached. It likely partially works now, but there may be some quirks that prevent it from being smooth.

    I’d love to hear more about how you’ve been using Slack for reaching out to other teams for help on the ticket. Can you provide a quick summary of how that works and any shortcomings it may have?

    @Jonathan — thanks for all the feedback and questions! I’ll answer them in order:

    1. Yup, like you discovered, the emails that get sent to recipients will simply update the side conversation when they are replied to.
    2. I believe that agent replies to these email notifications would still be private if that’s what your account-wide setting is. These notification emails from triggers are just regular email notifications that any other trigger would send, so the reply behavior shouldn’t be any different.
    3. Are you referring to the gray box that includes the details of the ticket state and changes made during the event? If so, we are going to look into adding that information to the side conversation events in the future. Unfortunately it’s not a direct copy/paste of the existing formatting for those events, but we think it should be doable.
    4. Ah, yes this is something we’re going to need to investigate and debug. This goes along with a different comment about having yourself as an explicit recipient in a side conversation… it would be a nice way to be able to get email updates and reply from your email client, but these types of scenarios can be tricky. I think we’ll need to look at the incoming emails and if the agent’s email is explicitly in the the TO of the incoming email, it should remain in subsequent replies from the web UI. Nice catch!
  • Avatar
    Jonathan March

    Thanks for the responses, Toby.

    > (3) Are you referring to the gray box that includes the details of the ticket state and changes made during the event? 

    Yes. Again, that's super important for forensics. Appreciate your looking into it.

    Continuing to investigate...

     

  • Avatar
    Gal Zohar

    @Toby

    How we use Slack: in a pretty basic way :)

    All teams have their slack channels, and additional channels exist for asking questions about different domains of the platform. 95% of slack channels are public, so anyone at Kenshoo can jump in, ask a question, get the answer from whoever is active, and leave the channel (optionally).

    The Support teams often do this to get answers. It's easier than email, because you don't need to know who exactly may know the answer for your question. Channels naming conventions _usually_ allow you to understand what they are about, and this way to address multiple people you don't even know (650 employees company, with offices across the globe).

    All of this is not documented in the ticket, of course. As an agent, I would go to slack, ask and get answer, and go back to my ticket to continue the conversation with the requester.

    As said above, what we are trying to solve are internal conversations discussing the ticket with light agents, usually started by them and not the agent. If we could integrate THOSE into slack as well - that would be amazing. Starting an ad hoc conversation in slack (channel+DM) from within a ticket, and having this conversation logged in that ticket is probably the holy grail here... 

    Hope this helps! Do feel free to contact me offline if anything is cooking in your product team that I can help steer towards this use case, review, give feedback etc.

  • Avatar
    Toby Sterrett

    @Gal – this is great! Thanks for the info on how you use Slack, it sounds very much in line with how we've been thinking about it. We'll be sure to contact you for further feedback on this type of stuff in the future.

  • Avatar
    Patrizia Eberhart

    We have been waiting for this feature for a while. We are currently testing it.

    Feedback + questions:

    1. would it be possible to have the same contact search available in the side conversation similar to the one in tickets? Currenty the system only automatically prompts the names of the agents, but none of the other existing contacts.

    2. Currently the enduser has access to his ticktets and the tickets he's on cc: in guide. Are there any plans to include the side conversations in the guide module?

  • Avatar
    Patrizia Eberhart

    another question:

    1. The agent started a side conversation on the ticket and received an answer. If the agent now replies to this side conversation to the same external recipient, the system does not include the previous email chain, but only the new message. Is there a way of including the whole previous email chain when the agent replies out of support?
  • Avatar
    Troy Catherall

    @toby 

    I am in the same place as Ola and Sebastian, and heartily agree. The only thing stopping us from wide-spread acceptance and implementation of Side conversations. 

    In our use case, we deal with the government a lot, and they dislike any sort of change in where we send emails from, and I know they will start a fuss if we try to send things from collaboration@subdomain.zendesk.com

    This option works best for is one you mentioned:

    • Send the message From: the address that ticket replies would normally come from, and have the Reply-to be that address +identifier. Ex: From: support@acme.com, Reply-to: support+1234@acme.com

    Thank you so much for this wonderful addition to Zendesk, and I look forward to future tweaks to make it as near perfect as the rest of Zendesk.

  • Avatar
    Michael Adams

    @toby: Please bring us some iteration of the masked domain.

  • Avatar
    Toby Sterrett

    @Patrizia answers below:

    1. Autocompleting previously addressed side conversation recipients is in the works
    2. We don't have plans to integrate side conversations into the Guide view at this time, but I'd love to hear about some use cases where this would be desirable. As it stands, side convos are optimized for conversations outside of the one with the requester, so we haven't planned any integration into the requester view in Guide, but would love to hear your thoughts.
    3. Including the previous quoted messages in replies from within Support is something we have planned

    @Troy & @Mike sending/receiving emails from custom/brand emails is in the works!

Please sign in to leave a comment.

Powered by Zendesk