I’m sitting on an Amtrak train going from Seattle to Portland right now. I had a great morning meeting Gavin Riley, the new Sales Manager for Brian Miller’s company Fusiontek. In our industry, a sales manager is a rare thing so it made this morning interesting, challenging, and educational.
After working with Fusiontek in the morning, I had the opportunity to go eat incredibly hot wings at the Wing Dome in Seattle with Harry Brelesford of SMB Nation. As usual, Harry drops some serious knowledge from the front seat of his Volvo navigating the streets of Seattle with a million dollars of carbon bikes strapped to the back. Overall not a bad way to spend a day if you ask me.
So, none of that has crap to do with this blog post title, so let’s stop messing around and get down to business.
Centralized Dispatch. This is my answer to about 400 different IT company questions.
How can I increase managed services contract profitability? Centralized Dispatch
Where are my techs? Centralized Dispatch
Why won’t my techs enter their time? Centralized Dispatch
Why isn’t my service board clean? Centralized Dispatch
How do we get rid of these old tickets? Centralized Dispatch
How will I ever not have to be here all day every day? Centralized Dispatch
Why isn’t my Net Promoter Score higher? Centralized Dispatch
Centralized Dispatch is a model of scheduling engineering resources using one central position as the hub for all client – engineer interaction. Clients interact with a dispatcher through phone, email, or some manner of ticketing portal when they have a technical problem. The dispatcher formulates, immediate, short term, and long term schedules in order to meet SLA’s, address emergencies, ensure happy clients, and keep engineers billing their time for the maximum amount of time.
This model takes all of the burden off of engineers and clients and places it squarely on the shoulders of the dispatcher. (JOSH’s NOTE: please do not be stupid and think or even say “well Josh, what about when that person is on break or vacation?” If you can’t figure out that solution, pack it up and call it quits)
This is not a new idea. It is not an unproven idea. It is what some of the most sophisticated industries in the world utilize to make sure things run smoothly. Let’s take a look. How do planes come and go at O’Hare in Chicago? Do the pilots decide what time to take off? Do the pilots talk to each other and decide who should land next? Absolutely not, there are air traffic controllers watching every move directing the pilots on exactly how high to fly, what speed, and when they will land. The pilots have almost zero control over this process and I can assure you they don’t want any control over that process. They are pilots, not controllers. They are experts in flying, they love to fly, why would we rely on them to do anything else? Well if many of you were in charge, you probably would have the pilot “self dispatch.” Why? Well of course because pilots are smart, they shouldn’t have to be micromanaged, they should just look at the list of flights and know what to do next, right?
We can look at several other industries, but let’s keep it easy.
Who do you make your appointment with at the doctor’s office? Medical Scheduler. Doctor follows that schedule every day.
Who controls an NBA player on the court? Coach does. He says run this play, call a time out, come out and rest, get back in and play. Who decides the NBA game schedule for the season? Not the players…they just show up and play; give your engineers that same luxury.
Enough analogies, let’s get down to the fundamentals:
1. All engineering requests come to the dispatcher, even help desk requests
2. Clients NEVER call engineers on cell phones
3. Office phones do not round robin to engineers
4. Dispatcher OWNS the engineers day. This person determines who works on what and when and for how long.
5. Dispatcher is not technical and is not tier one support. They are experts in customer service and in utilization allocation.
6. Tickets will be scheduled out as far into the future as necessary.
7. Dispatcher SCHEDULES appointment time with client AND engineer. Now this one is interesting, I actually had someone tell me that their PSA provider told them never to schedule a time with client but instead to create a service window of 2 hours. I don’t believe this person because you’d have to be an absolute IDIOT to give advice like that. Only a total fool would advise their client to act like a cable or telephone company. For now, I’ll choose to believe that my friend misunderstood their PSA’s advice.
8. Finally, the dispatcher ensures that the ticket status is accurately updated to reflect it’s real state in the service process. Is it in progress? Is it waiting on parts? Is it complete? Engineers change the status, dispatch ensures that it’s accurate.
So that’s the basics. There are a lot of blanks to fill in here and maybe I’ll cover them in another post. Right now I just want you to start thinking about what’s working in how you’re moving engineers around right now and what could use some improvement. Is Centralized Dispatch the answer? I certainly think so.
I have 3 engineers and have hired a dispatcher two months ago. He barely knows how to turn on the computer, let alone provide any technology advice. I won’t lie to you, it has taken a lot of my time to get him up to speed and to work out the kinks in the system, but it is starting to pay off. I got an unsolicited email from a customer yesterday stating:
“[Your dispatcher] is doing a great job of checking the techsupport email and getting right back with people on scheduling a service call. I just thought you should know!”
This is the same customer that used to complain weekly about our poor response times.
We have taken Josh’s dispatching model and have implemented it almost verbatim. I am very happy with this “investment” so far.
Tom
Great post.
Like Tom K, we implemented our first “Service Coordinator” a little over a month ago. It’s been rough developing the new processes but we thought we made the right decision overall and are pleased with the initial outcomes. In our recent TBG check-in, some of our peers raised the question of a technical dispatcher vs. non-technical. I bring this up because our original non-technical SC just left and when rehiring the position, we are tempted to find that hybrid technical-dispatcher so he can greater understand issue triage (of course, not work any of the tickets).
I am a service coordinator currently for our company now and would consider myself a non-technical SC. I will admit that in the beginning there was a learning curve when it came to asking the right questions on a service call. Our techs are great though and I work with them constantly on finding out which questions I need to be asking. Currently we are working on documentation on questions for specific problems. I think it is important to have that information documented so that if you do need to find a new service coordinator they have something to refer to.
Great blog…I am currentlty a Service Mangager at my company but I also am responsible for the dispatching. I agree with this 100%. Dispatching is an essential part of the buisness and dare I say probably the most important. Its the first line of defense for the company. My preference would be to hire a dispatcher and for me to step out of that role, I think someone with at least a little technical knowledge wouldnt hurt so they can understand what is going on and whats being said. Once again great blog and look forward to reading more
We have 8 techs and do not provide dispatching as part of our model currently. People want faster and faster service and currently our SLA provides <60 second access to a tech that can actually fix their problem.
Although it's COMMON that we have to deal with a dispatcher when we schedule things like appts, etc, that is not the service we provide. We are providing access to actually FIX the issue of the caller…not schedule an appt to EVENTUALLY fix the problem. A better analogy would be your local "ask a nurse"… you call to talk to a nurse and not a dispatcher who will tell you when the nurse will call you.
How are you guys able to move to a model that introduces a middle man (who likes that?) and slows access to expertise?
Ken,
I can’t wait to hear some responses to your post. Great analogy by the way on the “Ask a Nurse”. In my experience, most companies seem to see a true decrease in time to resolution when they implement a well thought out dispatch model. Thank you for the comment and shoot me an email sometime to discuss. Best to you!
JP
Ken,
60 second SLA – are you serious? What happens when you have 9 calls at once, dump the first call so you can meet your SLA? How about sick days, pissed off techs, lazy techs, techs stuck on calls they cant fix. What happens when a tech forgets to call back a client? What happens when the tech schedules a repair for 2:00 and doesn’t show because his repair he schedule for 12:00 runs long?
You can not run a successful field service organization with out a dispatcher or service coordinator.
Ken, that sounds like a great model! If you have figured out a profitable model for that level of service, I would love to hear more. My problem, like the “other” Tom
, is that techs get lazy, forgetful, busy, etc, and that is where the problems start. Dispatcher model is not the only model that works well, but we have found it to be very efficient and profitable.