What is Reddit's opinion of
Request Tracker?
From 3.5 billion Reddit comments
➔ Request Tracker website
By popularity on Reddit, this Service is:
28 reviews of this app found across Reddit:
It has a lot of features these days, but the ticketing is pretty useful. I used to use it on a previous team for internal task tracking.
I'm surprised that there's no love for RT yet.
Granted I haven't used osTicket in like 6 years, but at the time I thought it was clunky to use and ugly compared to RT.
I've used Request Tracker (rt4) at several jobs in the past. Among the handful of free and commercial ticket systems that I've used (none of which I will name), I liked RT the best by a wide margin.
It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!
Here is link number 1 - Previous text "RT"
^Please ^PM ^/u/eganwall ^with ^issues ^or ^feedback! ^| ^Delete
We are using Jira from Atlassasin. It's a bit on the heavy side for handling service requests. On the other hand it's deployed corporate wide, so with development tasks one can link items dependent on each other. Before we used RT from Best Practical .
Request Tracket open source, but you can pay for support or writing custom modules for you. It can track assets. If you get interested in Perl coding, then you can really make RT do nearly what over you want.
I've also used WebHelpDesk by solarwinds. It works well as a ticketing system, but if you plan on wanting HA, don't. If you want to track servers and what not then NPM/Orion is what you want to help with that.
I'm currently using Autotask, and it can do what you want, but at a pretty steep cost. I'm still waiting on them to update their API from SOAP to REST.
We use RequestTracker:
- heavily email oriented, but allows for ticket creation and response via UI.
- highly configurable. If you know Perl, crafting an 'after hours' response Scrip is pretty easy.
- It has a FAQ manager (which I've never used)
- reporting exists via TicketQL, and the DB itself is easy enough to fathom for more complicated things in raw SQL.
- open source, free.
- mobile browser theme (though I usually just request desktop site)
- separated comment vs reply for threading internal discussion with responses directed at customers
- large set of community contributed extensions (ticket tagging, commands over email, customer groupings, time worked reporting)
Request Tracker is great. I've been using it for years. Very customisable.
You could easily have it logging everything. Links that refer jobs to other jobs. Reminding you when maintenance needs to be done. Tracking sales leads and making sure they dont get forgotten.
RT looks a bit dated, but does its work. The other I've tried was redmine, but is oriented to software projects. You have more to try in the awesome-selfhosted list.
Did you look into Request Tracker by Best Practical. I have used it before and it is very cutomizable even when compared to JIRA Service Desk.
Down side is that it takes some time to setup since it is so customizable.
https://bestpractical.com/request-tracker
​
They also have one that specifically works for Incident response if required.
I don't have a good answer to this, because like /u/TomahawkChopped I think they all suck.
If I were to build my own (and if I had the hubris to think I could do better than anyone else), I would ensure that it was possible to create a new ticket and sign up at once.
I suppose in one sense the closest I've used that meets this criterion is RT. From an end-user perspective, creating an RT ticket is just a matter of sending an email, and all further correspondence by the user on that ticket can be performed over email. There is no need for them to actually have an account on the corresponding web application.
It's more of a support ticket system rather than a bugtracker, though it can be used as such.
But I gather email isn't popular with the kids nowadays.
We put in Request Tracker about four months ago, and the more we use it the more we love it.
https://bestpractical.com/request-tracker/
Caveat. Be linux knowledgeable, or teachable. I spun ours up in a VM.
Best ticket system I ever used was RT. https://bestpractical.com/request-tracker
Been like 10 years ago but haven’t see anything like it and the automated things you could do at the time was awesome.
Make or sign up for one pronto. No way I could support 30 staff let alone 100 without one.
Don't make anyone create tickets through some portal. Creating a ticket should be as easy as emailing . Even if they email directly, call or stand at your desk. Make the ticket; and make it no matter what. Communication about issues should happen through a ticket; it's easy to catch on or simply reply to a ticket email and very few people care how things get done as long as they do.
Management will probably be behind a ticketing system but look down on a portal requirement for service. In fact 99%+ of tickets I have worked did not come from a portal and at least half I made for the client. Most ticketing systems track this in a source field: phone, email, walk-in etc.
Ticketing system will help you prioritize your time and say no, or not now when you really need to.
I haven't used it, but heard good things about how simple request tracker is. https://bestpractical.com/request-tracker
Request Tracker is a good solution, we use it for clients local installs all the time, https://bestpractical.com/request-tracker being open source it is easy to work with and modify as needed.
I can recommend Request Tracker from personal experience. I ran an IT dept, when I came in, that's the first thing I did: I brought up one VM, installed RT, gave it an email box and forgot about doing anything to that VM.
And I had an email-based ticketing system (as in, you can just shoot an email to open an issue), some nice reports, KPIs and a lot extras.
I'm one of those crotchety old unix admins, and I do love some Request Tracker.
https://bestpractical.com/request-tracker
The only downside? It's written in perl.
With that said, it handles assets (tracking all actions against a specific computer), staff/user accounts (kinda-ish), and is super extendable.
Is RT this? I haven't used it before
I work at an MSP (Gross), so knowing who is working on what, who is assigned to what, and having a clear record is really important. We actually have some weird custom software that is kind of slow... but pretty amazing in terms of feature set. We get email notifications and things, and we have cli tools we can use to update tickets, but generally we just work out of the ticketing system. With email, it's just kind of limited. For me atleast, it's difficult to read, and especially when trying to format or send code and output from logs etc... probably 90% of my work is in the terminal.
You should hire a team of ITIL Consultants, set up a swiss-army knife workflow in a tool like ServiceNow or Remedy, and then a year later burn it all in the dumpster, and install the lightweight and open source Request Tracker (RT).
It's crucial everyone gets that ITIL experience first, though.
> Try doing IT ticketing in Salesforce.
Oof, my sympathies. We’ve had some rotten luck with several ticketing systems but the one that has been rock solid for us has been Request Tracker.
Aside from doing upgrades it’s been pretty much a set and forget system. Not one issue.
There are proprietary solutions to do it but it's way too convoluted. Leave Outlook as your personal mail, and do all the support mail etc via mail groups that the ticketing system picks up. You want to train people to mail , not - when Joe quits, you're mildly screwed. At the very least there will be confusion.
Just use Freshdesk or something else that's hosted for you in the cloud.
Personally I set up OTRS even though we also are a tiny team. It's not hard. But OTRS seems to be pushing hard to ditch the community stuff and they litter the free products with exhortations to buy their commercial variant, so hard to recommend that now.
Another old tried and true option would be RT, https://bestpractical.com/request-tracker/ - FOSS so you can just stand up a VM for it, or you can get it hosted.
Maybe one of the really old hands at it from the FOSS end.
OTRS https://www.otrs.org is pretty solid. Built on standard stuff, ie PHP and MariaDB. Can run the community version for free, although they seem to be wanting to push people harder into paid solutions lately.
Very customizable but whether or not you can easily make it do what you want is another matter. It's a ticketing app that can do ITIL, not an integrated swiss army knife.
The other granddaddy in the field would probably be https://bestpractical.com/request-tracker/
https://bestpractical.com/request-tracker/.
As you're in a NIX shop, it should fit well with your environment. It can be as easy or as complex as you want.
There are quite a few products that do this... my investigations of them tend to be slanted towards free-to-use, on-premise, self-hosted options. It might be worth paying a little for a hosted solution, if you don't want to bother with the details.
A few to look into further:
My employer is currently using the following, which I can't recommend due to its 15+ years of accumulated technical debt, but does work & is quite flexible. Worth checking out for comparison purposes, possibly. Guess who knows Perl well enough to be responsible for it? :(
Is your NOC using any sort of ticketing system? If not, that would certainly be a great place to start, and it can be done extremely cheap with free software and modest infrastructure requirements. Some of the more common options are Request Tracker and osTicket.
If you're looking for more of a single-pane incident management/tracking/auditing solution, something like VictorOps might be a good fit, although it definitely isn't free.
Been using OTRS for years. You can go as ITIL as you want to, but out of the box it's a solid ticket management system with a ton of useful features.
They're pushing at going to the cloud now like everyone else, as you can make fantasy money off renting stuff to people, but it's still an open source solution you can install for $0.
In fact, our install morphed from being just the IT helpdesk system to becoming the way we handle communications in other departments also - the general mail to the company comes in there, the finance department and a few others have their own queues in the same install as the IT support does.
Queues are entirely separate, and if a ticket needs to move from one to the other, it's easy to do. For instance, the generic company email queue answers generic questions, but moves any specific ones to other queues - like the finance queue, for instance. I have normal users working as agents in it now and have had few if any issues.
It's 100% used via email over here, but it does have a customer-facing web interface also.
Another old-school (and therefore tried and true) option might be RT. https://bestpractical.com/request-tracker/
These are both built on Linux and use Perl, with MySQL/MariaDB as the data store. Which obviously opens up possibilities like setting up a Galera cluster for the DB if you want more redundancy, as well.
Request Tracker sounds like a solid fit for what you need to do. You could have a different queue for each client. You can give any specific user or groups rights to each queue. Help desk could work off of a single view of all queues or pick into each one if they like. Best part of RT is there is almost nothing it can't do if you put some time into designing it. Also it works heavily off of email so end users really don't need another system to learn.
It has been around forever so plugins expand what it can do. LDAP user import and LDAP SSO for clients and agents are what we use and are built it as of the latest release. RT give you a search feature based off of SQL so there is little you can't fine tune to see in a single view. No app, but the native mobile view does what you need in a pinch.
Not as easy as the others to install and configure and has a learning curve but honestly if you can learn it and master it then you have another fairly decent bullet for the old resume.
Every organization is different and these things are just tools. Kanban is useful for us (small devops team) and we use Trello for providing tracking and more context than what Github issues provide (often we link Github issue -> Trello. Scrum is mostly crap and not relevant even with heavy tooling/automation work and a few open source projects we work on and consume internally, my feeling is it's just a management checkbox fad. We're not 100% development with milestones so it doesn't work for us.
We prioritize the rest of our work with the RT ticket system, IRC bot announcements and good communication with each other (video conf, IRC, email and mailing list for timezone lapses).
Typically:
Kanban/trello/Github issues = project work, development and tooling priorities, big stuff you chip away at
RT Tickets = Day to day stuff.
Generally our best chances to automate repetitive tasks originate from an RT ticket request and turn into a development opportunity best tracked in Github issues and Trello Kanban.