This is a short note is to help you with your G-Cloud tender. This guide does not replace the Invitation To Tender (ITT) document, Terms of Participation or any of the other G-Cloud legal and guidance documents. Rather it clarifies a few points that the G-Cloud team have been asked during Gi and Gii.
CloudStore – your front door
The CloudStore is the way that most buyers find G-Cloud services. Most of the information you send us as part of your tender is loaded on the CloudStore. The ‘Description’ is a small area of plain text which summarises your service, this is generally the first thing that a Buyer will read. Hence suppliers should include this text in their tender and make it as buyer friendly as possible, noting there are a range of buyers across the public sector with varying degrees of technical and commercial expertise; thus brevity and ease of reading are important factors.
Contact
We ask for a Supplier Contact to put on the CloudStore. These details will be made public and they are the ones that people will tend to use if they want more information about each supplier so:
- make sure the contact supplied knows about your offerings and is prepared to talk about buyers (this may not be the same person that prepares the tender);
- make sure the contact is actually contactable; and
- if the contact changes, please update the details.
Pricing
You can price your G-Cloud services however you want just so long as they are commoditised.
You can reduce your prices during the term of the framework, but once you have tendered you can’t fundamentally change your pricing structure.
You are asked to provide a single price for each service so a price can be displayed on the CloudStore – this is either for a common configuration or for the most popular configuration of a given service. You should not only provide this price. You should provide your full pricing structure as part of your tender.
So, it’s important that when you tender you supply G-Cloud with as extensive a pricing structure as you see fit, this can include (but is not limited to):
- Volume discounts;
- Combination of G-Cloud service discounts e.g. if Buyer gets component (A) and (B) those components may be priced differently than if brought separately; and
- Education discounts.
We are not saying you have to offer any of these, you price as you wish, but your pricing needs to have a consistent structure throughout the term of the framework so you should tender for how you wish it to appear.
Specialist Cloud Services and Commoditisation
The G-Cloud Framework is for commodity services that are either cloud-based or support / augment cloud-based services. Lot 4 is for these supporting services. Like the other Lots, Lot 4 must be commodity based – typically this will mean the service is defined around quantified outcomes.
For instance a Lot 4 supplier may wish to offer email migration services, this can be done in a number of ways. The government does not restrict how suppliers should offer email migration, but it does restrict how they offer it on particular frameworks. On G-Cloud, such services must be commoditised, thus services of the form:
“email migration £X per Y mail boxes migrated to cloud-based service Y”
are permitted under G-Cloud. Whereas:
“email migration call for quotation” or “email migration based on assessment”
are not permitted under G-Cloud (though there are Frameworks where such services are permitted).
Lastly, suppliers of Lot 4 service should note that they do not have to offer any corresponding Lot 1, 2 or 3 services. For example, the permitted email migration service above does not have to have a corresponding email service by the Lot 4 supplier. Indeed a supplier on Lot 4 may offer a service that supports a cloud-based service not listed on G-Cloud at all, as it’s quite possible public bodies have services from providers that are not on G-Cloud.
So far commoditisation backwards through out supply chain has worked, suppliers just need to get their head around how to make it work for all concerned.
It’s a worthy goal, but I don’t think it would work.
For a start, some services aren’t priced per user – we have services that are priced per transaction, since that makes more sense for the customer.
But even if we’re talking about price per user, the comparison still doesn’t work. Are they named or concurrent users? In advance (ie a cap on the number allowed in the coming period) or in arrears (what was actually used in the previous period?
Those are the obvious problems, but there’s many more.
Licensing models are a major point of innovation for vendors, and can serve to lower actual costs (or deliver higher value) for customers.
If you forced a pre-defined SaaS per user pricing structure onto vendors you’d stifle innovation – which ultimately, limits competition. That’s never a good deal for customers.
Good points. Any suggestions as to how we can make the CloudStore more useful for buyers to short-list potential suppliers?
From the feedback we have received, the lack of a pre-defined SaaS per user pricing structure is one of the reasons that prospective buyers are finding the UK G-Cloud CloudStore difficult to use to do long and short-list comparisons.
With regard to licensed SaaS the common parameter across vendors should be cost per user per month/year. Whereas some services do not discount as user numbers increase others do. This of course can make it difficult to do like-for-like comparison across vendors. we would suggest vendors are asked to price per/user against certain stated thresholds, for example 25 users, 100 users, 500 users, 1,000 users, 5,000 users. This will not only make it easier for buyers to do a comparison, but also provide an insight into a vendors pricing strategy (can they support small numbers of users? do they discount on volume?). What will be the price of success? There is no point evaluating an initial purchase on the cost of 25 users, if you think you might realistically grow to 1,000 users. One complexity is that some vendors also bundle smaller user licenses with restricted levels of functionality to encourage organisations to upgrade, but is this is a true pay-per-use model?
If you want to build a trap for those companies that artificially bundle user licenses you can ask them to quote for 19, 76, 521, 1017 and 4708 users. If they are not pricing on a true per-user basis then they will not be as competitive as those who do!
Price per user can only ever be a rough guide. The next question should be “What else do I get for my money?”
The flip side question of the Lot 4 discussion is where a supplier of a Lot 3 service also wishes to provide associated support services for it.
Does such a supplier have total freedom on whether to include those services within their Lot 3 offering or split them out into Lot 4?
Or do they *have* to split them out into Lot 4?
If a Specialist Cloud Service can be ordered separately it must be listed under Lot 4. If the service is an inseparable part of of the Lot 3 service i.e. there are some
ostensibly technicalfunctions within the Lot 3 services that necessarily include some form human intervention by the service provider as a component part, then they should be set out in the Lot 3 service.This does not include things such as back end support (as that would simply be part of the operation of the service), or helpdesk (which again is either and operation or a Lot 4 services that can be bought as an optional component).
This would include services such as, say, photo-tagging: where photo’s are uploaded to a services and they are tagged by people rather than machines and the services is sold on a per-tag basis where one cannot buy either the interface or the tagging separate from each other.