Can relate, I've been in a similar boat running a small B2B Saas over the last 2 years. It does get easier over time.
I've learnt a few tricks for managing early stage pain points.
- You need to develop a polite but curt tone of voice for customer support.
- Once your core product is built, its worthwhile spending some time automating the heck out of everything. This will save a TON of time in the near future.
- Invest in good docs, even if you're not running a api saas. Good docs + consistent ux + rock solid support will solve most of your support issues.
I think a lot of literature around running a online biz has been boiled down to rather basic advice and its hard to find anything solid in this area. I've been running a small blog where I document these issues(operational.co) if anyone wants to check it out.
>You need to develop a polite but curt tone of voice for customer support.
And very focused responses in terms of action items.
You might think of 3 things to say, check, but sadly 90% of the people you respond to with a list will behave like they read just one of them. Sadly this also leads to dragging things out for everyone who can handle more than one thing at a time :(
I’m observing this for many years and it feels like there are two types of people. Those who perceive lists as a whole and those who list.shuffle().pop(). Try asking your colleagues/etc three semi-related questions in one message and you’ll get only a partial answer in a significant number of cases. When confronted (constructively, much later) they usually get evasive and can’t explain. I could theorize it’s a learned behavior to avoid threaded pedantry or something, but my messages aren’t even long and other people share my frustration too (we communicate 10x faster and clearer between us). I’d write it off to attention capacity issues, but these people often aren’t even busy at all.
I worked at a tiny startup with a single customer support plus sales person—she had an array of fake names that she'd use for different purposes (billing, sales, tech support, etc) to try to simulate a larger org. She actually kept them all straight and apparently it worked.
I think in the era of LLMs good docs/FAQ are of an even greater value.
You can write a support bot that sends a user's question + docs/FAQ to an LLM to automatically deal with the basic questions and only involve a human in the loop once a question goes beyond what's in the docs.
Even if users don't read them of their own volition, they're still valuable. You can copy/paste responses from them, link to them, or hell just use them to remember the answer yourself later without having to confirm it or even think about it.
Both xyproto and Gustomaximus have solid examples.
Here's more:
- Be direct,
Hi, the xyz feature is available on the PRO plan. You can upgrade to the PRO plan at app.saas.com/billing
- Be brutal,
Hi xyz, your card couldn't be charged for your Saas subscription, and hence your subscription has been deactivated. To reactivate, enter your card details app app.saas.com/billing
- Be honest,
Hello xyz, thanks for the feature request. We'll put it in our wish list but can't guarantee it will make the cut.
- Be generous,
Hey xyz, thanks for pointing that out. We have identified that as a bug and have pushed a fix for it. In the meanwhile, I've extended your trial by 7 days, on the house.
Couple of other tips:
- Dumb down your reply as much as possible. If you can't, throw your reply through chatgpt and make it dumb down.
- Unless a support issue is very basic, reply after a few minutes if you're near your computer. Usually users figure out things on their own if given some time.
- But don't allow issues to go stale. To really wow customer service, reply as humanely quick as possible, especially for existing customers.
- Make your support timelines clear somewhere in your product, eg: Our support will respond within max 48 hours, but most responses take 2-3 hours.
- Make your terms and privacy policy pages clear. People do read this. getharvest.com is a gold standard in this area.
Thanks for reaching out. The issue you’ve described seems to be on your end. Please check your settings or consult our docs for further guidance. If the problem persists, feel free to get in touch.
From the sound of it, the politeness is the shallow politeness that you can easily get with ChatGPT. The curtness is defending from the users expecting too much, which can include delaying handling issues before properly checking if they're real. I experienced this with Vercel and it probably makes economic sense for them. (BTW I really should cancel my Vercel account but haven't decided to take the time to migrate yet.) https://x.com/search?q=vercel%20benjaminatkin_&src=typed_que...
The reason it can be framed as curtness is because they're being curt about the expectations, and the real expectations are pretty low. "Sure, I can delay really addressing the issue for a couple weeks. You're only paying me 40 bucks a month, why would you expect more? The goal of responding within two days is just for a canned response." See, they were curt and didn't let me demand something more than I deserved, like being able to use the product I'm paying for in the next several days!
> - Once your core product is built, its worthwhile spending some time automating the heck out of everything. This will save a TON of time in the near future.
Interesting. Anything you've automated successfully that you can share? I've heard so many times that you should hold off on automating too early because constant pivoting and refining can end up making you spend more time fixing the automation than actually doing the work itself, so I kinda paused on it. I can see how it would make a big impact on my marketing outreach, which I'm doing manually right now with not much success.
Spending some time to learn technical writing (if you want to bootstrap a saas) is worth its weight in gold (same with marketing, business admin, accounting).
Ive had tremendous success submitting files to AI and just having it produce a structured readme.md for the logic within the code, I'll do a thing where I say Give me a readme, include description of functions, logic, how its invoked, dependencies, monitoring and give me a mermaid and swim diagram of the workflow.
Its great.
Another thing I do with an AI helper is when I have it write out a function for me I have it write out the descriptor that can go in the readme for that function. I also have it write a header with version description path etc.
It was an experiment which started with the goal is to have all the code for a simple project with its associated readme functions loaded into a textai workflow and postgres DB and I can dynamically call the readme functions for everything by having a bot yank all the MD table for all the functions and just put together a real-time readme. As I add txtAI workflow scripts, they put their MDs into the DB, I try having it spit a JSON of its MD to a mongo?
The point is playing with ways to have the system self document as I/it develops.
Because one of the ways I have been using Claude to learn is through a F-ton of iterating on an initial thought and bird-walking through implementing a tool wrapped around it.
This way, as I iterate through many many version of a concept or script/function/api/crawler - it keeps a reminder readme for when I want to know what the heck was I thinking (I have had super awesome moments of brilliance, and then after a sleep or lengthy distraction - totally loose the Mode and have no idea what I was doing, or how I came up with BrilliantIdea(TM)
EDIT: One thing I attempted was to have claude keep a running artifact for a readme while I worked out a problem - but that didnt work so well. Also, as it hallucinates, one of the first indicators that its losing context is that I keep a header section on artifacts it makes and a version and description ad path for the artifact...
when iterating and the header gets stripped in the response, the bot is taking a turn...
Sometimes ask it to spit out the full context and its understandings in a manner I can use to re-prompt itself for best efficiency, and it gives a nice summary of the concept I am thinking through, and I use that with vary degrees of satifying results.
One suggestion is simply increase the price. Price is strongly correlated with quality of customer. Price also acts as signaling that this is a tool for professionals who make actual money and so shouldn't be bothered coughing up something trivial like $100 for a subscription. You end up making more with far less customer support.
Raising prices works wonders when a product is both underpriced and hard to replace.
It can backfire when the new price point bumps it into a different category of decision making, though. For many, a $20/month product is an easy decision but $100/month price tag bumps it to a point where it becomes a more complicated decision making process. If you're not careful you can easily raise prices so much that people decide to jump to a more full-featured competitor product.
Projects like this one that are personal/side projects have an additional risk of raising prices: If the product becomes expensive, many people are going to notice that it appears to be highly profitable while also being within the realm of what a single person or small team can produce. Competition starts appearing quickly and you're back to cutting prices to stay relevant.
Finally, higher prices come with higher expectations from your customers. Whereas previously they might shrug off a slow response to a customer support request at $20/month, their $100/month service might lead them to expect more customer support, not less.
There are several indie SaaS companies that get posted on HN from time to time that take the opposite approach: They offer a low price but they're up front about what to expect. They don't try to pretend that you're getting world-class reliability, uptime, or support, but they do commit to offering a good service at a fair price. They could raise prices to match competitors, but now they're playing a very different game with very different expectations.
I agree with most of what you said, but there's significant nuance to this piece:
> Finally, higher prices come with higher expectations from your customers. Whereas previously they might shrug off a slow response to a customer support request at $20/month, their $100/month service might lead them to expect more customer support, not less.
This is potentially true, but there's other effects here too:
- When I was doing software and hardware consulting work, the people who paid the most were also the happiest customers. It felt paradoxical for a while until I really let it sink in and stew. Most of the high paying customers would just kind of... take my work products, say "yup, this meets the requirements we agreed to", and run with it. The ones who were paying the least were the most likely to pull the classic "well... is what we agreed to but... maybe you could move that button over to the other side and I've got this other feature idea that we didn't talk about, oh and I don't like how this works... it might be what we agreed to but it's not how it worked in my mind..."
- It sounds like OPs customers took that to the extreme with "customers" who hadn't paid anything at all yet being demanding.
- By going up-market, you can lose customers for sure but it might be worth it anyway. Given the support burden it sounds like 1/5 of the customers at 5x price would be a net win. Especially if it tracks my experience consulting where the remaining high paying customers are happier about your product in general. If you still maintain the same per-customer support burden or even have it climb some it could end up being less work overall.
Or just give yourself permission to not reply to people. Make a big visible unsubscribe button and relax knowing that anyone can just quit if they don't like it.
I find it hard to believe that this is true. For 100$ a month I expect a far more polished product than for 20$, where I can look over a lot of missing features.
If features don't work as advertised, I will absolutely make no distinction between a 500$ or 1$ product, and will demand a fix. But I will more likely have more patient if the service is cheap, before migrating away.
And then, if your customers are businesses, do you think the employees really care how much the product costs? No.
>For 100$ a month I expect a far more polished product than for 20$
I hate to put you on blast but this is exactly why people charge $100/mo instead of $20/mo. They do not want the customers who feel (sorry for the term) "entitled" to a heroic level of features, support, polish, etc. They want people who have a hair-on-fire emergency that is so awful that they'd gladly pay $1000/mo for it, and are thankful that your software - klunky as it is - is giving them $900/mo of free value.
Having run my own tourism business (so dealing with consumers directly, rather than b2b), and having spoken to many other business owners, this is counterintuitively true.
My worst customers were the ones that ask for discounts, or are otherwise looking for a deal. My theory is that people that happily fork out for an expensive product have already seen the value.
There are exceptions, but a lot of business owners see the same pattern.
We’ve also seen customer support inquiries, and in general quality of our customers, rise with an increase in price.
It doesn’t make sense as an end consumer, but B2B lens it makes sense.
If a business can afford the higher price tag, they most likely would rather have a hands off approach for the problem they’re trying to solve (in a service based business)
Many of our mid and lower tier customers want everything drawn out and explained, and give feedback at every step. Our higher tier customers pay faster, request minimal input (outside of times we ask for it), and generally much easier to work with
It's about creating a barrier to exclude unwanted individuals, similar to a gated community with homes priced higher than the average worker's budget, for instance.
Perhaps, but what's your idea of polish? For many developers, it's a shiny interface. Business users have much different metrics. Developers may get excited over "productivity"; business users are more focused on ROI (ie, quantifiable savings or profit)
The customer support efforts when you don't feel like it, being ghosted after helping a customer, the random or fraud disputes.
It's really tricky at that stage between hiring help and having the time/motivation to maintain those very non-tech parts while trying to continue doing other core parts of the side project / startup.
The first sale feels great, as does first showing the prototype.
By comparison, extra $100 MRR milestones don't feel so great, nor does dealing with customers/disputes eventually (it's a lot of negativity in general - pleased customers just leave reviews occasionally, negative ones email you). And a down negative month or two always feels like a stabbing and like it's all over.
Really don't know how to avoid this. Scaling quickly? Via investment in most cases? Maybe.
> The customer support efforts when you don't feel like it, being ghosted after helping a customer, the random or fraud disputes.
These three challenges + context-switching between marketing and product are really tough at the early stage.
I've found that growing a business from 0-1 is very formulaic - not easy but the roadmap is clear. Scaling one is much harder, especially without outside capital. There's a huge gulf between earning enough to replace your salary vs. hiring good people to take over lower-level tasks early on. And marketing usually ends up being too critical to outsource at first.
At least with digital products, customer disputes can always be settled with refunds, even when the claim is dubious. Eat the loss and move on. Physical product disputes really sting when you're out the cost of inventory + labor.
I wonder if there's often a mismatch between what one thinks a business is going to be like, and what a business is actually like.
One of the things that keeps me away from doing stuff like this is that I _hate_ every part that isn't the engineering part, and the engineering part is a minority share of what it takes to run a business.
We know the answer to this even before modern tech businesses existed: running a business is a very different experience from what people expect. This is exacerbated with certain experiences that create worldviews which are closer to the opposite of running a business.
This is why startup people straight out of school are often unencumbered with ideas that impact their mission. If you go into a large organization, you are exposed to a reality that can distort your perspective. It's a myth that people can't move between large and small organizations, but the differentiator is their awareness of and desire to embrace the current circumstances. Many end up preferring the luxury and ease of large organizations and fail because they don't make the switch. Many startup people don't make the move in the other direction (even if they are exceedingly successful and it might be practical move.)
Similarly, a desire to only focus on engineering is something you feel will inhibit your ability to run a business. Over time you might be able to discover ways to reduce your hate for the other work. People here love to prescribe advice for situations like this, but it's really hard to give good advice without knowing a lot more about you.
And if you get a partner, they will insist that the part that is engineering is even smaller than it objectively should be and end up leaving you with a minority position in the product you invented.
Usually if something isn't working it becomes a bottleneck so a lot gets built up behind it. Once the 'dam breaks' so to speak you're playing catch up plus you probably don't want to think about the problem anymore. This is also a reason things don't get documented.
Me too but I only ever do this unintentionally, and it usually corresponds with a delay in the reply from support coming back to me. (Ie I’m now focused on other things or have solved the problem a different way).
Whenever I’m conscious enough of it I do try to thank people - trying to remember how hard it must be on the other end!
A ticket system I've worked with in the past had an "autoclose" state where you could set the ticket to automatically close after a set date if no reply comes in until then.
If a reply comes with the info that it worked, I get a smile and close the ticket. If not, I never see the ticket again, no hard feelings.
Some advice: If you're going to monetize a side project, and you do it in a way where you're providing direct support, be sure the customer base it targets are people you actually want to deal with. Whatever the niche, imagine the worst people you've encountered on it, and be sure you want to use your spare time talking to them. Otherwise, the juice is likely not worth the squeeze.
That's good advice. Unfortunately though I think the nature of support is that on average it selects for the more difficult people in your customer base, for the same reason that doctors spend a lot of their time with hypochondriacs (despite hypochondriacs making up a small percentage of the population).
Something that helps to offset this psychologically, and is also a good thing to do anyway, is to proactively reach out more frequently to all your users. It can be the case that 95% of your users are happily chugging along, while 5% are unhappy and complaining frequently for whatever reason. If you rarely hear from that 95%, it can start to irrationally feel like no one is happy with your product, since that's the message coming from most of your support interactions.
I guess the old 80/20 Rule or Pareto Principle somewhat applies to the support distribution for many products. That is, 80% of the support resources are taken up by 20% of the clients. (incredibly-vaguely-speaking, naturally)
The variable is "20% of what type of client?". 20% of Taylor Swift concert attendees, or 20% of assembly coders? Each comes with its own unique challenges!
How do you ensure this? Are you suggesting more analysis pre-building the product, or doing things like increasing the price until you've effectively filtered out enough of the people you don't "want to deal with", assuming that works.
I'm sure there are good and bad people in all walks of life. But, yes, people in some markets are definitely (on average) less pleasant to deal with than others.
I love the ending of this story, which isn't obvious from just looking at the title. The author identified key pain points around customer support, automated them, and went back to enjoying life. This is the kind of thing that gets me excited about the possibilities of technology and AI as a force multiplier, especially when working on side projects, "lifestyle" businesses, or even startups as a single founder.
i've gone back and forth on this over the last few months.
I started out thinking that we've all been conditioned by bad customer support chatbots whose only purpose is to look up facts from the FAQ and then tell you to call the real customer support line to actually handle your problem. the problem was that the chatbots weren't granted hee ability and authority to actually do things. wouldn't it be great if you could aks a bot to cancel your account or change your billing info and it would actually do it?
but then i realized... anything with a clearly defined process or workflow like that would be even better if it were just a form on an account settings page. why bother with a chatbot?
customer support lines run by humans exist for two reasons:
- increase friction for things you don't want your user to do (like cancel their account without first hearing a bunch of sales pitches)
- handle unanticipated problems that don't fit into the happy-path you've set up on the settings page
My worry is that business dudes will get excited about making chatbots that can do the former and they'll never trust an AI to be able to handle the later. So I'm now of the opinion that having AI customer support will only be used to make things worse.
There's no wait in line. There's no waiting 2 min for each response in chat, or waiting 5 min on hold while the rep figures out what to do. And I've, shockingly, gotten issues resolved faster and better.
Using one semi-popular consumer app -- once it pointed me to docs on their site that Google wasn't finding because I didn't know what keywords to use. And twice it escalated me to send a message to the relevant team, where I got a response that addressed my problem -- and where escalation would have been necessary with a human call-center rep anyways.
The point is that it was far, far faster than any chat rep OR phone rep. And it's far faster to escalate too.
I'm sure this experience isn't universal, but I've been truly shocked at how it's turned what are otherwise 15-20 minute interactions into 3 minute interactions. At the same level of quality or better.
Doesn't need to be AI, most customer support was already automated before ChatGPT rose to prominence. Hell, I developed a mobile website once for a power company that was basically a wizard / checklist of "Have you checked for known outages? Have you checked your breakers? Have you checked if your neighbours have issues too?" before they were shown the customer service number.
Human contact doesn't scale, or is prohibitively expensive. I sat with customer support a while ago (again energy sector, but different company) to observe, and every phone call was at least ten minutes, often 20-30, plus some aftercare in the form of logging the call or sending out a follow-up email.
They also did chat at the time, where a chatbot (which wasn't ChatGPT / AI based yet but they're working on it) would do the initial contact, give low-hanging fruit suggestions based on their input, and ask for their information like their address before connecting to a real human. The operator was only allowed to handle two chats at a time, and each chat session took about half an hour - with some ending because the person on the other side idled too long. I mean granted, the UI wasn't great and the customer service guy wasn't a fast typer, but even then it was time-consuming and did not scale. They had two dozen people clocked in, if they were all as fast as this one person, they can handle 50 support calls an hour at most.
It does not scale. This was for a company with about 2.5 million users who rarely need customer support. Compare with companies like Google or Facebook that have billion(s) of users. They automated and obfuscated their customer support ages ago.
People want their support solved as quickly as possible. They don't want to talk to AI support bots because it's just an inefficient, error-prone wrapper over the documentation, which if you have an actual support need (as opposed to "I just haven't read any of the documentation") that kind of AI support isn't going to be helpful.
If you have an AI customer support that can actually support customer service requests and provide resolution, people will use it and be happy about it, or at least indifferent.
Broadly, I agree. And I am furious with Progressive insurance for requiring a smart phone/mobile app to file roadside assistance claims, and my inability to get someone real on a call.
But,
In this particular story, the people were asking questions that were answered in the instructions.
No one wants to waste their time answering stupid questions, particularly if they are a solo small shop who gets entitled people asking questions around the clock.
This isn’t really customer support, but prisma (popular typescript ORM) has an AI that can answer just about any prisma-related question. It’s got a great RAG setup, can help think through novel scenarios, and always refers to specific docs pages and GitHub issues.
I think it’s made by a company called kapa. Those guys are gonna go far. That thing works SO well. I’ve been imagining how good life would be with a prisma-style AI docs assistant for things like massive, obtuse google APIs.
I want to talk to an AI for customer support as the first line so long as there is always a "Talk to a human" escape hatch.
And for less than about $50 a month, I understand why they need to spend less than half an hour per month to retain me. It'd be net negative profit otherwise. (unless they offshore, in which case the math is only slightly better).
And, yet, millions already do. The point of AI for customer support is to handle the very simple requests (maybe half). The rest, you can escalate. If AI doesn't know what to do, "Hmm, I'm not sure. Let me escalate your question/request to my manager." For most normies, this will work well.
No one wants to perform customer support either. Generally, people who are smart and capable of offering good support will stop doing it because there are more fruitful and enjoyable things for them to do.
Eh... I think there's a balance to be struck. You could leverage AI to handle the initial messages (90% of which are tire kickers or scammers) and funnel worthy exchanges to continue the conversation manually.
But there are many ways in which AI can improve or help support. So even if "AI chat support" turns out to not work, AI can still be very helpful in automating support.
Like detecting duplicates, preparing standard answers, grouping similar requests, assigning messages to priorities and/or people and so on.
Sure, write an FAQ and usability test your software. But I'm not convinced that you can automated/AI away your support burden in any meaningful way that isn't going to piss off your customers.
Yes it's great writing. But it's not really about automating I feel (please chime in author OP?). To me he wanted to get away from customer email ghosting and disputes. He chose to change the customer support approach and create customer service tools to manage the common requests programmatically. I feel from the writing that his original vision, or continuing to extend the product and scale it, has now changed to maintaining it as is. He realizes customer requests and the time/disappointment of all that grows linear to revenue and does not want to do that any more.
The potential customer base being basically suckers waving wads of cash to be taken from them. The wild contrast of how nice the author tries to be to every single person that interacts with the project -- despite majority being the equivalent of single-celled organisms poking the fb markeplace "is it available" button.
Reading some of the messages from potential users is so eye-opening. I don't know if there's a sane way to deal with the entitlement, other than just plain ignoring those interactions.
How would one handle this type of project in 2024? Route most of the rote communication via an LLM, automate as much as possible, ignore all feature requests, dogfood everything as you continue to use the project yourself?
I really like the learnings the autor took from this experience. Seems like most of them came from adopting "I give up" attitude when flirting with burnout -- which inadvertently seems to follow the 80/20 rule.
I've done exactly one legit "SaaS startup" type venture around 2012-2015. I still think about the absolutely insane customer service requests we'd get. It was a very niched down Eventbrite competitor, so we did things like PDF ticket generation, QR code generation, attendance tracking, there was a big fundraising component as well so lots of payment infrastructure. We charged a percentage of ticket sales so any one event or even customer was not worth very much (a positive IMO). I still remember someone emailing me directly with the "oh we'd love to give you money but you have to add these features for us first" so they could use this event ticketing and fundraising platform to ... run their dog grooming business.
As many have learned, the people actually paying you money are usually pretty reasonable. It's the people who haven't paid you a cent who have all these crazy demands.
It’s hard, but my best advice for Saas builders who get crazy feature requests from non-customers is simple:
Don’t reply.
You have to judge which requests are “crazy” of course, which isn’t always easy. “If you could just do this one thing, I would gladly pay for a subscription” has to be weighed with how much work it would be, and whether you think it would apply to other potential or existing customers.
But a reply explaining your rationale for politely saying “no” simply gives the potential customer a reason to stay engaged, often leading to indignation when the inevitably feel dissatisfied with your reasoning. After all, they don’t care about your other customers, they just want their problem solved.
Many, many prospective customer inquiries don’t deserve answers, and you’ll find yourself buried in unproductive back-and-forth if you don’t do the simplest thing of ignoring them.
Unfortunately the IBMs of the world have taught a lot of entrepreneurs a very valuable lesson:
Companies only pay attention to you as a customer when they think the checkbook is coming out, or going away. Big companies have different reasons, but the behavior is similar. The people who understand this start making everything sound like a quid pro quo situation even if it's not very sensible.
The more clever and slightly pessimistic entrepreneur might go so far as suggest the problematic customer talk to one of their competitors. But that sort of biological warfare really should be covered by the Geneva Convention.
> As many have learned, the people actually paying you money are usually pretty reasonable. It's the people who haven't paid you a cent who have all these crazy demands.
Real question: I wonder if this phenom has been part of a case study for MBAs. It makes sense to me. If you are paying customer, you have already convinced yourself it is a valuable product. Deeper: Is it every worth trying to convert the "crazies" using sales strategies? Example: Well, if you sign-up for our enterprise package, we promise your needs in X months.
> How would one handle this type of project in 2024? Route most of the rote communication via an LLM, automate as much as possible, ignore all feature requests, dogfood everything as you continue to use the project yourself?
As someone else on the thread said, you start charging more. The large swathes of people looking for freebies will fade away and your customers, fewer in number perhaps, will be higher quality (or at least a bit more serious).
Interesting article to read. Part of the issues also seem to come from a few contributing factors like the unusual platform and expanding from this platform including whatever limitations come with it. Meaning you implemented things in a reverse order than people might otherwise do as they don't start out with a product on a platform trying to make it fit a subscription model.
I can imagine the specific type of user base also increasing specific types of annoying support requests. Although customer support almost always ends up being one of the things that at some point will annoy the hell out of you. Even on open source projects, the entitlement can be incredible. Although there you can get away with a remark like "You are free to uninstall <open source product>, we will give you a full refund!".
Automating a lot of that certainly was the right call, as well as filtering out all the low hanging fruits of bullshit requests. If people can't be bothered to read instructions (assuming they are clear instructions) then they certainly will also run into various other issues making them not worth the effort.
The one thing I don't entirely disagree with is "Be nice" which I personally have replaced with "Be civil" over the years. It still means listening to peoples requests, helping them where reasonable, even be courteous where applicable. To be fair, there might also be a cultural aspect involved here. In communication with US companies the "being nice" mantra often seems to be taken to such a degree where I am less wishing for someone sane to just help me swiftly with my support ticket and be done with it.
Before Reddit changed API access I built an iOS app called Pager (https://pager.app) that allowed users to set up alerts for content posted on Reddit. It had a lot of success but the issues you highlighted here kept me from monitizing the project.
Users became so demanding and I felt like if I began to take money from them it would only get worse. Looking back on it I'm not sure it was the best choice, but at least at the time the application being free felt like an important defense against users that you really could never satisfy.
The usual suggestion, often given by HN's patio11, is to charge, and charge more. For some reason free customers are the most demanding, and the more you charge the more people self-select out of the customer base.
The usual way this is presented as a free lunch has become disconnected from reality, IMO.
Free customers are not the most demanding, in my experience, but they are the most plentiful. If you cut them out, you don't lose any income (obviously) but you do cut down on requests by filtering out a lot of your users. A win!
So some people assume this is a monotonic function, where charging more increases their revenue while filtering out bad customers even further. If you press that button too many times, though, you discover that the higher price comes with increased churn, fewer signups, new competitors appearing on the scene, and, surprisingly, more demands from customers.
The last one is confusing because we were all told that "charge more" is a magic button you press to increase revenue and improve customer quality. The problem is that once your product becomes expensive enough, people expect it to perform at a certain level. If your $10/month service breaks one day, the number of people cancelling their subscriptions over it is going to be small. If your $100/month service is down for an entire day, people start asking themselves why they're paying so much for this thing anyway. The higher price gets more scrutiny at businesses looking to cut costs, so churn goes down. The higher price results it in getting recommend less over alternatives. It starts adding up.
Ideally you find the sweet spot where revenue is maximized, but that's hard to do. The feedback loop on price increases can take a very long time to show up in customer churn and reduced signups.
I've signed up for a number of SaaS products over the years that played the "raise prices" card too aggressively and then backtracked and cut prices.
There's this old story about an old farmer and his horse. You see, this old farmer had a horse that he loved dearly; took great care of it and pampered it.
But he was getting old, and wanted to retire to the City, where he could not keep a horse.
So what do I do with this horse, he wondered? He asked a wise friend, who told him: sell the horse for the highest amount of money that you can.
What?!? replied the farmer; I love my horse dearly and would never think of selling it like some goods.
The wise man replied: if you give it away, whoever gets it will abuse the shit out of it, and treat it like a workhorse, whip it every day, etc. because they got it for free, and won't value it. On the other hand, if you sell it for a huge sum, the buyer will pamper it and take good care of it, because it's an investment to them.
It feels like a hostage situation. Had you started to charge money for that app, the most demanding and unreasonable cohort of users would have become apoplectic and invested time into trashing you and the app. It's almost like that in order to start charging in that situation, you need to retire the app under that name and rebrand as a different, fee-based product.
Especially because if I had monetized it, it likely would have been a subscription model because that would obviously be the only way to cover the continued operating costs, and users have such an aversion to any subscription.
Hey, thank you so much for Pager! It helped me a lot (in supporting my own free users on Reddit)! I was often wondering how long it will remain free. Well, forever.
Readit News
I've learnt a few tricks for managing early stage pain points.
- You need to develop a polite but curt tone of voice for customer support.
- Once your core product is built, its worthwhile spending some time automating the heck out of everything. This will save a TON of time in the near future.
- Invest in good docs, even if you're not running a api saas. Good docs + consistent ux + rock solid support will solve most of your support issues.
I think a lot of literature around running a online biz has been boiled down to rather basic advice and its hard to find anything solid in this area. I've been running a small blog where I document these issues(operational.co) if anyone wants to check it out.
And very focused responses in terms of action items.
You might think of 3 things to say, check, but sadly 90% of the people you respond to with a list will behave like they read just one of them. Sadly this also leads to dragging things out for everyone who can handle more than one thing at a time :(
Me: Please try these 3 things and let me know how it goes: (list of 3 things with instructions)
Them: I tried (thing #1) and it didn’t work.
Me: Thank you, please try these 2 things and let me know how it goes
Them: I tried (thing #2) and it didn’t work.
Me: Thank you, please try this thing and let me know how it goes
Them: (no response)
Me: Just checking in to see if this is resolved?
Them: (no response)
Me: I’m closing this ticket as I haven’t heard back, let me know if this is still a problem and I can reopen it
Them: Don’t close the ticket, I’m still having this issue
Me: No problem, can you try this thing and let me know how it goes?
Them: (no response)
## Action Plan
- Read my comment
- Try it
- Comment on your experience
If this makes you uneasy, it can be easier if you sign initial support replies under another name.
https://m.youtube.com/watch?v=y-CA2EW4Z_U
In my experience, end users don't read the docs or FAQ's or help search - they send you a question.
You can write a support bot that sends a user's question + docs/FAQ to an LLM to automatically deal with the basic questions and only involve a human in the loop once a question goes beyond what's in the docs.
Here's more:
- Be direct, Hi, the xyz feature is available on the PRO plan. You can upgrade to the PRO plan at app.saas.com/billing
- Be brutal, Hi xyz, your card couldn't be charged for your Saas subscription, and hence your subscription has been deactivated. To reactivate, enter your card details app app.saas.com/billing
- Be honest, Hello xyz, thanks for the feature request. We'll put it in our wish list but can't guarantee it will make the cut.
- Be generous, Hey xyz, thanks for pointing that out. We have identified that as a bug and have pushed a fix for it. In the meanwhile, I've extended your trial by 7 days, on the house.
Couple of other tips:
- Dumb down your reply as much as possible. If you can't, throw your reply through chatgpt and make it dumb down.
- Unless a support issue is very basic, reply after a few minutes if you're near your computer. Usually users figure out things on their own if given some time.
- But don't allow issues to go stale. To really wow customer service, reply as humanely quick as possible, especially for existing customers.
- Make your support timelines clear somewhere in your product, eg: Our support will respond within max 48 hours, but most responses take 2-3 hours.
- Make your terms and privacy policy pages clear. People do read this. getharvest.com is a gold standard in this area.
The reason it can be framed as curtness is because they're being curt about the expectations, and the real expectations are pretty low. "Sure, I can delay really addressing the issue for a couple weeks. You're only paying me 40 bucks a month, why would you expect more? The goal of responding within two days is just for a canned response." See, they were curt and didn't let me demand something more than I deserved, like being able to use the product I'm paying for in the next several days!
Dead Comment
Interesting. Anything you've automated successfully that you can share? I've heard so many times that you should hold off on automating too early because constant pivoting and refining can end up making you spend more time fixing the automation than actually doing the work itself, so I kinda paused on it. I can see how it would make a big impact on my marketing outreach, which I'm doing manually right now with not much success.
https://passo.uno/signs-need-tech-writer/
What kinda things did you automate?
Its great.
Another thing I do with an AI helper is when I have it write out a function for me I have it write out the descriptor that can go in the readme for that function. I also have it write a header with version description path etc.
It was an experiment which started with the goal is to have all the code for a simple project with its associated readme functions loaded into a textai workflow and postgres DB and I can dynamically call the readme functions for everything by having a bot yank all the MD table for all the functions and just put together a real-time readme. As I add txtAI workflow scripts, they put their MDs into the DB, I try having it spit a JSON of its MD to a mongo?
The point is playing with ways to have the system self document as I/it develops.
Because one of the ways I have been using Claude to learn is through a F-ton of iterating on an initial thought and bird-walking through implementing a tool wrapped around it.
This way, as I iterate through many many version of a concept or script/function/api/crawler - it keeps a reminder readme for when I want to know what the heck was I thinking (I have had super awesome moments of brilliance, and then after a sleep or lengthy distraction - totally loose the Mode and have no idea what I was doing, or how I came up with BrilliantIdea(TM)
ADHD is a helluva drug :-(
when iterating and the header gets stripped in the response, the bot is taking a turn...
Sometimes ask it to spit out the full context and its understandings in a manner I can use to re-prompt itself for best efficiency, and it gives a nice summary of the concept I am thinking through, and I use that with vary degrees of satifying results.
Dead Comment
It can backfire when the new price point bumps it into a different category of decision making, though. For many, a $20/month product is an easy decision but $100/month price tag bumps it to a point where it becomes a more complicated decision making process. If you're not careful you can easily raise prices so much that people decide to jump to a more full-featured competitor product.
Projects like this one that are personal/side projects have an additional risk of raising prices: If the product becomes expensive, many people are going to notice that it appears to be highly profitable while also being within the realm of what a single person or small team can produce. Competition starts appearing quickly and you're back to cutting prices to stay relevant.
Finally, higher prices come with higher expectations from your customers. Whereas previously they might shrug off a slow response to a customer support request at $20/month, their $100/month service might lead them to expect more customer support, not less.
There are several indie SaaS companies that get posted on HN from time to time that take the opposite approach: They offer a low price but they're up front about what to expect. They don't try to pretend that you're getting world-class reliability, uptime, or support, but they do commit to offering a good service at a fair price. They could raise prices to match competitors, but now they're playing a very different game with very different expectations.
> Finally, higher prices come with higher expectations from your customers. Whereas previously they might shrug off a slow response to a customer support request at $20/month, their $100/month service might lead them to expect more customer support, not less.
This is potentially true, but there's other effects here too:
- When I was doing software and hardware consulting work, the people who paid the most were also the happiest customers. It felt paradoxical for a while until I really let it sink in and stew. Most of the high paying customers would just kind of... take my work products, say "yup, this meets the requirements we agreed to", and run with it. The ones who were paying the least were the most likely to pull the classic "well... is what we agreed to but... maybe you could move that button over to the other side and I've got this other feature idea that we didn't talk about, oh and I don't like how this works... it might be what we agreed to but it's not how it worked in my mind..."
- It sounds like OPs customers took that to the extreme with "customers" who hadn't paid anything at all yet being demanding.
- By going up-market, you can lose customers for sure but it might be worth it anyway. Given the support burden it sounds like 1/5 of the customers at 5x price would be a net win. Especially if it tracks my experience consulting where the remaining high paying customers are happier about your product in general. If you still maintain the same per-customer support burden or even have it climb some it could end up being less work overall.
If features don't work as advertised, I will absolutely make no distinction between a 500$ or 1$ product, and will demand a fix. But I will more likely have more patient if the service is cheap, before migrating away.
And then, if your customers are businesses, do you think the employees really care how much the product costs? No.
I hate to put you on blast but this is exactly why people charge $100/mo instead of $20/mo. They do not want the customers who feel (sorry for the term) "entitled" to a heroic level of features, support, polish, etc. They want people who have a hair-on-fire emergency that is so awful that they'd gladly pay $1000/mo for it, and are thankful that your software - klunky as it is - is giving them $900/mo of free value.
My worst customers were the ones that ask for discounts, or are otherwise looking for a deal. My theory is that people that happily fork out for an expensive product have already seen the value.
There are exceptions, but a lot of business owners see the same pattern.
It doesn’t make sense as an end consumer, but B2B lens it makes sense.
If a business can afford the higher price tag, they most likely would rather have a hands off approach for the problem they’re trying to solve (in a service based business)
Many of our mid and lower tier customers want everything drawn out and explained, and give feedback at every step. Our higher tier customers pay faster, request minimal input (outside of times we ask for it), and generally much easier to work with
The customer support efforts when you don't feel like it, being ghosted after helping a customer, the random or fraud disputes.
It's really tricky at that stage between hiring help and having the time/motivation to maintain those very non-tech parts while trying to continue doing other core parts of the side project / startup.
The first sale feels great, as does first showing the prototype.
By comparison, extra $100 MRR milestones don't feel so great, nor does dealing with customers/disputes eventually (it's a lot of negativity in general - pleased customers just leave reviews occasionally, negative ones email you). And a down negative month or two always feels like a stabbing and like it's all over.
Really don't know how to avoid this. Scaling quickly? Via investment in most cases? Maybe.
These three challenges + context-switching between marketing and product are really tough at the early stage.
I've found that growing a business from 0-1 is very formulaic - not easy but the roadmap is clear. Scaling one is much harder, especially without outside capital. There's a huge gulf between earning enough to replace your salary vs. hiring good people to take over lower-level tasks early on. And marketing usually ends up being too critical to outsource at first.
At least with digital products, customer disputes can always be settled with refunds, even when the claim is dubious. Eat the loss and move on. Physical product disputes really sting when you're out the cost of inventory + labor.
One of the things that keeps me away from doing stuff like this is that I _hate_ every part that isn't the engineering part, and the engineering part is a minority share of what it takes to run a business.
This is why startup people straight out of school are often unencumbered with ideas that impact their mission. If you go into a large organization, you are exposed to a reality that can distort your perspective. It's a myth that people can't move between large and small organizations, but the differentiator is their awareness of and desire to embrace the current circumstances. Many end up preferring the luxury and ease of large organizations and fail because they don't make the switch. Many startup people don't make the move in the other direction (even if they are exceedingly successful and it might be practical move.)
Similarly, a desire to only focus on engineering is something you feel will inhibit your ability to run a business. Over time you might be able to discover ways to reduce your hate for the other work. People here love to prescribe advice for situations like this, but it's really hard to give good advice without knowing a lot more about you.
It's a necessary part, but without marketing/sales/support/etc, very few projects work as a business.
I am one of those people. Gotta keep in mind to let people know that the solution worked
Whenever I’m conscious enough of it I do try to thank people - trying to remember how hard it must be on the other end!
I guess that's a matter of expectation.
A ticket system I've worked with in the past had an "autoclose" state where you could set the ticket to automatically close after a set date if no reply comes in until then.
If a reply comes with the info that it worked, I get a smile and close the ticket. If not, I never see the ticket again, no hard feelings.
I know it's more than once, but less than 100%.
Something that helps to offset this psychologically, and is also a good thing to do anyway, is to proactively reach out more frequently to all your users. It can be the case that 95% of your users are happily chugging along, while 5% are unhappy and complaining frequently for whatever reason. If you rarely hear from that 95%, it can start to irrationally feel like no one is happy with your product, since that's the message coming from most of your support interactions.
The variable is "20% of what type of client?". 20% of Taylor Swift concert attendees, or 20% of assembly coders? Each comes with its own unique challenges!
I started out thinking that we've all been conditioned by bad customer support chatbots whose only purpose is to look up facts from the FAQ and then tell you to call the real customer support line to actually handle your problem. the problem was that the chatbots weren't granted hee ability and authority to actually do things. wouldn't it be great if you could aks a bot to cancel your account or change your billing info and it would actually do it?
but then i realized... anything with a clearly defined process or workflow like that would be even better if it were just a form on an account settings page. why bother with a chatbot?
customer support lines run by humans exist for two reasons: - increase friction for things you don't want your user to do (like cancel their account without first hearing a bunch of sales pitches) - handle unanticipated problems that don't fit into the happy-path you've set up on the settings page
My worry is that business dudes will get excited about making chatbots that can do the former and they'll never trust an AI to be able to handle the later. So I'm now of the opinion that having AI customer support will only be used to make things worse.
There's no wait in line. There's no waiting 2 min for each response in chat, or waiting 5 min on hold while the rep figures out what to do. And I've, shockingly, gotten issues resolved faster and better.
Using one semi-popular consumer app -- once it pointed me to docs on their site that Google wasn't finding because I didn't know what keywords to use. And twice it escalated me to send a message to the relevant team, where I got a response that addressed my problem -- and where escalation would have been necessary with a human call-center rep anyways.
The point is that it was far, far faster than any chat rep OR phone rep. And it's far faster to escalate too.
I'm sure this experience isn't universal, but I've been truly shocked at how it's turned what are otherwise 15-20 minute interactions into 3 minute interactions. At the same level of quality or better.
Human contact doesn't scale, or is prohibitively expensive. I sat with customer support a while ago (again energy sector, but different company) to observe, and every phone call was at least ten minutes, often 20-30, plus some aftercare in the form of logging the call or sending out a follow-up email.
They also did chat at the time, where a chatbot (which wasn't ChatGPT / AI based yet but they're working on it) would do the initial contact, give low-hanging fruit suggestions based on their input, and ask for their information like their address before connecting to a real human. The operator was only allowed to handle two chats at a time, and each chat session took about half an hour - with some ending because the person on the other side idled too long. I mean granted, the UI wasn't great and the customer service guy wasn't a fast typer, but even then it was time-consuming and did not scale. They had two dozen people clocked in, if they were all as fast as this one person, they can handle 50 support calls an hour at most.
It does not scale. This was for a company with about 2.5 million users who rarely need customer support. Compare with companies like Google or Facebook that have billion(s) of users. They automated and obfuscated their customer support ages ago.
If you have an AI customer support that can actually support customer service requests and provide resolution, people will use it and be happy about it, or at least indifferent.
But,
In this particular story, the people were asking questions that were answered in the instructions.
No one wants to waste their time answering stupid questions, particularly if they are a solo small shop who gets entitled people asking questions around the clock.
This isn’t really customer support, but prisma (popular typescript ORM) has an AI that can answer just about any prisma-related question. It’s got a great RAG setup, can help think through novel scenarios, and always refers to specific docs pages and GitHub issues.
I think it’s made by a company called kapa. Those guys are gonna go far. That thing works SO well. I’ve been imagining how good life would be with a prisma-style AI docs assistant for things like massive, obtuse google APIs.
And for less than about $50 a month, I understand why they need to spend less than half an hour per month to retain me. It'd be net negative profit otherwise. (unless they offshore, in which case the math is only slightly better).
Deleted Comment
But there are many ways in which AI can improve or help support. So even if "AI chat support" turns out to not work, AI can still be very helpful in automating support.
Like detecting duplicates, preparing standard answers, grouping similar requests, assigning messages to priorities and/or people and so on.
Deleted Comment
The potential customer base being basically suckers waving wads of cash to be taken from them. The wild contrast of how nice the author tries to be to every single person that interacts with the project -- despite majority being the equivalent of single-celled organisms poking the fb markeplace "is it available" button.
Reading some of the messages from potential users is so eye-opening. I don't know if there's a sane way to deal with the entitlement, other than just plain ignoring those interactions.
How would one handle this type of project in 2024? Route most of the rote communication via an LLM, automate as much as possible, ignore all feature requests, dogfood everything as you continue to use the project yourself?
I really like the learnings the autor took from this experience. Seems like most of them came from adopting "I give up" attitude when flirting with burnout -- which inadvertently seems to follow the 80/20 rule.
As many have learned, the people actually paying you money are usually pretty reasonable. It's the people who haven't paid you a cent who have all these crazy demands.
Don’t reply.
You have to judge which requests are “crazy” of course, which isn’t always easy. “If you could just do this one thing, I would gladly pay for a subscription” has to be weighed with how much work it would be, and whether you think it would apply to other potential or existing customers.
But a reply explaining your rationale for politely saying “no” simply gives the potential customer a reason to stay engaged, often leading to indignation when the inevitably feel dissatisfied with your reasoning. After all, they don’t care about your other customers, they just want their problem solved.
Many, many prospective customer inquiries don’t deserve answers, and you’ll find yourself buried in unproductive back-and-forth if you don’t do the simplest thing of ignoring them.
https://successfulsoftware.net/2010/11/21/problem-exists-bet...
Companies only pay attention to you as a customer when they think the checkbook is coming out, or going away. Big companies have different reasons, but the behavior is similar. The people who understand this start making everything sound like a quid pro quo situation even if it's not very sensible.
The more clever and slightly pessimistic entrepreneur might go so far as suggest the problematic customer talk to one of their competitors. But that sort of biological warfare really should be covered by the Geneva Convention.
This is the kind of thing no startup puts in their year one budget and (alongside supplier cashflow issues) is why those projections don't work for
As someone else on the thread said, you start charging more. The large swathes of people looking for freebies will fade away and your customers, fewer in number perhaps, will be higher quality (or at least a bit more serious).
I can imagine the specific type of user base also increasing specific types of annoying support requests. Although customer support almost always ends up being one of the things that at some point will annoy the hell out of you. Even on open source projects, the entitlement can be incredible. Although there you can get away with a remark like "You are free to uninstall <open source product>, we will give you a full refund!".
Automating a lot of that certainly was the right call, as well as filtering out all the low hanging fruits of bullshit requests. If people can't be bothered to read instructions (assuming they are clear instructions) then they certainly will also run into various other issues making them not worth the effort.
The one thing I don't entirely disagree with is "Be nice" which I personally have replaced with "Be civil" over the years. It still means listening to peoples requests, helping them where reasonable, even be courteous where applicable. To be fair, there might also be a cultural aspect involved here. In communication with US companies the "being nice" mantra often seems to be taken to such a degree where I am less wishing for someone sane to just help me swiftly with my support ticket and be done with it.
Overall, nice write up of the experience though!
Users became so demanding and I felt like if I began to take money from them it would only get worse. Looking back on it I'm not sure it was the best choice, but at least at the time the application being free felt like an important defense against users that you really could never satisfy.
Free customers are not the most demanding, in my experience, but they are the most plentiful. If you cut them out, you don't lose any income (obviously) but you do cut down on requests by filtering out a lot of your users. A win!
So some people assume this is a monotonic function, where charging more increases their revenue while filtering out bad customers even further. If you press that button too many times, though, you discover that the higher price comes with increased churn, fewer signups, new competitors appearing on the scene, and, surprisingly, more demands from customers.
The last one is confusing because we were all told that "charge more" is a magic button you press to increase revenue and improve customer quality. The problem is that once your product becomes expensive enough, people expect it to perform at a certain level. If your $10/month service breaks one day, the number of people cancelling their subscriptions over it is going to be small. If your $100/month service is down for an entire day, people start asking themselves why they're paying so much for this thing anyway. The higher price gets more scrutiny at businesses looking to cut costs, so churn goes down. The higher price results it in getting recommend less over alternatives. It starts adding up.
Ideally you find the sweet spot where revenue is maximized, but that's hard to do. The feedback loop on price increases can take a very long time to show up in customer churn and reduced signups.
I've signed up for a number of SaaS products over the years that played the "raise prices" card too aggressively and then backtracked and cut prices.
So what do I do with this horse, he wondered? He asked a wise friend, who told him: sell the horse for the highest amount of money that you can.
What?!? replied the farmer; I love my horse dearly and would never think of selling it like some goods.
The wise man replied: if you give it away, whoever gets it will abuse the shit out of it, and treat it like a workhorse, whip it every day, etc. because they got it for free, and won't value it. On the other hand, if you sell it for a huge sum, the buyer will pamper it and take good care of it, because it's an investment to them.
Ever try giving something away for free on an online marketplace?
If not, don't. Always charge something. Even if you'll just tell them afterwards you don't actually want/need the money.
You'll run into the worst people imaginable on the internet.
<3