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.
It’s interesting that you did the experiment, and I appreciate you sharing your results. It all seems reasonable, even if a bit depressing.
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.
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'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"?
> 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 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.
Yes and no.
You want enough logging and telemetry that you can roll out an update to 2% of users and know if something is terribly wrong before you roll it out to the other 98%.
On the other hand, you probably don't want enough telemetry to detect that customer Jim Smith has trouble with WebRTC when joining calls without a microphone while using Firefox and Cloudflare Warp with split tunnels enabled.
And for some subscription situations, you can probably offer them a price that works for both of you.
There's a 'PhotoSync' app that offers a premium option for either $1/month or $24 for life. Presumably because they looked at the average subscription duration and found it was in the region of 2 years. Modulo the time value of money and per-transaction processing costs.
Personally I much preferred the one-off purchase, even though it's not clear I'll be using the app in 24 months, because it fits a lot better with my (somewhat chaotic) way of managing my money.
Which is exactly why HN's anti-telemetry stance is so unjustified.
It's rarely 0.03 though in my experience. More like 10 a month or even more between the cheap options with bad support and the better ones. Even if you have one issue every year (sounds high to me), that's over a hundred per support phone call. Makes you think twice about the trade-offs.
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.
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.
> 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.
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.
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.
How soon is it? Tomorrow? Next week? 10 years?
People are so sure that LLMs will change everything >>soon<<.
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.
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.
Even just oodles of debugging for a particular customer's build can go a long way.
I’ll tell you even more, in enterprise b2b saas, usually the company paying few thousand per month would have less questions and requests than the one paying few hundreds.
Building rapport is not the reason for doing this. Being liked by everyone is an impossible goal. And yes, there is a class of customers who are power users who think their input should dictate the development roadmap. And yes, there are users who become psychologically reliant on you as their personal Geek Squad. And yes, there are non-technical people who encounter hard to reproduce bugs, who it's worth taking the time to work with if they can help you isolate the problem.
But doing it for "likes" is a terrible idea. I was once put out as a coder to be a public face of a big AAA game, on their dev forum, to interact with fan requests, and I think that was catastrophic both for my own sanity and for the company that chose to field fan mail that way.
With your big fans, you see what you can do about their feature requests. Never promise anything. With people who encounter real bugs or otherwise provide signal, try to turn them into sleuths and get them to beta test your next release. Draw boundaries. Letting your users be your testers is enormously valuable, so respect them and don't stop listening to their feedback. But the overarching goal here is to get value out of the process. Explicitly not to waste your time on being "liked". Because the kind of people who become obsessive over your CS responses are actually the worst customers who don't want to pay for anything anyway, and expect everything to be free.
What I'm saying does not mean to pull back on customer service, at all! It means that the goal is to improve your product, not to suck up to all those categories of customers in the hopes they'll like you more. They will or they won't like your product, and in the end, whether they personally feel that affinity for it is based on their enjoyment of it. If it's based on their sense of importance at being able to order you around, they're not your real customers anyway.
This is a podcast app. It's in no way essential, how did you use to explain this to your customers ?
I think it's fairly well understood that vocal users aren't necessarily representative. The bulk of your happy users will never contact you for support. But they are some of the most important users to talk to to improve the product.
You need to build your own model of who your users are to provide a basis for interpreting user requests: is the support request signal or noise? if the request is coming from someone in your target market, and expressing a pain point, that's potentially an important signal. If the request is to charge only 20% of your current price, that's only useful if you're prepared to consider restructuring your offering (receiving many such emails might signal an opportunity for a budget product with specific feature subset) -- otherwise: "Thanks for your email, we don't have any plans to change our price right now." move on.
By the way, I'm impressed that this is even a conversation for a developer selling through the App Store. I always felt that Apple killed the ability to maintain customer relationships by injecting themselves into the process. Never published on the Mac App store myself.
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.
> We have heard this before, but we cannot see it or replicate it. The user gets to do work for us and/or get no resolution
Well, if you're not willing to resolve individual customer's problem then don't expect to build goodwill with just prompt reply on support!
I turned out that customers are not ready to pay for support. Cognitively, paying for a service and paying on top for this service to work well is not consistent.
As a result, people have minimal support and complain. But they don't value good support either.
NB: companies do pay for (insurance) support, especially for swift resolution. But consumers or small businesses don't want it.
When I was in a product leadership position I liked to spend time doing some of the customer support work. This is a common experience. Customers who write angry emails do not care about your reasons. They want something from you (cheaper rates, a specific feature they need, a discount, a freebie) and they do not care about anything else. It’s the digital version of the “I’d like to speak to your manager” customer who thinks that if there’s a 10% chance of getting what they want by being a jerk then it’s worth pushing as hard as they can.
Some times you’d get a little satisfaction from someone who realized there was a person who cared on the receiving end of that email address. Made it feel worthwhile.
Most of them are just doing some transactional game where they think that they can exercise some power over the company if they complain loudly enough.
This also has a lot of cultural differences. Some of the customer contact we’d get from one of the countries we served were out of control mean. There were casual threats of violence from time to time and 90% of them came from one country, which I’m not going to name but I’ve added it to my mental list of places not to visit. It was weird that it was so consistent.
The difference is that my customers are mostly engineers in small to medium sized businesses. They understand that 1) ongoing development costs money, hence subscriptions, 2) there are no magic wands and things are indeed more complex than they seem.
This is one of the reasons why I don't want to get into B2C. At a first approximation, people just don't want to spend money, hate subscriptions, have zero appreciation for how much ongoing development costs, do not understand that the money has to come from somewhere and that $5 purchase 6 years ago really doesn't cover the costs, and do not understand the complexity of software and product development.
Even here on HN, if you read the comments, there is so much blind hate against subscriptions, with little (if any) consideration for a sustainable software business.
Incidentally, I thought personal support would be a competitive differentiator, but I don't think it really works that way. Yes, customers do appreciate it a lot, but so what? Business customers don't talk to each other much, you won't get "viral" recommendations. And new potential customers have no idea how your support works, they think it's the same AI chatbot and knowledge base search as anywhere else.
As a user, if the CEO/founder is answering my questions, I honestly will wonder if this is a one man fly by night operation that will be gone next week.
Also, a satisfactory support experience may not be the fastest one. If I ask for something, L1 says "no", but then escalates to sales, sales say "no", but escalate to the founder, the founder says "yes", the user may feel more "heard" and has a better sense of achievement than if the founder is the L1 who says "yes" immediately. The outcome is the same, but one will feel "earned".
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.
Every line item there has a solution. Even if it is just 4 different email addresses.
It’s not too late to change the first sentence to:
> I had an idea when I bought [Castro](whatever_the_url_is), a XXX app, that human support…
It's really not possible to avoid that when, at the end of the day, you're doing it to make a living for yourself and your employees, not doing charity work in your free time because you enjoy it.
> The bulk of your happy users will never contact you for support. But they are some of the most important users to talk to to improve the product.
Yep, but that's then called market research, not customer support.
Throw those people out immediately. Not only are they bad customers themselves, they also drive away the good ones.
I'll admit I mostly don't care for subscriptions for this sort of thing. But to be more constructive, it seems to me like it's a hole in the market that doesn't have a really good solution right now. I mean, software like this which does need at least a little bit of ongoing support, but doesn't seem to generate enough ongoing value for customers for it to feel reasonable to have a subscription for. None of the solutions we have for that right now really feel great to anybody.
Having maintained and done tech support for both B2B and B2C products, as a small shop and often solo, B2B customers are far more predictable and less inclined to load you up with nonsense. And your weekends are always free. However, when they do complain, you're up at 6am on a Sunday. When you have a consumer complaint, you're welcome to sleep as long as you want.
This may seem trivial, but it's a proxy for saying that your feet are constantly to the fire with B2B deployments, in a way that you are not held accountable with B2C apps. I personally work better with the B2B stress and motivation... but it's not without its mental overhead.
I think I need to take a break from posting on HN.
The only exception is that I do get a decent amount of word of mouth because many of my customers are individual franchisees in national networks, so they tell their peers who they don’t compete with about me. But that’s not really so much about customer support as the product itself.
The main value I get from doing customer support myself is the same that I get from doing sales myself: learning. I have my pulse directly on what my customers need, like, and dislike about the product.
Secondarily, I do think it helps with both close rate and retention to be able to talk to the business owner, but this might be less true in other niches.
genuinely curious. Which country was it?
This is correct thanks for the comment. You will enjoy my next post which is about exactly this. (HN will not enjoy it)
The perspective is very different once you actually try to make ends meet.
I get the post was a little provocative, but I have posted a lot of content on the internet in the past and usually get like 1 comment if that, so I'd rather get feedback tbh and it seems like it resonated with a good number of people
I had an idea when I bought Castro that human support based around actual user experience was an easy differentiator. I’ve rarely gotten useful answers from support from services I use. I thought if I used my own product every day, read every email and answered it thoughtfully, people would appreciate this, and it would build some degree of loyalty and appreciation. This way, customers would feel their subscription dollars were actually going toward something. 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.
However, what I found is this whole thing didn’t work as I thought it would. Sure sometimes we were able to wow customers, particularly when we responded right away with an exact fix for them. But the vast majority of our honest, thoughtful answers were deeply unsatisfactory to users, and it often annoyed them more than anything else.
Here are my unscientific categories of support requests/emails we get and why the approach is flawed.
I have already thought about this a great deal. I am not changing anything based on your email. I can of course try to justify why we charge what we do, and I’m happy to explain why an essential app is worth your money, and why software lends itself to subscription so well. But in reality the user is not satisfied with this. I can think of exactly one customer in two years who was surprised that software costs money and we’re actually doing work every day, thus charging a subscription makes sense. 99% of the time, no matter how carefully or kindly it’s explained, the reply will be more negative than the initial email. I tried just offering an additional 30-day trial to anyone who asked, but this didn’t change the sentiment of the emails, and those trials had a substantially lower hit rate than our typical free trials. I could fill several blog posts with thoughts on subscriptions, but suffice it to say, emails about pricing are not helpful in terms of building rapport.
These emails are genuinely useful to me, the receiver. I want to know about the bugs people are experiencing on a daily basis. In the best case, I can say we know about this and are actively working on a fix or have already fixed it. Due to the way shipping works in the App Store, it’s common for a bug to be fixed but not distributed yet. Those are great emails to answer and we can satisfy the customer.
But there’s a long tail of bugs that are not like this:
We have heard this before, but we cannot see it or replicate it. The user gets to do work for us and/or get no resolution. Bad experience for them, bad experience for us, mostly a waste of everyone’s time. Very, very occasionally a user will send a detailed report with steps to reproduce or a meaningful factor. Still we need to get these emails to know what people are seeing.
We have never heard this before. User can provide details for us, but if others aren’t experiencing it, it’s unlikely to be prioritized. Still, useful signal for us.
We get no information. “It doesn’t work” is the whole email. Not much I can do without the user doing more work, which they understandably aren’t interested in doing.
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.
None of these categories seem to build any meaningful rapport. Any honest answer I give is deeply unsatisfying to both parties, and we typically have better data from telemetry or crash logs than the emails provide. It’s certainly useful for us to receive them, but there’s not a helpful response I can give. In retrospect, this seems obvious, but before owning Castro it was not obvious to me that 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!
Sometimes we get nuanced questions about App Store processes, store issues, specific locales, hyper-specific podcast questions, etc. A user recently had a Castro subscription on two different accounts at different times and wanted to let one expire while ensuring they got the months they paid for. We were able to resolve it for them quickly. People do genuinely appreciate this kind of responsiveness. So yeah, the idea probably works here. Unfortunately, these are less than 1% of support emails.
This comes closest to building the customer relationships I was hoping for, with the worst results. Customers email us with confusion about how podcasts work, how the App Store works, how their Mac works, and any number of tangential issues. What tends to happen is the same users do this over and over, and once they find out we answer, the requests get more frequent and more burdensome. I think I heard Patrick McKenzie use the term “pathological customers”. While in theory building rapport and loyalty sounds nice, what you actually end up doing is spending a lot of time on the people who ask the most of you, but their subscription dollars aren’t worth more, and they’re rarely satisfied. You end up feeling taken advantage of.
Similar to the last category. Good in theory, sometimes useful, but often the same small, unrepresentative segment with strong thoughts. Woe to the team who implements a suggestion based on an email, you are likely to get a full product roadmap soon!
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. If I did, by catering more to persnickety power users, we run the risk of alienating newer users who don’t know how things work. But our power users probably aren’t going anywhere, at least they’re a little harder to shake, and alienating new users is the death of the product.
To the user, any response aside from “Okay, we’re going to build that right now” is meh-to-negative. Various honest responses, such as “I thought about this or tried it in the past and it unfortunately didn’t work very well” are not going to knock their socks off. These just don’t do much in terms of loyalty and rapport.
Ultimately, for us, putting too much time into support isn’t a differentiator, and it’s often counter-productive. The person who paid our subscription but would never think about emailing us and asking for something for free deserves a great app just as much as the person who emails us every week. If we have a specific resolution or fix for their problem, great. If not, we’ve had better results by saying we appreciate the email, we read them, and we are actively working on the product to improve the issues. Avoiding explanations and specifics tends to get a neutral response and doesn’t suck anyone in or waste too much time. In other words, the best approach for us is what most companies do. Because building loyalty or rapport at the moment something isn’t working and the user is frustrated hasn’t worked. The real positive experience comes when you actually improve the product, so that’s where we’re spending our time.