Slashdot Mirror


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."

9 of 321 comments (clear)

  1. 100 people, 5-10 questions per minute? by bakuun · · Score: 5, Informative

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

    1. Re:100 people, 5-10 questions per minute? by Nocts · · Score: 5, Informative

      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.

      --
      "It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change."
  2. RT by dg41 · · Score: 5, Informative
    1. Re:RT by jgaynor · · Score: 4, 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/

      Very capable.

    2. Re:RT by trawg · · Score: 4, 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.

    3. Re:RT by Bazman · · Score: 4, 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.

  3. Open source help desk suggestions by Amigan · · Score: 5, Informative

    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

    --
    "Software is the difference between hardware and reality"
  4. Liberum by SoupGuru · · Score: 4, 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

    --
    What doesn't kill you only delays the inevitable
  5. The disconnect here by symbolset · · 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? They have about 500 CRM systems with trouble ticket tracking. Search for "CRM".

    --
    Help stamp out iliturcy.