Recently, we’ve been looking at helpdesk alternatives. Up to this point, we’ve been using Zendesk, and for the most part have been relatively happy with it. However, the pricing is crazy: as soon as we added one person (going from 3 to 4), pricing for Zendesk went from $20 per year to $120 per MONTH.
It was important that we find a solution that we could live with, long term.
For the most part, we are a group of developers and webmasters. We all “chip in” to help in our areas of expertise. Support is kind of a team effort, even though for the most part support volume is low.
Last week I started evaluating – yet again – helpdesk options. Our current criterion is that it be relatively easy to use, and have the primary features we need. (easy != simplistic). This includes good email support, a “ticket” system (not a forum), and the ability to integrate with our systems.
Nico just reminded me what our original criteria for a support desk was. Here are her email notes on what we’re looking for:
- To be affordable for a larger team, – OK
- Have canned response features, – OK
- Allow replying via email and properly associating the reply with the ticket*
- Provide a KB feature, – OK
- Allow domain mapping – OK
During the evaluation what we found is that Software as a Service helpdesks, with their per-user pricing, just isn’t a good fit for our use case: needing to have lots of users, but relatively low volume in number of tickets.
Sometimes we don’t receive a support request in a week, other times – for example, when a new version of PHP comes out – the desk can be quite busy. Some systems do have ways to add additional users on a temporary basis, but for various reasons are otherwise unsuitable.
What really surprised me is after weeks of on-and-off evaluation of both Software as a Service, proprietary, and open source solutions, the one that _best_ fit our needs was the classic osTicket system – an open source, PHP / MySQL ticket system that has been around for about 10 years.
No, osTicket isn’t perfect. It’s UI could use an update, and you won’t find fancy routing rules or (as of yet) social media integrations. What you will find is a solid, PHP-based helpdesk that you can run with unlimited usage on your own servers.
Here are some things I really like about osTicket:
* It meets all of our criteria, except seamless email handling
* Of course, it’s unencrypted, priced right, and supports unlimited users
* It is quite easy to install
* The code is available on GitHub
* It has most of the features I’m looking for, and the others aren’t going to be hard to implement. The remote API will making integration with Twitter and Facebook (for example) pretty straightforward.
The big gotcha – email handling
For a long time, we’ve been using a service for transactional email. This is, in part, because my time is not best spent managing email and email deliverability. It’s also because I strongly believe that email servers don’t belong on application servers, period. I specifically do not install any outgoing (MTA’s) or incoming (POP/iMAP) systems on my app servers.
This frees up tons of resources and prevents configuration headaches, while resolving a whole class of security and performance issues. (A post for another day, perhaps)
A ticket system, however, needs both incoming and outgoing email to be useful (one reason so many open source ticket systems – especially those created as plugins for Joomla! or WordPress – failed to pass our requirements is that they did not gracefully handle email ticket responses).
So, how are we going to manage the requirement that the helpdesk system handle email, seamlessly?
Recently, a friend turned me onto Mandrill, a remote email service by the company behind MailChimp that handles both outgoing email and (to my surprise and delight) incoming email as well.
It does this by accepting the mail for the domain, parsing the email, then sending it to a web-application via a “web hook”.
What I did to connect osTicket to Mandrill:
a) setup osTicket to use the Mandrill SMTP server
b) setup Mandrill so that it would POST incoming tickets back to the app
c) wrote a small “plugin” which would then forward Mandrill mails to osTicket using the osTicket API
The integration took under an hour. Because injecting the email into osTicket wasn’t quite as straightforward as I’d like, I “cheated” and had the Mandrill POSTed message re-sent via the osTicket API.
This integration could be made more robust and performant, but for now it works well. It’s a great alternative to polling POP email accounts or setting up piping.
There is still one feature that is required before we release the new helpdesk, however. That’s the ability for staff users to reply to tickets via email, so we aren’t having to constantly log into the system.
There are a few patches that add this feature available “in the wild”, so we’ll be integrating staff email support functionality over the next few weeks.
To follow along, feel free to “watch” the our fork of the osTicket 1.7 source code on github.
osTicket is under active development, today. It’s a worthy competitor to (much) higher priced solutions, especially if you have a collaborative team that would otherwise make having all your people on board cost-prohibitive.
You can download osTicket at their website, osTicket or clone the official osTicket from Github.