A Conflict of Interest - SLA Negotiators vs. Consumers of IT Services

Written by admin on June 3, 2009

 

John Towsley has been talking recently about the fact that IT Service Managers are renewing their focus on customer service.  Funny enough, I had an interesting discussion about customer service-related SLA’s with a Service Desk Manager in Europe today about that very topic.

 

 

What is ‘Good’ Customer Service?

 

We all have preconceived notions of how long we should have to wait before reaching the Service Desk.  We get upset when we have to wait a moment longer than we think we should (and often complain about the experience as we wait on the phone to those within an earshot). 

 

Therefore, let us say that good customer service for a Service Desk is when:

Reasonable Expectations of Service Delivery = Actual Service Delivery

 

 

The Conflict of Interest

 

The Service Desk Manager I was speaking to said that, while customer service was important, it didn’t necessarily have to a back-breaking effort.  Instead, negotiated customer service standards (i.e. SLA’s around abandon rates, first call resolution, etc.) should be diligently managed towards.

 

But here’s the catch!  She remarked that while a target abandon rate* for a large Service Desk might be 5%, it’s important to remember who negotiates this SLA.  While a VP might find it acceptable for abandon rates to stay under 5%, the end user community at large may find it unacceptable.  For example, imagine – from an end user’s perspective – what the acceptable abandon rate would be at a legal firm!

 

It looks to me that there is a conflict of interest between a VP trying to negotiate the best deal he can get vs. the end user community seeking their definition of good customer service.

 

 

Lessons Learned

 

Perhaps an end user panel should be created when negotiating SLA’s.  At the very least, we should make sure that SLA’s are communicated to the entire end user community so that they have their expectations managed when they pick up the phone to call the Service Desk or engage in other IT services.

 

*The Abandon rate refers to the number of callers that hang up (out of 100) before reaching a Service Desk Analyst.  This will often happen when an IT consumer is fed up of waiting for support.

 

 

Michael Jagdeo (SCM, ITIL v2/v3)  has an extensive background as an ITSM/ITIL enthusiast. He has worked on placements in Singapore, Dubai, London, and across North America. As Director at B Wyze Solutions, he manages relationships with clients like Johnson & Johnson, Toyota, Maple Leaf Foods, and the Government of Ontario. Follow him on Twitter!

Five Best Practices For Managing A Virtual Support Team

Written by Christie Chuakay on May 26, 2009

It’s amazing how often a simple question can really make you think. We recently hosted a webinar called “Best Practice Service Delivery Review for Remote Support Professionals.” A Service Desk Manager who works in the health care industry was concerned with how to motivate a virtual team.

She asked a great question: “What are some of the best practices in place with regards to team building for virtual staff?”  I’ve heard many managers responsible for a virtual team express the same concern.  Tim Dewey, CEO of B Virtual, answered the question with a list of the Five Key Best Practices:

1) Recruiting the right candidates is essential. Build an assessment document that outlines the special skills required for remote agents. These skills should differ from traditional “brick and mortar” support professionals.

2) Define a balanced training program that includes multiple layers of training delivery including live instructor led, E-learning self paced, webinars, and recorded calls & support sessions.

3) Develop a pre/post checklist for support professionals that brings visibility to daily quality, performance and challenges.

4) Develop team building exercises with the remote team, focusing on collaboration and continuous communications across all of the company.

5) Create employment agreements for any remote employees that includes objectives and expectations of the position.

These are just a few of our Best Practices. Do you have some of your own? Leave a comment and tell us what they are!

Help Desks renew Customer Service focus

Written by John Towsley on May 22, 2009

I recently met with four of our clients, each from a large, name brand organization.

All of these people stated that right now, their key initiatives and mandates revolve around improving Customer Service and the customer experience with respect to their Help Desk / Service Desk.

I found this to be a bit curious. Customer Service has long been a focus of a well managed service desk. Why the renewed focus in 2009?

Is this the same in your organization? Are you renewing your emphasis on customer service? Or is it just business as usual? Post a comment and tell us why!

ITIL Misunderstood – Insights from a VP of IT (Part 1)

Written by admin on February 26, 2009

Recently, I was speaking with a colleague of mine, Cindy Allingham.  Cindy has over 25 years of experience in IT and is a former VP of IT at a national bank in Canada.  We started talking about why ITIL initiatives have such a low rate of success, and I was truly amazed at the perspective she had to offer.  This is part one of our conversation (through email).

 

MJ –

You mentioned that ITIL initiatives haven’t realized their apparent goal of cutting costs.  Perhaps you can help me understand that a bit.  Wouldn’t Change Management – implemented correctly – reduce failed changes and save money?  Am I being naïve!?  Let me know what your experience has been when you say it makes things efficient rather than explicitly reducing costs.

 

Cindy Allingham –

Once upon a time, back 25 - 30 years, when IT was all mainframe, things in operations were very much more organized. They had to be, because they wouldn’t work otherwise. Processes were developed and put into place to handle incident, problem, change, release, upgrade and many others. There was no such thing as ITIL, but IBM, major banks, and insurance companies in Canada all had their own forms (some very sophisticated) of these kinds of processes.

 

As the 1980s and 1990s moved along, think of all the changes in technology and business usage there were!!!!! Can you image how much in business changed (and IT jobs too) when networks were introduced to link PCs? When the Internet made it possible for electronic communications outside of individual corporations? And then all the flurry of activity for Y2K. In the meantime, technology was streamlining itself too, in order to reduce the need and cost for human intervention to operate it. For instance, in the early 90s the rule of thumb in large corporations was to staff networks with one administrator for every 10 workstations. Imagine these days - one administrator usually takes care of an entire network of 1500+.

 

We have talked in the past about how Y2K meant a huge amount of work and money, interrupted the technology activities of most companies for a few years, and then because it seemed such a non-event, resulted in lack of business faith in IT. In the early years of the new millennium, businesses began to demand for the first time that IT account for itself, measure itself, prove to the organization that it was worth the money.

 

ITIL became popular in many organizations beginning in the early 2000s because it was a way to measure, monitor and manage IT in a formulized way, and IT could justify its activities. By this time IT needed to find ways of occupying many staff who had become unnecessary through technology streamlining, and improving process and measuring IT performance was a great way. Business was relatively happy because for the first time they were seeing what IT was providing and how they were doing it. Those preaching the ITIL gospel had opportunities for new specializations.

 

However, by 2003/2004, organizations had slimmed down considerably from pre-Y2K, and there was continued pressure from business to reduce IT operational costs by reducing staff. ITIL processes required reinstatement of roles that had disappeared in the late 90s; Incident managers, Problem managers, Change managers, Help Desk specialists, Release managers and specialists, process and project experts. This was acceptable while businesses could see returns - ITIL could help IT show what value they were providing and what levels of performance were being achieved. But as the economy started to tighten, businesses wanted to keep getting these things along with ever-decreasing costs.

 

MJ is a Director at B Wyze Solutions.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222

Tales from the Unsung Heroes of ITIL & ITSM blog - Middle Management

Written by admin on January 20, 2009

 

I’ll use my blog posts to share interesting ideas/frustrations/stories from my conversations with ITSM Management.

Incident Categories - AWESOME perspective!
1.  Ticket comes in.
2.  Ticket gets categorized based on what the Service Desk Analyst believes to have caused the incident.
3.  Ticket get escalated.
4.  Ticket gets closed by 2nd or 3rd level.
What’s missing here?  What is the categorization that 2nd or 3rd level would use to classify the ticket!?  That’s the true classification you’re looking for.

Balancing what is new and what is efficient
We’re in IT, and IT is cool to us.  That’s sometimes the reason that network, security, and applications groups want to implement new technologies.  However, IT is a service to the business, and as such we must ensure that we balance what is new and what is feasible given business needs and budgets.
When considering new technologies, make sure you perform a:
- Benefit Analysis
- Cost Feasibility Analysis and
- Risk Analysis
Good questions to ask:
- Should we implement a new solution now, 6 months from now, or next year?  
- How will the change interact with other changes already scheduled?

MJ