Best FOSS Help Desk Software For Small Firms? 321
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."
100 people, 5-10 questions per minute? (Score:5, Informative)
Servicedesk+ (Score:1, Informative)
RT (Score:5, Informative)
OTRS (Score:3, Informative)
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.
I hear Good Things about RT (Score:3, Informative)
Unfortunately, my company uses the godawful Siebel.....
http://bestpractical.com/rt/ [bestpractical.com]
Open source help desk suggestions (Score:5, Informative)
CalemEAM (Score:3, Informative)
Yes, RT (Score:4, Informative)
Liberum (Score:5, Informative)
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 [liberum.org]
Mantis (Score:4, Informative)
http://www.mantisbt.org
Re:RT (Score:5, Informative)
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/ [rutgers.edu]
Very capable.
Re:OTRS (Score:3, Informative)
How about GLPI (Score:4, Informative)
check out otrs (Score:3, Informative)
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... (Score:3, Informative)
http://www.oneorzero.com/ [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.
Re:RT (Score:3, Informative)
Re:RT (Score:3, Informative)
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 (Score:3, Informative)
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:Yes, RT (Score:4, Informative)
Re:RT (Score:2, Informative)
Web Help Desk Software (Score:2, Informative)
Re:100 people, 5-10 questions per minute? (Score:5, Informative)
Re:100 people, 5-10 questions per minute? (Score:3, Informative)
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:RT (Score:5, Informative)
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 (Score:2, Informative)
The disconnect here (Score:5, Informative)
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 [sourceforge.net]? They have about 500 CRM systems with trouble ticket tracking. Search for "CRM".
Re:ruQueue (Score:3, Informative)
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 (Score:4, Informative)
Re:ruQueue (Score:3, Informative)
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.
Re:RT (Score:5, Informative)
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.
Re:100 people, 5-10 questions per minute? (Score:3, Informative)
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/