Stop Trying to Schedule a Call with Me
44 comments
·January 11, 2025SteveVeilStream
portaouflop
More power to you but in my experience
- people don’t read your documentation - if they find one edge-case that is not covered by your product they concentrate all their energy on it even though the competitor product doesn’t even work for the happy path (but ofc they won’t learn that until too late) - you will have a person on the free tier who is not able to the simplest programming take up all the time of your technical support if you let them
The rest (disclose usage of AI, offer multiple newsletters (imo unnecessary work), be upfront if it’s not a good fit) is very sensible and works in my experience.
The first three will break your product - but maybe I’m just cynical and was holding it wrong all this time
edit: I’m assuming you want to build some kind of investor fuelled unicorn - your approach probably will work for a single person slow but steady growth while you have other side income
efitz
You need docs. Most users won’t read them. Do a good job anyway because they can save you a TON of support costs if they’re good, even for the few people who do read them. The cost of writing docs is easily offset by even a modest reduction in human support cost, unless you just half-ass your support with LLMs and FAQs and chat with overseas wage slaves.
ALSO: your UX needs to warn people about sharp edges and one-way doors, BEFORE your user commits to an action they might regret. These are not incompatible.
johnnyanmac
If nothing else, the "smart cows" will read the docs and may even help out on support forums when some of the user base doesn't and decides to complain. Docs are good for everyone and will save time internally and externally.
>your UX needs to warn people about sharp edges and one-way doors, BEFORE your user commits to an action they might regret. These are not incompatible.
Assuming trump doesn't nix it, the recent FTC ruling should fix this by itself. it should be as easy to unsubscribe as it is to subscribe.
freefaler
They also are great for the support team, to "educate" where they can find additional info and for linking as help links if the interface needs this.
rkagerer
Good advice.
I created and sold software (and services) for over a decade, and could never have lived with myself if I'd treated customers the way the original article describes.
johnnyanmac
sadly, they do it because it works, and (not trying to be too offensive): lotta people are dumb. If you're confused, a nice "team mate" will be more comforting than a cold hard doc and web form. Even if they are upcharging you on a bunch of stuff you will never use. They call multiple times because some people genuinely forget and appreciate the reminder.
I'm sure you knew all this better than me, but just want to elaborate for anyone who genuinely don't understands who falls for this.
Scotrix
This story is for me a real painful death I have experienced way too many times, absolutely nuts.
But then you find an open source solution which is in general better and can do everything you want (simply tested already with just a docker compose up) but for deployment you get hit hard by compliance who just checks the SOC2 certifications and wants a in-depth due diligence of the code since everyone in the world can theoretically change it. Then your manager asks how it can be so good if it's for free and open source. And of course, last but not least, your overloaded team in general not happy to support just another unpredictable piece of software...
So it's the question to rather burn money and nerves with an awful SaaS offering and their endless and useless sales cycles and terrible and super expensive vendor-lock-ins or burn some money and nerves by utilising and running open source inhouse...
So typically I prefer to chose for the open source option and especially if the SaaS option isn't allowing me easy and fast self-onboarding, meaningful testing periods and a predictable and transparent pricing.
And then, if it get's widely adopted, I allocate some budget to support the authors and/or get some support plan (for more complex open source software) in place even though you most likely never need it...
jwr
What is amazing for me is that these sales tactics actually work, because many people want to be sold to in this way.
Do the direct approach with no bullsh*t, instant demo, meaningful trial period, easy onboarding, etc and lose those customers that expect the usual sales ride.
Source: I do the direct approach.
tptacek
Right; the thing here is: the author obviously knows the game (because they wink knowingly at it repeatedly). Given that: why are they ever getting on the phone with a sales engineer? You can just delete the emails.
grepLeigh
Maybe I'm the outlier here, but 15 minutes to chat with a human about my use case and pricing is way more efficient than donking around in docs/trial product.
The only product I really want to punch in credit card info and GO is commodity software (e.g. AWS EC2 or a domain registration service.
I think wires sometimes get crossed in pricing/sales models, where an enterprise product gets priced like commodity software ... but that's usually a sign the company is immature. There shouldn't be a sales team for software that costs 2-3 figures. Software costing 5-6+ figures absolutely requires people in the sales/onboarding process, because a big part of what I'm paying for is support.
johnnyanmac
[delayed]
scarab92
Maybe I’m not asking the right questions, but I consistently find that I get “Yes” answers in these calls, that turn out to actually be “No” in practice.
I think the problem is that we rarely want to know “can you meet this use case”, but rather “how well can you meet this use case”, and that’s hard to assess without putting your hands on the software.
ghaff
I don't really disagree. The problem is outreach when you're clearly mostly researching something whether to do with computers or something else. One travel company is particular was pretty aggressively reaching out because I downloaded a couple brochures.
DriftRegion
I've had a couple of experiences in the past month where I do respond to the enthusiastic sales engineer's check-in with a genuine product question, only to receive an immediate, lengthy, and subtly wrong LLM generated response. It feels gross.
jlund-molfese
Two comically bad lines in an AI-generated spam email I recently received:
"Saw on LinkedIn that you spoke Spanish. I've heard that the way "¡Qué chévere!" brings such energy and brightness to a conversation is uniquely charming. Have you had a chance to practice it recently?"
"Develop a compliance automation tool that adapitates to changing regulations, reducing overhead costs while ensuring secure and efficient investment programs."
No human would ever see my "limited working proficiency" of Spanish on LinkedIn and say something like the first line! And the second? "Adapitates" is not a real word, it's a hallucination. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Sales isn't the problem, and most people are tolerant of some level of sales. I've gotten unpersonalized cold outreach from a data replication company that actually made me interested in the product, because it was short, to the point, and (as far as spam emails can be), authentic.
Aloha
Maybe adapitates should be a word! ;-)
AznHisoka
Was the main reason you were interested in it because you actually could see yourself using the product? Rather than because it was short and to the point?
noman-land
Please consider responding and telling them how you feel and providing feedback in whatever feedback forms that accompany the ticket.
Every company on Earth is exploring this tech and if we don't give them strong signals when they fuck it up we are just dooming our future selves to this garbage.
robocat
> providing feedback > ticket
Where do you work that this is an effective strategy?
In my experience telling a vendor something is broken wastes my time and has no effect on the vendor. I don't know whether sales don't care or sales can't make dev changes. The only exception is when I can contact the devs and I know the devs have a history of fixing problems.
david38
Anyone who doesn’t have their head up their ass would realize this.
Better to not tell them and just boycott them.
Those companies who don’t push the boundaries on how bad they can treat their (potential) customers deserve to be rewarded.
tptacek
You have to pay extra to get 12- (or 4-) hour support SLAs and SSO access because if you didn't, the entry level of the product would cost integer multiples more. The people that want those product features --- regardless of how much they cost (support: a fortune; a SOC-2 report: zero) --- subsidize the people who don't. If it helps: just look at the "bells-and-whistles" package with SSO and an SLA as the true price of the product. Nothing in technology is really cost-based pricing to begin with.
jwr
This. And to expand on the above: few people consider how much it actually costs to provide 12- or 4- hour support with a strict SLA. This pretty much means that the business needs to bear the full loaded cost of at least one additional employee. Now go divide that fully loaded cost (take the salary and multiply it by 2x, roughly, and I'm not quoting any numbers here to avoid stupid discussions about "but it costs less to hire a person in my area") by the number of customers that require these SLAs and see how much this needs to cost.
tptacek
Support is an example of an "enterprise" feature with a high cost basis. SSO is an example of an "enterprise" feature with almost zero cost basis. But in both cases, the cost is a sideshow. The real driver for the pricing of these features is market segmentation: the customers with high expectations of support, or a requirement to have SSO, strongly tend to be less price sensitive than the rest of customers. The fundamental goal of product pricing is to find ways to charge price-insensitive customers more than price-sensitive customers.
Like, yes, you'd lose money offering 4-hour-SLA support to customers paying the entry-level price. But you could make that decision, and have part of your business model be subsidizing those customers. It depends on everything else in your model; how you acquire customers, what their lifetime value is, &c.
efitz
This article rings so true.
There are lots of ways to make a lot of money selling a service. The best way IMO is to build a service that is easy to integrate and customize, delights your customers, and has a simple pricing model. There should be no surprises in any of these traits. Customers will be loyal because you’ve made their lives easier - you didn’t just “solve their problem”, you solved their problem in a way that doesn’t require them to change anything else about their business to adapt to you.
The other way involves minimum viable products, basic features only available at top tier pricing, only have a single way to integrate and no meaningful customization. You make your product a black box that your customers can only escape with Herculean effort and lots of begging on many time consuming phone calls.
It seems like startup culture somehow funnels everyone into the second category.
tptacek
If you're not deeply steeped in startup business model lore, the search query you want here is [product led growth], the very-fashionable trend of go-to-market and business models that admit your preferred way of marketing products. Tailscale, Slack, Notion, and Dropbox (at least, early Dropbox) are all big examples of PLG startups.
This model works especially well when your early (pre-series-B go-to-market) is not big companies (say, 1000+ employees).
Aeolun
> I start to wonder if I should’ve just reverse-engineered your tool myself.
Ever since I started taking this advice instead of going through a sales process (I really only need this inflicted on me a single time in my life), I have been a lot happier. We also stick the counter at around $50k saved per year for applications that are essentially fancy crud forms.
The best part is it bypasses all the complicance requirements, since if it’s written in your company it can’t possibly be bad.
nraynaud
10 years after I left a company, new relic still calls me twice a year in the hope of selling something there.
bityard
Oof. If I never have to endure another hard-selling enterprise vendor salescritter, it'll be too soon. Mat has really nailed the agony of the experience here.
randall
pretty accurate. sales teams are kind of the worst, but buying from the company founders are fun.
i wonder if there’s a world coming where the oss and the company become the same person.
thexumaker
This is why I stopped working at companies that build dev tools. Building sales/marketing tools because they love having anything built for them lol
mhx1138
The sales person does not have any incentive for that. They need their name to be associated with the purchase.
Against all of the advice in the world, I'm trying to set things up to avoid basically everything described in the article. It's tricky because the truth is that a lot of the tactics work and that is why companies implement them. A lot of investors also consider that process to be best-in-class and look for it as a sign of maturity.
The counter approach is: - Make complete information available as transparently as possible and don't gate it. - Be forthcoming about weaknesses. Don't force prospects and customers to find them. - Ensure that when a prospect or customer does want to talk to someone, they immediately reach someone who can handle the problem or answer the question (no need for escalations.) - Never have an AI agent call someone unless the customer specifically requests that and be sure that all AI agents immediately disclose that they are AI. - Offer flexible e-mail list subscription options (monthly, quarterly, annually, only release notes, etc.) - If the product is not a fit, try to offer something useful anyway such as a suggestion of another product that might be a better match for their needs.
Value based pricing is one of the reasons why a lot of companies end up in these situations. Rather than setting a standard price, the company does a detailed investigation of the customer to try to find out how much value they will gain from using the product and then they set the price based on that determination. Although it maximizes revenue in theory, it is slow and invasive.