There are several elements to SharePoint, all of which require support. These elements include back-end, front-end, integrated, business, configuration support. To SharePoint supported customers using the SharePoint platform and the relevant SharePoint solutions on that platform, there will be instances where that support is not entirely the same as what the customer thinks you support (though that’s another conversation altogether).

So, a key success criteria of SharePoint depends on the level of its support service success. The capability of that support service is simply defined on a key element – the defining, understanding and setting exactly what is being supported and setting customer expectation.

So what is supported to cover SharePoint? I thought the best way to explain would be to craft a basic table giving a high level view of the key areas:

SharePoint ‘support’ could not possibly provide 100% support cover to all areas described in the above table. Also, support tends to become more vague as the problem area tends towards user specialization moving from the bottom of the table upward. An example of specialization is the use of third party SharePoint tools or SharePoint Apps. This may require specialized skills coming from the third party, of which SharePoint support consumes. Another example would be SharePoint solutions built internally by bought-in external expertise, which will require an element of internal support once delivered. Again, those skills cannot be provided solely by an internal facing SharePoint team. Similarly, a finance specialist writing macros in a spreadsheet and expecting SharePoint support may also find that he or she is alone, and yet, if that finance specialist needs to upload that document loaded with macros he or she may need support. In any case, it is quite possible that at this level users often fall back on their own resources, training they have had, or contact with other user with similar problems.

Henceforth, one conclusion that can be drawn from the above table is that one method for delivering support is rarely enough. The same can be seen from the individual weaknesses of the different forms of support.
To further explain, I am now going to describe a fictitious scenario where a software house that has developed SharePoint Apps and add-ons, and provides a SharePoint support service to provide support to those products for their clients. In doing this, it may give you an understanding of the associated successes and failures in that model.

1. Scenario – Fabrikam SharePoint software house

Fabrikam is a software house which develops SharePoint tools and apps. The software house the sells these to customers. And, as the software house sells these products, the software house provides a support team to look after a number of external clients, with its head office and several branches in the UK and branches in two other European countries. As well as having to support its own SharePoint tools and apps customers, it also has a large number of users of its own internal SharePoint platform.

Support to external users is slick and professional. Fabrikam has its SharePoint customer support service split into two. One part is a ‘Maintenance’ operation. Support members use an administrative helpdesk system which is used for customers to report product failures, and from there contact the clients to resolve the issues. These support members also have access to a further ‘technical’ helpdesk which they can contact for assistance regarding the SharePoint issue. In this way, the support team has an extremely high spot rate. It rarely needs to pass on queries, and to keep this spot rate high it maintains a SharePoint site acting as a ‘technical library’. The technical helpdesk also re-contacts key clients, first to see if the issue can be resolved without SharePoint support getting directly involved, and second to decide whether additional resources are required.

The second part of the customer support service is the ‘Users helpdesk’. This is dedicated to solving problems and challenges users have. This has two tiers; first, general query and answer helpdesk, and a second, a chargeable premium support helpdesk for customers requiring a fully fledged problem-solving service.

Both parts of the customer service have a strong emphasis on user relationships, keen to build up a rapport with their external customers. The service take queries from customers who are also technical competent (usually calling them from a client’s internal helpdesk service), answer those they can immediately and pass on what they cannot answer to a separate, central , ‘technical support’ function, which solves the problem and contacts the customer. Technical support also provides software solutions to the system maintenance helpdesk. Also, clients and the company teams can also use the technical library, which as well as retaining a professionally managed catalogue of technical volumes also offers online technical documents.

In contrast, support to internal users is slender. Fabrikam has a ‘development’ function responsible for coding SharePoint Apps, Tools and patches. It answers the occasional user query but does not operate a formal helpdesk. User training is virtually non-existent. Users are expected to learn from their office colleagues and no responsibility for the standard of user ability is taken. Due to the regular nature of the interaction between internal users and development, a single, overstretched ‘technical support’ operative emerges, moving from user to user, solving problems reactively.

2. Successes

The contrast in this scenario between the professionalism of external customer support and the sparsity of internal support is not uncommon. SharePoint support grows out of commercial imperative under the watchful eye of managing the corporate purse. Internal support can risk a little complacency, for it can always turn to its better equipped and better financed colleagues down the corridor. However, the lack of internal user training and poor internal support reduces the effectiveness of the workforce and worsens the learning curve for new recruits. It also occasionally causes customer support to be diverted from its true purpose in order to help out with internal support.
That the customer support side is successful is not in doubt. With such a broad range of services, plus a technical library to catch those support queries which don’t fit the other services, their coverage is as broad as could be expected. They have separated loss-making from profit-making customer support work and use one to fee, finance and necessitate the other.

The separation of helpdesk and technical support causes problems in some implementations, however, here it is a distinct advantage. Great store is set by the helpdesk’s ability to answer queries on the spot. This pleases external customers, who of course want the fastest possible answer, as well as minimizing the number of staff needed in technical support. In order to make sure technical support does not get out of touch with customers, job rotation takes place between the helpdesk and resolver function. The main weakness of this focus on a high spot rate is the tendency of some technicians to mark a query as closed, when in fact the client may have wanted more. To control this tendency, the helpdesk manager needs to keep a careful watch on answer quality, particularly ensuring that requests for aid are directed and recorded correctly.

3. Failures

Where the systems helpdesk fails is in its inherent inability to manage user expectations for internal support services. In order to attract custom, the company sales force naturally tends to overstate the capability of SharePoint support to its customers, and this increases demand to a level at which the quality of support becomes unsustainable and unusable for internal staff.

From the company’s point of view, there is a trade-off between reducing technical people to logging fault calls from users and having a separate, less-skilled but expensive service just to answer the telephone. To put this into context, in the past companies may have solved this dilemma by issuing its customers with batches of fax header sheets, pre-printed with their account details, for reporting issues or requirements. Nowadays, customers are asked to fill in an online support form which is then routed to the engineers via an administrative helpdesk.

No administrative helpdesk is needed, the faults come straight into the technical helpdesk who can then decide whether to call the client for further information before passing the report on to an administrator to allocate the job to the relevant support individual.

4. In Conclusion

Concerning the scenario described in this article, the more products created by a software house the more diverse and complex the nature of the support becomes.

However, whether the SharePoint solutions are created externally, or internally, or a combination, the increase in products decreases the impetus for internal support to have their skills upgraded. The answer to the question on who supports what therefore is dependant on the level of support that you wish to provide to your customers.

If the product is an App, then most likely you will not support anything else than that App. However, where do you start offering support, and where do you stop offering support. Do you start at the client PC side to the web application to the site collection to the App? Or just the App? And, if you do, is that clear to the customer so that the level of support provided is what they expect? What happens when another product is created which is closer to the client PC? How does that change the support for the App?

And, even if we move from custom development to solution development from a business user? Say, for example, that a solution using a third party web part component in a SharePoint site is configured by a business user? Where does the support start and end for that business user?

And in order to support internal customers, they need to be defined on a level of importance – some internal customers will be as important (if not more so) than external customers. That needs to identified and wrapped into the professional offering provided. Support for any SharePoint solution must be aligned to the SharePoint Service Delivery, so that resources required to support released solutions are defined and agreed. The reason for that statement is made clear in the following blog:

http://www.sharepointgeoff.com/what-is-sharepoint-service-delivery/

Six action points to properly define what is SharePoint supported are (in order):
1.  Identify the customer base – define their priorities.
2.  Inventory the products the customers use and map accordingly.
3.  Associate products to specific levels of support
4.  Create Service Level Agreements backed up by operational statements aligned to the products offered. A service level agreements aim is -to teach, inspire confidence in the availability of the solution provided and outlines support details. http://www.sharepointgeoff.com/articles-2/sharepoint-service-level-agreement/
5.  Associate skillsets to the areas of support identified in the Service Level Agreement
6.  Ensure that all products are part of a roadmap that includes configuration management

If you have any questions or feedback on Geoff’s article please leave a comment below. We would love to hear from you.

Geoff Evelyn is speaking at ESPC14 – check out his session ‘Ten Steps to Creating a SharePoint Support Model!‘. For more expert advice on on SharePoint support Model check out Geoff’s ESPC13 conference presentation on ‘Ten Steps to Creating a SharePoint Support Model‘. Download Now>>