←back to thread

No Calls

(keygen.sh)
1603 points ezekg | 2 comments | | HN request time: 0.426s | source
Show context
freedomben ◴[] No.42728008[source]
I'm a CTO who makes purchasing decisions. There are numerous products I likely would have purchased, but I either find a substitute or just go without because I won't play the stupid "let's get on a call" game.

If your website doesn't give me enough information to:

1. Know enough about your product to know that it will (generally speaking) meet my needs/requirements.

2. Know that the pricing is within the ballpark of reasonable given what your product does.

Then I will move on (unless I'm really desparate, which I assure you is rarely the case). I've rolled-my-own solution more than once as well when there were no other good competitors.

That's not to say that calls never work or don't have a place, because they definitely do. The key to using the call successfully (with me at least) is to use the call to get into true details about my needs, after I know that you're at least in the ballpark. Additionally, the call should be done efficiently. We don't need a 15 minute introduction and overview about you. We don't need a bunch of small talk about weather or sports. 2 minutes of that is ok, or when waiting for additional people to join the call, but beyond that I have things to do.

I know what my needs are. I understand you need some context on my company and needs in order to push useful information forward, and I also understand that many potential customers will not take the lead in asking questions and providing that context, but the sooner you take the temperature and adjust, the better. Also, you can get pretty far as a salesperson if you just spend 5 minutes looking at our website before the call! Then you don't have to ask basic questions about what we do. If you're willing to invest in the time to get on a call, then it's worth a few minutes of time before-hand to look at our website.

replies(30): >>42728440 #>>42729968 #>>42730113 #>>42730304 #>>42730478 #>>42730488 #>>42731122 #>>42731205 #>>42731562 #>>42731625 #>>42731654 #>>42731749 #>>42731845 #>>42732395 #>>42733222 #>>42733534 #>>42733736 #>>42733894 #>>42734213 #>>42735020 #>>42735376 #>>42736599 #>>42736685 #>>42738466 #>>42738777 #>>42740067 #>>42740099 #>>42740345 #>>42754672 #>>42786202 #
freedomben ◴[] No.42728440[source]
Oh I might add another huge thing: Have a way to justify/explain your pricing and how you came to that number. When you have to "learn about my company" in order to give me pricing info, I know you're just making the price up based on what you think I can pay. That's going to backfire on you because after you send me pricing, I'm going to ask you how you arrived at those numbers. Is it by vCPU? by vRAM? by number of instances? by number of API calls per month? by number of employees? by number of "seats"? If you don't have some objective way of determining the price you want to charge me, you're going to feel really stupid and embarrassed when I drill into the details.
replies(11): >>42729495 #>>42730125 #>>42732046 #>>42732559 #>>42732597 #>>42734855 #>>42742357 #>>42742452 #>>42752697 #>>42757640 #>>42786151 #
JoshTko ◴[] No.42729495[source]
I'm confused by this, why would sales team know in detail the vRAM contribution to sales price, and how is it relevant to your purchase decision? I've never heard of enterprise/SAAS pricing to be based primarily using cost plus pricing.
replies(2): >>42729762 #>>42730300 #
freedomben ◴[] No.42730300[source]
Some products (especially infrastructure) still bill based on (outdated and often irrelevant) core counts and memory count. A few years ago I talked to a seller of a PDF library/toolkit who wanted to know my production and staging core count before they would quote me a price. Explaining to them that it runs in a serverless function on-demand was fun, especially because they would say things like, "well, what's your average?" I would often reply and say my average is defined by a function where you take the number of active users (which itself is highly elastic) and calculate for average runtime at 4 cores per user for approximately 50 ms per page (which page count is highly elastic too) and sum to get "average core use per month". Needless to say it was like pushing a rope.

More common now with SaaS seems to be employee count or some other poor proxy measurement for usage. I love actual usage based billing, but some of the proxies people pick are ridiculous. Like, if I have 5 seats or 500 employees, but 2 users spend 6 hours a day in the software and then 10 others maybe look at it once a quarter, paying the same for those is absurd and is not usage-based billing at all.

replies(4): >>42731262 #>>42731526 #>>42733648 #>>42733837 #
ricardobeat ◴[] No.42731262[source]
Usage-based pricing makes sense when you’re buying infrastructure products. For (most?) other things, the price is based on value, not material cost.

The cost of that PDF generation might as well round up to zero, but developing the tech cost multiple man-years of work. How do you price that “objectively” unless you’re given a breakdown of the company R&D expenses, operation costs and margins. That is not a reasonable request. Either you’re happy paying $X because it solves your problem and brings equivalent value to your business, or you’re not.

I do agree seat-based pricing is often ridiculous, but that’s a problem for the free market to solve. Alternatives usually pop up given enough demand.

replies(3): >>42731557 #>>42731847 #>>42732456 #
eastbound ◴[] No.42731847[source]
Salespeople often misunderstand value-based pricing. If a product costing V dollars is made of N parts, then each part provider claims their value is V, so they deserve V-$1.

A PDF conversion may be required for the end-users, but it doesn’t make the entirety of the value of the product. It just doubles it, as well as the N features before that. But although each feature doubles the value of the product, the order of features doesn’t matter; A PDF export might have been added as the second feature, but the 10th feature still doubled it.

replies(1): >>42732295 #
1. WJW ◴[] No.42732295[source]
It's uncanny how accurately this maps to departments claiming they contribute V-$1 of the total profits. Sales argues they bring all the money, engineering argues sales would have nothing to sell without the products being made, platform claims no products would run without the infra they provide, support claims everything would grind to a halt without their constant babysitting of the users, etc etc. Only HR and Facilities don't claim to be directly responsible for any revenue, but that's only because everyone needs them anyway.
replies(1): >>42732889 #
2. stavros ◴[] No.42732889[source]
Well, it's all true. Without one of these, there would be no V.