This is the first opportunity I have had for a while to put something on this blog — busy, busy, busy. (I can tell you that I am building up a fairly sizeable backlog of articles on parallel development and I will, I promise, get round to publishing them soon.) In the meanwhile, here’s a brief thought on designing ticketing systems.
Many ticketing systems, supporting processes such as incident management, are prone to ticket ping -pong where tickets are bounced from queue to queue as people keep forwarding the problem to get it off their queue. This is simple to control once you see the problem.
Processes that suffer with this problem all have one thing in common; they all allow one user to simply pass a ticket from their queue to another unchallenged. For example, an incident ticketing system shows up a ticket on Person A’s queue. They cannot deal with it (or do not want to deal with it), so they look for someone they believe should deal with it and assign it to their queue (Person B). Person B looks at the ticket, decides they should not be dealing with it and looks around for someone else to deal with it (Person C). And so it goes, the ticket to bounced around from queue to queue never being handled but always being sent on, possibly even returning to Person A who forwards it on again and the cycle continues.
The problem is that the ticket owner in such systems is defined as the person who has the ticket on their queue and anyone can pass a ticket to another queue. Since no one wants to be lumbered with the ticket it just keeps being passed on. It becomes an SEP (someone else’s problem), doomed to forever wander the queues, never being resolved.
Fixing this process is actually very simple. When a ticket is initially raised by a user onto someone’s queue (let’s say Person A) the queue owner becomes responsible for progressing the ticket. If the Person A believes the ticket belongs to someone else (say, Person B), they propose it into Person B’s queue. But, and this is the important change to the process, ownership of the ticket remains with Person A. Person A remains responsible for ensuring that the ticket is progressed (not simply passed from queue to queue) until Person B accepts the ticket into their queue. This puts pressure on the Person A (as the ticket owner) to actually manage the process, whereas the original process did not pressure anyone because they could simply pass the ticket on to someone else.
It may seem unfair on Person A. It could be that they really cannot deal with the ticket. It could be that Person B really should take ownership of the ticket but they may be trying to avoid doing so by not accepting it into their queue. This is what escalation is for. If Person A has a legitimate cause they can escalate the problem and effectively force Person B to acknowledge their responsibility. In practice this is seldom an issue as Person B, if they recognise their responsibility will simply accept the ticket into their queue and progress it to completion.
I Person B genuinely cannot, or should not, deal with the ticket they simply inform Person A of their reason for not accepting it into their queue. Person A must now seek the correct person to resolve the ticket. Because Person A is responsible for the ticket until someone else takes charge of it they have a vested interest in finding the correct person to deal with it. If they propose the ticket to someone’s queue and do not get a quick response they have a vested interest in following up to find out why the ticket has not been accepted. Person A is motivated to find the correct ticket owner since no one but the correct ticket owner will take the responsibility for progressing the ticket away from Person A and until some takes it from Person A it remains theirs to progress.
Ensuring that people cannot simply pass tickets around the system ensures that they are progressed because it puts pressure on owners to either resolve the ticket or to find the person who really should resolve the ticket.
