Follow Slashdot stories on Twitter


Forgot your password?
Businesses Software

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."
This discussion has been archived. No new comments can be posted.

Best FOSS Help Desk Software For Small Firms?

Comments Filter:
  • by bakuun ( 976228 ) on Thursday February 26, 2009 @08:34PM (#27006479)
    That's one helpdesk question per user every 10-20 minutes.. my god.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      Seriously. Does he work at Retards R Us or something?

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      He probably means he has 100 people running the help desk not 100 people using the end product.

    • by Gorobei ( 127755 ) on Thursday February 26, 2009 @09:00PM (#27006831)

      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.

      • I always thought this was called "IRC".
        • Re: (Score:3, Interesting)

          by Gorobei ( 127755 )

          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.

          • Congratulations on having enlightened management people.

            They've been on the endangered species list for 40 years.

    • Re: (Score:3, Funny)

      by Tim99 ( 984437 )
      Yes, but how long does it take after you have told them "Hello IT, have you tried turning it off then on again"
      If you are lucky they will only get about 5 minutes of 'work' done...
    • by Nocts ( 1185911 ) on Thursday February 26, 2009 @11:17PM (#27007877)
      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.
      • by Pjerky ( 1270800 ) on Friday February 27, 2009 @12:00AM (#27008099) Homepage
        Why don't you just setup a simple forum that people can submit to and anyone can answer. Then your moderators can not only answer for one person but other users can see the answers to their same questions. Thus reducing the number of questions.
        • 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

      • by richlv ( 778496 )

        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

    • by Sycraft-fu ( 314770 ) on Friday February 27, 2009 @05:23AM (#27009563)

      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)

        by nmp0906 ( 1402471 )
        It has been awhile since I have looked at free ticketing systems, but I seem to remember that outside of OS Ticket there was not a whole lot of offerings. Granted, at the very core, a ticketing system is not terribly complex, but finding one with a good workflow out of the box is the difficult part.

        Now I know you said free, but I highly recommend you check out Kayako []. 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)

    by dg41 ( 743918 ) on Thursday February 26, 2009 @08:36PM (#27006507)
    What about RT? []
    • Yes, RT (Score:4, Informative)

      by br00tus ( 528477 ) on Thursday February 26, 2009 @08:49PM (#27006683)
      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 (Score:4, Insightful)

        by dskoll ( 99328 ) on Thursday February 26, 2009 @10:05PM (#27007419) Homepage
        We use RT and it works very well for us. We don't have a very high volume of tickets (we're up to about 14000 in 5 years, so only about 8 tickets/day on average), but RT is insanely flexible and customizable and has excellent e-mail integration.
      • Re:Yes, RT (Score:4, Informative)

        by sqldr ( 838964 ) on Thursday February 26, 2009 @10:54PM (#27007741)
        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.
    • Re:RT (Score:5, Informative)

      by jgaynor ( 205453 ) <jon AT gaynor DOT org> on Thursday February 26, 2009 @09:02PM (#27006859) Homepage

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

      Very capable.

      • ruQueue (Score:3, Interesting)

        by dskoll ( 99328 )

        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)

          by dskoll ( 99328 ) on Thursday February 26, 2009 @10:17PM (#27007509) Homepage
          YIPE! I took a closer look at ruQueue... can you say XSS attacks and SQL injection, folks? /me mails the authors...
        • PHP and MySQL kind of grew up together. That is probably the main reason.
        • Re: (Score:3, Informative)

          by AlXtreme ( 223728 )

          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.

      • 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)

        by jesse ( 306 ) on Thursday February 26, 2009 @10:40PM (#27007645) Homepage

        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.

        • Yeah but you wrote in PERL a reporting language that was bastardized into something pretending to be an OOP language. Thanks but no thanks.
          • by mkosmo ( 768069 ) *
            Have you ever developed anything with Perl? (Its not "PERL"!!!) It is an elegant language. You just have to be mature with it just as with any other language so you don't get ahead of yourself and stuck with the stereotype Perl maintenance beast. Please remember that Java is not a suitable language for most things (I assume you're a fresh Java developer from your ignorance).
        • Don't take this the wrong way, because I love RT, but it does have some serious performance problems in the large scale.

          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)

        by Bazman ( 4849 ) on Friday February 27, 2009 @04:25AM (#27009331) Journal

        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)

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

          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

      • 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, Informative)

      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. []
    • Re: (Score:3, Informative)

      by Rob Riggs ( 6418 )

      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)

      by ribo-bailey ( 724061 )
      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 (Score:5, Informative)

      by trawg ( 308495 ) on Thursday February 26, 2009 @11:46PM (#27008025) Homepage

      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.

    • by noldrin ( 635339 )
      My company used to use RT. I could work the ticket system from Opera Mini on my Symbian based phone. My company moved to a closed source solution called Connectwise because it integrated the entire customer database into the ticket system. Although now we have trouble using even from windows mobile phones.
  • by lousyd ( 459028 ) on Thursday February 26, 2009 @08:36PM (#27006509)
    If your organization is only 100 people, and you get 5 to 10 support requests per minute, one wonders if you're doing something wrong.
    • by Bryansix ( 761547 ) on Thursday February 26, 2009 @08:47PM (#27006645) Homepage
      Never underestimate the retard capacity of a sales department of about 75 people. Next keep in mind those positions turn over completely in about a month.
    • by EEPROMS ( 889169 )
      If your organization is only 100 people, and you get 5 to 10 support requests per minute, one wonders if you're doing something wrong.

      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)

    by alexborges ( 313924 ) on Thursday February 26, 2009 @08:37PM (#27006521)

    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)

      I second the choice of OTRS. Good system.
      • Re: (Score:3, Insightful)

        by Lumpy ( 12016 )

        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)

          by sumdumass ( 711423 )

          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

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

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

  • by IMightB ( 533307 ) on Thursday February 26, 2009 @08:40PM (#27006561) Journal

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

    • Re: (Score:3, Funny)

      by Anonymous Coward

      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

    • by dickens ( 31040 )

      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.

  • by Amigan ( 25469 ) on Thursday February 26, 2009 @08:46PM (#27006627) Homepage
    Here's a website that lists many of the open source helpdesk options: [] The only one I have experience with is ZenTrack [] and both the users and helpdesk folks found it easy to use. jerry
  • CalemEAM (Score:3, Informative)

    by Shark4126 ( 1391765 ) on Thursday February 26, 2009 @08:47PM (#27006649)
    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: []
  • by Ulf667 ( 227615 )

    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)

    by SoupGuru ( 723634 ) on Thursday February 26, 2009 @08:53PM (#27006727)

    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. []

  • Mantis (Score:4, Informative)

    by _Pablo ( 126574 ) on Thursday February 26, 2009 @08:59PM (#27006803)

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

      • by ivoras ( 455934 )
        Mantis is not really built to scale - it's one of those applications that are philosophically in line with MySQL - lots of small queries repeated wherever needed, not really elegant database layer. But for the workload that it's built for - small teams and/or products (I'd say about 20 developers / 200 users is an "optimal maximum" for it) it rocks.
  • We deployed OTRS [] 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 [] appear, and it looks most promising, though I haven't had a chance to play with it yet.

  • IRC (Score:3, Funny)

    by Collinp6 ( 1456711 ) on Thursday February 26, 2009 @09:06PM (#27006903)
    What about IRC? Its simple, you can PM people with specific questions, its free and open source, and it has many web-based clients.
  • How about GLPI (Score:4, Informative)

    by EvilGrin666 ( 457869 ) on Thursday February 26, 2009 @09:14PM (#27006969) Homepage
    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 (Score:3, Informative)

    by DarkOx ( 621550 ) on Thursday February 26, 2009 @09:17PM (#27007007) Journal

    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.

  • 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

    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

    • 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)

    by AMuse ( 121806 ) <> on Thursday February 26, 2009 @09:34PM (#27007189) Homepage

    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.

  • by Gavin Scott ( 15916 ) on Thursday February 26, 2009 @09:36PM (#27007215)

    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.


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


    • by lanner ( 107308 )

      Read the headline. Small firms may not have a development staff to pull this off.

  • by jkrise ( 535370 ) on Thursday February 26, 2009 @09:39PM (#27007235) Journal []

    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.

  • by Kugrian ( 886993 ) on Thursday February 26, 2009 @09:58PM (#27007349) Homepage

    I use [].

  • MailManager (Score:2, Interesting)

    by weegiekev ( 925942 )
    Try mailmanager - [] It will scale well (up to 100k tickets per day if you push it), and it lacks some of the major restrictions of RT in terms of workflow.
  • 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.

    • I second the recommendation of Request Tracker, or RT: []

      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 to be polite and helpful, even when my questions were stupid. Thanks guys !

  • This one works: []
  • by SpikeT ( 1488075 )
    Hands down it has to be the Web Help Desk Software: [] 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 important
  • My company has 65,000 users and a desktop client staff of 5, supervisor included. we are a mixed enterprise shop of Unix, VMS, Windows, Linux This staff doesn't include networking/operations/system administration staff, SO you either have a real non-tech base of customers(read Monkeys), your tech's never really fix an issue and they are repeat calls, and/or something is very wrong with your hardware/software configurations, if your handling that many calls, just maybe you should spend this time not looking
  • Cerberus Helpdesk (Score:4, Informative)

    by waa ( 159514 ) on Friday February 27, 2009 @02:10AM (#27008735) Homepage
    Giving up my mod points to recommend Cerberus []
  • 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
    -some sort of wiki which is integrated.
    -selfservicedesk where a user can review and update incidents

    There were only two (bel

  • 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

  • You want RT and RTFM. Period.

    Just look at the list of adopters on

  • I like Bugzilla. It works well for me, and has become much easier to install and configure (with Webmin for administering the MySQL directly, as needed). Sourceforge and RedHat both also use it, so it seems to scale well, and doesn't have the locking problems some of the other systems have.

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann