Zendesk Hosted Customer Help Desk: Review

Organisations running a Zendesk-powered help desk can accept new tickets via email or through a web-based form interface, as well as create tickets by flagging Twitter messages or forum posts and escalating these communications into support tickets. On the help-desk agent side of the equation, support personnel can view and process open issues through email, through customisable ticket views or via mobile applications on Apple’s iOS or Google’s Android platforms.

What’s more, all data stored within Zendesk is accessible and open to modification through well-documented application programming interfaces.

For my tests of Zendesk, I tapped the company’s free 30-day trial offer to create a help desk of my own and populate it with data from our eWEEK website. I had no trouble importing user and issue data from a MySQL database through Zendesk’s bulk import and API features.

Companies in search of a no-hassle help-desk solution would do well to evaluate Zendesk, which is priced in three tiers of functionality, starting with a $9 (£6) per agent, per month Starter edition, a $29 (£19) per agent, per month Regular and $59 (£38) per agent, per month Plus editions. The Regular and Plus editions expand on the Starter edition (which allows a maximum of three agents) with added customisation and scalability options. For a full rundown on the three editions, see http://www.zendesk.com/compare.

Testing Zendesk

As one might expect, Zendesk eats its own dog food when it comes to providing help desk, forums and knowledge base services for the Zendesk product, and I found that interacting with the company’s help-desk resources gave me a good feel for the product from a user perspective.

All told, I found Zendesk’s help-desk resources informative and easy to navigate. However, when I first attempted to comment on a forum post, and was redirected to a log-in page, I couldn’t figure out why the site’s authentication dialog wouldn’t accept the credentials for the account I created alongside my trial help-desk instance. It turned out that the account I created was associated only with my trial help desk — I had to create a second account to act as a user of Zendesk itself, even though, as the creator of a trial help desk account, I had, by definition, already registered with Zendesk as a user.

With that said, I was happy with the variety of authentication options offered to users — I could create a typical account with Zendesk, sign in with my Twitter account or provide an OpenID account URL for authentication. As web applications proliferate, I find it increasingly annoying when services require that I invent a new user name/password combination. All told, the forums/knowledge base setup worked well. While reading up on the service’s pricing plans, I noticed what appeared to be a typo on the service sign-up page, and added my comment to the forum post, along with a screen grab as an attachment. About an hour later, I found in my email an “updates in topic” notification, in which a Zendesk support agent acknowledged my minor bug report.

The Zendesk service’s knack for encouraging organic knowledge-sharing among users, with apparently auto-generated related topics lists to aid in navigation, is a definite benefit, but it requires a certain amount of “gardening” to weed out confusing or outdated information. For instance, a recent “what’s new” forum post in the Zendesk forums was displayed with a list of related content that included a feature request for SSL support across all account types. The thread, from 2008, was from a time when the lowest-tier account type lacked SSL encryption beyond the log-in pages and offered no indication this had subsequently changed.

Customisation

When it came to customising my test help-desk instance, I opted for a business process test case similar to the one I used in my recent review of Bonita Open Solution. With the goal of ensuring that product pitches we receive through our eWEEK site are considered by the staff, I set about importing vendor representatives into my Zendesk test instance as users, and then importing those vendors’ pitches into the system as tickets.

In the Zendesk management console, I found a tool for importing user lists in the form of a CSV (comma separated values) file, which was easy enough to do by querying our MySQL database and exporting the result in the proper format. I included a dummy password with each account, to prevent Zendesk from emailing each user to obtain a password for logging into the system. Alternatively, I could have configured the service to authenticate against an external source, such as Active Directory, but I did not test this functionality.

I noted that Twitter user names are not among the supported user fields for the CSV update, so I would have to add those in a second step, either manually or through the service’s REST-based API.

Importing the product pitches as tickets also required the API, which I found fairly straightforward to operate, by fetching or sending data in X M L format using the command line tool curl. I used Talend Open Studio to convert the product entries I meant to load into Zendesk from MySQL query rows into individual files formatted according to the documentation at zendesk.com/api, and tapped a simple shell script to send each entry into the service.

With a healthy set of user accounts and support issues in place, I was able to assign tickets to individuals or to groups, which, by default, would generate email notifications for the relevant agents. It was easy to customise the tickets that would appear on a particular page by creating views — based on arbitrary search criteria — which could apply globally or to particular users or groups.

I took the iOS Zendesk application for a spin on my iPod Touch, and managed to view and update the same lists of issues and views that I found on the product’s web interface — as long as I remained connected to the Internet.