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/

Servicedesk+

[MyrddinBach]

Try Servicedesk Plus from Adventnet. They have a free version you can use. http://manageengine.adventnet.com/products/service-desk/index.html

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

[Rob Riggs]

We use RT at my company. It's been in use for over three years. We're at the 150K ticket mark at this point with 300+ users. We use it for production processes, production support, CIT/helpdesk, systems admin, software development process and more. We use it a ton. The complaint that it slows down with a large number of tickets is a valid one. We also have a ton of ticket queues and a very busy home page which makes it even slower. But we're pushing something like 60K tickets a year right now so it's not slowing us down too much.

One thing that helped was to have it start feeding a Google Search Appliance with content on every update. Now we use the power of Google to index & search the content, which makes searching through tickets much more bearable.

Re:RT

[ribo-bailey]

I used RT at the last place I was a UNIX admin. It's not a terrible system, but writing extensions in perl/mason was not a simple task, do to what should have been simple reporting metrics.

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

[theillien]

It's still slow but otherwise quite usable (not as slow as it used to be). Highly customizable and extensible, too. While it isn't the most polished app out there, it has a strong user base with various options for support including community and paid. There are many recommendations I could offer such as not uploading binary files and optimizing the database on a regular basis.

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.

Re:OTRS

[nicolas.kassis]

I second the choice of OTRS. Good system.

I hear Good Things about RT

[IMightB]

Unfortunately, my company uses the godawful Siebel.....

http://bestpractical.com/rt/

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!

check out otrs

[DarkOx]

OTRS is what we use. Google it. Its great and its FOSS. If you know a little perl you can make it look and act anyway you want.

Try One or Zero helpdesk software...

[jkrise]

http://www.oneorzero.com/

We've been using this tool for more than 6 years now. Excellent code, easily customisabele... it's written in PHP. We've modified the default software to include SMS, email alerts, SLAs etc. Initially we used it for Helpdesk, but now we've extended it to Accounts, Leave Management, Purchase Requests, General Administration, HR dept. and even for Bug Tracking in s/w development.

Reply under this post and I will email more details.

Web Help Desk Software

[SpikeT]

Hands down it has to be the Web Help Desk Software: http://www.webhelpdesk.com/ We needed a customer web portal, an faq knowledge base for self-help (to get them off our backs), customizable ticket form submission with custom fields and customizable ticket categories, email-to-ticket conversion, auto-ticket routing to our techs based on skill-set, customer satisfaction surveys, escalations, reporting, service level agreements with alerts, track time spent on tickets (and report on them), and most importantly, it had to look professional, as it is forward facing to our customers ...and not look like we brewed it up in a day. (we also wanted to run it on a mac os x server, and it does! Win and Linux installers too; don't let the mac bit scare most of you ;) We got it all with WHD! Couldn't be happier. We looked at their Free Edition but it is only for one support agent. The Lite Edition may fit your needs, but we need to track computer and software assets, which was not avail in the Lite Edition. They have stellar support and the UI looks totally "enterprise" and less "spreadsheet-like" vs. most of the open source and php digs out there. Again, couldn't be happier! Worth a peak! :) 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

Re:ruQueue

[AlXtreme]

Why is it that so many PHP programs only work with MySQL? Is it because PHP lacks a decent equivalent of DBI?

Nope, there are a number of database abstraction layers (PDO comes to mind).

PHP programmers (at least the kind who code directly with mysql-statements) tend to do things as quickly as possible with the least amount of effort. The amount of tutorials and snippets that also do so simply keeps the average PHP programmer coding against MySQL, and only MySQL.