We use RT, or Request Tracker from Best Practical, and it works very well. The issues we have all stem from the people using it. To give you some background, our department (Computing Services / ITS) is made up of 4 individual units I guess you could say and they make up our large dysfunctional family.
I’ll be very general from now on, as to not point fingers and call any one particular group or person out. There are a few issues with the interaction of these groups when working “together” with RT. These seem pretty petty on one level, and could be solved with a “How we use RT” document (cough *policy*), however they’re as real as this blog post.
When we first started using RT, there was some basic training on its features, how tickets moved through the system as a whole, how to pass off and steal tickets if needed, etc. We never had a document effectively telling us how to use it institutionally. There was no RT Strategy or grand vision, it was installed to be a ticket system and possibly knowledge base. Due to this oversight, each group uses RT differently, and to be honest, some people within each group use it differently depending on what they support
There is a culture that each group works autonomously, meaning groups rarely work together on things. Granted, if there’s a database issue, and the DBA finds an underlying network problem, sure, those two will work together to get it fixed, but in general there are chasms between us which leads to the next issue. People in group B don’t appreciate being told by group A (aka phone calls, emails, personal visits) to go look at RT because there is a ticket out there that may (or may not) apply to their expertise. Wait, I know what you’re going to say, they should monitor RT more so they can jump on the ticket and not get nagged. The problem here is RT monitoring can’t be a full time job, and if you’re working on something, you probably can’t be looking at RT at the same time. This issue caused such a rift that it changed how group A contacts group B, and the way A process tickets for B. Craziness.
Another issue is that tickets coming into group A were being assigned to people in group B, when A has no idea what B does, and often times mis-assigned tickets. Again, sounds petty, just removed yourself from the ticket, or reassign it yourself. The heart of this issue is that typically not enough information was in the ticket and a quick assumption of who does that job was made and the ticket was assigned to the wrong person. That not only inconveniences the new owner of the ticket, it also delays the resolution because it gets passed around until it lands on the right one. In this scenario, who’s job is it to request more information? The assigner, or the assignee? People in general don’t appreciate getting work handed to them by people that aren’t they’re boss, and for the record the boss didn’t like his people being assigned things either.
To sum it up, everyone seems to use it a bit differently, we don’t like to be nagged by another group and especially don’t like getting work added to our plate by just anyone.
Wow, right? What a mess. Again, kind of petty, yet a bit serious.
How do you deal with personal, and personnel issues like this? Create policy, rules and regulations, a SOP manual for RT and have more people pissed because they’re being forced to change how they do their job? (which most everyone does well btw).
Enter Machine Learning.
I was out splitting wood a couple weeks ago and thought about all of the above issues and how to change RT to deal with them. Lets forget the policy discussion because that still has to happen and even after it does if all of the above procedures are taken care of, there are still going to be issues monitoring and mis-assigning tickets, and everyone will still have the job of assigning and taking ticket from the various queues to deal with.
What if something could be built to analyze a ticket when it came in and determine the best person to assign it to. That simple sentence, eliminates the two major issues above, monitoring and (mis)assigning. Sounds like a job for some machine learning, or keyword relevance, or context analysis, or a mixture of all three. How difficult would it be to build a plugin for RT, or bolt on something to analyze and route tickets properly.
I bounced this off of a few other people here, including a couple professors, one of which I took an Artificial Intelligence course from. They loved the idea and both wished their summers were free to help built it 🙂 I do have their support to hit up for help.
RT is the perfect application to try this with too, because it can operate using email. Here’s the concept –
Anytime a new ticket comes into RT, an email with all the ticket information is sent to a special address setup for this. The analysis system monitors that mailbox and pulls in new emails, analyzes them and determines whom the ticket should go to. Currently this analysis is a black box, and could contain any set of rules, logic, Natural Language Processes, etc. Email goes in – best match(es) come out.
At first this system, we’ll call Sherlock (because he’s awesome), will analyze a ticket and come up with the person or persons it thinks is a good match. It will email those people on its own, not using RT, to alert them to the new ticket it thinks falls within their expertise. The email contains a link to the ticket, a couple response links, and a “Pandora – why did I get this” section that shows the rules it used to determine why it thinks this is for them.
For example, lets say a ticket came in and Sherlock deduced that Bob and Jon may be potential owners. Bob and Jon both get emails with a link to the ticket. They click the link and view the ticket in RT. If this indeed is correct and they should be the owner, they click the “yes this is correct” link/button in the email message and that is used to reinforce the rules Sherlock used. If this has nothing to do with them, they click the “no, this is not correct” link and conversely this downgrades the rules used. The no link can also (if desired by the user) ask 2 more questions –
- who should this ticket be assigned to
- what keywords or phrases can help me process this better in the future
Often times we as humans can read into text, get the idea of what the person means, realize that they called one system something else. Maybe two or more systems are integrated and I can tell which one they’re accessing by the description of what they were doing, or by the URL or error message. So asking #2 above will be helpful in teaching Sherlock those nuances.
Sherlock can be extended to actually request more information from the user before anyone ever sees the ticket (unless you’re one of the RT hawks that constantly lives in RT). For example, a ticket comes in and someone says generically, I received an error when I was filling out the vehicle request form. We know that error could be anything, literally. Sherlock could determine there is no error message in the ticket, nor a url and email the user back and request they paste in the error message and url. This can be expanded and we can have Sherlock ask for a multitude of information we may need to fix the issue, when this information is also necessary to figure out who to route the ticket to.
Notice NONE of the above is not affecting RT at all. Its removed the nagging from group A, because now its a bot that is gently asking if this is yours, and if not you can help it learn why. It alerts the “proper” people of new tickets, eliminating the constant monitoring of RT and reading many, many tickets that have nothing to do with you.
After a period of time, its accuracy should be pretty good, and with RT’s email interface, can generate an email back to RT and assign the ticket. When doing anything to a ticket in RT, Sherlock will always add a comment to the ticket with its Pandora disclaimer, so you know why you were assigned. That comment will also contain the yes/no links allowing Sherlock to be continually trained.
As I move forward with this project, I’ll use this blog to track my progress, and you can all view my successes and failures, and watch me learn all about NLP and content analysis, and who knows, maybe the system will make us one big happy family again.