ITIL 4 Use Case: Farfetch

Farfetch Limited (NYSE: FTCH), is a leading global technology platform involved in the luxury fashion industry. The business is mainly focused on fashion and it is supported by technology area F-Tech. When they planned to expand their business, they realized that they needed to revamp the service management tool and the service request process, to meet the needs of internal customers. Furthermore, Farfetch must comply with several regulations, including adding an approval process, and a formal documentation process, in order to float on the New York stock market.

The revamp process started with the creation of customer-orientated applications, which aimed to make the service request process more intuitive and straightforward to users. The revamp process mapped 15 major areas (these could be a team or an application) that were then input as a unique point of entry within the service management tool. The revamp projects are centralized so that users can raise requests to the appropriate teams: infrastructure, data support, and IT service. The projects were organized into a small group of subjects, to make navigation easier. In events where requests have multiples resolvers, it was divided by applications such as: mobile apps support, Farfetch portal support, finance tech support, and production support. The queries are then forwarded to the service desk for triage by the service desk or forwarded to the correct group.

The next step of the process was to define a service catalogue containing the services provided and the time to fulfil the services and create a unique request type for every service mapped. The service management area provided guidance. The time taken to fulfil the request was related to the request type rather than its priority, except when the customer is responsible for choosing the correct priority stream. The service desk mapped 45 services that it provided and executed, and defined how long it would take to fulfil the following five possible SLA´s request types:

• 24 hours with 24/7 support
• 48 hours with 24/7 support
• 45 hours with working hours (9am to 5pm five days a week) support
• 180 hours with working hours (9am to 5pm five days a week) support.

A solution was then found for a common customer complaint, which was the constant need for updates after a request had been submitted. The service catalogue and types of request ensured that the customer was asked the right information when opening a service request. As a result, all request types had been mapped, a basic form was created for every request type. This was to ensure that all the information required to execute the request was obtained from the customer during the opening process. Below is an example form from the service desk that the customer is expected to complete when requesting access to application A.

Example form: Gaining access to application A
Summary:
Purpose of application usage:
Attachment:
Application name:
Email address:
Role:

Example form: Unsubscribing from the newsletter
Summary:
Reason for unsubscribing:
Attachment:
Customer email:

The request types, which are independently managed by the teams, contain a basic set of information: summary, reason for the request, and attachment. Additionally, every request type has a specific set of information, to ensure it can be successfully accomplished without requiring further information from the customer. Further information requests only occur when a specific requisition is made, or if the customer makes a service request using the wrong request type option. At the triage stage, the service desk will identify the customer’s request and direct them to the correct request type. The form will then have to be completed.

This new approach resulted in more accurate and reliable metrics, the team could see what they were executing, how long it took each time, and how often the requests were escalated to a specialized team. However, the most important outcome of this approach was that the team could see the daily numbers for each request type. Consequently, it showed that a unique request type (in this a request to change the address prior to shipment, when a customer incorrectly completed it) was responsible for more than 40% of the service desk’s work.

There were already several processes in place before the revamp started. For example, data and knowledge about the service already existed. This included a catalogue that could be updated with the details of every new service, such as a change in the time taken to perform the service or any new information that should be included in the opening form. The process of continuous improvement could now start; however, some issues needed to be resolved first.

Despite the efforts to map every service, there was still a need to create a generic request type form to accommodate everything that was not included in the first version of the catalogue. So, one area of improvement was to identify the type of request and decide if it was a frequent request. If that was the case, then a specific request type for those requests should be made. This was an important task as repeating the same specific request in a generic request form did not create value and obscured knowledge about the type of services delivered. Currently, and for the foreseeable future, the service management team is mapping and analysing the generic request form so that it is relevant to the company. The team are creating new request type forms as a result of their analysis.

The analysis performed on the most frequent requests resulted in another solution. After discovering that one specific request type was responsible for 40% of the service executed by the service desk, the service management team started working with the developers to automate this activity and reduce the workload of the first line support. This activity was automated; the customer changed the necessary fields and a script ran the form. This resulted in more time to execute tasks important to the business, both in terms of generating income and decreasing unnecessary expenditure. This is already delivering financial savings.

The subsequent changes not only showed that there was room for improvement, but also that there were opportunities to improve other areas of the business, outside of F-tech. Moreover, it showed that the whole company could be engaged with the ideas of controlling, management, and customer centricity.

To keep the momentum going in relation to these changes, the service management team supported other business areas, by providing support or services internally as a result of the centralized structure. Consequently, it was easier to complete requests, measure targets, and deliver a better experience to customers. This approach was integrated into the service management structure areas such as the team, office management, and treasury. Work had been delivered to define the service catalogue, assist on the new project configuration, and define the agreements. This created a unique standard and every Farfetcher now knows where to find and proceed with requests for anything, within any area, of the company.

Another opportunity was the creation of organizations within the service management tool, which allowed customers to subscribe only to the services and communications that matter to them. For example, a person in the partner services team would be able to subscribe to the projects that they work on and receive the required support. They can also subscribe to receive communications regarding outages on relevant applications, schedule activities, and receive announcements regarding new features. So, the person would only receive meaningful information. They avoided: wasting time, receiving communications or updates from services/applications that the user did not even know existed, and avoid viewing options to open tickets when they only need the same set of requests.

The service request revamp process has delivered good results, not only in terms of finances, but also in terms of the service and the customer experience. It is a continuous process that must not be forgotten. The success of this project depends on the updated catalogue and request, a consistent time to fulfil agreements, and the continuous participation of the business. It is a journey that is shared with everyone within the company to create an incredible customer and partner experience.

Paulo Tourinho graduated in FATEC-Guaratinguetá college studying IT. Since then, he has built his career entirely in service management and was introduced to ITIL in 2009. At various other work places such as AT&T and British Telecom, Paulo was able to consolidate this knowledge and become an ITIL expert while using these concepts to deliver a unique customer experience. Paulo currently works with Farfetch and built a support centre from scratch; he has contributed to the development of ITIL 4, and was a reviewer for the ITIL 4 service request practice publication.