Hello everyone! I’m new here and excited to join the Best Practical community. Can anyone recommend the best resources for getting started with RT (Request Tracker)? I’m eager to learn more about its features and how to effectively implement it for my organization. Any tips or advice would be greatly appreciated.
The forums are a good starting place for help with issues that have already been posted, sometimes 
You may want to seriously consider a support contract if your organization can afford it, especially if you have a high number of users, or plan to use RT in a high visibility setting.
You can find all of the RT extensions by searching RT::Extension on CPAN:
https://metacpan.org/search?size=500&q=RT%3A%3AExtension%3A%3A
Also, the Best Practical Github is a good place to look for extensions that were authored by Best Practical Solutions:
If you’re planning to use RT in any sort of production setting, you should create a development/test instance, especially if you’re new to the system so you don’t risk bringing down your production instance while familiarizing yourself. It’s really a good idea for anyone at any level. I wish I had one
Are there any specific areas you’re looking for advice in?
1 Like
The documentation provided by Best Practical is an excellent place to start, with the README probably being your first port of call. This forum and the wiki are also handy, though with both bare in mind that they cover a wide range of RT versions, and sometimes things have changed over the years so you may need to check how the version your using works (the main documentation is available for each released version).
As for how to effectively implement RT for your organisation, that will depend a lot on the sort of organisation you’re part of, how many tickets you’re likely to be handling and how your staff and end users want to interact with one another. In my experience every organisation, and even different bits of the same organisation, can work very differently.
For example you might have a “first line support” (help desk, service desk, call centre, etc) that you want end users to email problems and requests to using one standard email alias. You then let these first line support staff either quickly answer common questions (possibly returning pre-written RT articles with helpful information) or pass on to second/third line support teams. Other places have different email aliases set up for different types of support requirements, each going to different queues with different specialised support teams. Here for example we have a mix of the two - most IT requests from end users currently go into a general “it.services” queue initially but if people know they want my team’s help they can shortcut this by emailing a different address that drops tickets straight into our queue. You might also prefer end users to use the web interface rather than emailing requests in, or even use the new RT forms to guide end user through making requests.
Probably the best thing to do is to look at the workflows you have already, see if there are any “pain points” or bottlenecks at the moment and then design your support workflows around that. The look at implementing these using RT’s groups, queues and possibly life cycles to direct tickets to the right members of staff to handle them.
If you’ve not used something like RT before it’s probably worth having a play with a test system. You can either install one yourself, or play with the demo one Best Practical host.
1 Like