Better Service from Service Providers

Tips for Customers - Part 2

This is the second of a 2 part paper. The first part can be found here. A separate paper on Tips for Providers will follow.

“An educated customer may have a firm idea about his needs, what he would wish to purchase. He may be able to specify these needs so that a supplier may understand them. A wise customer will nevertheless listen and learn from suggestions from a supplier”

W. Edwards Deming, The New Economics for Industry, Government, Education

The paper at a glance

In this article I provide some tips on how customers can manage their service providers so that both may benefit. These tips are written in the context of IT infrastructure service provision, but they are relevant to all service providers.

More and more business activities are now being undertaken by external and internal service providers, yet dissatisfaction with the services provided is common, as are its drivers (service failures/disruption, lack of responsiveness, same issues repeatedly).

Dissatisfaction leads to desertion – expensive for both parties. Better to work together on continuous service delivery improvement and cost reduction.

A mutually rewarding customer-provider relationship begins with a provider selection process that clearly and correctly sets consistent expectations of service scope and quality. The process also sets out the parameters for managing a successful relationship – service levels, performance reporting, multi-level communication, collaborative reviews, change management and continuous improvement.

Service quality and high customer satisfaction are not, however, solely the responsibility of the service provider. The customer also has responsibility for service assurance with regard to maintaining user competence, keeping work documentation and service documentation up to date, and testing business continuity plans and disaster recovery mechanisms (in conjunction with the service provider).

A PDF version of this paper is available here

Part 2

This second part covers
  • Service Delivery
  • Service Improvement
  • Service Governance
  • Service Assurance.
The first part covered:
  • What are service providers?
  • Satisfaction with service providers
  • Selecting a service provider
  • Customer-Provider Agreements.
Service Delivery
Internal technical staff
Some of you will employ internal IT staff to supplement and assist your service provider. This role will usually encompass:
  • Liaison with your service providers’ technical staff
  • On-site assistance to your operational staff with IT-related matters
  • Testing of new, upgraded or modified services and/or equipment
  • Implementing local “workarounds” while your service provider pursues incident resolution
  • Conduct of IT-related projects that are outside the scope or capability of your service provider
In medium size organisations, such staff can be very useful for maintaining required service availability and minimising any disruptions. Smaller organisations will generally not be able to or wish to incur such costs, as a team (2 or 3 staff) is necessary to ensure continuous support.
TIP – Working with your service provider, apply continuous improvement methods to reduce on-site needs to the absolute minimum.
Your internal technical staff should be trained in all the technologies, services and procedures relevant to the service (both your and your provider’s). Their skill levels should be maintained as the service evolves and technology changes.
TIP – Agree with your service provider that your service staff be included in some of their employee programs such as induction and training.
They should receive all service reports and attend all services reviews, but should not be given responsibility for scheduling, conducting and following up on these reviews – that your responsibility.
Service Reporting
A general, and not insignificant, level of dissatisfaction of customers with service providers is common. This level of dissatisfaction is one which I have experienced in the areas of financial services, payroll services, IT infrastructure services, IT support services and software development services - working with both the customers of services providers and with service providers themselves.
Your service provider should regularly report to you on the services provided, and the items reported must be consistent with those for which service commitments were made in the SLA.
The purpose of service reporting is to ensure consistent understanding between customer and provider of the extent, timeliness and quality of service delivery.
Reporting should:
  • Be regular and frequent (monthly is a good interval)
  • Be service-oriented not equipment-oriented
  • Clearly show performance over time against commitment (preferably graphically with tabular data in support)
  • Highlight variance from commitments and the status of any action taken to address the variance (or explanation of why no action has been taken)
  • Comment on any trends that indicate action may need to be taken (e.g. “free disk storage will be below 10% in 3 months”) with options and recommendations
  • Notify of any events requiring action e.g. pending software license expiry
  • Set out additions/reductions to agreed monthly charges e.g. service guarantees.
Reporting should not:
  • Simply show only this month’s performance or only this month and the last month/same month last year
  • Reproduce system reports e.g. malware scans.
TIP – Request that standard reporting (frequency, structure, format and content) be included in the RFP response and agreed during contractual negotiations.
Service Reviews
The service providers who conduct customer satisfaction surveys commonly find an overall satisfaction in the 70% decile. Survey vendors tend to promote 80+% as "best practice" or "excellence". It may be "best" but it's not healthy (Australian readers will be familiar with bank misbehaviour and lack of attention to "customer interests" that come with around an 80% level of satisfaction)!

Scores of 95+% lead to loyal customers; below that, customers are "indifferent" or likely to "defect".

What makes customers unhappy?
The major dissatisfiers are:

  • Service disruptions to your daily work – services that you shouldn’t have to even think about – take up more and more of your staff’s time.
  • You’re kept waiting when you have raised an issue
  • Problems keep returning even after you’ve been told they have been fixed (and the ticket is “closed”)
  • You’re treated disrespectfully or dismissively by the service provider’s staff.
You also notice that the treatment you receive improves dramatically around contract renewal time or when you want to buy further services (or the provider wants to sell you further services).
TIP – If your service provider surveys you, make sure you share the above HBR article with them, and ask that they include an update on their activities arising from the survey in their regular service reporting.
What are the consequences of being an unhappy customer?
The ultimate consequence of being an unhappy customer is that you move to another service provider. This is difficult for the customers of internal service providers but it's not impossible (outsourcing is still popular)! However, it is costly and will take a lot of your time and effort.

Defection results from a customer suffering, over an extended period, poor service that gradually declines further as the relationship with the provider deteriorates and moves to conflict rather than collaboration.
TIP – Before meetings with your service provider, use SurveyMonkey or similar to conduct a quick in-house survey of satisfaction with their service; provide the feedback to them and ask for regular updates on action they take in response.
Building your satisfaction with a service provider
Being happy (an "Apostle") is obviously good for you and your service provider. In this article I provide some tips on how a customer can manage their service providers so that both are in a "zone of affection"! These tips are written in the context of IT infrastructure service provision in the small and medium sized business (SMB) sector, but many are relevant to customers of all types of external and internal service providers.
Selecting a service provider
Finding service providers
There are many, many IT infrastructure service providers (I'll call them "xSP"s) operating in Australia). Given this, one would think that finding an xSP would not take any effort - they'd be constantly calling and writing. This has not been my experience or observation.

Best places to start looking for a possible xSP:
  • Your peers - ask them who they use, what services are provided and how satisfied are they with the service and value
  • Your IT application vendor - most SMBs are dependent on a key application and the vendor will have a preferred or listed set of xSPs ("partners")
  • Search engine - this will provide links to xSP websites and to magazines and analysts who provide list such as "Australia's Top 10 MSPs".
Going to your technology provider - Microsoft, HPE, Dell etc - is unlikely to be useful as they have so many xSP partners.
TIP – Referral from organisations with similar needs is best, but you should undertake some form of competitive evaluation – their needs may not in fact be exactly the same as yours.
Getting a proposal
Governments and large organisations may choose to use a request for information (RFI), followed by a request for proposal (RFP) or request for quotation (RFQ) process but an RFP is sufficient for SMBs and most procurement efforts.

Responding to an RFP involves considerable effort and investment by providers, and they prefer not to be in open competition with other vendors as they are when a RFP is used. On the other hand, you need an efficient and effective process that delivers your desired outcome with the least cost and effort for you.
TIP – Pursue a RFP process that:
  • Provides complete, correct and clear information to all participating providers
  • Makes your selection criteria absolutely clear to the providers
  • Provides opportunity for providers to ask questions and seek clarification
  • Is fair to all participating providers.
Preparing a RFP
An RFP is a request for providers to propose services that will meet your business needs. It should have a structure something like this:
  • Summary of your business need and why this need exists; key terms and conditions of the RFP; and, a list of invited providers or some indication of participants
  • Your business imperatives, future direction of your organisation and your related IT needs; specific requirements; summary of the selection process and criteria; and, how participants will be informed of the outcome
  • Details of how to respond to the RFP; key dates, required format (provide templates), required documents (MSA, SLAs - see below); obtaining further information; and, contact names(s)
  • Your current IT inventory and other information relevant to the required services.
TIP – Ensure that any critical needs (e.g. disaster recovery) are explicitly included or excluded in your request.
It is important that you structure your request in the form of a need for services not hardware/software/netware equipment. For example: “Data archiving that ensures any data file (related to the MS Office suite) can be retrieved up to 5 years prior to the date of the retrieval request, and within one (1) hour of the request being made” is preferred to “50GB of cloud-based file storage” or similar.
TIP – Always stress your service needs not related equipment).
Requesting proposals
Invite selected providers by email, providing them with all relevant documentation – in PDF format for information and native format (e.g. Excel) for templates – and announcing any briefing sessions (open or closed).
Answering questions
If further information or clarification is asked for in a plenary (open) session with providers, provide the requested material to all. If asked privately (closed) by an individual xSP, provide it only to that xSP unless you feel that it is essential to all vendors being able to do their best when responding to your needs. It is likely that you will have questions from each xSP responding to your RFP. Answer these in writing, supported by conversations if required.
TIP – Keep a record of all questions/clarifications and the response, with dates to ensure all matters are resolved.
Evaluating proposals
Use the template and selection criteria described in the RFP, applying any weightings. Select a clear “winner” or 2 or 3 if the results are close.
Inform these that you will be commencing negotiations with and inform the unsuccessful providers that you are doing so.
TIP – Use templates to simultaneously evaluate all proposals using the selection criteria communicated to the xSPs; this will help ensure a rational selection free from any internal or external bias or influence.
Customer-Provider Agreements
Master Service Agreements
A Master Service Agreement (MSA) is the formal contract between you and your service provider. It’s a legal document so make sure you have your lawyer look at it - the service provider’s lawyer wrote it! But it is not, and should not be considered to be, a document that is only useful if the relationship turns sour. Its primary purpose is to ensure mutual and consistent understanding between you and your provider of each party’s responsibilities and commitments. The xSP should furnish you with an editable form of their proposed MSA so that you can easily highlight matters for discussion and/or suggest alternative or additional wording.
TIP – Use “track changes” and version control when reviewing the proposed MSA as it’s easy for key points to be “lost” in the multiple exchanges of the document.
Often a service provider will have a standalone MSA and state in correspondence or the MSA that their proposal (separate document) and other related documents (see below) are part of the overall agreement. You should resist this and request that a single document be agreed. If not, associated documents must be clearly identified in the MSA by version and/or date and be bundled with the MSA when agreement is reached.
TIP – Final versions of all contractual documents must be exchanged in PDF format.
Service Level Agreements (SLA)
ITIL defines a Service Level Agreement (SLA) as an "agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents the service level targets, and specifies the responsibilities of the IT service provider and the customer" (some incorrectly refer to service level targets, e.g. “response within 24 hours”, as “SLAs”).

Your prospective service providers must provide their standard SLA as part of their response to your RFP. It should include their service offerings related to your stated service needs, providing details on:
  • Scope of service (functionality, hours of operation etc.)
  • Quality of service (performance, availability, security etc.)
  • Service assurance (e.g. proving that a 5-year-old file can be retrieved)
  • Monitoring and reporting of service delivery
  • Change control
  • Fees and charges
  • Review and improvement.
TIP – Review my article on getting the most benefit from an SLA.
Incidents, Service Requests (and Problems)
What's the difference?
An incident is an "unplanned interruption to an IT service or reduction in the quality of an IT service" (e.g. "my login failed") whilst a service request is a " formal request from a user for something to be provided" (e.g. “please reset my password") - definitions from ITIL.
Why distinguish?
Incidents, being unplanned, have uncertainty associated with them and there is some justification for a xSP being unwilling to commit to a resolution time (although the justification is diminished if it's a familiar incident and a workaround is available).

Service requests on the other hand should have firm fulfilment times committed to by the provider.
What should be in an SLA?
Service Level Agreements should clearly state:
  • Response times for incidents and service requests – the time between a user raising the matter with the provider and the provider’s support team telling the user “we’re working on it” (and not by automatic return email).
  • Resolution times for incidents – time to address the cause of the incident or to restore the service using a workaround (e.g. use a “guest” login temporarily); there is no reason a provider cannot make such a commitment even if it is qualified (“95% within 2 business days”) or segmented (“within 24 hours for Outlook 365 incidents”). The key is for your real need to be understood and addressed (with the acceptance that this may incur additional charges).
  • Fulfilment times for each type of service requests – the time between the user making the request and the request being carried out to completion (e.g. “1 hour for a password reset” and “3 business days for a new employee being fully provisioned”).
TIP – Align your internal processes with service request fulfilment commitments.
ITIL defines a problem as a "cause of one or more incidents" and your xSP should be identifying and solving these and reporting this to you, preferably with data on "incidents prevented/avoided" by their problem-solving.
TIP – Complete and correct data on an incidents and service requests allows sound analysis and continuous improvement, so provide staff with a formal procedure for logging an incident.
Service Guarantees
Service guarantees are common in the consumer world (“100% satisfaction guaranteed; if not - your money back!”) but not as common in business-to-business relationships. It’s obvious why a provider would not be keen on providing such guarantees, but there are benefits for both parties:
  • Focus by the provider on the service aspects that are critical to the customer
  • “Hard” measurement of the quality of the critical service provided
  • Balancing of the level of investment by the customer with the impact of service disruption.
In practice, service guarantees are claimed as service charge credits to the customer rather than as refunds.
TIP – Negotiating service guarantees can be time consuming and intense and not to be pursued in all cases, but for critical services they are worth considering.

Part 2

The second part of this paper will cover:
  • Service Delivery
  • Service improvement
  • Service Governance
  • Service Assurance.