Introduction to a Managed Services Provider implementation

General Add comments

In this article I would like to tell you about some of the particularities of an MSP implementation.

From Wikipedia:

A managed services provider (MSP), is typically an information technology (IT) services provider, who manages and assumes responsibility for providing a defined set of services to their clients either proactively or as they (not the client) determine that the services are needed. Most MSP’s bill an upfront setup or Transition and an ongoing flat or near-fixed monthly fee, which benefits their clients by providing them with predictable IT support costs.

I am currently involved as the lead technical consultant for a large MSP implementation in The Netherlands for worldwide operating IT company and want to share some lessons learned and best-practices. To give you an idea of the size of this implementation: when all customers are migrated to we’re expecting to process around 1.000.000 tickets per month.

Domain separation

The first question that needs to be answered is the matter of customer data separation, you don’t want your customers to be able to see other customers’ data.
Service-now offers two types of separation support: company and domain separation. The latter is included in the MSP plugin.
While company separation does what the name says: it separates the data on a company level, the domain separation plugin gives you more flexibility on how you setup your domains.

This wiki article about the MSP plugin explains the working of the plugin and gives you a possible setup for your domain hierarchy. We implemented ours in a similar way.
Knowing this the next step is to determine the separation requirements.

This organization operates worldwide and wants to deliver the same high quality services everywhere using the same process. For this purpose the Global Service Delivery Model (GSDM) was created. This made things easy for us from a domain perspective: no customer specific functionality or process workflow was allowed. This translates into the data partitioning part of the domain plugin. It is important to make sure your administrator accounts are in the global domain, so you don’t accidentally create business rules or change a form layout in a customer’s domain!

Global Service Delivery Model (GSDM)

As mentioned before, the global process means no customer specific business logic.
In practice this translates to the following:

  • When a customer has specific priorities agreed upon in the contract (eg. high, medium, low) we map these to the standard 5 priorities. Thus high maps to 1, medium maps to 2,3 and low maps to 4,5. Customer-specific SLA’s are created that reflect the mapped priorities and then a customer specific Service Level report is created.
  • When a customer has a specific requirement it is looked at by the process owners and when it is something that can be used by more companies it is added to the standard. Again no functionality is created for and used by only 1 company.
  • The big benefit is that it remains fairly simple to make changes to existing processes as we do not have to take individual customer’s requirements into account.

Empowering the Business User

With you have a real opportunity to empower your business users. We have achieved this at three levels within the customer’s organization.
The End user has access to the Self Service portal where they can report an incident, request a standard service, see the actual state of their requests and consult the knowledge base.
The IT Operations manager has visibility of all incidents, changes and requests for his own organization and can also be used for (financial) approval.
The Service level manager has access to the online service level reports, reducing the need for the traditional monthly paper reports.


We created roles for the IT manager and the Service level manager, then we created a homepage for each role. In case of the Service level manager the homepage holds the relevant gauges for service level reporting. The domain separation ensures that he can only see the data in his domain (when the table is domain enabled!).
However the own service delivery managers could not see customers service level reports as they are not in the customer’s domain. For this we created a customer selector that gives them the ability to see the same reports the customer sees.

Final thoughts

There’s a lot more to tell you than I can cover in one article and keep you reading until the end!
So here are some thoughts and things that I may expand upon in my next article.

    • Using the domain plugin only on a data level only keeps the maintenance fairly simple.
      Not all tables are domain enabled by the MSP plugin, an example is the task_sla table. We choose to have the task_sla follow the domain of the ticket it was created under.
    • Operating on a worldwide scale means that localization (i8n) is a big issue, has no out-of-the box way to deal with localized email notifications, this was something we had to create.
    • Customer specific workflow for the same catalog item is not possible as the workflow selection is determined by the catalog item. We had to work around this by creating a “generic workflow” that is data driven.
    • Migration thousands of customers in a relatively short time frame is reflected in some architectural choices made. It is difficult to upload (customer specific) SLA’s using Excel, so we created our own extension to the contract plugin to add a generic SLA to an incident or requested item.

    If you have any question you can send me an email on: .

  • One Response to “Introduction to a Managed Services Provider implementation”

    1. Abhijeet Says:

      Hi Marc,

      waiting for your next articles.
      Can you provide more insights challenges you faced. If we are planning to implement the MSP environment what things we should keep in mind etc..

      Your article is really helpful. If you can add more technical details it would be useful for us/

    Leave a Reply