Best FOSS Help Desk Software For Small Firms?

Nocts writes "I'm currently working for a moderately sized company that manages a large portion of its internal help desk questions through a Jabber-based chat room. What we're looking for instead is an open source, preferably Web-based solution that will give us the ability to have floor representatives queue questions and concerns in a similar fashion to BugTraq, directed at the help desk. Email capability would be preferred for elaboration of specific issues, but the more we can centralize everything into the queued system the better. Any recommendations and experiences? Just about any language is doable since I have the ability to configure and upgrade our servers and we're looking at about a user base of 100 people, with around 5-10 questions a minute."

Comments

100 people, 5-10 questions per minute?

[bakuun]

That's one helpdesk question per user every 10-20 minutes.. my god.

Re:100 people, 5-10 questions per minute?

[Nocts]

As the submitter, I should have elaborated in the main article so my apologies. We have ~100 users asking questions to helpdesk with an average of 5-10 questions a minute from those same users and it is being fielded by 2-3 actual helpdesk representatives at any given time. That's a silly number for representatives to require answers for what are generally common-sense responses, I agree. While we streamline our helpdesk ticket process we will also be reviewing our training procedures to eliminate the questions that these people should be able to answer themselves. While we could also just hire additional Helpdesk staff, it doesn't change the fact that Jabber is a terrible way to manage floor-level questions, especially when documentation is concerned.

Re:100 people, 5-10 questions per minute?

[Nocts]

3 people would have to answer each question in 20 seconds or less just to keep up

Correct. Since the questions are from our floor reps and not the clients the actual inquires can be something as simple as "Is x property out?" with a simple yes/no answer. And the system is generally in place for questions that the reps can not answer on their own. Our larger problem is the retraining of procedure and encouraging the RTFM method, but it doesn't change the fact that we needed a more elegant solution for documenting the escalated helpdesk issues.

And yes, sometimes the questions would be queued in the chat room with the simple questions answered in priority.

Re:100 people, 5-10 questions per minute?

[Anonymous Coward]

In my experience, RT ("Request Tracker") works well for 100-1000 users.

According to the site:

RT is an enterprise-grade ticketing system which enables a group of people to intelligently and efficiently manage tasks, issues, and requests submitted by a community of users.

The RT platform has been under development since 1996, and is used by systems administrators, customer support staffs, IT managers, developers and marketing departments at thousands of sites around the world.

Written in object-oriented Perl, RT is a high-level, portable, platform independent system that eases collaboration within organizations and makes it easy for them to take care of their customers.

RT manages key tasks such as the identification, prioritization, assignment, resolution and notification required by enterprise-critical applications including project management, help desk, NOC ticketing, CRM and software development.

RT is used by Fortune 100 companies, government agencies, educational institutions, and development organizations worldwide.

http://bestpractical.com/rt/

RT

[dg41]

What about RT? http://bestpractical.com/rt/

Re:RT

[jgaynor]

RT doesn't scale well. We used it at Rutgers but around the 100K ticket mark it started to tank. So we rewrote it:

http://ruqueue.rutgers.edu/

Very capable.

Re:RT

[ToddChapman]

RT Rocks. Great software, great community, lots of good extensions available. Our company is a heavy user of RT. We have one instance for external requests and one for internal requests. It was really easy to customize for our exact needs. Note: I wrote Asset Tracker, an asset tracking (duh) extension to RT. http://code.google.com/p/asset-tracker-4rt/

Re:RT

[LinuxOnEveryDesktop]

We're at almost 200K tickets. RT scales fine, you just have to tune it a bit. And run it on PostgreSQL, and *definitely* tweak your PostgreSQL for performance.

In older versions, many indexes were missing by default. That may have been fixed more recently. Also, PostgreSQL 8.3 made a huge difference for us performance wise.

Re:RT

[trawg]

We use RT at our work at the moment for both development/bug tracking and also user support. We had a LOT of teething problems and invested (imo) far too much time in trying to making it work properly - lots of odd performance issues, regular 10sec + load times, all sorts of weirdness. We spent a lot of time tweaking and finally got it running nicely (note: we're webdevs working on high utilisation sites so we know what we're doing as well, or at least think we do).

Aside from all the messing around - I don't like it for user support. We're doing maybe between 600-1000 inquiries a month - I can't imagine doing it at the sort of volume specified in the OP.

My big woes are the lack of good reporting, so its hard to identify trends - short of putting issues in queues I can't get visibility on what issues are cropping up regularly unless our staff remember them.

Also, there's no option for doing Standard Responses (at least not in the base install), meaning every response needs to be custom-written. There might be an addon or something for this; I haven't looked.

I got /really/ used to this in FogBugz (which I really liked for support purposes, but we got turned off by the price tag and closed-sourceness - we wanted something open so we could extend it. We've made a few changes to RT although have found hacking on it to be a pain in the ass (largely due to our inexperience with perl/mason/etc.

We also rolled our own and use that, which works much better for our purposes, as it is heavily customised for our specific uses.

All that said, I'd encourage you to try RT and see if it meets your needs. It's not terrible by any means, it just doesn't do what I want as well as I'd like.

Re:RT

[Bazman]

We have a pretty small RT system for managing departmental issues. It used to get very slow, and checking on the server revealed apache spinning like mad, so we'd have to kick apache and it would get going okay again.

I asked our university RT admin guy if he ever had this problem. And he said no, his RT was always pretty slick. Then I saw a lightbulb come on. Ah, he said, I do have a cron job that kicks apache every night at 3am. Why? I asked. Well, he replied, because RT used to get very slow and their apache would spin, was the answer.

So now we kick our apache at 3am every morning and RT hasn't grinded to a halt since.

OTRS

[alexborges]

otrs is ITIL compliant, has a webservice interface and generally rocks.

We use them and so should many others.

Another great one, but really complicated to deploy, is RT.... but its pretty cool, its what CERT uses AFAIK.

Open source help desk suggestions

[Amigan]

Here's a website that lists many of the open source helpdesk options: http://www.opensourcehelpdesklist.com/ The only one I have experience with is ZenTrack and both the users and helpdesk folks found it easy to use. jerry

CalemEAM

[Shark4126]

Got CalemEAM running over here. It has a massive number of features, but you can limit it to only the work order portion if need be. Open source and super customizable: http://eam.calemeam.com/eam/

Yes, RT

[br00tus]

We used RT at my last company. Keeps track of tickets, with different ticket queues, and different user groups. People can do it by web or e-mail or both. You can search the system for old tickets as well, although it's not a good idea to search the body of the message if you have a lot of tickets going back many years.

Re:Yes, RT

[sqldr]

If there is one piece of software I never want to use again, it's RT. It's all fine until you start modifying triggers and templates. First there's the evil, kludgey combination of bad perl and bad Mason which you have to write overlays to, then once you've done this, you can't upgrade! If you upgrade, all of your overlays break. So you end up stuck with an out of date version with patch on top of patch. Interface is a little ugly too.

Liberum

[SoupGuru]

I really liked Liberum when I used it a couple of years ago. It's really simple, web based, and can use Windows integrated authentication which was really nice at that job. Might not be exactly what you're looking for but I thought I'd mention it since google doesn't find it very well.

http://liberum.org/Default.aspx

Mantis

[_Pablo]

http://www.mantisbt.org

How about GLPI

[EvilGrin666]

I work as a network manager in a school in the UK. We use a French Helpdesk system called GLPI. We also use OCS Inventory as recommended to populate the database with our hardware. Overall the solution has a few minor quirks, but if teachers can cope with it I don't understand why office drones can't!

The disconnect here

[symbolset]

The problem here is that what you need is a dispatcher support system, not a helpdesk support system.

A dispatcher support system has things like maps to objects and a website for checking inventory levels. Your dispatchers are experts who field questions about that sort of thing, and are keyed into the systems where the questions are answered. The previous poster is correct that chat rooms work well for this. If your reps are local, radio works well too.

A helpdesk system creates trouble tickets that are tracked, assigned to service reps and accounted for. They're for blocking issues where nontechnical workers need technical help. If you had 5,000 customers and you're seeing two calls a minute, there's a major network outage and your call center stops entering tickets in minute two - if they can enter tickets at all with the network down. For a normal tech shop one or two tickets a year for the average customer is a pretty reasonable expectation.

A trouble ticket system would work well for those questions that need escalation and all of the available trouble ticket systems can support thousands of trouble tickets per minute because they're automated technology solutions. Your problem will be not letting the tickets get out of control. You'll need to teach your dispatchers not to create tickets if they can find an answer in less than a few minutes.

That said, have you tried sourceforge? They have about 500 CRM systems with trouble ticket tracking. Search for "CRM".

Re:ruQueue

[that_itch_kid]

XSS and SQL injection attacks are strongly correlated with bad coding practice.

Don't get me wrong, the problem is probably more prevalent with PHP as PHP is such an easy language and thus attracts a larger number of amateur/incompetent programmers. That doesn't meant you can't write secure code in PHP.
I'm currently re-writing a logistics system in PHP, and sure enough, XSS/SQL attacks would have been child's play in the original code (Even from the login page).
I can assure you every single one of my database inputs is checked for injection attacks (Even those that came directly from PHP built-ins like time()), and every piece of data that goes onto a web page is checked for scripts as well.

Writing secure code can be a difficult process, but it's not impossible even with PHP.

Cerberus Helpdesk

[waa]

Giving up my mod points to recommend Cerberus