Our key requirement is to be able to reassign incoming tickets and have simple notification to the person it was reassigned.
Our key requirement is to be able to reassign incoming tickets and have simple notification to the person it was reassigned.
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.)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.
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.
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.
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
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.
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)
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.
The latest 3.8 is not that bad with new theme.
I can even do a free install/setup for any non-profit.
And don't forget the http://hiveminder.com/ from same company.
EDIT: Added links.
http://blog.bestpractical.com/2008/07/today-were-rele.html#s...
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.
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.
We tried it and got hooked.
5 people doing support, thousands of tickets by now and not a single glitch. The built-in wiki also comes in handy.
I had to fiddle for a bit with plug-ins to get email notification and ticket handling to be working properly.
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.