Organizations running a Zendesk-powered help desk can accept new tickets via e-mail 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 e-mail, through customizable 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 labs.eweek.com 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 per agent, per month Starter edition, a $29 per agent, per month Regular and $59 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 customization and scalability options. For a full rundown on the three editions, see http://www.zendesk.com/compare.
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 e-mail 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.
When it came to customizing 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 labs.eweek.com site are considered by the Labs' 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 e-mailing 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 e-mail notifications for the relevant agents. It was easy to customize 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.