Can Slower Service be Better Service?
All else being equal, the quicker you complete a service visit, the better for everyone involved. Isn’t this obvious?
Well, from time to time it pays to take a look at some obviously true statement and ask whether there are cases when it is not true. For example, take two service engineers, Alice and Bob, who both install and maintain computer and office equipment. Bob is courteous, professional and effective. He gets the job done and moves on to the next job. Alice does just as well, but she stays for a few more minutes, chats with the customer about how he views the service he’s receiving, and offers to check up on some other computer and office equipment (whether these are covered under the customer’s contract with Alice’s employer). Needless to say, Alice will only do this if the customer is also interested in this additional time and service. By the way, her main motivation is to improve the service experience; she isn’t attempting to sell more services, though Alice will present such options if the interaction with the customer calls for it.
Now, would you like your service organization to pick Alice or Bob as the role model? On the one hand, Alice may complete fewer tasks per day, generating lower direct service revenue than Bob does. She might even be providing, for free, services that Bob’s customer would have paid for. On the other hand, she builds up customer satisfaction, which reduces customer churn (which is notorious for its highly negative impact on revenues and profits) and helps bring in more customers. When we add these considerations together, is Alice’s behavior contributing or causing harm to the service organization’s business goals? How about Bob’s behavior?
This question seems difficult to answer. However, there is a hidden assumption here: As I told the story, Bob always rushes away to the next task, and Alice always takes some time to build up the relationship with the customer. I would say that according to this story, both Bob and Alice are behaving sub-optimally. They should act according to the situation: If the work day is expected to be very busy, or if any delay at the current location risks being late to the next job, Alice and Bob should get to the next task as soon as possible. However, even in the best-utilized workforces, some free time windows will occur, for some parts of the day of some service engineers. When Alice or Bob reach such a “free window”, they should consider investing some more time in each customer visit.
Now, how will the service engineer know whether to act like Bob or like Alice (as portrayed in the original example)? They can know some of it by examining the next task(s) scheduled for them, but this is not a good answer: First, the engineer would have to examine these tasks, and the promised SLA or appointment window for each, and also consider the travel time along the route to these tasks, which takes time and has to be done while the customer is watching. Second, even if the engineers do so, they may be missing some important information: For example, if higher-than-usual workloads are expected later in the day, it may makes sense for the engineer to get back to the central office as soon as possible even without being dispatched to any specific task. Who has all this information and can make this decision? Only the scheduling team back at the central office. However, they will not have the time to make this analysis for each and every service visit. Fortunately, they can get the service management software to do it for them. This software can make an intelligent decision for each task, and communicate it to the service engineer’s mobile device. It can also take more things into account, such as the value of that customer for the service organization, or the last time since a thorough checkup has been performed. If the software determines that it would be worthwhile to perform a few more steps, it can feed information about these steps directly into the mobile device, and the service engineer will be prompted with these steps as soon as he or she reports the task as completed successfully. As happens often in such cases, this kind of additional automation actually enhances the service experience – for example, if the service engineer says “a couple of service visits ago, we fixed your laser printer; has it been OK since? would you like me to run a quick check?”, it does not matter that this was prompted by software. All that matters is that the customer receives a clear message that the service organization cares about its customers. If you can deliver this message while still meeting all your service commitments to other customers, isn’t this something to aspire to?