Comment by PaulHoule | Hacker News Reader

Comment by PaulHoule | Hacker News Reader

As someone who's sat on both sides of the table in enterprise software sales I understand this sentiment, but there are many kinds of software where you really do need to talk to a salesperson.

I once worked for a company that had an average sale well under than $100,000 but that sale typically included several licenses for at least two different products -- one a desktop app and the other a SaaS offering. There would always be at least a day of training, and possibly some consulting services and the possibility we'd bundle in something from a vendor we work with.

If customers tried to set that up with a web form they'd screw it up and hate our product.

Similarly, something like an ERP or Library Management System is going to take a considerable amount of attention from the vendor to fit it to your needs, so the salesperson isn't just there to harass you, he's there to make sure you get what you need to succeed.

----

I'm working on a product now that I could have sold through an impersonal automated process for $50 a month... If I could get enough subscriptions.

I didn't believe that I could, and decided to price the product much higher and sell it through a "high touch" process so I could make a living selling it to a handful of customers.

One issue is that anyone who sees the price would get sticker shock. However, the price per year will be between 1/3 and 1/4 of what it would cost to develop in house, and it would be charitable to estimate that most organizations would have 50% chance to produce a product that works (almost) correctly... After losing a few months on the schedule! Plus my product is documented, supported and comes with a pretty bow on top.

My guess is that for the value this delivers to customers it's worth my time to explain to them the value they're getting.

If your prospects are going to screw that up with a web form then I'd say some or all of these things are true;

a) your licensing model is too complicated. b) your web forms aren't usable c) your website isn't helpful enough

And before I get flamed, I regularly sell services worth north of $2k via a web form that lets the customer purchase solely using a credit card. Instead of making it hard for people to buy and assuming that "high touch" means "call us", we have staff ready at every step of the way to help people with their purchases and the use of their services when they need help. Instead of investing in artificial processes that force a customer to call us, we're investing in real customer service, training and product development. Automated doesn't have to be impersonal, unless that's your frame going in. Also, I have a suspicion that real customer value can't be created in the sales process. No one has ever come out of a negotiation or sale (automated or otherwise) saying "Now that's why I do business with these guys.". Customers derive value from using your product or service, not buying it. I think its misguided to try and create customer value in the sales process (Although you do say that your sales process simply explains the value to come, it doesn't try to create value... I'm just riffing on an idea... :)

I think you're completely missing the point. If you're doing software that needs per-customer customization (typically enterprise), then at some point the vendor and customer will need to talk. A great salesperson will be there to help you through the entire process (though I admit a lot of them suck, mostly due to misaligned incentives). It's not about bad UX in a web form, it's about selling custom software requiring interaction.

A, b, and c are all consistently true in enterprise software which sells for above $10k/mo.

I'll say that I've met a few sales engineers that really impressed me with their skills at understanding what I need and getting it to me.

I've met a lot of dolts too.

As someone who spent a year programming in job shops (a year too much) I can also say that the quality of the salesperson was a big factor in project success and quality of life.

Some salespeople qualify customers so we get customers that we can really help. Other salespeople "hire" nightmare customers that destroy the profit we made on 5 good customers.

Some salespeople would get contracts with specific requirements and a realistic budget and schedule. A project like this can be a joy to work on and it's equally gratifying to know you make your customer happy too.

Some salespeople write down "2.5 hours" to implement a feature, and it really would be "2.5 hours" if you knew what the feature would do, but it takes 4 hours of talking to the customer to find out what they think they want, then they're wrong and you have to do it again, and you end up spending more like 12.5 hours when it's said and done. That's no fun.

So yes, good salespeople add a lot of value. If the salesperson sells something impossible, the best architects, designers, and programmers can't make the story have a happy ending -- probably the greatest advancement in my programming career was realizing that I can't code myself out of an impossible situation.

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?

Instead, just call us. Pretty please.

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.

Again, I disagree.

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.

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.

Sounds ripe for disruption.

Any takers? ;-)

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.

"North of $2k" is not a large number. The company that I work for routinely sells services for 10's or 100's of thousands of dollars (and software for 10x of that). No one purchases that via web form.

We also offer a cheap, buy via credit card offering for people who just want to get going without talking to a sales rep.

For our particular software, the high touch model has roughly 100x higher sales figures.

I'm on the purchasing side and I can say that I've been turned into a customer during a sales process. I've called just to check things out and ended up a very happy customer.

I think a lot of what people don't like about the "enterprise sales process" is actually just due to shitty salespeople--folks acting pushy, calling all the time, trying gimmicks, being stupid or uninformed, etc. In contrast, interacting with a good enterprise salesperson feels exactly like getting great customer service, only it begins before you've plunked down any money.

The key to managing the sales cycle is to learn how to figure out early that you've got a shitty salesperson and either get a new one (if you really want the product) or get rid of them and find another option. You have to be willing to be firm, and maybe even a bit of a jerk sometimes.

Definitely true for most mass market software. But there are definitely products where a web form would have to be extremely long and/or complicated to be helpful at all.

In this specific instance it's $199 setup fee + $40/month + $4/month/user so really nothing too wild. I don't know what the others charge but I am not willing to play the game to save a couple of bucks here or there.

Also, they ask you to qualify the size of your company before giving you pricing (e.g., "Small business 1-50 employees click here"). I would be cool if they had a high-touch process for companies with more complex needs but at this level, it's really a plain-vanilla service.

That pricing model is about a month old. Before that you'd have to go through the sales process, and it was like everyone else, base fee plus surcharges depending on what services you want.

By sheer coincidence I'm sure, we (wavepayroll.com) launched with a flat rate pricing model ($3/employee/pay period, all in) back in November. I'm curious if you considered us, and if so, what your impressions were.

Wow - what a great, simple pricing model!

No, I had not considered you because you did not come up in my search (Google + asking founder friends). I am signing up right now. Thanks.

Wavepayroll looks awesome - also looks like it's Canada only though :( Is there a US equivalent?

So it turns out that you guys don't support Quebec. 2 things: 1) When are you planning to roll out that feature? Is it possible to sign up as a beta user now? 2) In the spirit of transparency, this should have been made clear before I signed up.

Our Quebec audience has been almost nonexistent so we didn't think to mention that on our page. Email me at sean @ waveaccounting.com and I'll let you know when we're ready with Quebec.

That's a great pricing model!

> If customers tried to set that up with a web form they'd screw it up and hate our product.

I'm sure it's true for quite a number of products. But what I wonder: how many products are that way because of the sales channel?

Even in the best case, a product built for self-service and user-driven adoption is going to be designed very differently than something sold through a high-touch sales channel with an expectation of expensive training before use. And that's before you account for all the product distortion that many enterprise salespeople introduce. "Why of course we'll have feature X in the next release!"

I expect there are a lot of companies that started out with an enterprise approach that are now ripe for disruption with a user-friendly, self-service model. A classic Innovator's Dilemma situation: the competition would seem laughably weak until it's too late. E.g., Linux vs proprietary Unix solutions.

I think the decisions are driven by the market, honestly, not the sales channel.

The products targeted at enterprise simply have to be vastly different than products targeted at small to medium sized businesses. The 37Signals business model of "Minimal features, give the customer what we give them, and nothing more" just doesn't work for companies with over xx,000 people.

How many large enterprises are using Basecamp? Highrise?

It isn't because they aren't good products, and it certainly isn't because they don't sell well... It also has nothing to do with the sales channel and process. But, simply put, the bigger the customer, the higher-touch the integration process must be, which by nature, drives up the touch-requirements of the sales cycle.

The long-drawn out sales cycle is a feature, really. It helps the customer get a really good understand of product capabilities before a lot of money is spent, as well as a realistic timetable of how long it will take to be integrated with their existing services, tied in to their existing data, authenticating against their native ADs or LDAPs, and provisioned within their existing storage arrays.

It isn't for everybody, and it certainly isn't the silicon valley way, generally speaking, but it works when done well, despite how much people might hate it.

> The products targeted at enterprise simply have to be vastly different than products targeted at small to medium sized businesses.

Sometimes. Sometimes not, though.

A while back I heard a story about SurveyMonkey, a classic self-service tool. At the time, they are going along like gangbusters: shipping new features, gaining new customers, making users happy. Eventually, some finance person at a major enterprise notices all the corporate credit card charges to SurveyMonkey and contacts them wanting an enterprise deal. Consolidated billing, special discount, special features.

The SurveyMonkey people, I am told, consider it carefully and then tell them "no". They figure they're doing just fine as they are, and have actual user needs for their coders to work on. In a huff, the large-company CFO cuts a deal with some more enterprise-friendly search company and sends out a memo: no more SurveyMonkey.

The memo is widely ignored. The other product isn't as good, and people have actual work to do, so they just keep charging SurveyMonkey to their credit cards like they always have.

My conclusion: with self-service products, the user is the customer. With enterprise products, the customer is often somebody totally different. So I think the sales channel shapes the market, which in turn shapes the product.

That's a fair point indeed, and if I seemed to represent the entirety of enterprise sales, I misspoke.

There are utility applications that work for enterprise, though I think we could both agree that SurveyMonkey wasn't specifically written at that audience. In fact, it seems that they turned their nose up at it, which is and isn't shocking. Like you said, sometimes the sales funnel does shape the product, and it takes a certain kind of person to go after enterprise sales, as it certainly isn't for everyone.

Winzip is another one. It's certainly valuable in the enterprise, and perhaps even necessary but, to my knowledge, the last time I saw it licensed (many moons ago) they didn't have any sort of enterprise agreement. You just paid for the number of seats.

That makes perfect sense. I agree with you that some things will always be enterprise products, sold the traditional way. The interesting thing to me is wondering which products people think are enterprise-only, but are actually ripe for disruption like survey tools were. Only time will tell, I guess.

It's a fair point. It also leads to the enterprisation of otherwise commodity software. Jive, for example, takes software that everybody has easy access to, adds enterprise features and enterprise class support, and sells them to the enterprise.

Need a blog? You could use Wordpress, for free, or you could pay Jive a large bundle of money, have them come in and install it, have active directory and oracle support, and somebody to blame when it doesn't work.

I know for a fact that if somebody would clone Evernote and allow it to operate within the Enterprise (instead of storing data in public cloud), there are at least three government agencies that would buy it for $10,000 or more.

Your point is definitely solid though, but the process that the enterprises are used to following are the ones that will win. If you hired a seasoned enterprise sales team, you could probably make a killing selling Wordpress, or something similar, to prevent people from overpaying for the existing enterprise solutions. You'd just have to know how to get in, and how to follow the sale.

The product itself has nothing to do with that.

> If customers tried to set that up with a web form they'd screw it up and hate our product.

Then your product, its documentation, or both is crap.

There are two kinds of "enterprise" solutions. The practically turn-key, and the kind that have ridiculous licensing models and "at least a day of training" attached. The latter are inevitably a gigantic waste of resources. The former are invaluable.

Your job is to solve problems, not give your customers more problems.

Some systems are inherently complex, it's stupid to pretend otherwise.

It's like someone saying "Why do I have to learn to program, all I want to do is make an app for my phone".

I disagree. With software that works on top of client data the more hands on you are the better. Each client had "irregularities" in their data that have to be ironed out. With good access (and good communication) you can hopefully take care of "irregularities" before the client even knows they are there.

This is completely true, something that I'd like to note is that the more hands on your are, the better trust you build with the customer.

This means they are more likely to keep buying your product (they know you and like you).

They are more likely to come to you when they have an awesome idea for a feature that they want that would make their lives easier. (And you never say no to an ambitious request, you either explain that you lack the budget, or you try to redirect it into something that would fulfill the same need, but is easier for you to do, or you can explain how to do it with the currently offered software).

This is not just enterprise stuff either. Having a bunch of enthusiastic and engaged customers pointing out the holes in your software is extremely useful.

This all assumes that you have technical people who 'get it' and are looking to help satisfy the customer. I would never let an aggressive sales staff near them, however. It would be awesome to have something like 'contact a technical person to discuss solutions.'

OR, documentation is a 'feature' you need to pay (double) for (true story)

General customer requirements for enterprise software: - Must integrate with their existing authentication. Their authentication may be LDAP, Active Directory, or any number of other things you may or may not have heard of.

- Must store to their existing storage hardware. Hardware may be SANs from EMC, 3Par, HP, etc. Storage arrays may or may not be writable over the network. Storage arrays may require fiber channel. Storage arrays (I'm looking at you EMC Celera) may require interaction against custom APIs.

- Must work against their existing load balancers -- load balancers may be hardware or software, may or may not utilize sticky sessions, and may or may not preserve the integrity of data packets passed along.

- Must allow for SSL encrypted traffic to be intercepted by their proxies, decrypted and logged, then forwarded along and still run as quickly as you would expect any application to run.

- Must support Microsoft SQL Server and Oracle Database.

Take the '10/30 minute blog' programming videos you see for all the common frameworks, make them work with the above feature set, and tell me how long it takes. Then sell that to a company with more than $10,000 users, and then do so without requiring any support from you or your company.

After that, if you still think it's as easy as you do, I will more than happily issue a public apology for having disagreed with you. Until then, honestly, I think you're looking at the problem space a little naively.

You're really missing the point.

If your product doesn't already meet the needs of a particular customer, it's not a product suitable for that customer. If the customer wants you to make it suitable, talk about the cost of that. Otherwise, stop annoying me with sales drones and let me give you money for the software I already know I need.

Somewhere along the way it looks like you and a few other people have confused "products" and "consulting". They're not the same things. Either you have a product ready to go, or you don't. If you don't, you're not a software company, you're a consulting company, and should act like one -- don't pretend to have a packaged solution ready to go.

It sounds like you're misinterpreting your own advice here.

We do in fact have a product that's ready to go. We have all of the features I listed, plus a hundred others. However, once you get to having all those features, the product is no longer something that you can expect people to download and just install. Sure, there are people that can do it, but it isn't the majority, and it isn't the sort of pain we want our customers to have to experience.

In short, our product requires both the software and the consulting. Not for lack of features, or lack of documentation, but for ease of integration. If the software already costs millions, then the user shouldn't be objectionable to another couple hundred thousand for a team of integration consultants to make their experience a smooth one.

All that said, it honestly sounds like you don't have a lot of experience in this arena, so I'd really appreciate it if you'd stop looking down your nose at me for meeting the needs of our customers in exactly the way they expect them to be met. We're doing a fantastic job, and have stellar relationships with all of our customers, partners and vendors. Just because it isn't the way you'd prefer it isn't reason to be snide, especially as it doesn't sound like you're anywhere close to the size of our target customer.

In which arena, exactly? Systems that cost millions of dollars? Help build 'em, seen the disaster from the inside, I know all about the massive bullshit involved with selling to Fortune 100s, and I know that you and most other companies involved are doing it exactly wrong. I also know that the Fortune 100s know it, and it absolutely destroys any relationship of trust with their vendors.

And yet, we're so far off topic it's not funny. Millions of dollars? This started with a small business owner trying to find pricing for a payroll system. Maybe you'd like to back up and tell me why your ego got hurt when apparently you're such a big man in what you apparently consider a completely separate universe?

I don't disagree that most people are doing it wrong, but the issue that we're onto here is that either our product is crap, or we're treating our customers like idiots.

The point is that neither has to be the case to require a phone call. The point is that our target audience doesn't have people with both the technical skills to install our product and the authority to make the purchase.

There is absolutely no point in a 'download now' option for this type of software. There is no point in making it easy for the medium-sized customer because they will almost never buy our product. They'll buy something with half the features and much less than half the cost. They'll end up with a vendor who will charge them for every modification they require and they'll end up with a product that does most of what they want, and solves 80 or more percent of their pain. That's what things like Basecamp and Highrise do. They aren't made to fit anyone's needs 100%, except maybe 37Signals.

Our software is expensive because, while it isn't perfect, it does solve 100% of the need for more than one customer. It's a complete, entire package.

And for the record, my ego isn't even remotely hurt, nor did I mean to imply in any way that I'm some sort of big shot; I'm not. I just think that you're wrong, or more specifically, I think that you're painting us with the same brush that you'd paint EMC or Cisco, based solely on the evidence that we're selling expensive software to customers and we don't let people download it. Our competitive advantage is that we aren't them, and that we aren't approaching enterprise sales in the same traditional way that everybody else does.

But that doesn't change the fact that giving our customers access to a download link doesn't help them. Giving them access to our pricing tables doesn't either.

Actually, if you'd be so kind as to indulge, let's back up a step and tell me what you think it is that we're doing so horribly wrong.

How would you sell enterprise software differently?

Reply on news.ycombinator.com