

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)
Re: (Score:2, Funny)
Seriously. Does he work at Retards R Us or something?
Re:100 people, 5-10 questions per minute? (Score:5, Funny)
Re: (Score:2, Insightful)
He probably means he has 100 people running the help desk not 100 people using the end product.
Re: (Score:3, Interesting)
Re:100 people, 5-10 questions per minute? (Score:5, Funny)
Re:100 people, 5-10 questions per minute? (Score:5, Funny)
Until the next exocytosis, anyway.
Re: (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, R
Re: (Score:3, Insightful)
Perhaps his small firm provides helpdesk services to other firms?
Re:100 people, 5-10 questions per minute? (Score:5, Interesting)
We handle that traffic level with a few simple many-to-many chatrooms. All askers and answerers can see all messages, with highlighting of messages aimed at them. Bad answers are corrected quickly, and stupid questioners tend to get told to STFU: you quickly learn who is competent and who is not to be trusted. New users get up to speed quickly because they can watch the text stream and learn the expected style of communication.
Very interesting. (Score:3, Insightful)
Re: (Score:3, Interesting)
Pretty much, but private with full audit trail, etc. As always, many in-house groups sought to kill it and replace it with something less anarchistic, but those efforts failed because the managers saw that a problem-queue approach would destroy the sharing of institutional knowledge.
Re: (Score:2)
Congratulations on having enlightened management people.
They've been on the endangered species list for 40 years.
Re: (Score:3, Funny)
Re: (Score:3)
Ah yes, the good old zero-n/zero-FF user operator error.
Re:100 people, 5-10 questions per minute? (Score:5, Informative)
Re:100 people, 5-10 questions per minute? (Score:4, Insightful)
Re: (Score:2)
usually the problem with forums depends on the kind of user you have.
If you have technical/interested users, they will spend all day surfing the forums, asking and answering questions (hmmm.... like I am doing right now).
'ordinary' users will just want to know the answer, will not bother to search the forum, and will ask the same old questions over and over.
In the latter case, a 'knowledgebase' type list of common answers is a better option - and if they ask a question that is on that simple-to-view list, y
Re: (Score:2)
it sounds like you are currently solving many problems with single tool. at least attempting to.
i would suggest spreading it out.
for simple questions, leave jabber nad implement forum. make it so that helpdesk personnel rarely answers on jabber (peer help), and somewhat answers on forums. maybe even give moderator rights to some sane user, if you can find one. phpbb might work for that.
create a location that could collect these answers from jabber and forum in a way _users_ can easily find and understand th
Re: (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 docu
What you REALLY NEED (Score:5, Insightful)
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:Is x property out? (Score:4, Insightful)
I'd imagine that's part of the reason (Score:5, Insightful)
They want a helpdesk. One problem you find with support is that if you make support too easy, some people will stop thinking for themselves. When they can get instant answers to their questions, they just stop trying, they ask first without thinking. So I could see something where it's an immediate communication leads to a situation of people asking tons of dumb questions all the time.
Where I work, that's one of a number of reasons why we insist people send e-mail to the help desk. When they just wander in or call, they are prone to ask simple questions they can answer themselves because they expect an immediate response. When a response will take a little bit, they'll solve the problem on their own.
Sometimes I'll deliberately wait on a ticket, doing other first, if it is something simple I think they'll figure out. Often I'm right about this. We'll get something like "My printer is broken help!!!!" Then 15 minutes later "Oh it just wasn't turned on, never mind."
So ya I think IM based support is probably the worst you can have for that. At least with a phone people still have to call, maybe wait on hold, etc. With IM they can fire it off any time, even while doing other things, but it is still near realtime so they expect a response right away. That leads to a real brain shutdown in many people. They find it easier to just IM support rather than think about anything, so you'll get request after request.
Re: (Score:3, Interesting)
Now I know you said free, but I highly recommend you check out Kayako [kayako.com]. I personally have not found anything close to the workflow and capabilities this offers. When I used to work for an outsourced support
RT (Score:5, Informative)
Yes, RT (Score:4, Informative)
Re:Yes, RT (Score:4, Insightful)
Re:Yes, RT (Score:4, Informative)
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.
ruQueue (Score:3, Interesting)
I took a look, but ruQueue seems only to work with MySQL. One of the pluses of RT is that it's somewhat database-independent; we use it with PostgreSQL. Since we use PostgreSQL for everything else, we don't really want to install MySQL just for one app.
Why is it that so many PHP programs only work with MySQL? Is it because PHP lacks a decent equivalent of DBI?
Re:ruQueue (Score:5, Interesting)
Re: (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 databas
Re: (Score:2)
Re: (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: (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:5, Interesting)
Readers might want to take my comments with a grain of salt, as I'm RT's original author and chief architect. I routinely work with clients with RT instances that are well over 100,000 tickets. When using any large application at scale, you're going to need to invest time in performance tuning, but 100k tickets isn't "big" for an RT instance. With a single front end box and a single backend (untuned, but beefy) DB server, I've seen an RT server doing 10,000 tickets on a slow day, bursting to 25,000 with several million in the database.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's absolutely perfect for the volume that I'm currently administering (3K-4K tickets per year, roughly 15K correspondence, 70K transactions) and once you realize why certain things are laid out the way they are, the API is *very* easy to extend and customize.
The last RT shop that I worked in was a completely different story. We were doing 100K+ tickets per year easy (with that incr
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: (Score:3, Funny)
Restarting IIS nightly used to be SOP back in the Windows NT4 and Win2000 days, but Microsoft cleaned up their act with IIS6 on Windows 2003, which we have never had to restart* for any of our applications.
It's nice to see that Apache has caught up to Microsoft circa 1996!
*Yes, I know about automatic worker process recycling, but that isn't nearly the same thing as a service restart. And yes, I know these boxes get bounced
Re: (Score:2)
Your DBAs are incompetant then.
Our RT instance is currently at almost 3 million tickets from the last 8 years, and still going strong. Thats running on a single DB server, and a pair of frontend web servers.
It will run a bit slow if you do something silly like a full text search across every queue, but other then that it's fine.
It's also crazily extendable, although we are about hitting it's limits now, after adding support for a lot of internal processes.
Re: (Score:3, Funny)
We're using a much more robust solution called JIRA.
Automatic JIRA or Manual JIRA [thedailywtf.com]?
Re: (Score:3, Informative)
Re: (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
Re: (Score:2, Informative)
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: (Score:2)
Re: (Score:2, Informative)
5-10 per minute? For 100 people? (Score:5, Funny)
Re:5-10 per minute? For 100 people? (Score:5, Funny)
Re: (Score:2)
Spoken like someone who reads specs but hasnt ever designed products that interact with end users. Answer me this question, do you buy a product designed to meet your average needs or one that meets your maximum peak needs ? When I read the request submitted I immediately understood he/she were talking about the maximum worst case scenario.
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.
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Nice part of OTRS is the ability to set up caned responses that point to online docs that tell the user nicely..
STFU, RTFM you ID10T!
It has saved my company's sanity. I have about 30 canned responses setup to "remind" users that the answer is right there in the wiki, go there and read this, if you ignore us and ask again, you will get the same response over and over and over.
I also like how you can create rules to automatically fire them off to users based on keywords. If set up right OTRS will save your
Re: (Score:3, Interesting)
While pointing to key words in articles is nice for you and all, how does the customers like that?
I know several customer I have who I personally think just get lonely and want to talk to someone for $85 an hour. They call and ask stupid questions like How do I find a file I saved in the "My Documents" folder because word opens to his last saved directory or something. I have one guy who calls about every three to four weeks asking me what his password is for Quick books. I usually have to tell him to look
Re: (Score:2)
We too use otrs. It allows for e-mail creation of tickets, the backend data is stored in MySQL and we use in-house Crystal Reports expertise to extend reporting. You can create custom fields.
The administration is not as well documented as it could be, but the mailing list is active.
I had not heard of RT, so I can't say how it compares, but otrs works well for us.
Re: (Score:2)
otrs is ITIL compliant
Sorry but I had a good look at the demo system, feature list and screenshots.
There is nothing to suggest that OTRS is even remotely close to "ITIL compliant".
I hear Good Things about RT (Score:3, Informative)
Unfortunately, my company uses the godawful Siebel.....
http://bestpractical.com/rt/ [bestpractical.com]
Re: (Score:3, Funny)
I get contract work calls because Siebel is on my resume. I explain that I've helped 3 departments in 3 different companies stage active revolts against Siebel, demonstrating exactly how badly it sucks for anything but sales contacts, and override the VP who clearly got the pretty demo with pretty Gant charts, the permanent invite to 3-martini business lunches with Siebel "sales reps", and probably the weekly blowjob to get them to commit their companies to it. I then explain to the recruiter that any compa
Re: (Score:2)
I especially love how Siebel (used by a certain EDI provider) makes the user type his question in a tiny little box in a tiny font. Seems to assume I'm running 640x480. Makes me want to reach through the internet and throttle someone.
Open source help desk suggestions (Score:5, Informative)
Re: (Score:2)
CalemEAM (Score:3, Informative)
Roundup Issue Tracker (Score:2, Interesting)
http://roundup.sourceforge.net/
FOSS, not freeware, web-based issue tracker written in Python. It's extremely flexible and customizable to your needs, as every organization is different.
It comes with an embedded webserver so you can get it running quickly, and of course it works with apache/mod_python.
As for email, you can create, update, and close tickets via email using keywords/value pairs in the subject line.
I miss this ticket tracker. I work for a consulting firm where we need to handle multiple clien
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: (Score:2)
Mantis is good for bug tracking an application. We used it internally before we switched to using google code and/or a private SVN/Trac hosting for development projects.
I'm not sure how well it scales. We were just using it between 5 developers and 60 end users. On average we only filed less than 5 bug reports per day, and most of those were between the development team members saying their latest revisions broke someone elses code.
Re: (Score:2)
Avoid: OTRS; Try: RoundUp (Score:2)
We deployed OTRS [otrs.org] locally when we had to deploy something open-source off-the-shelf quickly, and it's proved painful. It might be possible to make it do what you want with more time and customization.
Since then, I've seen RoundUp [sourceforge.net] appear, and it looks most promising, though I haven't had a chance to play with it yet.
Re: (Score:2)
Are you sure this isn't a grass is greener thing?
IRC (Score:3, Funny)
Seconded... (Score:3, Interesting)
IRC is great for one-on-one support chats... there's tons of support for it out there in terms of utilities (log file handling, e-mail transcripts to clients, etc.), web-based front-ends (java and 'ajax'), IM client support (all the does-it-all IM clients have an IRC component available), etc.
Sure, you COULD just open up an MSN hotline (do they still charge for this?), but then all your Yahoo-using clients will complain that they have to first install MSN (though Yahoo! does MSN now, I suppose), and vice-ve
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.
Kindof in the same position. (Score:2)
We have about the same number of employees and "helpdesk" currently consists of:
10 DIAL BLHACK'S DESK PHONE!!!! --- No answer
20 DIAL BLHACK'S CELL PHONE!!!! --- No answer
30 SEND BLHACK 30 EMAILS ALL MARKED AS URGENT --- No answer
goto 10
In all honesty, about 90% of these questions are things like "I'm trying to download and it keeps saying that thing!", that "thing" is usually dansguardian telling them that they are not allowed to download .exe. Or "the things aren't going across" where the "things" are rec
Re: (Score:2)
There's no reason not to use some existing FOSS solution and then modify it to your needs. OTRS, Mantis, etc, etc have a lot of features that a helpdesk will want. If you want to add answers to FAQs, you can, you can build in whatever you want. You have the source.
My point is that I think the best approach is to figure out exactly what you want, find a FOSS tool in a language/toolset you can support that is a close as possible to requirements, then modify and close any gaps. If you're feeling generous and y
OTRS (Score:3, Interesting)
I've had fantastic results using OTRS to support both research scientists in a professional organization (8 sysadmins, 350+ scientists), a web-based document repository with a few thousand users (And 2 support staff) and a volunteer parrot rescue with about 50 staff, hundreds of volunteers/adopters and 2 support techies.
It's free, open source (LAMP) and having hacked at the source code I can say that it's VERY Solid and well-written Perl. With mod_perl2 even an older Linux box could handle the load.
Write your own, seriously. (Score:4, Insightful)
Service, whether it's software, hardware, helpdesk, whatever, is very hard to generalize.
Everyone wants to do things their own way and everyone has some weird little set of extra requirements. So every package that's available has already choked to death and drowned in features that most people will not need.
You get web UIs with tabs containing tabs containing hundreds of fields, of which a typical customer will probably use about 2-5%, and they'll end up stuffing information into them that they weren't originally intended to contain.
I really can't think of an application domain that cries out for a completely custom solution in almost every case.
G.
Re: (Score:2)
Sigh, I mean "I really can't think of another application domain that so cries out for a completely custom solution in almost every case".
A service application is at the core of any good service organization, and should be seen as an asset rather than a liability.
G.
Re: (Score:2)
Read the headline. Small firms may not have a development staff to pull this off.
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.
No need to look far (Score:5, Funny)
I use ask.slashdot.org [slashdot.org].
MailManager (Score:2, Interesting)
Request Tracker (Score:2)
I really like Request Tracker. I think it is hands down, the best open source Help Desk Software. It can be used in solution ranging from Help Desk Management to Queue Management. It also has excellent documentation. An O'reilly book was written about RT so you can get a nice amount of assistance getting it going and even customizing it.
Re: (Score:2)
I second the recommendation of Request Tracker, or RT: http://bestpractical.com/rt/ [bestpractical.com]
However I have not used many other systems, although we tried to do this with GForge (GForge has come a long way since we were using it).
Also, I have found the people on #rt on irc.perl.org to be polite and helpful, even when my questions were stupid. Thanks guys !
PHPSupport (Score:2)
Web Help Desk Software (Score:2, Informative)
umm this is not correct (Score:2, Interesting)
Cerberus Helpdesk (Score:4, Informative)
it is one of the few markets all OSS fails (Score:2)
I've looked and looked. Most OSS tools only provide 'tickets' and maybe 'inventory'. In my book a (ajax web-based) helpdesk application consists of a little more:
-user management, including imports ...)
-problem management
-change management
-configurable email responses (get mail when you report a ticket, when you get a ticket on your name,
-good comprehensive overviews
-reporting
-searches
-some sort of wiki which is integrated.
-selfservicedesk where a user can review and update incidents
There were only two (bel
100 people, 5-10 questions a MINUTE? (Score:2)
Dear god indeed!
We have around 100 staff here, and our entire IT team consists of two technical people. At most we field maybe 5-10 questions an HOUR, and I feel that is too high. Very occasionally we won't even take 10 questions in an entire working DAY, and that's the kind of level we aim to.
The vast majority of our time is spent looking after the system, planning future deployments, and generally keeping things running smoothly. Our aim is to have the technology working and simple enough that all the
RT & RTFM (Score:2)
You want RT and RTFM. Period.
Just look at the list of adopters on rt.bestpractical.com
Bugzilla? (Score:2)
!foss (Score:2)
Re: (Score:2)
Re:Wesley (Score:5, Funny)
Perhaps they are trying to "higher" English (or whatever their language is) literate individuals.
Re: (Score:2)
It's a valid suggestion though with good motivations.
Re: (Score:2)
I can only recommend this one too... I have to evaluate a new trouble ticket system last week. And of all the open source products I found this one was the best.
We had OTRS before. OTRS is very good too, but really hard to install.
A friend is using RT. Now with the newest version the user interface looks really good too. And I think many problems mentioned by others are gone.