Vendor Reply Creates New Ticket Instead of Updating the Original | Community
Skip to main content

Vendor Reply Creates New Ticket Instead of Updating the Original

  • January 8, 2024
  • 4 replies
  • 0 views
D

Our agents oftentimes have to interface with a few of our vendors that use Salesforce to ingest their emails for customer service, which means Zendesk is emailing to Salesforce. Since Salesforce strips out header data that Zendesk uses to associate replies to an existing ticket, every time our vendor replies, it creates a brand new ticket rather than updating the original one started by our agent. 

Any suggestions on how to work around this scenario or to solve it? We currently just keep merging one reply into another but it's a horrible solution and makes researching old tickets impossible. 

Is there a way to resolve this or best practices on how to work around this Zendesk limitation? 

      4 replies

      Brandon12
      • Brandon12
      • January 9, 2024

      Hey @daniel27 -

      Unfortunately there are no easy answers here.  Since Zendesk was built to talk with customers, not tools/systems, getting the ticket to thread is pretty much a non-starter.  Best practice here is to solve the original request and leverage the ticket history for that user inside the context panel.  

      About the only other thing I can think of is leveraging a 3rd party tool like LInkets and a webhook via the API to search for and manually link the tickets, but the juice may not be worth the squeeze.

      You could always tell the vendor to get Zendesk, in which case a ticket sharing agreement would make things much easier :)

      Brandon

      Stephan12
      • Stephan12
      • January 10, 2024

      Hi Daniel, 

      We are also facing the other way that we are receiving answers on old tickets. Did you have the chance to discuss that result with your vendor? Is he realy answering on your ticket or is he issuing a complete new task in salesforce? 

      In fact, should salesforce also have to use the metadata in the message to add the comments in their system as well?

      Thank you for your feedback in advance.

      Regards, 

      Stephan 

      Marla12
      • Marla12
      • May 20, 2024

      Has anyone found an answer to this problem?  Does anyone know if SalesForce has a way to fix on their end since they are the ones stripping the information?

      D
      • Daniel27
      • Author
      • May 21, 2024

      @marla12 @stephan12 

       

      We've wrestled with this extensively with our vendors and here is what we've uncovered:

       

      They've been able to modify their settings in SF (which apparently is not very easy) to accomodate Zendesk's requirements for email threading. ZD's requirements are relatively unique in that regular email providers like Google / MSFT do not have an the issue with threading replies. Despite that, there are still some imperfections depending on the cadence of communication. 

      1. If we create a ticket by emailing our vendor (example@vendorsupportemail.com) and they reply to that email, the reply will now thread properly. Again, this is AFTER they've made customizations to database. 
      2. If a NOT created by us initially, but they send the first email. Any subsequent replies WILL NOT thread properly. all subsequent replies will create new tickets. However, if we reply “thanks” to the first inbound email then the subsequent tickets will thread…. basically, we have to be that really annoying customer that just replies “thanks" to everything to keep reopening their tickets; but that's the only way to pass the metadata that ZD woudl need on subsequent replies to thread properly.
      3. With that said, all bets are off with Side Conversations. Apparently this requires a whole other set of processes between ZD and SF that is different than actual tickets. So when we email example@vendorsupportemail.com from a side conversation, all replies create new tickets then circle back to #1 above to play the game again. 

      Ultimately we have found Zendesk's inability to accomodate standard emailing a bit of a deal breaker and are gearing up to migrate to a more versatile product. This limitation presents itself in many other ways like “Scheduling emails” or some other similar functionalities that you see in Salesforce, Hubspot, Gmail, etc. 

      Terms & ConditionsCookie settingsAccessibility statement