Questions about specific capabilities of RT

Hello list,
I’m looking for a free ticket/issue tracker for where I work. My boss wants such a system for internal use (so public access/customer relations isn’t a big concern). I’ve installed, set up, and even modified the code of OSTicket, but I keep running into little problems that I have to work around or tell my boss we can’t do. I’ll post our basic use case, then the problems/features we’ve hit/want, below. If anyone can chime in on whether RT can handle these, please do so. Keep in mind that code changes aren’t going to be easy, as I don’t really know Perl. Thanks in advance for any help.

Our main use case is internal. We’re a company that ships auto parts to other sellers, so the bulk of issues will be “this package went to the wrong place” or “the item was damaged upon arrival”. The basic workflow might look like this:

  • A reseller gets a damaged package sent from us. He calls his customer rep, who works for us, and explains the problem.
  • The rep opens a ticket with our shipping/claims people, detailing the situation.
  • Claims files for a claim with, say, DHL, and updates the ticket. The rep sees this update and fires off an email to his customer.
  • DHL accepts, and we re-ship the item. Claims notes this in the ticket, the rep tells the customer, and the rep closes the ticket.

Note that at no point did the customer see the ticket. My boss wants the structure to be set up so that tickets are for us, in the company, and all communication about issues with customers is between the customer and his/her assigned rep. He doesn’t want customers on the tickets at all.

It is also important to note that our structure is a little odd. I do only IT stuff, but many people have multiple hats. My boss is management, IT, and customer service (at least, he likes to keep up on major issues). Another guy does IT and shipping. Another does graphics and some IT. Another does IT and customer service, with a little shipping mixed in.

I say all that so the below series of questions will make more sense:

  • In OST, agents (that is, staff who can take care of tickets and make internal notes) must belong to one department only. We can use multiple teams, but those are harder to deal with than departments… In RT, can staff belong to multiple departments, assuming RT has a similar setup?

  • Can SLAs be set to ignore weekends and holidays? If a 72-hour SLA is assigned on Friday, that should mean three business days, not that it has to be done Monday.

  • Can things be set so that staff are notified upon certain events firing? A very overdue ticket in any department might go to one guy in management automatically, for instance, so that he can keep tabs on all overdue items.

  • Can we use custom IMAP folders? I had to modify OSTicket to do this, but we have just tickets@domain.com for our email address for the system. It’s with Gmail, so I have tickets+graphics@domain.com set to go to Graphics. I did this by telling Graphics to check the ‘graphics’ folder in the tickets email account. Each department has the same setup, with a custom folder. We did this because each new email address costs money, and we saw no point in paying hundreds per year for a feature I could add to OST. RT will have to be able to do the same, though.

  • In OST, replying to an email notification posts only an internal comment, not a full ticket reply. OST says they do this so two agents don’t reply with conflicting information for the user. For our situation, though, we need email replies to post ticket replies, so everyone on the ticket gets email notifications. Essentially, part of what we want is to let users carry on email conversations surrounding a ticket, but for those responses to be posted to the ticket at the same time. This will keep activity archived, and will automatically create ad-hoc email groups for everyone who needs to be part of a given issue. Since we’re not using this for customers, we don’t care who sees what in * In OST, when an agent creates a ticket, it must be done on behalf of a user. Since most of our tickets are internal, this gets very annoying, and results in us posting tickets to ourselves most of the time. I’d much prefer it if tickets could be opened on behalf of agents or, better still, on behalf of no one at all. I just want a ticket to consist of the issue, the creator, and everyone who needs to deal with it, plus an SLA.

That’s all I can think of for now. Sorry for the long message, and, again, thank you in advance for any ideas and responses anyone has.

  • In OST, agents (that is, staff who can take care of tickets and make internal notes) must belong to one department only. We can use multiple teams, but those are harder to deal with than departments… In RT, can staff belong to multiple departments, assuming RT has a similar setup?

users may be in multiple groups (teams). And may have rights and roles
(works) on multiple queues (team+workflow). So yes.

  • Can SLAs be set to ignore weekends and holidays? If a 72-hour SLA is assigned on Friday, that should mean three business days, not that it has to be done Monday.

yes, see
https://docs.bestpractical.com/rt/4.4.1/customizing/sla.html#Does-business-time-support-holidays

  • Can things be set so that staff are notified upon certain events firing? A very overdue ticket in any department might go to one guy in management automatically, for instance, so that he can keep tabs on all overdue items.

yes, using rt-crontool you can do automatic escalation. You can also use
saved searches with relative dates and dashboards subscriptions.

  • Can we use custom IMAP folders? I had to modify OSTicket to do this, but we have just tickets@domain.com for our email address for the system. It’s with Gmail, so I have tickets+graphics@domain.com set to go to Graphics. I did this by telling Graphics to check the ‘graphics’ folder in the tickets email account. Each department has the same setup, with a custom folder. We did this because each new email address costs money, and we saw no point in paying hundreds per year for a feature I could add to OST. RT will have to be able to do the same, though.

best use of RT is usually to directly send email to him using smtp, but
you can use fetchmail to get emails from pop/imap/…

  • In OST, replying to an email notification posts only an internal comment, not a full ticket reply. OST says they do this so two agents don’t reply with conflicting information for the user. For our situation, though, we need email replies to post ticket replies, so everyone on the ticket gets email notifications. Essentially, part of what we want is to let users carry on email conversations surrounding a ticket, but for those responses to be posted to the ticket at the same time. This will keep activity archived, and will automatically create ad-hoc email groups for everyone who needs to be part of a given issue. Since we’re not using this for customers, we don’t care who sees what in * In OST, when an agent creates a ticket, it must be done on behalf of a user. Since most of our tickets are internal, this gets very annoying, and results in us posting tickets to ourselves most of the time. I’d much prefer it if tickets could be opened on behalf of agents or, better still,
    on beha
    lf of no one at all. I just want a ticket to consist of the issue, the creator, and everyone who needs to deal with it, plus an SLA.

in RT notification are fully customizables and there is usually to kind
of emails address per queue, one for comments, other for replies.

As you have a great view of what you wan’t but litle knowledge of RT
which is higly configurable/customizable, I strongly suggest you to
contact Bestpractical or other RT specialist working near you to help
you so you’ll do the rights choices between
queues/customfields/groups/roles for your org.

Easter-eggs Spécialiste GNU/Linux
44-46 rue de l’Ouest - 75014 Paris - France - Métro Gaité
Phone: +33 (0) 1 43 35 00 37 - Fax: +33 (0) 1 43 35 00 76
mailto:elacour@easter-eggs.com - http://www.easter-eggs.com