I strongly disagree that any of those things is necessarily the case.
Licensing models tend to be complicated for enterprise software, but it's usually complicated for a fairly decent reason.
I can't possibly expect somebody to understand how Sun Access Manager (now defunct) is going to work when they buy it without talking to us first. Even those people who understand the product well enough are going to need support from the mothership, and the high touch process gives us the ability to plan for that, to your benefit.
Depending on the features you need, it might entail wrapping in five or six different products. Some of those products might be given to you for free (if they're only there to fit a requirement of another product, and aren't going to be used, otherwise) -- some of those products will be discounted based on expected use, or the expected benefit to your organization. Some of those products might have different requirements. In large software companies, it's entirely common for two companion products to support different databases, or different message buses, etc. You need to know that before you buy.
My company currently sells software that costs $3million a year or more, and involves weeks of professional services to get up and running, training on how to use the produt, etc.
You really expect us to let you just buy this on the internet?
Also I use the contact process to determine whether or not someone needs training. I have spent enough time fixing folks broken setups regarding accounting software to know that you want to have a good idea of what someone needs to know and work that into the project price as well :-P
That's also a good time to determine customer fitness as well.
The better at enterprise sales you get, the more quickly you can determine who is going to drag their feet, who's going to give you a bunch of money and then be a pain in the ass, and who's just going to draw out the sales process to infinity while making sure to call you every day so that they can get their money's worth.
Believe it or not, we ARE the disruption in our market, and we're taking tons of sales from the old guard.
That said, there's only so much you can disrupt enterprise sales. There's an art to it that, while I hate to stereotype, isn't commonly known to most of the valley types I've met.
It's arcane, it's awkward, and it takes lots and lots of practice and failure. In short, selling multi-million dollar software simply isn't something you can accomplish with a Paypal button and a download link. The average sales cycle is measured in months, and a sub-30-day sale is considered monumental.
> It's arcane, it's awkward, and it takes lots and lots of practice and failure.
I'm confused. You seem to be making conflicting suggestions. Is this "arcane" and "awkward" sales process truly a sine qua non for your industry? Or is it the product of social inefficiencies that just can't be corrected by technical measures?
It's largely driven by the people who buy the software having a complex business need that they want to fulfil, but who don't know the best solution, if it even exists.
So they surround themselves with advisors (consultants, project managers, architects, etc), some of them good, some of them bad, and between the 3 groups (the buyers, vendors, and advisors), they try to come to an agreement where all 3 are happy.
The sales process is basically nudging all 3 groups into positions where everyone is happy, and can be a long and painful process.
You're treating your customers with enormous disrespect. If your chosen example is really Sun Access Manager, why don't you expect the developers using it to understand how it works? You're assuming we're morons. Absolute drooling morons, judging from the documentation I can find for Access Manager, which shows a product that is orders of magnitude simpler than a few others I've dealt with, and I'm having no trouble understanding how it works.
I don't think you're a moron. But the developers generally aren't the same people that pay for the software, especially not in the size of the organizations we're selling to. If you're a 10, 20, 250 person company, you're probably not buying our product. If you're a 30,000 person company, you're in our market.
If you're in a 30,000 person company, I almost guarantee that the 'developer' implementing the product isn't the same person as the guy writing us our check. I'm willing to bet there are at least two layers in the org chart between those people, if not more.
In the size of these organizations, there are enterprise architecture counsels, change control boards, executive steering committees. We need to document to those individuals how we're going to help them further their missions and operating objectives for the years to come. We're going to show how our products can be leveraged to maximize the efforts they're already undertaking.
The change control boards are going to want to see white papers that document what effect our application is going to have on the existing environment. They're going to want to know exactly what ports and protocols need to be exposed for things to work. They're going to need to know what kind of load balancing techniques will work best for our product. They're going to need to know how much storage allocation to expect at years 1, 2 and 5.
These aren't things we expect anyone to know, and they change from version to version. These are the things that we know, and not even necessarily one guy in our group knows them, we need a few people in our team to explain these questions and more.
Licensing models tend to be complicated for enterprise software, but it's usually complicated for a fairly decent reason.
I can't possibly expect somebody to understand how Sun Access Manager (now defunct) is going to work when they buy it without talking to us first. Even those people who understand the product well enough are going to need support from the mothership, and the high touch process gives us the ability to plan for that, to your benefit.
Depending on the features you need, it might entail wrapping in five or six different products. Some of those products might be given to you for free (if they're only there to fit a requirement of another product, and aren't going to be used, otherwise) -- some of those products will be discounted based on expected use, or the expected benefit to your organization. Some of those products might have different requirements. In large software companies, it's entirely common for two companion products to support different databases, or different message buses, etc. You need to know that before you buy.
My company currently sells software that costs $3million a year or more, and involves weeks of professional services to get up and running, training on how to use the produt, etc.
You really expect us to let you just buy this on the internet?
Instead, just call us. Pretty please.