←back to thread

No Calls

(keygen.sh)
1603 points ezekg | 1 comments | | HN request time: 0s | 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 #
1. xp84 ◴[] No.42733837[source]
Yes. There’s nothing more obnoxious to me than products like Figma where my company has a limited number of full licenses. They are super stingy with what my account type can do, so the 2 times per year when I need to get involved inside a Figma document or even a FigJam board I have to go begging for someone else’s license, but it would be way too costly to pay as much per seat for the entire company as we pay for our designers, for whom that’s obviously a core tool.