This was also my thought! OP is going to get a lot of arrows for this article, but it's a genuinely great write up that matches a lot of my experience with mass-market products.
It's a great account for people to reflect on. I've immediately sent this article to several early-stage founders who are burning astounding amounts of time on undesirable customers.
Thinking about customer support as a ‘differentiator’ or a way to drive profit is depressing. You should simply strive to do what’s best for your customers. The sort of feedback you’re getting is golden and in the right hands can be put to use rather than be dismissed. Assuming that people who disagree with your pricing model just don’t understand how business works is really telling. You have to accept that your pricing model sucks to a group of people (who are likely experiencing subscription fatigue) and decide if it’s worth losing or never getting their money.
Your support strategy is missing an outlet for needy users to ask questions, effectively blaming customers for a structural flaw in your own setup. You could easily spin up a forum where power users help each other and devs can occasionally jump in to help or note pain points. Furthermore, your development and QA processes clearly need scrutiny. The reason bug reports feel like a ‘waste of everyone’s time’ is likely because you don't have the right error logging or telemetry built into the app itself. Having to wait for a manual bug report from a user is already a failure.
It’s completely okay to define your product however you want and to reject feature requests, but to say you’ve singularly thought through every problem in an armchair, in comparison with the distributed minds of the rest of us, is pretty arrogant.
> but to say you’ve singularly thought through every problem in an armchair, in comparison with the distributed minds of the rest of us, is pretty arrogant.
Somehow incredibly ironic when applied to you comment itself...
Sure, people want a personal human answer. But not as much as they want the correct answer.
Also, I think that we want to communicate with a company (Human or AI), and not a person, quite often. As you’re supporting a business transaction, not making friends. There’s a certain anonymity that comes with the business transaction. I wouldn’t ask for a refund from a friend.
When I was in college, I worked at a bakery and actually made some long-term friends by talking to customers that came into the store. I later used this job experience to get an email support job, answering questions that users had about our software plugin. Never made any long-term friends with customers there, even if they emailed us once a month.
The difference is that email / online support has no “human downtime moments.” At the bakery, I usually would talk to people while we were waiting for their order to be finished heating up / cooking / etc. So there was a moment or two people standing around waiting, which naturally leads to a conversation. Or at least it did a decade ago when cellphones weren’t quite as omnipresent.
I wonder if having a monthly Zoom “open office hours” type thing would replicate some of this feeling in a software context. Probably not, but it might be better than just answering emails.
Porkbun is an interesting case study for this support model. They reply to everything personally, and for me the important thing is not that I'm talking to a human, but that I'm not hearing corporatespeak.
I would even be happy to talk to a bot if it was fine-tuned to speak like a regular person instead of a corporate drone.
Thank you, @dabluck, for sharing what failed. I think stories of failure are incredibly valuable, and more useful than stories of success, which are often post-hoc rationalizations.
I’m sorry all the airchair geniuses in this thread feel compelled to express how they’re so much smarter than you and would never fail… or at least, never admit it.
> When emails overwhelmed me, I asked a thoughtful user who emailed frequently and seemed to know as much about the product as I did if he’d help answer the emails, so I paid him to do that. And he did a great job, especially in terms of directly solving user problems.
Hey, I got promoted from customer to Customer Support at _my_ $dayjob!
Let's review some common areas.
- Pricing: everyone is always looking to get a better deal. That's their right but I'm unlikely to give one. Saying no here is just another (emotional) cost of doing business.
- Bug reports: broad agree on all four points but not necessarily the conclusion. Users who are willing to go down the debugging rabbit hole with me are golden.
- Pathological customers: I like to call them "frequent flyers". Enough said.
- Feature requests: we're not necessarily as "opinionated" so we rarely give a hard no, but this is why we have a "feedback board with upvotes" approach.
- General usage questions: I have an attitude of fresh eyes often being the best eyes for usability testing. If it's not obvious, what can we do to make it so? We also use Intercom Fin to handle a lot of these level-0-support questions though.
Indeed a helpful article for it's detailed insights. Once you think about alternatives, it's clear why everyone else is on the well-known path (such as unhelpful support.)
I've often heard stuff like "telecom provider support sucks" or "IKEA furniture breaks easily."
When you ask people whether they researched support quality before deciding on a provider or whether they considered a $3,000 heavy-wood furniture the boomers had, they immediately sense the accusation in the question: It was their decision to suffer these fates. They then tend to get mad fast.
People like to save 3 cents on their monthly internet bill and to disassemble their furniture in 5 minutes. It's exactly why everyone is optimizing for it.
Haha, I meant it the way I said it but I see what you're getting at. Perhaps it's better to say one person was genuinely surprised we work on the product all the time and it has to maintained, etc and was happy to support it since that was the case.
One suggestion — when you have an unsatisfying answer for a customer like “I can’t reproduce that”, or “I won’t build that feature”, the customer may not appreciate the amount of effort you have invested in that decision. A 30 minute phone call/video call may communicate more effectively the depth of care you have. Even if you convey the same information, people _love_ talking to the owner/founder, it is a very strong indication that you care about their thoughts.
Thanks it's hard to find time to do 30 minute calls as this is a glorified side project, but I actually had the same idea and recorded some calls with customers for public consumption as I thought might improve some of this communication, but I never got around to editing it and wasn't sure if the content would be compelling.
Definitely feels like some form of video might be superior vs email, which is easiest in some ways but also seems to be a bit of a barrier in thoughtful communication.
You know what’s also great? A five minute phone call. Cuts through endless email chains and creates an instant human connection. You don’t need 30 minutes if you have competent support personnel who know how to deal with needy customers.
Personally I'd guess this is a big part of the issue. If this is a glorified side project, you really don't / can't care _too_ much about everything. I don't mean that as a criticism, it's just if you have little time to give the product will improve little, and the customers will get a just-ok experience. It's not surprising that translates poorly to customers. People like devotion; luke-warm commitment is dissapointing.
On the contrary I care a great deal, an unreasonable amount really, but since it isn't my primary gig my time is limited and I have to try to spend it where it is most effective.
I started off reading this article thinking "well, anyone who has ever maintained an open source project has almost certainly experienced the unending entitlement of users even when working for free". But after reading the article, I'm not surprised your users dislike you more after communicating with them...
> I have already thought about this a great deal. I am not changing anything based on your email.
> User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized.
> We know about this, but fixing it is a decent amount of work or low-priority because it’s not a big deal or few users see it.
> a human response detailing why I am unable to solve your problem today and am not even going to try is about the worst thing a user can receive!
> Good in theory, sometimes useful, but often the same small, unrepresentative segment with strong thoughts.
> Castro is an opinionated app and I’ve thought a lot about what we’re building and what we’re going to work on next. It’s unlikely I’m going to implement the request.
Your support policy seems to be more along the lines of "you may e-mail me for an explanation of why I'm not interested in your thoughts" than an actual commitment to support for paid customers. You aren't interested in comments on the payment model, bugs, or feature requests.
> why software lends itself to subscription so well [...] no matter how carefully or kindly it’s explained, the reply will be more negative than the initial email
Especially when you're using it to justify scummy practices, it's no wonder that no matter how kindly and carefully you piss on your users, they know it's not raining.
You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products. But does your user experience with other products tell you that you want to subscribe and be nickle-and-dimed for the rest of your life for every last thing? Especially when you're promising to users that while you're still working on the software and that's why they need to pay every month forever, you won't work on the bugs nor features they want? Subscription works "so well" for software because it makes you a lot of money, but it doesn't work well for the users its being forced upon who don't actually want the updates you're working on.
As far as I can tell, your software is not significantly based on ongoing maintenance costs, ergo it does not inherently justify ongoing payments to use. If you let greed stop clouding your eyes, you could adopt the approach that many ethical independent developers use: an option to pay once per major version and keep it for life, with optional subscriptions to try the waters and keep up with the latest and greatest version.
It’s for these reasons LLMs are going to chip away at silly subscriptions. When many projects get 70% of what the user needs and the maintainers aren’t willing or able to address what paying customers want…why bother paying anymore when you’ll soon be able to have just those bespoke features/fixes/integrations built yourself?
It seems to often boil down to the fact that paying customers are paying to solve a problem so they don’t need to deal with it. Whereas developers are more interested in writing code than solving said problems for customers.
> You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products.
This was the biggest (1) complaint for me - in light of what you discovered from your actual support experience, why was your expectation so off?
Was it that you expected support to be full of "how do I do this complicated thing?" questions that can be answered by an expert? That's an unrealistic expectation, but I guess now you know.
Or was it that you really thought that customers would be happy if you just took the time to explain your pricing model to them (also unrealistic).
It is kind of obvious from the types of emails you get, and the types of responses you give that it was not going to lead to strong customer relationships. If all you're doing is writing a 100 words to say "No, I'm not going to do what you want" that's not going to make things better.
(1) Actually 2nd biggest - the biggest was talking about "buying Castro" but having no explanation/links about who the author is, what Castro is, or how/when/why it was bought.
Pricing is a bad example I guess I should've minimized that part of the post.
I guess I didn't think about it enough, but if someone emailed in with a feature request, or with an opinion that this tab should behave differently or whatever, I thought giving explanation would be helpful. "I actually tried it that way, but it didn't work because X, and Y, and I didn't even think about Z which breaks the whole concept, etc etc." As a dev, these types of explanations would seem meaningful to me. But in reality, these conversations are mostly not helpful for either party. That was the point I was trying to make in the post.
Fair point on 2, I honestly didn't expect anyone to read this tonight and had another post planned I thought might get comments on HN, but I just put this up for now until I could finish that one. I will do better at giving context next time.
Thanks for reading. I'm not sure what you think is scummy unless it's just having a subscription? If so, you are going to love my next article on how subscription apps are the best invention ever and the only business model that makes sense! Definitely subscribe so you don't miss that one.
I agree his responses could be more compassionate and show more effort, but i feel your characterization is over-critical. There _isnt time_ to chase bugs that aren’t reproducible. The software _cant_ have every form factor, _some things_ need to be set in stone as a North Star. These aren’t scummy practices, these are realities of a time-bounded existence.
> There _isnt time_ to chase bugs that aren’t reproducible.
There absolutely is. I fully engage with any user who is willing to put effort into helping me identify the problem, even if I can't reproduce it myself. Many users are cooperative and will go to great lengths to assist. If they don't, then sure, put it on the backburner as "I literally don't know how I can solve this". But I value my users and fix every single bug I'm capable of fixing.
Is it the most efficient use of time? No, I doubt it. I would probably make more money if I didn't do that. But that's the crux of the issue, isn't it. Software development is already extremely lucrative because the cost of reproduction and shipping is effectively zero, so you have ~infinite margin on every sale after the initial development cost is covered, with a potential market size of ~the entire connected world. Yet so many of us are always chasing more, more, more. It's not enough until you make $500k/yr or sell out for billions.
Don't say "it's not possible". Say "I don't want to do it because I can make more money by not doing it". You're allowed to make that decision. But then you're at least being honest with yourself, and you'll clearly understand why your customers are angrier after communicating with you than before. I can proudly say that my users are happier after communicating with me than before.
The customer can reproduce it, or they wouldn't be complaining about it - and if you connect with them you can get much of the detail you need; especially if they're "test-support" inclined and can help diagnose possible causes.
Even just oodles of debugging for a particular customer's build can go a long way.
It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.
It's a great account for people to reflect on. I've immediately sent this article to several early-stage founders who are burning astounding amounts of time on undesirable customers.
Your support strategy is missing an outlet for needy users to ask questions, effectively blaming customers for a structural flaw in your own setup. You could easily spin up a forum where power users help each other and devs can occasionally jump in to help or note pain points. Furthermore, your development and QA processes clearly need scrutiny. The reason bug reports feel like a ‘waste of everyone’s time’ is likely because you don't have the right error logging or telemetry built into the app itself. Having to wait for a manual bug report from a user is already a failure.
It’s completely okay to define your product however you want and to reject feature requests, but to say you’ve singularly thought through every problem in an armchair, in comparison with the distributed minds of the rest of us, is pretty arrogant.
> but to say you’ve singularly thought through every problem in an armchair, in comparison with the distributed minds of the rest of us, is pretty arrogant.
Somehow incredibly ironic when applied to you comment itself...
I’m missing the irony.
Also, I think that we want to communicate with a company (Human or AI), and not a person, quite often. As you’re supporting a business transaction, not making friends. There’s a certain anonymity that comes with the business transaction. I wouldn’t ask for a refund from a friend.
The difference is that email / online support has no “human downtime moments.” At the bakery, I usually would talk to people while we were waiting for their order to be finished heating up / cooking / etc. So there was a moment or two people standing around waiting, which naturally leads to a conversation. Or at least it did a decade ago when cellphones weren’t quite as omnipresent.
I wonder if having a monthly Zoom “open office hours” type thing would replicate some of this feeling in a software context. Probably not, but it might be better than just answering emails.
I would even be happy to talk to a bot if it was fine-tuned to speak like a regular person instead of a corporate drone.
I’m sorry all the airchair geniuses in this thread feel compelled to express how they’re so much smarter than you and would never fail… or at least, never admit it.
Hey, I got promoted from customer to Customer Support at _my_ $dayjob!
Let's review some common areas.
- Pricing: everyone is always looking to get a better deal. That's their right but I'm unlikely to give one. Saying no here is just another (emotional) cost of doing business.
- Bug reports: broad agree on all four points but not necessarily the conclusion. Users who are willing to go down the debugging rabbit hole with me are golden.
- Pathological customers: I like to call them "frequent flyers". Enough said.
- Feature requests: we're not necessarily as "opinionated" so we rarely give a hard no, but this is why we have a "feedback board with upvotes" approach.
- General usage questions: I have an attitude of fresh eyes often being the best eyes for usability testing. If it's not obvious, what can we do to make it so? We also use Intercom Fin to handle a lot of these level-0-support questions though.
I've often heard stuff like "telecom provider support sucks" or "IKEA furniture breaks easily."
When you ask people whether they researched support quality before deciding on a provider or whether they considered a $3,000 heavy-wood furniture the boomers had, they immediately sense the accusation in the question: It was their decision to suffer these fates. They then tend to get mad fast.
People like to save 3 cents on their monthly internet bill and to disassemble their furniture in 5 minutes. It's exactly why everyone is optimizing for it.
I think you meant "I can think of exactly one customer in two years who was NOT surprised that software costs money"?
Definitely feels like some form of video might be superior vs email, which is easiest in some ways but also seems to be a bit of a barrier in thoughtful communication.
Personally I'd guess this is a big part of the issue. If this is a glorified side project, you really don't / can't care _too_ much about everything. I don't mean that as a criticism, it's just if you have little time to give the product will improve little, and the customers will get a just-ok experience. It's not surprising that translates poorly to customers. People like devotion; luke-warm commitment is dissapointing.
> I have already thought about this a great deal. I am not changing anything based on your email.
> User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized.
> We know about this, but fixing it is a decent amount of work or low-priority because it’s not a big deal or few users see it.
> a human response detailing why I am unable to solve your problem today and am not even going to try is about the worst thing a user can receive!
> Good in theory, sometimes useful, but often the same small, unrepresentative segment with strong thoughts.
> Castro is an opinionated app and I’ve thought a lot about what we’re building and what we’re going to work on next. It’s unlikely I’m going to implement the request.
Your support policy seems to be more along the lines of "you may e-mail me for an explanation of why I'm not interested in your thoughts" than an actual commitment to support for paid customers. You aren't interested in comments on the payment model, bugs, or feature requests.
> why software lends itself to subscription so well [...] no matter how carefully or kindly it’s explained, the reply will be more negative than the initial email
Especially when you're using it to justify scummy practices, it's no wonder that no matter how kindly and carefully you piss on your users, they know it's not raining.
You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products. But does your user experience with other products tell you that you want to subscribe and be nickle-and-dimed for the rest of your life for every last thing? Especially when you're promising to users that while you're still working on the software and that's why they need to pay every month forever, you won't work on the bugs nor features they want? Subscription works "so well" for software because it makes you a lot of money, but it doesn't work well for the users its being forced upon who don't actually want the updates you're working on.
As far as I can tell, your software is not significantly based on ongoing maintenance costs, ergo it does not inherently justify ongoing payments to use. If you let greed stop clouding your eyes, you could adopt the approach that many ethical independent developers use: an option to pay once per major version and keep it for life, with optional subscriptions to try the waters and keep up with the latest and greatest version.
It seems to often boil down to the fact that paying customers are paying to solve a problem so they don’t need to deal with it. Whereas developers are more interested in writing code than solving said problems for customers.
How soon is it? Tomorrow? Next week? 10 years?
People are so sure that LLMs will change everything >>soon<<.
This was the biggest (1) complaint for me - in light of what you discovered from your actual support experience, why was your expectation so off?
Was it that you expected support to be full of "how do I do this complicated thing?" questions that can be answered by an expert? That's an unrealistic expectation, but I guess now you know.
Or was it that you really thought that customers would be happy if you just took the time to explain your pricing model to them (also unrealistic).
It is kind of obvious from the types of emails you get, and the types of responses you give that it was not going to lead to strong customer relationships. If all you're doing is writing a 100 words to say "No, I'm not going to do what you want" that's not going to make things better.
(1) Actually 2nd biggest - the biggest was talking about "buying Castro" but having no explanation/links about who the author is, what Castro is, or how/when/why it was bought.
I guess I didn't think about it enough, but if someone emailed in with a feature request, or with an opinion that this tab should behave differently or whatever, I thought giving explanation would be helpful. "I actually tried it that way, but it didn't work because X, and Y, and I didn't even think about Z which breaks the whole concept, etc etc." As a dev, these types of explanations would seem meaningful to me. But in reality, these conversations are mostly not helpful for either party. That was the point I was trying to make in the post.
Fair point on 2, I honestly didn't expect anyone to read this tonight and had another post planned I thought might get comments on HN, but I just put this up for now until I could finish that one. I will do better at giving context next time.
There absolutely is. I fully engage with any user who is willing to put effort into helping me identify the problem, even if I can't reproduce it myself. Many users are cooperative and will go to great lengths to assist. If they don't, then sure, put it on the backburner as "I literally don't know how I can solve this". But I value my users and fix every single bug I'm capable of fixing.
Is it the most efficient use of time? No, I doubt it. I would probably make more money if I didn't do that. But that's the crux of the issue, isn't it. Software development is already extremely lucrative because the cost of reproduction and shipping is effectively zero, so you have ~infinite margin on every sale after the initial development cost is covered, with a potential market size of ~the entire connected world. Yet so many of us are always chasing more, more, more. It's not enough until you make $500k/yr or sell out for billions.
Don't say "it's not possible". Say "I don't want to do it because I can make more money by not doing it". You're allowed to make that decision. But then you're at least being honest with yourself, and you'll clearly understand why your customers are angrier after communicating with you than before. I can proudly say that my users are happier after communicating with me than before.
Even just oodles of debugging for a particular customer's build can go a long way.