A few years back I discovered my phone had been barred which prevented me from making or receiving calls. As a customer of 10+ years I was confused and so I called the service desk to find out what the problem was.
Me: Hi I need to find out why my phone…<<cut off>>
Them: Welcome to an hour of your life you won’t get back. May I start with your full name, date of birth, account number, last bill details, random bit of information you will be scratching your head to remember and finally a password.
Me: stumble through the questions correctly
Them: How may I be of assistance to you?
Me: Explain issue (also mentioning I’m in a new city, this is my only means of communication and I cannot make or receive calls causing worry from interstate family)
Them: We found “issue” and we need to transfer you to another team -> Exit stage left.
Automatic Message: Sorry our hours of operation are between blah and blah.
Me: Rinse and Repeat 3 times. Each time, asking them to stop transferring me. Each time failing. I temporarily concede defeat and try again the next day.
I’m sure I’m not the only one who’s been a customer and ended up frustrated trying to get assistance from the Service Desk. At the same time, I have worked a Service Desk environment a few times and I know what it’s like to be the person following the script. In truth, I’m guilty of writing and enforcing them as well.
Why we script support
Within a matured support environment processes are defined and procedures exist to facilitate consistent customer support. These processes are (usually) underpinned by clearly defined and measurable Service Level Agreements based on a methodology/framework such as ITIL. The use of work instructions ensure each person – no matter whom they are, where they are located or what time they are working – will consistently respond to the customer issue. Great – this makes complete sense! We can measure this. We can estimate how long a service takes to deliver. We can compare and contrast how effective the service issue. We can obtain metrics to represent quality. And in many cases: we can outsource or offshore this.
Blind adherence
Having defined procedures and implemented them I have become of two minds as to whether goal of consistency improves or impedes customer service. On one hand, consistent procedures aim to take each incident from a symptom through to a successful resolution for the customer. Within a level one support scenario (such as password resets or account creation) the procedure can be established to collect evidence that due diligence has been performed (identity established and approvals obtained). The procedure can also include templates for consistent communication to ensure the right information is sent to the customer – something that is quite useful for situations where you have personnel from all over the world with varying language competency.
Yet, on the other hand, we create a risk of “monkey see monkey do”. We risk the expectation that our team follows procedures they may not actually comprehend. We risk having a team in the situation I experienced when my phone stopped working. Yes, they did their job and followed everything through to the “T” but they didn't resolve my issue. At no point did any of them stop and question the script. As the customer, I had a negative experience and it became a key factor in choosing a different phone provider on my next contract.
Realising there is a limitation
Procedures and work instructions are created based on work activities and common incidents. It is impossible (or unproductive) to anticipate everything a user can do (or not do) in a system. Creative users are brilliant at finding new and interesting ways to break the system. Therefore, the procedures are more likely to be an 80:20 fit to covering work situations. It’s the 20% of the time when we need to have the ability to realise the steps don’t make sense for the situation we find ourselves in.
Within the SAP security area, we frequently define procedures for user access request: Request --> Approve --> Provision. However, the provisioning step requires more knowledge than just how to assign security roles to a user (you could argue an additional step of VALIDATE). It requires an understanding of the security design and knowing whether access is appropriate or not. For example, if an end user asked for debug change or Basis access no amount of approval would persuade me to provision the access even if the procedure tells me to provision. Someone who blindly follows the procedure as part of provisioning step may inadvertently assign this access.
Admitting there is limitation to documentation by no means invalidates or undermines the use of documentation. It still has use for - most of the time. However, good procedures require continual review and testing to ensure they remain current. And this includes defining the limit for the usefulness of the documentation.
Teaching Limitation
Team members need to learn that documentation can have a limit and will not always help them. Part of this is developing your team and trusting their abilities to speak out when they believe the limit has been reached. To achieve this, team members must know their domain/knowledge as well as the design for the business. They must also understand the goal of the procedure – the intended outcome. If they can learn why the system works a certain why they will be in a better position to realise the procedure does not apply to their situation.
When I train staff in the procedures I will devote time to teaching the theory and content but also spend as much time encouraging trainees to prove me wrong and find fault. As well as that, I will reward mistakes. This may seem counter intuitive but it is a step in gaining trust. I have found it takes a high investment in training to build up a team who is willing to admit when they are confused or lost and what they are being asked makes no sense. In some cases basic revision fixes the problem. In other situations, we can discover the procedure is ambiguous, makes assumptions or is incomplete. This documentation can then be improved. Regardless, encouraging them to recognise a limit and ask for help prevents mistakes in the system.
Controlled Deviation
Depending on your position you will need to discuss with your team leader when it is appropriate to deviate from procedure. Part of this conversation requires you to prove your abilities. You do this by demonstrating your knowledge of the procedure as well as understanding of the system. You can further demonstrate this by notifying your team leader if you believe there is a mistake in the procedure. Rather than deviate, you pause for clarification and validate.
Where you find legitimate cases to deviate (can’t be bothered does not count) you need to think through the implications. Analyse your solution and where possible test it. If critical and irreversible then take a back up first (make sure you always have a way to reverse your actions). Be prepared to justify your actions to management (there will more than likely be a root cause analysis if the situation was critical). Ensure you have documented your actions.
Getting back on track
Always aim to re-align with the process. Take the time to analyse why the process failed. You may find the need to update the procedure or add notes to an FAQ. Take the necessary actions to fix the root cause. You might even realise there was a human error at play. Either way, deviating from a procedure is a temporary measure. Next time you are in the same situation you procedure will make sense.
What are your thoughts on procedures and work instructions for Support Environments? Do you encourage (trust) your team to deviate when necessary? As a team member, do you make effort to understand why the procedure was designed a certain way? Do you pause and ask for help when the procedure makes no sense?
Regards
Colleen
