Good Services. Lou Downe

Чтение книги онлайн.

СКАЧАТЬ environment.

       The simple fact that our services weren’t designed for the channel they’re delivered in is one of the most common causes of service failure.

       A timeline of services

       1840s: letters

       Services first started to be accessible remotely through direct correspondence to the service provider.

       1920s: forms

       These letters of request started to become codified into ‘forms’ to improve the speed and accuracy of people responding to requests.

       1960s: forms + support

       With the first call centres becoming popular means of supporting customers, remote support started to be added to larger services, such as insurance and banking.

       1970s: process + forms + support

       With the introduction of computerised processes, the 1970s heralded a new way of seeing a service. No longer a set of instructions given to staff, computers started to make some decisions about our services for us. Making sure that records were accessible to staff meant having account numbers and an increasing number of unique IDs to identify users.

       1980s: process + forms + customer service

       The 1980s saw a rapid expansion of consultancies and methodologies to deal with the numbers of services now operating with remote support. The term ‘customer experience’ was first used to describe the growing need to make sense of the complexity of modern services. These were still mostly manual input, and the ‘form’ still dominated as the main means of interaction.

       How services work now

       Services today are composed of small component pieces joined together through data or user experience to form a seamless user journey that helps a user achieve their goal.

       The goal that a service helps you to achieve can be very large – like buying a house – or it can be very small – like getting lunch. Either way, it will be broken down into smaller parts that help you achieve that overall goal.

       Services in the internet age are not only defined by the user who’s looking for them, but composed of ‘small pieces loosely joined’ as David Weinberger predicted in 2002. For example, when you’re embarking on the goal of buying a house you might find that you need to complete several very distinct steps in order to be able to achieve it – like hiring a surveyor. Those steps themselves will then be broken down into smaller tasks. For example, when getting a survey done, you might need to first book a time for that survey to be done, then pay for it and review the final result.

       In that way, each service is broken down into steps, and each step into a series of tasks. Each one of these steps or tasks will probably be called ‘a service’ by the person running it. What defines the edge of a service is very dependent on your context, so if all you do all day everyday is provide surveys, it’s easy to think of the service as providing surveys.

       While it’s important for each step and task to be well-designed, it doesn’t mean that these things are services. The only person who gets to decide what the service is, is the person who has the goal they need to achieve – and that’s your user. It’s your job to orchestrate all of the pieces of this service in as seamless a journey as possible, even if you don’t provide the whole service yourself.

       Designing services that are defined by user needs can seem like a daunting prospect. These services could be very large, and involve multiple different organisations to string together. It’s important therefore to have some sense of how to break down a service into its component parts so that each ‘loosely joined’ piece can be designed in the context of the whole service.

       Your user defines what your ‘service’ is

       Designing how each of these pieces works together to help a user to achieve an end goal is not only possible, but vital to the success of a service.

       Service: for example, buy house

       A service is something that helps someone to do something. Only your user can determine what the service is.

       Steps: for example, get a survey

       Step are the things your user needs to do in order to achieve their overall goal. Crucially, steps should be introduced to a service where your user needs visibility and control over what happens next. For example, it would be incredibly unnerving to be able to do all of the things needed to buy a house in one seamless step.

       The separate steps within the service of selling your house and buying a new one give you visibility and control over important decision points – like deciding which house to buy, how much money you want to spend or how many bedrooms you might need for any children. All of these steps are separate within the overall service of buying a house for the good reason that time and consideration are needed to make these decisions. This is why different organisations often fulfil different steps within the service. The break between those different organisations (if it works well) act as a natural point for consideration of information and decision-making.

       Tasks: for example, check your survey

       Tasks are the individual things you need to do to complete a step. How many steps or separate interactions your service has will depend on how many decision points your user has to make to achieve the desired outcome.

       What makes a good service?

       When Jordan Haignes started to get phone calls from Citigroup about repaying a loan, he didn’t know why. He was annoyed. The bank, it seemed, thought he owed them $15,000. But Jordan hadn’t ever taken out a loan with Citigroup. After some investigation, it transpired that, like millions around the globe before him, he had been the victim of identity fraud. Someone had taken his name, address, date of birth and other information and run up a bill of thousands on a credit card in his name. He complained, why had Citigroup agreed to give this fake Jordan a credit card, and why, now that the fraud was discovered, was it his job to sort it out?

       The answer lies in our fundamentally different views on what we expect from services, in contrast with our expectations of almost anything else in our lives.

       Any person in the US who is a victim of identity fraud is legally required to prove that their identity has been stolen in order to not be held liable for any damage done by that impersonator – and yet service providers don’t suffer these penalties when they fail to identify users correctly.

       This is a problem that stretches across the banking services sector and beyond, and it shows that, not only are the providers of services often not culpable for the failure of their service, СКАЧАТЬ