In the past I have written about the hierarchy of documents in  https://peteralderliesten.com/2015/05/05/the-hierarchy-of-documents-in-business-process-outsourcing/  and that Service Specifications are a document that is highly undervalued by some. For some others, this is the most important document in the BPO-chain, since it communicates from the ‘Control’ center to ‘Operations’ exactly what needs to be performed. (Similar how the Training Documents and the Work Instructions might be the most important documents in Operations since it communicates to the Support Functions how they should do theirs.)

Roles & Responsibilities, and Communication Lines (‘Customer’)

The first and foremost document in the Service Specification is the ‘Roles & Responsibilities’-overview. This is not (just) the organization chart. A RACI-table might be more like it. This document defines who may decide on topics. A closely associated document – sometimes integrated – is the overview of the Communication Lines – or who communicates with whom – on what topic. The simplest way of creating such an overview is to start with a list of topics that need to be addressed on a regular basis. Per topic a forum (meeting/’gremium’) is defined, and soon one will see the pattern that e.g. all operational topics are to be discussed in an Operational Jour Fixe, and all commercial ones in a Commercial Jour Fixe. The various topics that have been thought off are then a great basis for the initial ‘standard’ agenda. Important in that respect is that also in such a set-up certain topics can be declared ‘off-limits’ to ensure the scope of the meeting is held. In that context, the setting of a price for a service might be deemed inappropriate for the Operational Jour Fixe, since it has te be decided in the Commercial Jour Fixe.

In larger constellations, it makes sense not to mention names of individuals but roles or functions. For instance, when all Country Representatives ought to speak to their respective National Account Manager, I usually make an overview of the roles that communicate with one another with then a separate listing of the Country Representatives and National Account Managers per country. Such an overview is also much easier to maintain…

If one wants to make the ‘Roles & Responsibilities’-overview very nice, it also includes a description of the tasks and the responsibilities of each role. (This overview could then be the basis for the job descriptions, which are not necessarily if not to say ‘usually not’ the same. In addition, this ‘Roles & Responsibilities’ usually defines the interaction of the roles around it: contact person at the clients’, Operations Manager, Key Account Manager etc., usually less the exact definition of what the operators perform, which is covered more by the Processes and Procedures)

Change Request Procedure (‘’Product)

Once people know their roles, one can start and define their actions (or ‘Operations’). Since the highest activity in the ‘Operations’-sphere is the ‘Products List’ or ‘Services List’ the Service Specification should define both a starting ‘Products List’ and a way of addressing changes to this document, the so called ‘Change Request-Procedure’. Whenever people hear a term like that, there is a large chance they roll their eyes in disgust, recalling some horrible administrative maze. This procedure usually is. When taking into account all aspects that might be relevant, forms to describe Change Requests are known to be ‘monsters’, the alternative being changes being implemented and retracted halfway because of some kind of oversight. Or worse, to be adjusted erroneously again…

Since in a formal sense Change Requests do not only cover changes in Products, but also in Processes and Procedures, one also – and easily – goes overboard. All kinds of minor changes will occur in processes or procedures all the time: the names of contact persons will change, e-mail addresses, telephone numbers to call etc. One could busy oneself with administering all of these changes with full-blown Change Requests. On the other hand, one also could define larger ones as ‘Process Adjustments’, with effects on the AHT or Training, and minor adjustments as ‘Procedure Adjustments’, which have no major effect on Average Handling Times, Service Level, or Training, and thus on prices or budget. There should be a quick acceptance check by the BPO-provider, but then it should be ‘just implemented’, preferably into the professionally designed Knowledge DataBase, of course.

Forecast Procedure (‘Product’)

The third most important component in the Service Specification, and ‘only’ in the realm of Products, is the Forecast Procedure. Where the (production of) the individual Forecast is part of ‘Product’, the process that controls the creation of the Forecast is an essential part of the Service Specification itself.

Where inhouse contact centers often see Average Handling Times as part of the Processes, in BPO the AHT’s often are part of the Price List in Products. There are 2 reasons for this:

1. as soon as definitive AHT’s have been agreed upon, the number of transactions performed or the contractual Total Handling Time often is the basis of the invoice rather than the actual number of FTE deployed. Usually, a provider obtain a a certain volume guarantee, to exclude the possibility that the outsourcer just voids the contract by shifting volumes away and to minimize the provider’s risks on the investments made when taking over a service. If not, this lack could result in a significant extra cost factor the provider charges to the client. This volume guarantee often is given on the basis of contractual Total Handling Time rather than on number of transactions to allow for flexibility on the outsourcer’s side.

2. in the currently quickly evolving world, there is little use of sticking rigidly to numbers of transactions. Crucial is the total workload that needs to be performed, since that is going to be the basis for the planning later on, which by itself determines the expected cost level.

Here I want to make a distinction between the Forecast, which predicts the number of transactions and their AHT’s that are predicted (the Total Handling Time, or ‘demand side’) and the number of people that are required to process these transactions, (the Planning the ‘supply side’). The latter will be covered in the section on People.

Crucial to making a proper Forecast are both a. an accurate data structure which allows for a proper measurement of historic data, the quantitative basis, and b. a qualitative view on how the future is going to look like.

a. For an accurate data structure, several hindrance are very common. When parties have not properly implemented the registration of multiple transactions per call or e-mail, no useable relationship between reason codes and volumes are possible to distinguish. In addition, when in one site transactions are registered as one and in the other as three components, no transparency of data can be achieved. It is not uncommon when implementing a new service that suddenly new tasks appear, that have been done in the background, totally undocumented, but on automatic pilot by people who have been doing the same job for years.

b. A professional outsourcer would provide the provider with a periodic overview of the changes that are planned from their side.

The pun in the first sentence of this section ‘b’ is intended: it should be clear that after the contract has been signed the relationship can not become a one-way street, both party’s will have to ‘get and give’

KPI’s and Report Processes (‘Processes’)

When both the qualitative and the quantitative parts of Products covered, we can turn our attention to the two parts of Processes: KPI’s and Reports. The Service specification does not only specify these two factors, but also the ‘how to’ go about them.

 Where the Reporting Procedure speaks for itself, the Countermeasures (or ‘Corrective Measures’) are the way how to achieve KPI’s, but less common. These are nothing but a predefined set of actions that need to be put into place in predefined situations. Later on we will speak about Emergency Plans, when typhoons or pandemics hit, when IT or Facilities’ break down, but Countermeasures relates to situations where Operations (threaten to) ‘break down’. A typical example would be where a Service Level would fall below a certain threshold: When do you inform the client (and when not, she does not want to be spammed with hourly warnings that an interval Service Level is not being met) , Who at the client do you inform? And maybe even more important, What do you do?

Personnel Planning (‘People’)

One then could argue that the creation of a Personnel Planning to ensure that the workload of the Forecast can be handled is the next major component of a Service Specification, but in my experience it generally is not. The reason is that the personnel planning is a purely provider topic. (Virtually) No client is interested in how exactly the personnel planing is executed. Furthermore, a provider does not want to commit to a certain way of planning, since she does not want the introduction of a new planning system to be aligned with all of her clients.

Work Instructions (‘Procedures’)

The next topic of the hierarchy of BPO topics is definitely something to be covered in the Service Specification. There is only one ‘But’. In almost all instances, procedures are voluminous works, with frequent additions and changes. In almost all cases I have seen (if not all), the Service Specification mainly referred to the place where these work instructions could be found.

One very specific set of documents in this realm is the training documentation. Based on the work instructions it goes into details to explain how to use them. By themselves they usually are separate documents and only referenced, but often certain agreements are made on the kind of selection (e.g. a security check for employees working for a bank) or the training requirements before agents become ‘minimum skilled’ (e.g. sales training for agents doing outbound).

Channels and Configuration (‘Systems’)

In general it is way to cumbersome to add all technical systems designs to a Service Specification. However, in some cases it may make sense to define the communication channels used: which points of entry does a customer have? Sometimes certain customers for certain purposes are allowed to use certain channels. In such a case the client generally has a very professional Customer Contact Strategy prepared and is able to provide forecasts per entry point.

Another element of Systems might also find it’s way into the Service Specification: the Configuration. This document – usually a schematic overview – shows how the systems have been set up for this particular account, e.g. an overflow for multilingual accounts. Although very ‘unsexy’, I dare to say that the intelligence of the configuration has much more effect on the effectiveness of the service than the intelligence of the underlying system. Too often did I see expensive systems being underutilized, too often did I use simple systems to achieve the same effect by just using a smart configuration. One example is ‘Skill Based Routing’: often this buzz word is great in convincing a client that she really has to choose for this particular system or provider. It would be interesting to note how many of theactually implemented configurations could not be copied by a simple agent group configuration (as we already used 20 years ago), used in an intelligent manner.

Emergency Plan (‘Safety’)

The Emergency Plan is a subject one could write a complete book on, ranging from a simple evacuation plan to a comprehensive ‘Business Continuity Plan’. There are just a couple of suggestions I would like to mention for it’s contents: focus on actions before, during and after an emergency; and do not limit the Safety to just Facilities, but also take into account IT and other Systems, and Operations. On the latter it goes further than in the Countermeasures:   what do you do when your total center has been devastated by a typhoon? And how do you bring back in a controlled manner the emergency capacity to the original site?

It is amazing how helpful it is if you then still have access to the implementation plan and the acceptance tests for systems and personnel…

Invoicing Procedure (‘Finance’)

After all is well and done, there is an Invoice to be produced, sent and paid. Purchase Order numbers are usually quite difficult to obtain, invoicing addresses and VAT-numbers should be correct to ensure a signature on the right dotted line. Somehow, this part is not often overlooked…

This is a living document. I will not administer all the changes that will be applied, but I expect that in the course of time it will be many

 (Originally published August 28, 2013)