Support service development for SharePoint is crucial to ensure sustained SharePoint Governance and User Adoption. I had the situation where in building a SharePoint support service that a customer needed the provision of support to be handled differently for a newly delivered SharePoint solution, and also needed that to be documented and agreed by the SharePoint sponsor. The reason for this is that they needed the support service to be measured against the supply of support to that solution, which was critical to the department and the organization.
I started thinking of this, and a thought came to me concerning how Office 365 would be supported for multiple customers. If you are a provider of Office 365 tenants, and you have multiple customers, then you may wish to consider building an SLA so that you are clear on the service responsibilities that you will have to the customer. Reasons for this will include the simple fact that each solution provided for these customers will be different, and that the customer will require satisfaction that you have taken into consideration how they will be supported.
Note, that this is no different for on-premise as noted above. And from chatting to various SharePoint workers they didn’t know what an Service Level Agreement was, and as soon as I explained it they have all said things on the lines of “Why on earth don’t we look at whether we can use that for our SharePoint support , at least we would know what is being supported!”.
Anyway, onto the article. I thought it best that instead of doing a template for you to download and fill, that instead you see this as a MindMap, so you can see the various headings of an SLA and within those an idea of what information should go into each area. This is not a ‘set in stone’ SLA. Its designed so that you can follow the headings, and then apply your requirements to it.
Hope this is of use!
