In Jenkins project, I use JIRA. And for CloudBees customers, we use Zendesk. And I positively and passionately hate Zendesk. It’s quite painful for my usage, and even more disappointing as many of the things that make me suffer can be fixed so easily. So I decided to write this to make myself feel better.
The way we use Zendesk, it’s really not that diffrent from the way Jenkins JIRA is used, which probably applies to just about any software projects. People report strange behaviours in software, stack traces, log files, etc. We look at those, sometimes ask for more information, ask them to try a new binary, get a new data, and repeat this process until it runs its course. I don’t think we are that unique.
This kind of support work is a lot like a detective work. You look at various log files and stack traces, you connect dots, and you derive a certain hypothesis. Sometimes additional facts are discovered later, or a hypothesis is proven wrong, and you start digging in another direction.
When I’m doing this, it’s very important that I “cite” my sources correctly. I’d like to be able to say “the stack trace in comment #7 indicates that X is doing Y when Z. This is consistent with ticket #150 comment #9.” But I can’t do this in Zendesk, because they do not have any sequence number nor ID for comments. So the best I can say is “comment made by John 11:59 on Apr 13th 2013 in ticket #150”, and if somebody (like me 6 months from now) wants to see the referenced comment, he has to manually find that comment. This is like writing a research paper without a bibliography section, or how a sloppy program managers refer to tickets (“what happened to that ticket — you know, the stability issue from Acme Corp a few weeks ago?”). This is particularly maddening because obviously they have an unique ID in their database, and I can even see it in the HTML source. It’s really only a minor additional work to make comments referencible. And yes, JIRA has permalinks for comments for long time.
There’s a lot of useful features to be built in this direction — for example, I’d love to see log files visible online, in such a way that each line is separately addressible as URL, and allow agents to left comments, much like how you review code. In this way, I can leave the audit trail for my detective work so that others can retrace that later.
Another thing that bugs me is the inability to edit comments that have already been posted. Zendesk supports markdown, which is good; it helps you organize information a lot more than just plain text. But some customers don’t know that, and file a ticket in plain text. Similarly, when the ticket comes from the e-mail gateway, often line wrapping and etc messes up the format.
In JIRA I often edit the ticket description to fix this up — convert a section of the text to a fixed-width font, remove line wraps, delete the pointless e-mail footers, etc. Have you ever had someone who posted 1500 lines of log records as a comment? Move that off to an attachment, and edit that out! In other situations, I want to go back to my earlier comment and strike out something, for example when my earlier hypothesis turns out to be wrong. But I can’t do that either in Zendesk. (And Zendesk doesn’t let you collapse a comment, either.)
I can go on forever, but I should be working, not whining, so I’ll finish this up with just one more problem; inability to edit a closed ticket.
Since CloudBees uses Zendesk for supporting paid customers, developers are expected to bring tickets to completion, to the “closed” state. I’m pretty sure we aren’t unique. The problem is that once a ticket is closed, one cannot make any further updates.
Say another ticket was filed later by somebody else that is seemingly related? Can’t add a comment to link to it. If a detective work led to an old “unresolved” case and you came up with a new hypothesis that might explain a behaviour? Can’t put it there. Adding a new tag? Nope.
My colleague Ben Walding made an observation that Zendesk probably has a different kind of audience in mind — ones where a relatively unsophisticated “level 1” support people sitting in an office somewhere in Asia goes through 100s of tickets every hour as fast as possible. In other words, Comcast or AT&T kind of support. Prominence given to features like a templated response backs up this assumption. I can only assume Zendesk works well for those use cases.
But if you are considering Zendesk and your use case is more like ours, the sophisticated software support, then I hope you learn from our mistake and stay away from Zendesk.
8 Comments Add yours
Sorry to hear about your experience. It sounds like you’re using Zendesk mainly for bug tracking. Zendesk isn’t designed as a bug tracker, but JIRA is excellent for that. We have an integration with JIRA to bridge the gap between bug-tracking tools and Zendesk. We use it ourselves, and it might help you out. It would be great to hear more of your feedback and discuss the integration. I emailed you directly to find a time.
Product Manager, Zendesk
Thank you for reaching out. Now that I feel better by writing it. I feel bad how it must have come across to you.
We don’t use Zendesk as a bug tracker, but as a shared investigation tool for customer issues. So as KK explained we have to make tons of reference to previous comments, attached logs, other tickets. We also sometime have to share ticket within engineering, but ticket as a sole owner, so we had to setup our own triggers to “ping” engineers. Has also limited priority capabilities, that depend on customer subscription in our case, and can’t be implemented with native Zendesk automations.
I also agree with KK analysis on ZD target audience: multi-tab UI with “next” button on list suggest a “handle max tickets per minute”. This isn’t the way we do support.
Not even considering UI slowness I already reported, has been improved but still don’t offer the smooth experience I’d expect.
Hi, I agree, Zendesk is way too bloated with features and you can easily feel uber frustrated with their app. Have you found a solution you enjoyed using?
If it was up for me, I would have used JIRA. Our engineers have more experience with it, including tooling and automation.
But at this point, the problem isn’t purely technical any more. We have reporting and automation developed around it, customers have been educated to use it, and we have amassed data in it. All these things create a substantial cost to the switch over, and I doubt if our complaints are sufficient to justify it.
And that was all the more reasons to write the post to vent the steam.
I am Chirag Shah and i am founder of IntegrateCloud Inc (www.integratecloud.com) and we have launched a product which allows seamless connection between Zendesk and Atlassian Jira.I would really appreciate if you can go through this overview video and try free for 30 days on our website (www.integratecloud.com).Please use google chrome or Mozilla or IE10.
Youtube URL (Overview on Connecting Zendesk and Jira)
Interesting! It could always be worse though I suppose. For instance, you could be using Altiris or Manage Engine.
I’m on the customer experience side of Zendesk. The reason I hate Zendesk is that the responders don’t usually know what they are talking about and don’t read the information sent. This has been my complaint for YEARS.
I’ve repeatedly rec’d canned replies that have little or nothing to do with my question, the steps already taken to solve a problem totally ignored. I scream every time a vendor I have to work with, whose product I’ve purchased, relies on the illiterates at Zendesk.
Now BigFishGames is using Zendesk and CS is horrible. I realize the vendor sets the rules about what CS or solutions they will make available to the public, and some of what I’m encountering is not Zendesk’s fault. I just had to vent because of all my past experiences.