By Chris Pope - 2014-05-20
Have you ever wondered, while you are consuming a specific service and human interaction is required, the reason for the level of effort to deliver that service? For example, when checking into a hotel there are a few basic tasks needed:
1. Validate the guest
2. Take a form of payment
3. Provide a room key
The first two of these tasks can be easily automated and managed, due to online booking or reservation pre-booking your stay at the hotel. The third task is an output of the successful completion of the first and second. Therefore I challenge you during your next hotel stay to count the number of keystrokes it takes to complete the third task!
On recent business trips, I have experienced anything from 83 all the way up to 147 keystrokes (jet lag can play weird tricks and makes me more inquisitive so sadly I did count them!). Upon further questioning of the front desk agent, I was given the opportunity to experience the other side of the desk and watch what actually required 83 keystrokes. To my amazement this is how it broke down:
Now, it seems very clear that with the right level of design and automation, only four of those keystrokes are truly required (the room number) – saving a huge amount of time and, ultimately, providing a fantastic service experience.
Too often in IT when implementing enterprise systems, bigger is thought of as better. It’s a notion that more fields, the bigger the screen, the more powerful the server will lead to a much better service experience, high levels of performance or the ability to do more faster and cheaper.
When implementing these systems, a symptom that often occurs is to provide a solution that focuses more on How to solve a specific problem without actually understanding What the problem is in the first instance, and then optimizing the service experience to deliver the solution. In a recent meeting with the CIO of a national service provider, they made a comment that has stuck with me: “Drawing cylinders and arrows doesn’t satisfy the business user or end customer.”
Certainly this process can help in delivery or implementation of a service, but has no concept or persona that focuses in on the service experience that the system is required to deliver. In many cases, the implementation team of very smart technicians and architects (there, I said it!) have never or will never actually interact, consume or use the service being designed. What hope do they ever have of hitting the mark to ensure an optimal service experience for both Requestor and Provider?
IT has to walk in the shoes of the provider/consumer, delivering solutions that provide an optimal service experience. On the flip side, the consumer/provider has to drive and demand that IT is delivering the outcomes that directly correlate to the service experience required.
Next time you are waiting for a service to be fulfilled, take a look and pay attention to what is being done to deliver it. Yes, get brave and ask them what they are doing and why? You’ll be amazed!