Kellblog covers topics related to starting, managing, leading, and scaling enterprise software startups. My favorite topics include strategy, marketing, sales, SaaS metrics, and management. I also provide commentary on Silicon Valley, venture capital, and the business of software.
When I looked at the posts they picked, I thought they did a good job of identifying the best material, so I thought I’d share their list here. They also called me “a GOAT software blogger” and after playing around with acronyms for about half an hour — maybe Groove, OpenView, AngelVC, Tunguz? — my younger son swung by and said, “they called you a GOAT? Cool. It means greatest of all time.” Cool, indeed. Thanks.
Here’s the APPEALIE Kellblog’s Greatest Hits 2016-2019 list:
I think for many sales-aggressive enterprise SaaS startups, a fair amount of churn actually happens at inception. For example, back in 2013, shortly after I joined Host Analytics, I discovered that there were a number of deals that sales had signed with customers that our professional services (PS) team had flat out refused to implement. (Huh?) Sales being sales, they found partners willing to do the implementations and simply rode over the objections of our quite qualified PS team.
When I asked our generally sales-supportive PS team why they refused to do these implementations, they said, “because there was a 0% chance that the customer could be successful.” And they, of course, were right. 100% of those customers failed in implementation and 100% of them churned.
I call this “inception churn,” because it’s churn that’s effectively built-in from inception — the customer is sent, along with a partner, on a doomed journey to solve a problem that the system was never designed to solve. Sales may be in optimistic denial. Pre-sales consulting knows deep down that there’s a problem, but doesn’t want to admit it — after all, they usually work in the Sales team. Professional services can see the upcoming trainwreck but doesn’t know how to stop it so they are either forced to try and catch the falling anvil or, better yet, duck out and a let partner — particularly a new one who doesn’t know any better — try to do so themselves.
In startups that are largely driven by short-term, sales-oriented metrics, there will always be the temptation to take a high-risk deal today, live to fight another day, and hope that someone can make it work before it renews. This problem is compounded when customers sign two- or three-year deals  because the eventual day of reckoning is pushed into the distant future, perhaps beyond the mean survival expectation of the chief revenue officer (CRO) .
Quality startups simply cannot allow these deals to happen:
They burn money because you don’t earn back your CAC. If your customer acquisition cost ratio is 1.5 and your gross margins are 75%, it takes you two years simply to breakeven on the cost of sale. When a 100-unit customer fails to renew after one year, you spent 175 units , receive 100 units, and thus have lost 75 units on the transaction — not even looking at G&A costs.
They burn money in professional services. Let’s say your PS can’t refuse to the implementation. You take a 100-unit customer, sell them 75 units of PS to do the implementation, probably spend 150 units of PS trying to get the doomed project to succeed, eventually fail, and lose another 75 units in PS. (And that’s only if they actually pay you for the first 75.) So on a 100-unit sale, you are now down 150 to 225 units.
They destroy your reputation in the market. SaaS startup markets are small. Even if the eventual TAM is large, the early market is small in the sense that you are probably selling to a close-knit group of professionals, all in the same geography, all doing the same job. They read the same blogs. They talk to the same analysts and consultants. They meet each other at periodic conferences and cocktail parties. You burn one of these people and they’re going to tell their friends — either via these old-school methods over drinks or via more modern methods such as social media platforms (e.g., Twitter) or software review sites (e.g., G2).
They burn out your professional services and customer success teams. Your PS consultants get burned out trying to make the system do something they know it wasn’t designed to do. Your customer success managers (CSMs) get tired of being handed customers who are DOA (dead on arrival) where there’s virtually zero chance of avoiding churn.
They wreck your SaaS metrics and put future financings in danger. These deals drive up your churn rate, reduce your expansion rate, and reduce your customer lifetime value. If you mix enough of them into an otherwise-healthy SaaS business, it starts looking sick real fast.
So what can we do about all this? Clearly, some sort of check-and-balance is needed, but what?
Pay salespeople on the renewal, so they care if the customer is successful? Maybe this could work, but most companies want to keep salespeople focused on new sales.
Pay the CRO on renewal, so he/she keeps an honest eye on sales and sales management? This might help, but again, if a CRO is missing new sales targets, he/she is probably in a lot more trouble than missing renewals — especially if he/she can pin the renewal failures on the product, professional services, or partners.
Separate the CRO and CCO (Chief Customer Officer) jobs as two independent direct reports to the CEO. I am a big believer in this because now you have a powerful, independent voice representing customer success and renewals outside of the sales team. This is a great structure, but it only tells you about the problems after, sometimes quarters or years after, they occur. You need a process that tells you about them before they occur.
The Prospective Customer Success Review Committee
Detecting and stopping inception churn is hard, because there is so much pressure on new sales in startups and I’m proposing to literally create the normally fictitious “sales prevention team” — which is how sales sometimes refers to corporate in general, making corporate the butt of many jokes. More precisely, however, I’m saying to create the badsales prevention team.
To do so, I’m taking an idea from Japanese manufacturing, the Andon Cord, and attaching a committee to it . The Andon Cord is a cord that runs the length of an assembly line that gives the power to anyone working along the line to stop it in order to address problems. If you see a car where the dashboard is not properly installed, rather than letting it just move down the line, you can pull the cord, stop the line, and get the problem fixed upstream, rather than hoping QA finds it later or shipping a defective product to a customer.
To prevent inception churn, we need two things:
A group of people who can look holistically at a high-risk deal and decide if it’s worth taking. I call that group the Prospective Customer Success Review Committee (the PCSRC). It should have high-level members from sales, presales, professional services, customer success, and finance.
And a means of flagging a deal for review by that committee — that’s the Andon Cord idea. You need to let everyone who works on deals know that there is a mechanism (e.g., an email list, a field in SFDC) by which they can flag a deal for PCSRC review. Your typical flaggers will be in either pre-sales or post-sales consulting.
I know there are lots of potential problems with this. The committee might fail to do its job and yield to pressure to always say yes. Worse, sales can start to punish those who flag deals such that suspect deals are never flagged and/or that people feel they need an anonymous way to flag them . But these are manageable problems in a healthy culture.
Moreover, simply calling the group together to talk about high-risk deals has two, potentially non-obvious, benefits:
In some cases, lower risk alternatives can be proposed and presented back to the customer, to get the deal more into the known success envelope.
In other cases, sales will simply stop working on bad deals early, knowing that they’ll likely end up in the PCSRC. In many ways, I think this the actual success metric — the number of deals that we not only didn’t sign, but where we stopped work early, because we knew the customer had little to no chance of success.
I don’t claim to have either fully deployed or been 100% successful with this concept. I do know we made great strides in reducing inception churn at Host and I think this was part of it. But I’m also happy to hear your ideas on either approaching the problem from scratch and/or improving on the basic framework I’ve started here.
# # #
 Especially if they are prepaid.
 If CROs last on average only 19 to 26 months, then how much does a potentially struggling CRO actually care about a high-risk deal that’s going to renew in 24 months?
 150 units in S&M to acquire them and 25 units in cost of goods sold to support their operations.
 I can’t claim to have gotten this idea working at more than 30-40% at Host. For example, I’m pretty sure you could find people at the company who didn’t know about the PCSR committee or the Andon Cord idea; i.e., we never got it fully ingrained. However, we did have success in reducing inception churn and I’m a believer that success in such matters is subtle. We shouldn’t measure success by how many deals we reject at the meeting, but instead by how much we reduce inception churn by not signing deals that we never should have been signed.
 Anonymous can work if it needs to. But I hope in your company it wouldn’t be required.
Just a quick post to share a slide deck I created for a session I did with the top S&M executives at a private equity group’s sales and marketing summit. We discussed some of my favorite topics, including:
After years of experience with and thinking about multi-year, prepaid SaaS deals, my mental jury is back in the box and the verdict is in: if you’re a startup that is within my assumption set below, don’t do them.
Before jumping in, let me first define precisely what I mean by multi-year, prepaid deals and second, detail the assumptions behind my logic in response to some Twitter conversations I’ve had this morning about this post.
What do I Mean by Multi-Year Prepaid Deals?
While there are many forms of “multi-year prepaid deals,” when I use the term I am thinking primarily of a three-year agreement that is fully prepaid. For example, if a customer’s ARR cost is 100 units for a one-year deal, you might approach them saying something akin to:
By default, our annual contracts have a 10% annual increase built in . If you sign and prepay a three-year agreement, i.e., pay me 300 units within 60 days, then I will lock you in at the 100 units per year price.
Some people didn’t know these kinds of deals were possible — they are. In my experience, particularly for high-consideration purchases (where the customer has completed a thorough evaluation and is quite sure the system will work), a fairly high percentage of buyers will engage in this conversation. (In a world where companies have a lot of cash, a 10% return is a lot better than bank interest.)
Multi-year prepaid deals can take other forms as well:
The duration can vary: I’ve seen anything from 2 to 7 years.
The contract duration and the prepaid duration can decouple: e.g., a five-year deal where the first three years are prepaid.
But, to make it simple, just think of a three-year fully prepaid deal as the canonical example.
What are My Underlying Assumptions?
As several readers pointed out, there are some very good reasons to do multi-year prepaid deals . Most of all, they’re a financial win/win for both vendor and customer: the customer earns a higher rate of return than bank interest and the vendor gets access to capital at a modest cost.
If you’re bootstrapping a company with your own money, have no intention to raise venture capital, and aren’t concerned about complicating an eventual exit to a private equity (PE) or strategic acquirer, then I’d say go ahead and do them if you want to and your customers are game.
However, if you are venture-backed, intend to raise one or more additional rounds before an exit, and anticipate selling to either a strategic or private equity acquirer, then I’d say you should make yourself quite familiar with the following list of disadvantages before building multi-year prepaid deals into your business model.
Why do I Recommend Avoiding Multi-Year Prepaid Deals?
In a phrase, it’s because they’re not the norm. If you want to raise money from (and eventually sell to) people who are used to SaaS businesses that look a certain way — unless you are specifically trying to disrupt the business model — then you should generally do things that certain way. Multi-year prepaid deals complicate numerous things and each of those complications will be seen not as endemic to the space, but as idiosyncratic to your company.
Here’s the list of reasons why you should watch out. Multi-year prepaid deals:
Are not the norm, so they raise eyebrows among investors and can backfire with customers .
Complexify SaaS metrics. SaaS businesses are hard enough to understand already. Multi-year deals make metrics calculation and interpretation even more complicated. For example, do you want to argue with investors that your CAC payback period is not 18 months, but one day? You can, but you’ll face a great risk of “dying right” in so doing. (And I have done so on more than one occasion ).
Amplify churn rates. An annual renewal rate  of 90% is equivalent to a three-year renewal rate of 72%. But do you want to argue that, say, 79% is better than 90%  or that you should take the Nth root of N-year renewal rates to properly compare them to one-year rates? You can, but real math is all too often seen as company spin, especially once eyebrows are already raised.
Turn your renewals rate into a renewals matrix. Technically speaking, if you’re doing a mix of one, two, and three-year deals, then your renewal rate isn’t a single rate at all, but a matrix. Do you want to explain that to investors?
Tee you up for price knock-off at sales time. Some buyers, particularly those in private equity (PE), will look at the relatively large long-term deferred revenue balance as “cashless revenue” and try to deduct the cost of it from an acquisition price . Moreover, if not discussed up front, someone might try to knock it off what you thought was a final number.
Can reduce value for strategic acquirers. Under today’s rules, for reasons that I don’t entirely understand, deferred revenue seems to get written off (and thus never recognized) in a SaaS acquisition. So, ceteris paribus, an acquirer would greatly prefer non-prepaid TCV (which it will get to recognize over time) to deferred revenues (which it won’t) .
Can give pause to strategic acquirers. Anything that might cause the acquirer to need to start release pro forma financials has the potential to scare them off, particularly one with otherwise pristine financial statements. For example, having to explain why revenue from a recently acquired startup is shrinking year-over-year might do precisely that .
Can “inflate” revenues. Under ASC 606, multi-year, prepaid deals are seen as significant financing events, so — if I have this correct — revenue will exceed the cash received  from the customer as interest expense will be recorded and increase the amount of revenue. Some buyers, particularly PE ones, will see this as another form of cashless revenue and want to deflate your financials to account for it since they are not primarily concerned with GAAP financials, but are more cash-focused.
Will similarly inflate remaining performance obligation (RPO). SaaS companies are increasingly releasing a metric called RPO which I believe is supposed to be a more rigorous form of what one might call “remaining TCV (total contract value)” — i.e., whether prepaid or not, the value of remaining obligations undertaken in the company’s current set of contracts. If this is calculated on a GAAP basis, you’re going to have the same inflation issue as with revenues when multi-year, prepaid deals are involved. For example, I think a three-year 100-unit deal done with annual payments will show up as 200 units of RPO but the same deal done a prepaid basis will show up as 200-something (e.g., 210, 220) due to imputed interest.
Impede analysis of billings. If you want to go public or get acquired by a public company, financial analysts are going to focus on a metric called calculated billings  which is equal to revenue plus the change in deferred revenue for a given time period. For SaaS purist companies (i.e., those that do only annual contracts with one-year prepays), calculated billings is actually a pretty good measure of new sales. Multi-year prepays impede analysis of billings because deferred revenue ends up a mishmash of deals of varying lengths and is thus basically impossible to interpret . This could preclude an acquisition by a SaaS purist company .
More than anything, I think when you take these factors together, you can end up with complexity fatigue which ultimately takes you back to whether it’s a normal industry practice. If it were, people would just think, “that’s the complexity endemic in the space.” If it’s not, people think, “gosh, it’s just too darn hard to normalize this company to the ones in our portfolio  and my head hurts.”
Yes, there are a few very good reasons to do multi-year, prepaid deals , but overall, I’d say most investors and acquirers would prefer if you just raised a bit more capital and didn’t try to finance your growth using customer prepayments. In my experience, the norm in enterprise software is increasingly converging to three-year deals with annual payments which provide many of the advantages of multi-year deals without a lot of the added complexity .
# # #
 While 10% is indeed high, it makes the math easier for the example (i.e., the three-year cost is 331 vs. 300). In reality, I think 5-6% is more reasonable, though it’s always easier to reduce something than increase it in a negotiation.
 Especially if your competition primes them by saying — “those guys are in financial trouble, they need cash, so they’re going to ask you for a multi-year, prepaid deal. Mark my words!”
 Think: “I know the formula you’re using says ’18 months’ but I’m holding an invoice (or, if you wait 30 days, check) in my hand for more than the customer acquisition cost.” Or, “remember from b-school that payback periods are supposed to measure risk, no return, and to do so by measuring how long your money is on the table.” Or, “the problem with your formula is you’re producing a continuous result in a world where you actually only collect modulo 12 months — isn’t that a problem for a would-be ‘payback’ metric?”
 Renewal rate = 1 – churn rate
 That is, that a 79% three-year rate is ergo better than a one-year 90% renewal rate.
 Arguing that while the buyer will get to recognize the deferred revenue over time that the cash has already been collected, and ergo that the purchase price should be reduced by the cost of delivering that revenue, i.e., (COGS %) * (long-term deferred revenue).
 If the acquired company does a high percentage of multi-year, prepaid deals and you write off its deferred revenue, it will certainly reduce its apparent growth rate and possibly cause it to shrink on a year-over-year basis. What was “in the bag revenue” for the acquired company gets vaporized for the acquirer.
 Or our other subsidiaries, for a strategic acquirer.
 Known either as billings or calculated billings. I prefer the latter because it emphasizes that it’s not a metric that most companies publish, but one commonly derived by financial analysts.
 We are testing the limits of my accounting knowledge here, but I suppose if deferred revenue is split into current and long-term you might still be able to get a reasonable guestimate for new ARR sales by calculating billings based only on current, but I’m not sure that’s true and worry that the constant flow from long-term to current deferred revenue will impede that analysis.
 A purist SaaS company — and they do exist — would actually see two problems. First, potential year-over-year shrinkage due to the write-down discussed in footnote . Second, they’d face a dilemma in choosing between the risk associated with immediately transitioning the acquired company’s business to annual-only and the potential pollution of its otherwise pristine deferred revenue if they don’t.
 Minute 1:28 of the same video referenced in the prior link.
 Good reasons to do multi-year, prepaid deals include: (a) they are arguably a clever form of financing using customer money, (b) they tend to buy you a second chance if a customer fails in implementation (e.g., if you’ve failed 9 months into a one-year contract, odds are you won’t try again — with a three-year, prepay you might well), (c) they are usually a financing win/win for both vendor and customer as the discount offered exceeds the time value of money.
Happily, in the past several years startups are increasingly recognizing the value of strong sales enablement and sales productivity teams. So it’s no surprise that I hear a lot about high-growth companies building onboarding programs to enable successfully scaling their sales organizations and sustain their growth. What’s disappointing, however, is how little I hear about the hiring profiles of the people that we want to put into these programs.
Everyone loves to talk about onboarding, but everybody hates to talk about hiring profiles. It doesn’t make sense. It’s like talking about a machine — how it works and what it produces — without ever talking about what you feed into it. Obviously, when you step back and think about it, the success of any onboarding program is going to be a function of both the program and people you feed into it. So we are we so eager to talk about the former and so unwilling to talk about the latter?
Talking about the program is fairly easy. It’s a constructive exercise in building something that many folks have built before — so it’s about content structuring, best practice sharing, and the like. Talking about hiring profiles — i.e., the kind of people we want to feed into it — is harder because:
It’s constraining. “Well, an ideal new hire might look like X, but we’re not always going to find that. If that one profile was all I could hire, I could never build the sales team fast enough.”
It’s a matter of opinion. “Success around here comes in many shapes and sizes. There is not just one profile.”
It’s unscientific. “I can just tell who has the sales gene and who doesn’t. That’s the hardest thing to hire for. And I just know when they have it.”
It’s controversial. “Turns out none of my six first-line sales managers really agree on what it takes — e.g., we have an endless debate on whether domain-knowledge actually hurts or helps.”
It’s early days. “Frankly, we just don’t know what the key success criteria are, and we’re working off a pretty small sample.”
You have conflicting data. “Most of the ex-Oracle veterans we’ve hired have been fish out of water, but two of them did really well.”
There are invariably outliers. “Look at Joe, we’d never hire him today — he looks nothing like the proposed profile — but he’s one of our top people.”
That’s why most sales managers would probably prefer discussing revenue recognition rules to hiring profiles. “I’ll just hire great sales athletes and the rest will take care of itself.” But will it?
In fact, the nonsensicality of the fairly typical approach to building a startup sales force becomes most clear when viewed through the onboarding lens.
Imagine you’re the VP of sales enablement:
“Wait a minute. I suppose it’s OK if you want to let every sales manager hire to their own criteria because we’re small and don’t really know for sure what the formula is. But how am I supposed to build a training program that has a mix of people with completely different backgrounds:
Some have <5 years, some have 5-10 years, and some have 15+ years of enterprise sales experience?
Some know the domain cold and have sold in the category for years whereas others have never sold in our category before?
Some have experience selling platforms (which we do) but some have only sold applications?
Some are transactional closers, some are relationship builders, and some are challenger-type solution sellers?”
I understand that your company may have different sales roles (e.g., inside sales, enterprise sales)  and that you will have different hiring profiles per role. But you if you want to scale your sales force — and a big part of scaling is onboarding — then you’re going to need to recruit cohorts that are sufficiently homogeneous that you can actually build an effective training program. I’d argue there are many other great reasons to define and enforce hiring profiles , but the clearest and simplest one is: if you’re going to hire a completely heterogeneous group of sales folks, how in the heck are you going to train them?
# # #
 Though I’d argue that many startups over-diversify these roles too early. Concretely put, if you have less than 25 quota-carrying reps, you should have no more than two roles.
 Which can include conscious, deliberate experiments outside them.
I had the pleasure of working with Elay Cohen during my circa year at Salesforce.com and I reviewed SalesHood, his first book, over four years ago. We were early and happy customers of the SalesHood application at Host Analytics. I’m basically a big fan of Elay’s and what he does. With the average enterprise SaaS startup spending somewhere between 40% to 80%+ of revenue on sales, doesn’t it make sense to carve off some portion of that money into a Sales Enablement team, to make sure the rest is well spent? It sure does to me.
I was pleased to hear that Elay had written a second book, Enablement Mastery, and even more pleased to be invited to the book launch in San Francisco several weeks back. Here’s a photo of Cloudwords CEO Michael Meinhardt and me at the event.
I have to say I simply love salesops and sales productivity people. They’re uniformly smart, positive, results-oriented, and — unlikely many salespeople — process-oriented. A big part of the value of working with SalesHood, for a savvy customer, is to tap into the network of amazing sales enablement professionals Elay has built and whose stories are profiled in Enablement Mastery.
I read the book after the event and liked it. I would call it a holistic primer on sales enablement which, since it’s a relatively new and somewhat misunderstood discipline, is greatly in need in the market.
Elay’s a great story-teller so the book is littered with stories and examples, from his own considerable experience building the impressive Salesforce.com sales productivity team, to the many stories of his friends and colleagues profiled in the book.
Some of the more interesting questions Elay examines in Enablement Mastery include:
Why sales enablement?
Where to plug it organizationally? (With pros and cons of several choices.)
What to do in your first 90 days in a new sales enablement role?
What to look for when hiring sales enablement professionals?
How to get organizational (and ideally strong CEO) buy-in to the sales enablement program?
How sales enablement can work best with marketing? (Hint: there is often tension here.)
What is a holistic process map for the sales enablement function?
How to measure the sales enablement function? (And it better be more than instructor ratings on the bootcamp.)
How to enable front-line managers to be accountable for their role enabling and developing their teams? (Elay wrote a whole chapter on this topic.)
What core deliverables need to be produced by the marketing and sales productivity teams?
Elay, never one to forget to celebrate achievement and facilitate peer-level knowledge sharing, also offers tips on how to runs sales kickoffs and quota clubs.
Overall, I’d highly recommend Enablement Mastery as a quick read that provides a great, practical overview of an important subject. If you’re going to scale your startup and your sales force, sales enablement is going to be an important part of the equation.
Most salespeople are familiar with so-called BANT qualification: does the prospect have Budget, Authority, Need, and Timeframe in order to make a purchase? While Solution Selling purists dislike BANT (arguing that it’s great way to find existing deals that have been already rigged for the competition), most sales organizations today use BANT, or some form of it, for lead qualification and scoring. Typically, in an enterprise SaaS company, a sales development rep (SDR) will not pass an opportunity to sales unless some form of BANT qualification has been performed.
The purpose of this post is to drill into how you should do price (i.e., budget) qualification, which I believe is far more subtle than it appears:
People can sometimes spend far more than they are spending (and/or imagine they can spend) once they realize the total cost of owning their current system and/or the total benefits of owning a superior one. Great salespeople, by the way, help them do precisely that.
SDRs barking average configuration prices or, worse yet, price list items (e.g., “enterprise edition has a base fee of $100K/year plus $2.5K per admin user/year”) can either scare away or anchor bias prospects to given price points.
For example, let’s say that your company sells a high-end planning/budgeting system (average cost $250K/year) and you find a prospect who is spending $50K/year for their existing planning/budgeting system, which isn’t delivering very good results.
It’s inflexible and doesn’t allow the VP of Finance to make the reports the CFO repeatedly requests.
It’s arcane and requires highly paid consultants to come several weeks/quarter in order to make changes and performance maintenance on the basic setup.
It’s slow, so users are frustrated trying to load their budgets, and instead mail them to Finance via spreadsheets, asking Finance to do the loads, creating a significant amount of incremental work for the finance team.
How are we supposed to price qualify this opportunity? Ask the prospect:
How much they want to spend? Answer: as little as possible.
How much budget they have? Answer: $50K.
How much they are paying for the existing system? Answer: $50K.
As an SDR, are you supposed to pass this ostensibly $50K opportunity to a salesrep who normally does $250K deals ? If you’re smart, you know they have the money — those consultants in problem 2 might run $100K/year, they probably have to hire an extra analyst or two to solve problem 3 at $80K/year each, and problem 1 — which is career threatening for the VP of Finance — is, as Mastercard likes to say, “priceless.”
What’s more, what do you say if the prospect tries to price qualify you?
You know, we don’t have a lot of money for this project so I need to know the typical price of your system?
What do you say then? $50K and jeopardize the deal downstream when the salesrep proposes $250K? $250K and possibly scare them off at the start — even though you know the total cost of their existing system might be bigger than that today?
I’ve always liked Tiffany’s as a reference point for this. As you may know, most Tiffany’s stores are divided in two. On one side — typically the smaller, more crowded one — you can buy jewelry from $200 to $2,000. Then there’s the other side, where the security guard hangs out, that’s bigger and less crowded, and where the jewelry costs from $10K to $200K+.
The thing I find funny about Tiffany’s is that somehow, magically, most people seem to figure out what side they belong on. And when they don’t, the staff don’t ask you how much money you have — they tell you broad price ranges on each side of the store.
The keywords, in an enterprise software context, being “broad” and “ranges.” So, in our scenario, I think the best initial answer to the pricing question is:
That’s a hard question to answer at this point. Each customer and every situation is different. Our systems scale across a broad range of needs and, as a result, prices typically range from $50K on the low end to $500K+ on the high-end. Based upon what I know about your situation, I’d recommend that you have a conversation with one of our account managers so we can better understand your challenges, our ability to meet them, and establish a clearer price point for so doing.
Your goal is to neither scare them off nor anchor bias them to a lower price (“sure we can do that for $50K”) that later results in disappointment or, worse yet, a feeling your company can’t be trusted.
Finally, the great part about the Tiffany analogy is that most enterprise software companies actually do have both sides of the store — corporate sales and enterprise sales, often each selling different and appropriately priced editions of the software. While few SaaS companies actually segment between the two based on deal size, they typically use other variables that are intended to act as direct proxies for it.
# # #
 The answer in most SDR models would be “yes, just pass it” so the hard part isn’t the decision to pass it, but how to do so without anchor biasing the prospect to a $50K price. (“Whoa, the SDR told me you could do this for $50K; he asked how much budget I had and I told him precisely that.”)
I’m Dave Kellogg, technology executive, investor, independent director, adviser, and blogger. I’m also a hiker, oenophile, and fly fisher.
From 2012 to 2018, I was CEO of cloud enterprise performance management vendor Host Analytics, where we quintupled ARR while halving customer acquisition costs in a highly competitive market, ultimately selling the company in a private equity transaction.
Previously, I was SVP/GM of Service Cloud at Salesforce and CEO at NoSQL database provider MarkLogic. Before that, I was CMO at Business Objects for nearly a decade as we grew from $30M to over $1B. I started my career in technical and product marketing positions at Ingres and Versant.
I love disruption, startups, and Silicon Valley and have had the pleasure of working in varied capacities with companies including ClearedIn, FloQast, GainSight, Lecida, MongoDB, Recorded Future, Tableau and TopOPPs. I currently sit on the boards of Alation (data catalogs) and Nuxeo (content management) and previously sat on the boards of agtech leader Granular (acquired by DuPont for $300M) and big data leader Aster Data (acquired by Teradata for $325M).
I periodically speak to strategy and entrepreneurship classes at the Haas School of Business (UC Berkeley) and Hautes Études Commerciales de Paris (HEC).