The good and the bad about Dispatch. Learn from my experiences and improve the way you dispatch tickets!
I remember the first time I worked a dispatched ticket. I was hammering away at a printer issue that appeared to be driver related. While trying to figure out if there was documentation or process defined for printers, I received an email from dispatch with my next ticket scheduled to start in just 15 minutes. As the day progressed, this was a recurring experience.
Our dispatcher was taking incoming calls, creating the tickets, assigning them to the team, and reassigning them when it became necessary. She constantly controlled and adjusted the team’s schedules during the day and was good at what she did. She kept the entire team working, prevented cherry-picking, and made sure issues didn’t fall through the tracks. (Most of the time)
We used automated workflow rules to help her manage the tickets by adjusting their status as they aged or got close to breaching our defined SLAs. She would keep an eye out for these statuses while monitoring our boards.
The system worked much better than an unstructured approach but I struggled to ‘like’ it.
It required an incredibly organized and dedicated resource to manage it properly. So it’s expensive and prone to user error. Not to mention, there were always little rounds of bickering between dispatch and support/engineering. I am sure many of you can relate to!
Our dispatcher may have been a wizard, but she couldn’t always be perfect… It’s incredibly difficult to know exactly when a tech is going to finish up the ticket they are working on. She wanted to assign to the next available technician as quickly as possible so that she can be ready to take the next incoming call. Unfortunately, she was always forced to guess, and/or interrupt the entire technical team to get an estimate for higher priority issues.
Dispatchers have a lot to remember and remembering to reassign that critical ticket amidst the chaos of modern-day services? HA! It can’t be perfect every time and critical issues cost you business.
So it’s costly, can create tension between dispatch & tech, interruption is part of its process, and it essentially creates ‘multiple queues.’ Check out this SlideShare by ‘Lavi Industries’ – it describes why a single queue system is often favorable.
I am the LT Ninja, an engineer, who loves to create things that solve the things I don’t like. Queue. Ninja is my solution to traditional dispatch. I designed it to address the issues I discussed above.
It works by providing real-time insight into your service boards. So, as your tech(s) finish a ticket, they get a personalized pulse from Queue Ninja directing them to the next ticket that they should work. It can be fine-tuned and easily adjusted to grow with your business.
Sign up for early access at http://Queue.Ninja/ before 2016 for free implementation($249 value) and 15% off your queue.ninja subscription costs for a year!
And remember, with Queue. Ninja, technicians dispatch themselves! (Like Ninjas!)
