Skip to Content

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

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Florian Henninger

    Hi Colleen,

    nice written. I think it is a ongoing process everywhere, not just at hotlines/support or something similar to it.

    All of the defined processes out there need to reviewed constantly. I mean, there are some which are not that fast changing, but others changing really fast and it hurts everyone if nobody cares about it.

    As a quality manager I just can say I do care about such stories and try to redesign/enhance the process, so that people like you not get directed to some dead line.

    What I want to say, in the end I’m pretty sure companies which are listening carefully what their customers are talking about will survive and will reach their goals, so I think the support environments are the best glass into a company to be sure, if it is a winner or a loser in future 😉

    ~Florian

    (0) 
    1. Colleen Hebbert Post author

      Hi Florian

      Thanks for you feedback. Your are right, it’s not just a support environment. I’ve referenced support here as I felt the Career space needed more focus on this aspect and hope to encourage others to think about the skills necessary to work in a support environment (as well as such jobs being important and fulfilling if you have the disposition for them).

      Quality and continual re-testing is necessary. In an outsource/offshore model, you still need to retain people who can ensure quality standards are being met. We need more people like you who value quality and the need to continual review processes to improve customer service.

      Regards

      Colleen

      (0) 
  2. Martin English

    Hi Colleen,

    This touches nicely on your previous blog Why so curious?. In this case, you’re talking about the business needs versus system security… why are we giving this user a particular role ? is there a better security role for what they need ? From a technical view, the questions range from how can we speed up the provisioning process to is it time to move off CUA on to IDM and / or GRC ? As you allude to, someone who is interested / curious enough will come to learn when to deviate from the script / process, or when it is more appropriate to “disrupt” the script / process by writing a new one.

    It isn’t “smarts” or even aptitude; it is interest. I have worked with people who were quite open that the point of their job was about having, say, 2 days a week at home, or being home by 3:00 PM everyday. The smart ones were aware of the choices they were making and the impact it would have on their technical knowledge, but were also open that family time was more important. They were valuable team members, because they valued these jobs for what they provided outside the technical aspects of the job, and so they were committed to these jobs, during work hours. By comparison, I always look a bit sideways at people who claim to be “committed” developers or administrators, but don’t have access to systems or playpens that they’re fiddling with or learning on outside “work” hours (for example, how do you know you can do a system recovery if you don’t have a spare system to break ?)


    The challenge is recognizing where an individual staff member fits on this continuum, having the appropriate mix of staff (which will be different for each team and each organisation) and managing each individual appropriately.

    hth

    (0) 
    1. Colleen Hebbert Post author

      Hi Martin

      Disruption is a great word you have used to describe it. I wish i had thought of it.

      Thanks for your thoughts. Yes, this topic did come to me when I was writing about curiosity and I had meant to link the blog in but I forgot to. Also, seeing articles on business trends and design thinking got me reflecting more on support environments. In my current client site, we are going through business transformation. I started to reflect more on how procedures (as much as they are needed) can limit some creativity as it stops people from thinking outside of the box or questioning why a process has been defined a certain way. We risk falling into the trap of “that’s how it’s always been done”. It’s hard to obtain simplification, etc without be allowed to disrupt process – or consider it as option. At the same time, I didn’t want to position this blog as an encourage for everyone to throw the procedures at the window – there needs to be some balance.

      The different types of colleagues also has impact. I’m the type that chooses what time I arrive in the morning as the day can be so unplanned that I don’t always choose what time I leave. There’s always something else I can work on (even harder if it’s the home office). For the colleagues who have a different priorities and commitment, I do admire them. It would be a challenge to continually develop and keep up with the latest technologies. The brilliant ones manage their time so they make the most of their time at work. Perhaps it comes down to work smart instead of hard but if you can do both, even better.

      Regards

      Colleen

      (0) 
  3. Julie Plummer

    HI Colleen,

    Very interesting – made me think, and brought back memories. I worked on a tech support hotline 20 years ago: we originally had a mixed scripted/unscripted approach that worked well: ie a script for basic info (PC or Mac, OS version, RAM, HD space, etc), then “use your detective skills”. For us though, the ratio was probably 30:70 : 30% of callers had a known or pretty simply issue (too many fonts, not enough RAM) , 70% more complex.

    Later, managers imposed stricter rules about the script, training was cut, quality went down, and the best staff left.

    I agree that scripts can be useful. I think ultimately some of the issues boil down to good management or leadership: If you are prepared to invest in good training and mentoring and staff retention incentives, then you should (I hope) get staff who can judge when to go off script. Unfortunately (as in your story above), sometimes you get the other kind :-(..

    Best wishes,

    JUlie.

    (0) 
    1. Colleen Hebbert Post author

      Hi Julie

      I think you’re got a good point about the 30:70 split (or similar). Perhaps, that is more the difference between Level 1 Support and Level 2 or 3. The higher up the escalation process the less like the activity is repeatable and is based more on analysis and detective work.

      Stricter rules can be counter productive if the balance isn’t right.

      Cheers

      Colleen

      (0) 
    2. Matt Fraser

      Help Desks, and their scripts, can be tricky things to set up. For instance, it’s not uncommon for help desk staff to be evaluated on how quickly they ‘resolve’ calls that come in, or how many calls they handle per day. There has been a lot of speculation on SCN about whether this drives some of the experiences with SAP’s own customer support organization (though I personally had a very good experience with SAP customer support just yesterday). Obviously, if you as a member of the Help Desk are being evaluated on quickly getting calls out of your queue, then your default response to anything beyond a simple password reset is going to be to escalate it to the next tier of support and move on. Maybe even password resets get escalated, especially in times of high call volume. You look efficient, the Help Desk as a whole looks efficient, but now it has become only a glorified receptionist directing calls, and overall IT efficiency and cost-effectiveness has gone down, as more expensive staff are consuming their time handling simple matters instead of driving higher-value-added changes and improvements.

      On the other hand, if the Help Desk is trying to do too much, they are going to build up large queues of frustrated callers waiting their turn, and may spend too much time going down blind paths that an expert would quickly recognize as a wrong turn. So that’s the trick, to train them enough to handle that 70% (or 30%) of calls that can be scripted, to have enough knowledge to do some basic detective work on multiple disparate systems, but also to know when to escalate.

      Help Desk is often seen as an entry-level job for IT, but truly excellent Tier 1 support staff are worth their weight in gold, so what do you do when they naturally want to advance to something else? Have them write the script, then move them to Tier 2, and turn them into that more expensive staff driving high-value-add change. 🙂

      (0) 
  4. Julie Plummer

    HI Colleen,

    Very interesting – made me think, and brought back memories. I worked on a tech support hotline 20 years ago: we originally had a mixed scripted/unscripted approach that worked well: ie a script for basic info (PC or Mac, OS version, RAM, HD space, etc), then “use your detective skills”. For us though, the ratio was probably 30:70 : 30% of callers had a known or pretty simply issue (too many fonts, not enough RAM) , 70% more complex.

    Later, managers imposed stricter rules about the script, training was cut, quality went down, and the best staff left.

    I agree that scripts can be useful. I think ultimately some of the issues boil down to good management or leadership: If you are prepared to invest in good training and mentoring and staff retention incentives, then you should (I hope) get staff who can judge when to go off script. Unfortunately (as in your story above), sometimes you get the other kind :-(..

    Best wishes,

    JUlie.

    (0) 
  5. Otto Gold

    Consider a challenge: You have a customer with random “procedures”. How do you turn that environment around to work like described above? Ideally consider the size of the company as well while giving your guru suggestions 🙂 I will gladly read it…

    (0) 
    1. Colleen Hebbert Post author

      Your challenge sounds like the typical challenge for many support environments when they start going down a path to streamlines their processes (usually ITIL compliance included). Probably a blog in its own write but not sure if Careers is the right home for it (or if I’m qualified to write such an article 😉 )

      In my own experience, however, I have worked in teams to get back to a stage of being “robust and repeatable” and “efficient and effective”. Most of it tied in with SixSigma and ITIL training. The acknolwegement was that to improve your need to measure. To measure you need some consistency and a baseline to compare to. Hence procedures. Get everyone working the same way no matter the person, their skill or location. I was on board with these basic rules and concepts. But having worked in such environements and discussed with colleagues for handling of situations where things go bad (Basis friends having a ‘why did you press that button’ freak out to a member who replies ‘because that’s what the procedure said’ even though the screen showed something else), it inspired me to write this blog.

      I see the challenge as to getting a team to the stage that you can trust them to disregard process without having to receive a phone call in the middle of the night to step them through.

      (0) 

Leave a Reply