While nothing will ever be perfect, it always seems like everyone hates (or is, at least, unhappy with) their ticketing system. If you could have the "perfect" solution, what would it include? I'm pitching the idea.

For me it'd be:
-Web client with a formatted mobile version (For at least, iPhone/Android/Pre webkit browsers)
-...or a native mobile application that taps into the database
-Web client (duh)
-Some sort of "module system" so complexities can be removed for those that don't need them. Like, it can be as powerful as you want. If you don't need a feature, take it out.

This is what I've got right now..., I'd like to hear what you're thinking.

  • A system where the following is automated, 2 Versions. 1) Bastard Operator From Heaven: Parses ticket, analyzes problem, fixes problem, sends nice reply, dispenses beer to the admin to verify that the problem was resolved. Bastard Operator From Hell: Parses Ticket, Deletes Requesters Account, Sends Pleasant Reply. Aug 5, 2009 at 21:05
  • The perfect anything requires three things: predict the future, read minds, do what we mean.
    – Ernie
    Aug 5, 2009 at 21:22
  • So a perfect ticketing system would be what others expect a sysadmin to be? Aug 5, 2009 at 22:06
  • @John: Yeah. Just as importantly, it would basically replace us.
    – Ernie
    Aug 5, 2009 at 23:02

7 Answers 7


There are plenty of solutions out there. One solution that I'm familiar with is from Kayako. Granted it's not free, but it seems to offer what you're asking for.

From the Kayako site:

Kayako help desk software is turn-key and very easy to set up, requiring nothing more than an average web server. Be up and running in a matter of minutes using the automatic installer.

Again, they're probably not the best, but I've found their products to be solid.


You should be more specific as for the purpose of this ticketing system. There are at least two types:

Incident tracking system

  • OTRS (F/OSS)
  • RT (F/OSS)
  • Many fall under the CRM monicker

Bug tracking systems:

  • Bugzilla (F/OSS)
  • FogBugz
  • Trac (F/OSS)
  • That rails-based trac look-alike whose name escapes me (F/OSS)
  • Mantis (F/OSS)
  • Jira

OTRS and RT both have a long track record, are written in Perl and quite easy to customise. They both are butt-ugly but it took me only a couple hours to fix OTRS and make it look decent, but then I'm quite good at CSS.

OTRS is very well supported, the commercial support packages are quite affordable, the company behind it appears quite responsive. They have also integrated all kind of standard buzzword bingo-compatible features such as ITIL and whatnot.


We've gone through a couple of helpdesk ticketing offerings, including one which was pretty much customized for us.

I've been the main driver of changes, because I like ticket managers -- I have the memory of a sieve, and with a good ticketing system I don't have to remember. The system does. But due to problems with the various systems, my co-workers have been more reluctant to use them.

There are two key things I've learned:

First, Management MUST use the tool and ENFORCE its use in ALL cases. These things are driven from the top down. Any kind of task management will get in the way of getting things done, and if techs are under pressure to make customers happy, they'll take practically any shortcut available to them.

Second, It has to be simple. Management likes to have stages and phases and approvals and categorizations and metrics and integrations with asset histories and all that (sorry) crap. But all that stuff gets in the way.

It has to be trivial to open a new ticket. Not click-click-type-type-click-click-select-drag-click-click-type-type-type-type-click. Systems that let customers open tickets by email win for me, especially when emails can be parsed to pre-populate some of the stuff management like categories or queues.

It has to be trivial to update a ticket. Here email-based tools fall down, because most users seem to like the top-post-and-quote-the-whole-[bad-word-deleted]-thing. This makes histories hard to read.

It has to be trivial to change an owner/operator.

It has to be trivial to close a ticket, but techs should be encouraged to write up how it was closed in the interests of building a knowledge base.

The bottom line: it has to make it trivial to do the right thing, or there will be resistance against it.


Some of the features I'd like to see:

  • Clean, simple GUI that did not require user registration, or minimal user interface
  • Easy for customers to track their request
  • Includes an iPhone app with push notification
  • Web and Desktop client
  • Supports ticket creation from Phone call and SMS
  • Good spam filtering
  • Phone call, interesting. Like capturing the audio and playing it back, or transcription. I wonder if Google Voice can be leveraged with that (since they do both).
    – nullArray
    Aug 5, 2009 at 21:04
  • Or even just attaching an audio file. Exchange 2007 has the unified messaging system that does this, so maybe that can be adapted, the call ends up in the support in box, then is added to the ticket queue.
    – Sam Cogan
    Aug 5, 2009 at 21:10

The perfect ticketing solution isn't an "Enteprise" solution.

There may be a great implementation of ServiceCenter, ServiceDesk, Remedy, etc, out there somewhere... but I haven't seen it yet.

I discovered a web-based helpdesk system called HelpSpot on the Joel on Software forum that looked fantastic to me. We gave it a test drive at work, but wasn't enterprisy enough for us. (For big companies, paying someone $150/hour to install software is like offering goats to the volcano gods.)


Generally, the only perfect solution is to roll your own. Under the hood, they're pretty easy ... in fact, I think the PHP-Symfony project is trying to build a generic one that's a plugin you can just modify from there.

The issue gets down to what's important to your organization: In the previous organization I developed one of these for, the three big things were request lifecycle (SOX-ish), interdepartmental request tracking (for managerial fisticuffs), and time tracking (because different departments billed each other for time.) Our only solution was to roll our own, and it took less than a month to do.

The software was written in 2001 when I was a college student intern, and it's still running today ... with a lot of modifications and hacking that made it even MORE exclusive to the oraganization.

At the moment, I use JIRA for software developers, and we use RT for helpdesk because we had too many incidents with JIRA not being explicit enough about who it emailed due to the insanely complex privileges/rights/roles system.


BMC Remedy + ITSM + SRM installed on it

Not the answer you're looking for? Browse other questions tagged .