o Our legal team uses to track contracts
o Our helpdesk uses to track 20-30 requests a day. With SLA Timers.
o Our Project Teams use to track $20-$30 Million Dollar Projects,
with 30-50 subtasks each with independent dates.
And, oh, Yes.
o Our engineering team uses to track software defects (It's original purpose)
The 4.0 product is mind blowingly awesome, particularly with it's _super_ fast full text query (thanks Lucene). And, you can't beat the price for small shops - $10 for 10 users. (It goes up quickly after that, but the inexpensive buy in is great for small companies.)
It is big, it covers alot of ground, therefore it has large software product illnesses - complicated to setup, hard to master, tricky to optimize to run fast. However, it is a nice product for some heavy-duty task managing once you have it set up and running, absolutely nothing is horrible.
For a smaller project, though, I would roll your own to specific requirements, or would use a smaller package or product - because JIRA does everything and that could be too much sometimes.
The main issue it has is that the management tools are a hack. They (Atlassian) started with a very simple system built around their relational database schema. As more users adopted the system, there was increased demand for a number of additional features to be added in. These have all been tacked in and the fact that they are all an afterthought really shows through in how you setup and manage JIRA projects.
From an end user point of view, JIRA is bad because it is slow, has a bad user interface, and really doesn't quite fit most workflows. If you're trying to track a trouble ticket, which is what JIRA was originally designed for, then it will perform the job adequately. However, anything else forces you to fight more against the system design to get things just the way your work process needs to be.
Very, very, rarely do I burst out in complete and utter laughter to the point at which I actually drop my Laptop. This is one of those times.
I'll take these one at a time:
1) "These have all been tacked in and the fact that they are all an afterthought really shows through in how you setup and manage JIRA projects."
Slowly, but surely, Jira is going to a consistent role/schema/custom field mechanism format for managing issues. Jira _did_ start off as a "Software Defect Tracker", and, if you look closely, you can still see the DNA in the product, but, with things like issue-type-screen schemes, and custom workflows - you really can make it look like whatever you want.
2) "Jira is slow" -
I don't know how one makes it slow. I suppose it's possible. But our 8 Gigabyte Hard Disk, 2 Gigabyte Memory virtual machine currently has 45,000 issues that it's tracking, and searches come back pretty much instantly. Perhaps your Issue database is a lot larger than ours. I find it hard to believe your virtual machine is slower.
3) "Bad User Interface"
- simple. Straight forward. Create, Edit, View, close. Dashboard for custom views of your data.
4) "Doesn't quite fit most workflows"
- Uhm, it has a world class workflow _editor_.
5) "Trying to track a trouble Ticket, which is what Jira was originally designed for" -
Now we're going to inaccurate to completely polar opposite of reality - Jira was originally meant to go head-head with Bugzilla - Jira is a take off of GoJira, which is an alias for Godzilla, from which Bugzilla is named courtesy of Mozilla. Yes, it is rather indirect. Anyways, the point is Jira _evolved_ into an issue tracker from a defect tracker, in much the same way quicken evolved into an accounting package from a personal finance tool.
Anyways, as One who just spent four years using (and dearly loving) jira, and is now having to suffer the absolutely and utter agony of "Upgrading" to a Remedy ITIL suite, I can tell you that the Jira interface is a delight compared to this godawful web interface in Remedy. Now _that_ is a bad user interface - I challenge any remedy user out there to argue differently.
We're not quite ready for prime-time, but my startup (Mad Wombat) is developing a helpdesk application called Tracker, which might suit your needs, provided you don't mind us still being early in our beta.
Tracker is a very tightly focused piece of software; it doesn't have public forums, or a wiki, or a knowledgebase. It just tracks problems, which can be submitted via email, via the web interface, or via the REST API.
Now keep in mind, it's still early in our beta. The major features all work, but there are plenty of bugs, which we're fixing as fast as physics allows. Although we do use Tracker as our own customer support and bug-tracking application, so we've got a lot of motivation to make sure that it works.
Shoot me an email if you're interested: don@madwombat.com
Tender (http://tenderapp.com/ ) is pretty nice, and it looks like it's almost always cheaper than Zendesk. (I think the only time Zendesk would really be cheaper is if you're a 1- or 2-person team that can get by on the starter plan.)
As a support person, I don't find Tender especially amazing, but it gets the job done and never really gets in the way. But, more importantly, as an end user, I find Tender to be much easier and more pleasant to use than Zendesk. I cringe whenever I go to someone's support site and it's Zendesk.
We user Tender and absolutely love it. They've occasionally have issues with delayed jobs, but they were minor quirks. We use it all the time and cannot recommend it enough.
I was evaluating both zendesk and tenderapp last week. Tenderapp had serious confirmed email problems so I had to wait one day to see mails appearing on tenderapp.
This is not the thing we would like as an early startup.
We've to evaluate other services now because neither zendesk nor tenderapp are usable (imho)
Hey rmoriz. I just wanted to follow up on your email issues with Tender. Did you have an open support discussion I could pull up? We certainly strive to provide the best service possible as we built Tender for supporting our own services and clients and are highly dependent on it.
My co-founder wanted to give up tender because no mail were processed so I checked google apps mail forwarding and found no errors.
As I was unsuccessful I've tweeted to @tenderapp and got a reply some hours later stating that there was indeed a mail receiving problem.
As tender/entp also uses google apps, it's kind of scary to see that there was a problem. I mean that's probably the easiest combination to deal with imho.
Sending email isn't processed by Google Apps though, only incoming. We have a dedicated email server that handles outgoing mail. Sorry about the issue though and I would love to take another look at the problem directly. Some edge cases come up that take some pretty deep digging to find out what's wrong between the main email server and the setup on the users end, but that's typically pretty rare. I've only had that happen on a few isolated instances.
I don't recall if RT from Best Practical has the particular feature, but otherwise it's a well-rounded and battle proven solution. It's ugly as hell though.
I love RT. Real solid product with great hackers behind it. And you did not mention that it is open source and takes hardly 1-2 hours if you know your way through CPAN and Apache.
The latest 3.8 is not that bad with new theme.
I can even do a free install/setup for any non-profit.
Incredibly powerful, free, customizable. Expect to learn a little Perl if you want to integrate with external systems, as you can write Perl scripts to handle any transaction.
However, it has both the features that the GP wanted out of the box.
In my haste to up vote this, I accidentally down voted.
We've handled a couple hundred thousand support tickets in RT, some of them hundreds of interactions long, and it's still scaling happily.
Using email for support is liberating and using the web interface is phenomenal too. Can't complain about the licensing, but you'll definitely want someone who knows Perl and or the O'Reilly book.
Another vote for RT. It is ugly and looks (or at least looked) really hacky and old, but once you actually sit down and use it, it blows everything else out of the water. RT is the only help desk software that I've used that felt like it was written by people who had spent real time in the help desk trenches, studied the problem up close and actually got the whole help desk procedure.
The software is awesome to use and was clearly made by someone who spends lots of time using help desk software -- minimal clicks to get things done, automation rules based on predefined responses, etc.
It's also extremely flexible, and fairly affordable. We manage a pretty decent request load (many 100s/day) with a fairly minimal support staff.
Our key requirement is to be able to reassign incoming tickets and have simple notification to the person it was reassigned.