In the last article, we generally described what a managed service is and what are the benefits and risks for a customer. In the same article, we described a managed service as…
a well-defined task provided by a service provider and regularly delivered to a customer.
But what are the components that make up a managed service? How do I, as a customer, know what I opt-in for? What are the deliveries and what is expected of me as a customer and my IT-department?
A professional and mature managed service provider (MSP) provides the customer with a service description that in all details describes what will be delivered (read: in scope & out of scope), the service architecture, the prerequisites, who is responsible for what, the SLAs (Service Level Agreement), KPIs (Key Performance Indicators) and reporting.
With the service description in hand, a customer will exactly know what he is paying for and what will be delivered. Experience has shown that not having a clear and precise service description is the hotbed for many disputes between a service provider and a customer. Conflicts that at times, end in court and in no way are beneficial for either party. The losers in these disputes most often are customers’ users as they are held “hostage” many times.
Back to the topic at hand – the components of a managed service.
As mentioned above the focal point is the service description describing the actual managed service. Below several essential components within a service description are briefly described. It is not an exhaustive list, but the author deems those components as bare minimum content within a service description.
1. In Scope & Out of Scope
It is essential for a customer to know exactly what will be delivered within a given managed service, and thus, the service provider must list all deliveries within a service. This must be done clearly and precise – ideally in bullet or table form to give the reader of the service description an easy to consume overview of all deliveries within a service. This also relates to the RACI-matrix discussed later in the article. The example given is from the Atea Azure Cost Control service.
It is equally important to make the customer aware of what is not part of the service (read: out of scope), what add-on functionality is available and which additional services would be beneficial for a customer.
The out of scope section is rather important to ensure a common understanding and eliminate possible untold/unwritten expectations from the customer side on what the service provider will deliver.
2. Service Architecture
The service architecture gives a customer an overview of how the service works and which components are involved. Many times, this is visualized in the service description by showing the different technical components in a diagram.
The above is an example of the Atea Azure Cost Control service architecture. It shows clearly the different technical components and how they fit together. Combined, they make up the managed service.
3. Prerequisites
Experience has shown that many service providers are not clear about what requirements must be in place for a customer being able to be onboarded in a managed service. Prerequisites can range from software, licenses over hardware and on to access rights for the service provider. Often the prerequisite list is divided into technical requirements, deployment prerequisites, delivery prerequisites, and dependencies.
This may sound complex and lengthy, but it does not have to be. The list of prerequisites and dependencies is most often in direct correlation with the complexity of the services. The more lightweight a managed service is, the shorter is the list of prerequisites. Below example is – as previous – an example from the Atea Azure Cost Control service.
Two rather simple prerequisites are stated – the customer needs to have an Azure subscription with deployed resources, and Atea needs to have the appropriate access for being able to deliver the service. Easy to understand and follow.
4. The RACI-matrix
Simply put the ‘Responsible’ party is the one who does the work, the ‘Accountable’ one is the one with the money, the ‘Consulted’ party is in the know, while the ‘Informed’ party is kept in the loop.
Having a RACI-matrix in a service description gives a quick and easy to understand overview of who is responsible for a given task/deliverable within a managed service.
This will also give the customer a clear picture of what is excepted from them, where they, as a customer, must put some effort to successfully consume a managed service.
Ideally, the RACI-matrix includes the in-scope deliverables previously discussed in the article at hand. A RACI-matrix’ can be rather lengthy as it is vital to be clear and precise on who handles what. Below is an excerpt of such a RACI-matrix.
The above example has two columns – in this case, ‘Atea’ and ‘Client,’ which is the customer. It is not uncommon a RACI-matrix having more than two columns. For example, if a customer has charged a third-party to act on their behalf.
5. SLAs & KPIs
The foundation of any managed service is the Service Level Agreement (SLA) and measurement point (KPIs). Measuring SLAs and KPIs determine if a managed service provider lives up to the agreed-on obligations. This could, for example, be how fast an application package is delivered, how big a percentage of PCs are properly patched within a certain timeframe or the uptime of a system/solution.
Generally, SLAs and KPIs are service-specific as they take the content and deliverables of a given service into consideration – for example, from a technology standpoint. However, they can also define more high-level areas such as response and resolution times for incidents and service requests across a range of managed services.
A professional and mature service provider like Atea within its standard managed services will always offer a customer SLAs and KPIs based on experience and what most customers deem as acceptable for a given managed services.
From a customer perspective, it is crucial to align SLAs and KPIs to business needs within their company. At times customers might even have made concrete agreements between the IT-department and different user department such as sales, HR, and/or finance. It is important to note, that service providers often can accommodate different SLAs and KPIs as those stated in service descriptions, but at times it may come at a cost and increase the price for a given managed service.
6. Reporting
It is, of course, important for a professional service provider to be able to show the value delivered within a managed service through a given timeframe. In most cases, the timeframe is monthly, and ideally, the customer can see for themselves in a reporting portal and thus not being dependent on someone generating pdf-files with reports.
Examples of reporting – either as definitions or with screenshots – should be part of any service description as it will give a customer insight into what to expect from a reporting perspective.
Now we have gone through the most important components within the service description of a managed service. With these parts described a customer will exactly know what will be delivered, who is responsible for what and what to expect regarding service levels.
Have we missed something?
Join the conversation…
In the last article, we generally described what a managed service is and what are the benefits and risks for a customer. In the same article, we described a managed service as…
a well-defined task provided by a service provider and regularly delivered to a customer.
But what are the components that make up a managed service? How do I, as a customer, know what I opt-in for? What are the deliveries and what is expected of me as a customer and my IT-department?
A professional and mature managed service provider (MSP) provides the customer with a service description that in all details describes what will be delivered (read: in scope & out of scope), the service architecture, the prerequisites, who is responsible for what, the SLAs (Service Level Agreement), KPIs (Key Performance Indicators) and reporting.
With the service description in hand, a customer will exactly know what he is paying for and what will be delivered. Experience has shown that not having a clear and precise service description is the hotbed for many disputes between a service provider and a customer. Conflicts that at times, end in court and in no way are beneficial for either party. The losers in these disputes most often are customers’ users as they are held “hostage” many times.
Back to the topic at hand – the components of a managed service.
As mentioned above the focal point is the service description describing the actual managed service. Below several essential components within a service description are briefly described. It is not an exhaustive list, but the author deems those components as bare minimum content within a service description.
1. In Scope & Out of Scope
It is essential for a customer to know exactly what will be delivered within a given managed service, and thus, the service provider must list all deliveries within a service. This must be done clearly and precise – ideally in bullet or table form to give the reader of the service description an easy to consume overview of all deliveries within a service. This also relates to the RACI-matrix discussed later in the article. The example given is from the Atea Azure Cost Control service.
It is equally important to make the customer aware of what is not part of the service (read: out of scope), what add-on functionality is available and which additional services would be beneficial for a customer.
The out of scope section is rather important to ensure a common understanding and eliminate possible untold/unwritten expectations from the customer side on what the service provider will deliver.
2. Service Architecture
The service architecture gives a customer an overview of how the service works and which components are involved. Many times, this is visualized in the service description by showing the different technical components in a diagram.
The above is an example of the Atea Azure Cost Control service architecture. It shows clearly the different technical components and how they fit together. Combined, they make up the managed service.
3. Prerequisites
Experience has shown that many service providers are not clear about what requirements must be in place for a customer being able to be onboarded in a managed service. Prerequisites can range from software, licenses over hardware and on to access rights for the service provider. Often the prerequisite list is divided into technical requirements, deployment prerequisites, delivery prerequisites, and dependencies.
This may sound complex and lengthy, but it does not have to be. The list of prerequisites and dependencies is most often in direct correlation with the complexity of the services. The more lightweight a managed service is, the shorter is the list of prerequisites. Below example is – as previous – an example from the Atea Azure Cost Control service.
Two rather simple prerequisites are stated – the customer needs to have an Azure subscription with deployed resources, and Atea needs to have the appropriate access for being able to deliver the service. Easy to understand and follow.
4. The RACI-matrix
Simply put the ‘Responsible’ party is the one who does the work, the ‘Accountable’ one is the one with the money, the ‘Consulted’ party is in the know, while the ‘Informed’ party is kept in the loop.
Having a RACI-matrix in a service description gives a quick and easy to understand overview of who is responsible for a given task/deliverable within a managed service.
This will also give the customer a clear picture of what is excepted from them, where they, as a customer, must put some effort to successfully consume a managed service.
Ideally, the RACI-matrix includes the in-scope deliverables previously discussed in the article at hand. A RACI-matrix’ can be rather lengthy as it is vital to be clear and precise on who handles what. Below is an excerpt of such a RACI-matrix.
The above example has two columns – in this case, ‘Atea’ and ‘Client,’ which is the customer. It is not uncommon a RACI-matrix having more than two columns. For example, if a customer has charged a third-party to act on their behalf.
5. SLAs & KPIs
The foundation of any managed service is the Service Level Agreement (SLA) and measurement point (KPIs). Measuring SLAs and KPIs determine if a managed service provider lives up to the agreed-on obligations. This could, for example, be how fast an application package is delivered, how big a percentage of PCs are properly patched within a certain timeframe or the uptime of a system/solution.
Generally, SLAs and KPIs are service-specific as they take the content and deliverables of a given service into consideration – for example, from a technology standpoint. However, they can also define more high-level areas such as response and resolution times for incidents and service requests across a range of managed services.
A professional and mature service provider like Atea within its standard managed services will always offer a customer SLAs and KPIs based on experience and what most customers deem as acceptable for a given managed services.
From a customer perspective, it is crucial to align SLAs and KPIs to business needs within their company. At times customers might even have made concrete agreements between the IT-department and different user department such as sales, HR, and/or finance. It is important to note, that service providers often can accommodate different SLAs and KPIs as those stated in service descriptions, but at times it may come at a cost and increase the price for a given managed service.
6. Reporting
It is, of course, important for a professional service provider to be able to show the value delivered within a managed service through a given timeframe. In most cases, the timeframe is monthly, and ideally, the customer can see for themselves in a reporting portal and thus not being dependent on someone generating pdf-files with reports.
Examples of reporting – either as definitions or with screenshots – should be part of any service description as it will give a customer insight into what to expect from a reporting perspective.
Now we have gone through the most important components within the service description of a managed service. With these parts described a customer will exactly know what will be delivered, who is responsible for what and what to expect regarding service levels.
Have we missed something?
Join the conversation…