Software licensing models

The Register has a good article on Software Licensing Models which is a useful primer if you’ve never had to encounter this wonderful world before… I thought it might be worthwhile examining our choices in this area from a vendor perspective. I know some Lab Informatics and especially ELN vendors have some quite complex models, so this area is of continued interest to us (and then there’s Oracle’s model!).

We’ve always had a very straightforward model; because our Electronic Lab Notebook needs to know about every user to do its job (every user needs to be uniquely to sign and witness their entries), it is easy to just charge for the number of users which are enabled on the system. Fairly straightforward.

We do have a slight complexity in that we split PatentSafe functionality into modules, so you can have cheaper licenses for people who just want to read, or people who just want to submit and sign stuff, etc. We have assigned “points” values to these functions, and customers buy a certain number for their system which gives them a lot of flexibility.

Sometimes we’re asked about concurrent pricing but that request generally comes from an IT dept who are (quite reasonably) looking for ease of administration and don’t realise every user is going to be setup (automatically or otherwise) with a PatentSafe account anyway. Concurrent licensing wouldn’t help anyone in our use case.

We do have a mix of perpetual and rental options in our licensing structure; this accommodates customers who have capital and want the reassurance of owning something (generally larger more established customers) as well as making enterprise-grade solutions attainable to companies who might either be short of capital (being VC funded and at the end of a round) or unsure of their growth curve.

We don’t do anything silly in terms of copy protection; it just adds to pain for the users, and ultimately support pain for us! We don’t even lock a system to a particular number of users – PatentSafe just points out how many users you have and we trust our customers to have that many licenses. We also don’t charge for test servers, although we do make a small additional support charge if you want production-level support for an additional server.

I guess we are unusual in that we’re a records system which is intended to go into court at some point, so we can trust our users to do the right thing in terms of having the right number of licenses. This level of trust makes everything easier, and interestingly means users are more trustworthy back – in all the years I don’t think I’ve ever heard of a reason to be worried that a customer may be exceeding their entitlement.

I know some software companies view having a complex licensing structure as a sales tool but I’ve never found it all that attractive. We’re providing and supporting a tool which will benefit a customer’s organisation, and the question is how to fairly measure the value we provide and hence should be compensated for. We’ve found the easiest and most reliable way to do that is count up how many scientists we’ve freed from the drudgery of the Bound Paper Lab Notebook, so that’s how we price the system. Simple, transparent, predictable – and fair.

Interestingly treating our customers like adults means they act like adults; and the relief expressed in the sales cycle when the realise we’re straightforward to deal with is quite gratifying! I continue to remain befuddled as to why more companies can’t have understandable pricing schemes – I can’t see how complexity helps the vendors or the customers.

Buying an ELN: The perils of application-centric thinking

Over at The Integrated Lab, John Trigg looks at the ELN Vs LIMS issue which has come around again as more traditional “LIMS” vendors introduce “ELN” products targeted at their traditional QA/QC customer base. He says:

But perhaps the real issue here is our application-centric view of laboratory systems

Which I very much agree with. So many projects start out not looking at their problem but instead “What ELN should we buy?”. When the terms we use such as “Electronic Laboratory Notebook” and even “Laboratory Information System” cover such a wide spectrum of potential functionality, starting out that way without being clear about what you are trying to achieve is a recipe for failure.

When we meet people for the first time we always ask “Why did you make time to see us?”, and hopefully they tell us the business problem they are trying to solve. If they answer “Because we’re looking for an Electronic Laboratory Notebook and you are an ELN vendor, show us what you do”, we find ourselves asking questions like “Why do you want one?” and “What do you think one will do for you?” which helps us to get to the root of the issue.

You’d be surprised how many people who tell us they want an ELN (and are quite certain about that!) but in fact have a problem that doesn’t need one – they might just need to use their existing software in a different way, or buy something like an SDMS or a LIMS.

I know that the traditional sales school says you should immediately “re-engineer” the prospect’s “vision” to suit the features of your product, but in my experience that rarely leads to a happy outcome even if you do manage to make the initial sale. If the end users didn’t need one, then just because the organization went out and bought one, and the vendor’s salesperson convinced them to buy his (plus the consulting time to aid with the inevitable painful implementation) it doesn’t mean the project is going to be a success in terms of achieving a Return On Investment.

From my perspective (as a technology implementor, not a salesperson), the sales process is where a potential customer and a potential vendor communicate and establish if what the vendor has to sell is going to solve the business problem the potential customer is prepared to spend money to solve. That often involves clarifying what the real problem is, before we get into solutions.

From the vendor side that means being willing to say “That’s not us, why don’t you go talk to these guys”, and from the customer side that means talking to us about the business problem you need solve, not what application you think you want to buy.

Once we understand a business problem, then if appropriate we can show how our ELN might be able to solve it. But not before. This sometimes upsets people who want us to just come in and demo, but surely the idea of the sales meeting is to have a productive outcome, and requires communication? Which is why we like to ask as many questions of prospective customers as they might ask of us, as strange as people find that.

I’d rather have a meeting where after 10 minutes we mutually come to the conclusion that there isn’t a fit, than labor with on each side pretending there at some point might be a happy outcome. If we communicate well at the first meeting, it means if things do go forward there’s a high probability of success all round.

(This approach of finding out people’s business problem and telling them if we aren’t a good fit did cause problems with our sales team until we changed their focus and compensation to be biased towards “happy customers” rather than just “make sales”. A small but important tweak which really helped the quality of the business, but still raises eyebrows when we recruit new salespeople.)