Suggestions for ticketing systems?

We've been a small enough that users can just email IT problems. There's only two of us today, but the workforce has grown and getting emailed issues just doesn't cut it. We're about 100 users. I'm looking for a ticketing system that at the very least runs in the browser (IE8, 9, 10). That's pretty much my only real requirement. The only ticketing system I've used is TRAC, but that seems to be more for software development rather than just general IT issues. I suppose I could use it, but I want to know what else you guys use for a small userbase.

Anyone use System Center Service Manager (SCSM)? My company has been using Request Tracker with decent results, but the customization is a little tough as I'm not (yet) a Perl guy and haven't had time to sit down and learn how to make it do what I want it to do for my organization (500 users, 10 IT guys, 4-5 IT first-responders, 90% Windows-based).

SCSM looks intriguing because it integrates with AD and Config Manager which we already use. RT doesn't have any integration so sometimes it's a pain to capture users/computers properly in our tickets. I'm reading up on SCSM to see if it's worth the plunge. Also intriguing is the tie-in with Orchestrator to supposedly automate some common tasks/requests and seems like there's an ability to create a self-service web portal for users which could reduce or fine-tune some of the tickets you do get.

SCSM could be an option for you if you have System Center licensing (2012-level) already. But I can say Request Tracker is a good option if not.

I disagree. I'd use a ticketing system if I was the only responder. This is bad advice. If the ticketing system is slowing you down it isn't set up right, or people are bypassing the process, or something else is wrong.

I disagree. I'd use a ticketing system if I was the only responder. This is bad advice. If the ticketing system is slowing you down it isn't set up right, or people are bypassing the process, or something else is wrong.

I agree with your disagreement. A ticketing system should do at least two things - capture requests and provide visibility. You'll have to encourage users to use it properly, but it can be done. If a user calls you direct, enter the ticket as you take the call. Otherwise, teach them to email the ticket which should be easy enough to do vs. a web interface (which is also easy, but a little less so). The best is when people catch you away from your desk - if you have your phone, you can capture their issue with a quick email to the system. If not, you'd instruct them to send the ticket to the system for you so you can remember it when you get back to your desk.

The visibility part is important because users need the acknowledgement. As you teach them to submit tickets, at least triage the tickets and acknowledge that you've seen the new ones as soon as possible. That way, they know you're on it (ticketing system should email an update to users and web interface should allow them to see it too). And they can begin to trust their system. Sure, critical *NOW* things will still be a direct phone call, but anything less should get to the point of being trusted to a ticketing system.

I recommend that you look at two of Thomas Limoncelli's books - The Practice of System & Network Administration, and Time Management for System Administrators - which discuss how to do a ticketing system and use Request Tracker (RT) as an example.

I disagree. I'd use a ticketing system if I was the only responder. This is bad advice. If the ticketing system is slowing you down it isn't set up right, or people are bypassing the process, or something else is wrong.

I agree with your disagreement. A ticketing system should do at least two things - capture requests and provide visibility. You'll have to encourage users to use it properly, but it can be done. If a user calls you direct, enter the ticket as you take the call. Otherwise, teach them to email the ticket which should be easy enough to do vs. a web interface (which is also easy, but a little less so). The best is when people catch you away from your desk - if you have your phone, you can capture their issue with a quick email to the system. If not, you'd instruct them to send the ticket to the system for you so you can remember it when you get back to your desk.

The visibility part is important because users need the acknowledgement. As you teach them to submit tickets, at least triage the tickets and acknowledge that you've seen the new ones as soon as possible. That way, they know you're on it (ticketing system should email an update to users and web interface should allow them to see it too). And they can begin to trust their system. Sure, critical *NOW* things will still be a direct phone call, but anything less should get to the point of being trusted to a ticketing system.

I recommend that you look at two of Thomas Limoncelli's books - The Practice of System & Network Administration, and Time Management for System Administrators - which discuss how to do a ticketing system and use Request Tracker (RT) as an example.

This. I also made the assumption that pretty much all ticket systems allow a user to get assigned a ticket and that they all can email the user anyway. Am I wrong on that?

I always come into these posts to recommend Redmine. It has some features for development (code browser), but it's a great ticket system, has good email handling support, a very nice interface and a decent wiki.

If you want to do fancy stuff, JIRA might be worth a look, but it's definitely on the enterprise-y end of the spectrum.

We're using OTRS for ours. I can't say that I would really recommend it.It's been finicky at best, took more time that I think it should have to get setup and the administration of it I find to be rather unintuitive. For the most part it does work though. Users can send an email to the system directly and it will create the ticket and notify the various people involved. And it is free.

With 2 people responding I would agree that a ticket system is a definite benefit and should not slow you down at all.

That is what we use. Somewhere north of 1500 account-enabled users, with 4 active techs (although I am not supposed to be working helldesk much, but I end up doing so because the other 3 staff are varying levels of incompetent).

I'm hosting it on Windows currently. If I had the time to mess with it, I would re-do on Linux or BSD because performance on PHP + IIS (even with FastCGI/etc) has been displeasing with the latest release.

I suppose I could re-do on Windows with Apache, but I see no real reason to keep it on Windows period. I know they primarily develop for *nix platforms.

I used to hate ticketing systems (in the 1990's), then I grew the fuck up. :-)

Ticketing is excellent, as long as it's used properly. People get feedback to their problems, managers get their statistics, and STUFF GETS DOCUMENTED.

A good web-based product, once bedded down and doing what you want it to do, should suffice for many hundreds of users.

We use a horrible ticketing system (BMC Remedy), it's horribad, but it's still infinitely better than unrestricted phone calls trying to get stuff done. You have history, you have documentation, you have control. Don't just use an excel spreadsheet on a shared drive, it's not robust enough.

As a user I used to love Remedy because we had an admin who knew how to run that system properly and I could query the ever loving f*ck out of it to get what I wanted fast. Since then I've used some really crummy ticketing systems that wouldn't know it was hitting on it's own sister at a family reunion somewhere south of the mason-dixon line. HDWeb and Techexcel are junk for mid-size companies and up. Small operations I could see using it effectively. I'm sure some of it has to do with no one really owning the ticketing system that knows what they are doing.

I also made the assumption that pretty much all ticket systems allow a user to get assigned a ticket and that they all can email the user anyway. Am I wrong on that?

When you said "ticket systems allow a user to get assigned a ticket", you mean support staff? If so, then yeah, it's possible for support staff to get a ticket, but also communicate with the end-users anyway via the ticketing system. Key is, at least in my case, the user has to be the one to initiate the ticket in order for it to work well (a lot of our tickets are IT recorded/created, so sometimes this gets lost and replies go to IT staff instead). But yes, it's possible, and I'll describe how it works for us.

2. RT receives the incoming mail, puts it into our default queue, then emails support staff responsible for monitoring that queue.

3. Support staff member can simply reply to the email (with or without comments) to take the ticket or go to the web to perform more actions such as mark as duplicate, merge, or reject.

4. User should get emailed that the ticket was assigned. Ticket also get acknowledged in system.

5. Support staff and user can further communicate (questions and/or status) by replying to these emails as long as they keep the email address and subject line intact. The system is smart enough to parse the additional conversation and append to the ticket. More options on web interface.

6. Support staff marks ticket as resolved on web. User gets email update saying ticket was resolved and if further issues, reply to that email with subject/address intact to reopen same ticket.

Now, you have to setup RT-MAILGATE and Procmail/Sendmail properly to get this kind of interaction to work, but it's not too hard to do and the benefits are pretty good. Email in this case is a natural way to communicate for people (even more so when you make things as easy as hitting 'Reply' and, as long as conventions are followed, you have a running log of what's going on for further documentation.

RT has other plugins that can integrate with the system to make it even more effective. We used AD authentication plugin that makes it easier to login and we use a plugin that allows auto-assignment of a new ticket by emailing the system and cc'ing the intended assignee (my boss uses this to target tickets for people he wants to handle the issue). There are a lot of other plugins that provide some good functionality (e.g., a knowledge base).

Not sure about other ticket systems, but it should be possible to do what you said.

When I used to care about this, I used JIRA. Yes, it's enterprisey, but it's very customisable from the UI, complete with workflows (so enforce the steps a ticket goes through) and could be bent with minimal fuss to handle the needs of other departments. Where I work now rolled its own, and I don't think any external package would ever fit our environment (or our wackiness; last hack, someone made it possible to inline lolcat-type macros in your task comments, hoping that ships).

I always come into these posts to recommend Redmine. It has some features for development (code browser), but it's a great ticket system, has good email handling support, a very nice interface and a decent wiki.

It can read mail. Its evolution is complete.

Another +1 from me for Redmine. Used it as a ticketing system to manage general purpose stuff with rather tech averse staff. It worked well. Now I use it for Development purposes. It works well.

As a user I used to love Remedy because we had an admin who knew how to run that system properly and I could query the ever loving f*ck out of it to get what I wanted fast. Since then I've used some really crummy ticketing systems that wouldn't know it was hitting on it's own sister at a family reunion somewhere south of the mason-dixon line. HDWeb and Techexcel are junk for mid-size companies and up. Small operations I could see using it effectively. I'm sure some of it has to do with no one really owning the ticketing system that knows what they are doing.

Yeah a well-configured Remedy installation with an administrator who knows how to use it as a beautiful thing. A bad Remedy setup is an utter nightmare. Guess which is more common in industry?

Anyway, for two admins and 100 users anything as simple as possible will do that job. There are lots of good suggestions here, particularly spiceworks.

That is what we use. Somewhere north of 1500 account-enabled users, with 4 active techs (although I am not supposed to be working helldesk much, but I end up doing so because the other 3 staff are varying levels of incompetent).

I'm hosting it on Windows currently. If I had the time to mess with it, I would re-do on Linux or BSD because performance on PHP + IIS (even with FastCGI/etc) has been displeasing with the latest release.

I suppose I could re-do on Windows with Apache, but I see no real reason to keep it on Windows period. I know they primarily develop for *nix platforms.

Hi ZPrime,

I'm Chris from http://www.deskpro.com. One reason we sometimes find things can be slow on Windows is it there is no cache installed; WinCache being generally the best option. This is not installed by default unlike APC which often is on Linux. Have you got that installed? The other thing to make sure is you are not using "localhost" for mySQL - this can also be a problem on Windows.

We do have developers working on Windows; so everything should work there just as well. If you are still having problems please do submit a ticket so we can help you get it sorted.

I disagree. I'd use a ticketing system if I was the only responder. This is bad advice. If the ticketing system is slowing you down it isn't set up right, or people are bypassing the process, or something else is wrong.

2 words- "ticket compliance". When having to go through each ticket you work on to be sure each field required by management has a value approved by management (and there will be many) takes you nearly as long as correcting the issue, you have a problem.

I agree that you should have a ticketing system, it's important to track work, build history of known issues, etc. But ticketing systems and the metrics they can be used to generate seem to take on a life of their own in the hands of management who don't understand the difference between map and terrain (and who don't understand that process can be good, but it's also overhead, and it IS possible to have too much of a good thing). Some people I've known see this as nearly inevitable, and prefer to avoid ticketing systems at all if they can.

We've been a small enough that users can just email IT problems. There's only two of us today, but the workforce has grown and getting emailed issues just doesn't cut it. We're about 100 users. I'm looking for a ticketing system that at the very least runs in the browser (IE8, 9, 10). That's pretty much my only real requirement. The only ticketing system I've used is TRAC, but that seems to be more for software development rather than just general IT issues. I suppose I could use it, but I want to know what else you guys use for a small userbase.

That is what we use. Somewhere north of 1500 account-enabled users, with 4 active techs (although I am not supposed to be working helldesk much, but I end up doing so because the other 3 staff are varying levels of incompetent).

I'm hosting it on Windows currently. If I had the time to mess with it, I would re-do on Linux or BSD because performance on PHP + IIS (even with FastCGI/etc) has been displeasing with the latest release.

I suppose I could re-do on Windows with Apache, but I see no real reason to keep it on Windows period. I know they primarily develop for *nix platforms.

Hi ZPrime,

I'm Chris from http://www.deskpro.com. One reason we sometimes find things can be slow on Windows is it there is no cache installed; WinCache being generally the best option. This is not installed by default unlike APC which often is on Linux. Have you got that installed? The other thing to make sure is you are not using "localhost" for mySQL - this can also be a problem on Windows.

We do have developers working on Windows; so everything should work there just as well. If you are still having problems please do submit a ticket so we can help you get it sorted.

Thanks!

Chris

Chris, you and I have corresponded many times. We have WinCache loaded (it shows up on the DP "Server Checks" page) and it still doesn't seem to help much. I routinely see random PHP "time-out" Type errors from the helpdesk, which I then diligently submit to you guys with the little button in the corner. The "DP_DATABASE_HOST" is set to 127.0.0.1.

Only thing I can think of is that I used the latest PHP when I set it up (5.4.8), while WinCache claims to only be for 5.3.x. Should I back-rev our PHP release?

Remedy - avoid it like the plague. Although it can be a killer ticketing system, the number of times I've used it when it was dog slow due to misconfigurations make me question it's usefulness.

I've had favorable encounters with Tigerpaw, but it's more a CRM, inventory and time management/billing app. If your team is "separate" from the user base/clients it might work, but I suspect it's billing based background isn't what you are looking for.

ServiceNow is pretty much unusable out of the box. It's easy to make changes, but I wouldn't recommend it for a small shop. Maybe at 15-20 IT users it might become worth the setup time.It feels more like a development environment than prepackaged software. You can change anything with a couple clicks (when you're in as an administrator), for better or for worse.

Don't expect to get it going without an engagement with a ServiceNow partner, and training.

I disagree with this, but then again, the first time I implemented it, I'd been in an organization where everyone had just gone through ITIL Foundations v2. That said, I definitely agree that it's a terrible fit for the likely budget and needs of a 2-person IT org.

Quote:

Don't expect to get it going without an engagement with a ServiceNow partner, and training.

This is true, and the same is true for Remedy, HP, and anything else in the market segment it competes in. You want simple, then TrackIt, RT, SpiceWorks are much more the right size and right price.

I used http://www.cerberusweb.com/ (Version 4, they've since had 2 new version releases) for a 100+ person helpdesk / call center managing hurricane recovery assistance. The ticketing system handled our application processing workflow and kept everytihng nicely documented and moving. It handled the demand quite well and their support was excellent.

At my current gig, we use Zen; I dislike it. It has some odd ticket handling limitations that frustrate users.

Yeah, I was starting to look for something similar, and started here to whittle down the options. My needs might be a little different-I want o have multiple client specific portals on their side (so they can see what's going on) while the responder side can see everything). The client would email to a client/company specific email address (I find they feel that to be more personal, but maybe that's a holdover from it being a strictly email based system).

So something good for technically averse staff (we would use it for non-computer related tasks as well, like billing inquiries, needing a mover, and rescheduling cleaners). OTRS was recommended to me by someone, and I've seen WebHelpDesk not get used and suffered through a two week stint with Remedy (obviously not properly managed). But given the lack of positives about OTRS and WebHelpDesk maybe those aren't the right way to go. Spiceworks then? How is the "advertising" portion integrated (ie is it actually not obnoxious)? Or something else named above?