Selling to the Fortune 500, Government, and Other Lovecraftian Horrors
training.kalzumeus.com
training.kalzumeus.com
Edit: this is actually also true for those multi-million dollar deals. I want to understand your product before I have a call with you because I want to be able to ask the right questions. The craziest are those companies that even during sales calls only show buzzword slides and not a single screenshot
Over a month wasted on pointless meetings just because they were afraid to share their price.
This is often a sign the vendor doesn't know how to price their product. It sounds to me like they didn't have any index of where the lines really were - one line is price where the customer building it themselves ins the option. The other is the price too low we can't do the deal line. They were probably afraid to talk price because they were afraid to put the first number on the table.
> We ended up building the software we needed in house for 25% of what it would have cost to license theirs.
Not surprising. I've been in way too many of these kinds of meetings, both buying and selling. Now when I buy, I flat-out tell the sales rep:
"We make software. One of your competitors is us building what you have. Give us a price that makes that option unattractive."
Not that this can’t be done and done well, but just like running your own datacenter the idea looks much more attractive at the beginning than it does a year or three in.
But the software didn't cost 25% because that's not how software works. Basically you now have a choice, A) the project is done, so you can fire that new IT department. B) the project is not done, so they can keep working (meaning your 25% will keep growing) C) the project is done, but you keep the team for future development, so you give them other projects to do in the meantime.
And you just hope that you keep the team interested enough to stay around, so that in 5 years time when you have to make it work with TLS 1.4,or Windows 12,or the new Dropbox API, or whatever that there's still someone around to do it.
My point is that writing software is never done because it exists in a world that changes. And keeping programmers on salary to do that is expensive.
That said, yes, it can clearly still end up being cheaper than some Enterprise offerings I've seen.
Obfuscation of the actual product seems to work well for big ticket purchases. I have been in quite a few sales meetings where I tried to figure out what the f……ng product actually does but couldn’t get a straight answer. Same for pricing. But somehow the IT big shots loved the presentations and bought it. There seems be a layer of mutual bullshitting going between sales guy and VPs on the regular engineer doesn’t seem to be able to understand.
The best vendor product in my industry has an easily accessible website with PDF & YouTube videos on how to use all features. All documentation is easy to peruse, it's used by several college textbooks, and their company is small enough to where I can call up the lead devs and get a bug patch or just chat when needed. It is also much cheaper than the majority of the competition. I was an expert in using the product before I ever used it. They also have trial licenses for all feature add-ons and will extend them if you had a busy month and didn't get the chance to use it. I once arranged for a trial license, tested out the feature, and built a full process around it as a "this is a workable solution to one of our problems for management". They even left me a nice and simple quote. Two years later we got involved with a project that absolutely needed that add-on and I just forwarded management an email showing that I tested it worked on our systems as advertised and even had the quote ready so we knew roughly how much it would cost (the quote had expired, but we knew it would be close).
Yet some companies like to get potential suppliers in to check them out, despite all the literature & online website info. Thats when the real phishing begins, getting info thats not publicly available. Subtle questioning and things like that.
> Dealing With The "You're Not Big Enough" Objection
I know FTSE listed companies that would not trade with SME's because they were too small, even when it meant the product or service blatantly benefited the FTSE company.
That is why a lot of SaaS stuff does not have price on their page or at least "enterprise" option is always call only.
Oh uh, yeah... XYZ - it totally does that and definitely doesn't function like a prototype.
Exactly! Find out what the customer needs it to do, and then tell them your solution does exactly that, even if it doesn't.
If you list all your features online ahead of time, its a lot harder to lie to the customer.
Whereas you can pretty much agree to any terms that don’t misrepresent how your product works when you’re just starting out, there comes the point of wanting to spend a lot more scrutiny on your contracts without having in-house legal yet.
If you’re a founder, that probably means you will be sending redlines, thinking about indemnities and warranties and handling other wonderful aspects of doing business internationally (privacy terms, jurisdiction, insurance, …).
While true that price discrimination helps to make these cases mostly worth it, they are still a crazy time suck and finding a savvy lawyer to take it off your hands may or may not be easily possible (lawyer fees for one such deal once ended up being 50% of the whole deal value - we raised enterprise prices after that).
Watch out especially when you’re in an industry going through lots of M&A activity as your self-service customers may suddenly be part of large Fortune 500 organizations, and despite all advice to the contrary, stakeholders who know your pricing already do balk at your 5-10x Enterprise prices.
I do wish there were more stories of how the legal side of these deals is dealt with, what sticking points in contracts take up most of your time, and what „hacks“ you found.
(One hack that saved me a lot of time: Treat your terms like you would any other part of your product. Iterate, work on the UX, remove barriers to adoption. After a bunch of gnarly negotiations over things that matter to your client, but not usually to you I compiled a list of changes and had our lawyer revise the terms to avoid the need to negotiate those parts moving forward. Alas, it’s a moving target and we’re in the midst of another iteration like this.)
1) Separate your order form from your standard services agreement. Put your services agreement online as a PDF, which sends a strong signal that you don’t generally negotiate these terms.
2) Allow amendments within your order form, but make them part of the commercial conversation. You might want to have a cutoff where you choose not to customise the contract; eg no custom terms for deals less than $XX,000 per month.
3) Accept that this is just the process for your larger customers. In larger deals, you’ll probably be signing a standard supplier contract they already have, with only the service-specific terms mattering. This could include terms needed for regulatory requirements eg which are not negotiable. Design your contracts to account for this.
4) Understand why your customer wants to redline something. This might be regulatory, it might be consistency with other suppliers, or it might just be pushing their luck.
Case in point, we’re currently going back and forth with a FTSE 100 bank, and they have inserted a clause requiring us to have our working locations approved by them. We’re a remote, global company, so we’d need every employee approved. But the reason they care is due to banking regulations around sanctions, so we came to a mutual agreement that countries would be acceptable to us both.
4) Have a good way to track all these deviations. They’ll happen, so you just need to get used to them to some degree. Design variables into your system which integrate with your CRM so that you can codify this as much as possible.
(But, be careful when doing this, since you’ll be providing your sales team with more levers which they will pull to get the deal.)
While everything this guy says is largely true - I have after all had purchase proposals rounded up to the nearest $100k ( it wasn't close... ), But likewise it's often true that that $500-1000 credit card is only held by one person in a given team, and there are already many competing monthly charges on it, and it's also said manager's "get out of jail free card" for just throwing money at small problems that come up, without having to talk to their manager. That's an emotional requirement as much as anything, but it's linked to whether said manager can appear competent to their 1-up.. so if you think that $1000 card has more that $250 available for all reoccurring expenses, you may need to reconsider.
And you might, justifiably, decide that's a reasonable customer selection filter, because no one wants a customer that behaves like a big enterprise but pays like consumer.
But we're not like that, honest - I just want your X for me and the 3 people in the team it'd help, you'll probably never hear from us otherwise. Truly! Come on, we believed your marketing brochure.. meet us half way?
(* Actually, it can be fine, finance directors are often perfectly nice people, with that deeply soothing habit of just rounding up to the nearest $10k/100k/1M.. but really can we get this stuff of your credit card, Clair complains every week about chasing you for receipts)
Down to the penny. Two months ago my wife spent half a day tracking down a 2 cent discrepancy when somebody's handwritten 7 looked like a 9.
I get a lot of those. They will send their 27 pages of purchase terms and when I ask what they are buying it comes to $99.
We do B2B software for banks, and this is (was) easily the hardest barrier to overcome.
But, we did actually overcome and managed to get to production for several customers. Once you have ~3 customers to point back to, its like you have some secret access for the rest of the market segment. Our customers talk to each other a lot. It is a very tight community.
The bootstrapping was ultimately possible because our organization has been doing business with the banking industry since the 90s. We had a lot of prior contacts to work with to get that first install. I don't think what we did would have been possible without this prerequisite.
The very first customer was essentially an arrangement where they would not be billed a dime until some percentage of business functionality was stable in production. We had to burn a lot of time and money for zero payout just to get one shot to access the market.
Overall, doing business with banks is not fun. I would not recommend it unless you enjoy writing more emails than code.
a) The purchase is trivial. This is the "hack" the article is talking about, and for most SaaS is the best way to go. Over time, as more of the enterprise uses the product it starts to matter, and the next exception will apply.
b) If your solution is something that really matters and an officer of the company signs off on it, you have a legal contract, no matter the internal process that was supposed to be followed. Additionally, the officer of the company that signed off has signaled to the other officers that they can, if they wish, skip legal, IT and procurement vetting. In many cases vetting will be "adjusted" rather than have an internal fight between Sales and IT.
c) The purchase is from a company where the enterprise has an investment. I.e. the venture arm is into the vendor for $LOTS.
The best two ways to sell to the enterprise: price under the approval limit and grow wallet share, or have something so incredible that the enterprise will buy on your terms.
Real enterprise sales are much more relationshippy and less transactional --- just in my experience --- than this post talks about. Making these sales is a lot about taking and managing meetings, understanding RFP processes, structuring bakeoffs and trial deployments, and, probably most importantly, staffing sales prospects with SEs to handhold the deployment and keep the relationship with the technical decision-markers warm. Knowing who the economic buyer is, and who the real decision-maker is, is another important skill not mentioned here.
Patrick isn't really talking about enterprise sales; he's talking about how to hack the reflexes of enterprise purchasers to bootstrap a self-service product. Serious enterprise deals often take multiple quarters to close, and they can be staffed almost the whole time; it's a whole big thing.
None of this should be construed as me knocking the post. The post is fantastic for what it's actually about.
They're also price conscious. Everyone has a budget and the more of that budget you take up the worse it is for them. Enterprises are good because they have big problems that cost lots and lots of money. They're willing to give you a significant fraction of that money if you solve the problem.
Enterprises have to account for what they spend money on. They can either do that as part of an existing budget, or they can carve out a brand new budget. The latter is always harder than the former. If your price point fits neatly into a tiny gap they have left in their existing budget, things will be easier. OTOH if they have to carve out new budget, but they have an engineering department and there is a "free self-hosted" alternative, they will almost always go for that instead.
> 3. Purchasing Agent Sends Out Questions
There is often a very large and annoying process around this step that is much larger than purchasing, which is vetting a new vendor and product. Any Enterprise that has to deal with regulatory compliance or international laws will need to look for problems in the vendor or their product. This is a time-consuming and expensive process. If you are courting an Enterprise, do everything in your power to find out what their concerns are and make a 1-pager that explains them all, and separately a massive tome that details every answer. You'll want to cover all the questions Legal might have, address regulations, and enumerate exactly who has access to what part of a system['s data] and when and how.
If you really want to catch big fish, also detail every aspect of your different payment and operational models, even if you don't include the actual price. The price doesn't matter as much as knowing how the thing will function and what its limits are.
If you design your system to work a certain way for Enterprise, be prepared to change how it works for a whale customer. Always have in the back of your mind "I may need to fork this whole thing just for Customer X". Get the sale, worry about tech debt later. Anyone working in your company will hate that, but the ability to work around one detail or another can result in millions of dollars in sales.
Also, help craft their strategy for rolling out the solution thought the Enterprise rather than just for one team. Design a management portal that works at an Org level and can delegate access down a hierarchy of teams, and enable SSO using standards that Enterprises use. They may be much more inclined to purchase a big fat plan for their entire org rather than for just one team.
- "Oh budgeting isn't until end of year.. what can we do until then?" Then you do a 50K thing for 5mo until thing under their personal or direct bosses authority and work to get into budget thereafter at a higher rate. It's not surprising to find ~personal authority at $50-100K/yr for lowest level managers (the team who wants you and whose manager has someone trusted doing the picking), with only a quick informal/formal ok of their boss.
- Procurement often gets involved early and want to get their 5% or whatever discount. "Yes we can use discounts as part of rightsizing you.. how about multiyear, with X+Y licenses in year two and X+Y+Z in year three, and as long as you prepay, we are good."
- Security compliance people are often people ;-) Questions here to work around product gaps often just require you to align with whatever journey they need you to be on and identify some workarounds till then. (But you must be on that journey for this to work)
- "what would 10x how useful this is? What feature would be a game changer for your team, and for the org?" Part of the enterprise trick is steadily enabling them to pay more and more over time.
- "We don't do this for our smaller customers , but would you feel less at risk with a bundle where add training and support at $$$/day, with 1 week / qtr prepaid? Or any integration + feature services like for important system X?" What's ho-hum and easy for you may significantly derisk + increase value to them, and their sense of cost is different from yours.
It's to see 5-10% of a SaaS's customers be enterprise yet half the revenue be from them, and 20%+ being around these funny service add-ons. Early on, they can even be your main revenue ("design partner") while the tinySaaS revenue builds up.
A good hack early on can be to get an enterprise sales or product advisor / consultant to sit in some calls with you for the most embarrassing basics like these, and same around your product + pipeline process, until you can get dedicated folks.