Preview

The Service Definition is an essential marketing tool and it has got to be good

In this article we explore what should be in a good Service Definition

Consider some content as ‘mandatory’ – CCS recommend this content because buyers have asked for it

I also draw from analysis of G-Cloud 9 to show what makes a bad Service Definition

Clear, crisp executive summary and good navigation to allow buyer teams to find what they want

Try and avoid a compendium of all your portfolio and consider different documents for different markets

In the Insight Article “Service Definition Non-conformance – a catastrophic fail for 60% of SaaS suppliers” we saw that 80% of successful vendors have posted some form of Service Definition.

G-Cloud 9 SaaS sales analysis

Number of vendors with and without a published Service Definition (SD)

(sales intervals arithmetically annualised assuming 7/12ths in first 7 months)

SMEWith SD% of lineNo SD% of lineTotal
Over £250k2878%822%36
£100k - £250k1986%314%22
£1 - £100k7182%1618%87
SME sub total11881%2719%145
All vendors (incl. SME)
Over £250k4773%1727%64
£100k - £250k3186%514%36
£1 - £100k9380%2421%117
All vendors sub total17179%4621%217
Vendors with no sales109271%44629%1538
Total126372%49228%1755

 And in reviewing the 20% which have ‘got away with’ the absence of a Service Definition I have explained the circumstances under which sales may take place without this document.

 For the majority of vendors not in the exception classes of being a monopoly provider, those enjoying exceptional lock-in privileges (perhaps from some legacy predecessor to a Cloud service), or those selling a globally recognised commodity service, the analysis shows that to achieve sales success on G-Cloud you must have a Service Definition.

 It is a logical extension of this finding that success requires a good Service Definition.

What makes a Good Service Definition?

There is a section in the Suppliers’ Guide exemplifying what could go into the Service Definition. I suggest that this list is taken as mandatory but insufficient. Mandatory because the list has been compiled by CCS engaging with buyers to understand some of the common questions they want suppliers to answer, insufficient because suppliers need to describe their points of differentiation and compensate for weaknesses in their offering – this can’t be done from a 10-point template. CCS also explain:

You don’t have to provide a service definition document but the lack of one would severely impair the quality of your submission in the eyes of the buyer. It should include more in depth information about the service you are offering.

The key to developing a successful G-Cloud sales campaign is to understand how buyers are instructed to use it. This is published as the G-Cloud Buyers’ Guide it is essential reading.

 Buyers are human too and as we get more experience and exposure to different buyers looking to procure services we find a spectrum of adherence to the guide – some apply it assiduously, some are more relaxed and there is a minority who in error or in bad faith ignore the guidance.

 But the sound foundation of an effective sales plan and campaign is to build on the assumption that all follow the guide.

 “How to assess services” is a useful component of the Buyers’ Guide. If applied strictly the buyers will need to fit your product to their requirements mainly from the documentation on G-Cloud. They are allowed under the guidance to seek clarification, but “If it isn’t in their service description, you can’t ask a question about it.”

 This is a true signpost as to what makes a Good Service Definition: lots of information, anticipating all a buyer may need. It doesn’t matter if we come across a more informal buyer who picks up the phone to chat about what your service is capable of – this we can handle with alacrity. What we must avoid is excluding our offering from the buyers who consider an informal chat outside the rules. If we provide information that is too sketchy and rely on informal contact by a buyer, we shut ourselves out of part of the market.

What makes a bad Service Definition

 For G-Cloud 9, I tested a random sample of 5% of the SaaS supplier’s approach to the Service Definition:

G-Cloud 9 SaaS

Qualitative review of Service definitions

No Service Definition filed23%
Service Description does not describe the SaaS offering23%
Highly superficial and inadequate description17%
At least adequate additional information about product37%
Sample of 5% of all SaaS suppliers100%

Here is a summary of the issues identified:

  • Fatally inadequate or no description of the service
  • Inadequate description save for links to the vendor’s web-site
  • Inadequate description save for links to the product owner’s website (not party to the contract)
  • Technical specifications without describing function
  • Outcomes and benefits without describing service
  • Illegible documents and erroneously uploaded documents (e.g. terms & conditions)

A common weakness is to post a leaflet of the kind that might be used at an exhibition – an overview of a service or a set of services the purpose of which is to act as a ‘teaser’ to encourage engagement with the sales team. This is not adequate for purpose.

Plan your campaign for the buyers who strictly interpret the rules and you automatically embrace those who would be satisfied with less information. The question of how much to rely upon links to your website has a similar answer as the guidance is a little confused:

Don’t include links marketing the service or pricing information. You can refer to your website. [Suppliers’ Guide]

I am mystified by the concept that a supplier’s website would not market their service, but some buyers will want to shortlist potential candidate services without reference to external websites while others may find this more relaxed approach appropriate. So, we need to address the largest population of prospects by a highest common factor approach: do not rely on links to a website for conveying details of the service description and value proposition, put this in the Service Definition document.

The long and the short of it

Interviews with buyers reveal a common wish-list: make your Service Definition concise, provide only the facts we need, express them in our language and clearly spell-out shortcomings, disadvantages and risks.

Well, they would say that, wouldn’t they?

My take is that we need to compromise, provide efficient navigation and a clear, concise style. But a buyer in ‘department A’ may have entirely different questions to a colleague in ‘department B’. The level of detail needed to answer both means more documentation than either colleague would consider ‘just the facts we need’ – work on style and navigation to enable each to find the answers they need.

One way to cut down on the volume of material that some buyers find an obstacle is to avoid a single document that is a compendium of your entire portfolio and don’t duplicate in the Service Definition the terms & conditions and pricing which are stand-alone documents.

 Spelling-out shortcomings is a useful concept that we mostly approach in a different way. If we are aware of a competitive disadvantage – offer a solution. For example, many SMEs are at a disadvantage over their size and financial resilience. A competitive response may be to consider establishing code reviews and escrow or code reviews and open source to provide a risk mitigation strategy. Where in the catalogue can you describe this? In the Service Definition.

 I favour longer Service Definitions to include a lot of detail a buyer will want to see. But structure it well. An executive summary with the principal differentiators and then appendices on technical specifications, use-cases and other details.

Public sector is not all-the-same

 Communication is hard. Public sector buyers want solutions to problems they describe in a language specific to their agency or department. NHS may talk of ‘clinical pathways’ where others may refer to ‘business processes’. We need to use the language we expect the reader to use. In any event we need to recognise the difference between describing a technology and a solution to a need. This involves selecting your target audience, studying their needs and, if necessary, publishing separate products for separate users. This is covered further in the Insight Article on Campaigns.