Reminds me of my (far less exciting) story when I opened a php forum for a small community I was in charge with, way back, only to come the next day and find it full of botspam.
Similar experience. I built a very small online helpdesk platform in the early 00s. This was to support my own business mostly. I had several paying customers after 6 months. They were HELL, particularly when it came to paying the bill. I sold the whole business for pocket money after a year to a small tech company who rewrote it into a fairly well known commercial product. I couldn't be bothered. I have ZERO regrets about this.
I still have the source code somewhere, which was about 25,000 lines of ASP in one file!
I’ve done enough freelancing and side jobs to know that I didn’t enjoy and—most importantly—didn’t care enough to get better at the customer service aspect of it.
Possibly the primary reason that software engineers don't just go into business for themselves is that running a business is a very different problem domain with different challenges and rewards.
I have never envied any CEO, VP, or manager I've worked for their job. The hardest part of my day is crafting novel SQL queries or tricking C++ into compiling code that will work on all my target hardware in spite of an unknown number of undefined behaviors. I've never had to figure out how we're going to keep documentation in sync on our flagship project when the head documentation engineer is dying of cancer (and has chosen to finish out the week because he knows how screwed the project will be without him and he believes in it), or how to make payroll next quarter if the next investor says no, or how to keep the quarterly goals met when the President has just declared that all of our employees working in the country on a visa may suddenly not return to the country.
I think certain personality types just have a really different view about risk than we do. I once talked to our CEO about it and he was like "I'd risk it all again, I like to play!". There are people who LIKE to take those kinds of risks, I'm certainly not one of them. But one must also not forget the upside: get really, really rich from the work of 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.
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.
Once people notice AI is responding they will skip it and will request to talk to a human. AI will look the same as FAQs or Chatbots, people don't want to interact with them, they want a human being that is able to understand their problem exactly as it is.
Most chatbots are both useless and tedious to interact with. But I've also had plenty of interactions with human first-level support that's just following a script without any actual understanding. An AI would be able to provide a genuine improvement over that.
AI isn't an improvement for companies that already provide great customer support, but it has the ability to seriously raise the bar for companies that want to keep customer support costs low or that have a lot of trivial requests that they have to deal with cost-effectively
That is exactly what is happening at my employer, and it’s been really effective for trivial support, especially when it’s empowered to make meaningful changes on the customer’s behalf. It’s got large swaths of the whole UX in chat, with an authenticated session. You could see it being better a better experience than clicking around anyhow. It does a great job at search too. Lots of room to improve but it’s hitting its targets for reducing human support time and as a sales tool.
The right pattern is to put them directly in a queue to talk to a person, but have an system (AI or otherwise) in the queue to gather the minimal information. Like having the person explain the problem (and have something transcribe it) and have the system transfer them to the appropriate team after parsing their problem.
Or for really common cases (ie. turn it on and off, you're affected by an outage, etc), redirect them to an prerecorded message and then let them know that they are still in the queue and can wait for a person. 9/10 it'll solve everything, but also reduce friction of simple things that might be answered.
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.
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.
Customer support isn't paid well, so they often aren't motivated to become very skilled beyond the level of a chatbot before they move on to other things. So the interface to bad docs doesn't matter much. And good docs are very hard to produce. AI magnifies problems when good docs are lacking.
> aren't motivated to become very skilled beyond the level of a chatbot
Everyone has some amount of common sense. The current state of the art does not, so it cannot make decisions. This is why these things can't currently replace real support beyond being a search function exceedingly capable of interpreting natural language queries and, optionally, rephrasing what the found document says to fit onto the query better
You can't even have these systems as first line support, verifiying whether the person has searched the docs because you can't trust it with a decision about whether the docs' solutions are exhausted and human escalation is needed. There currently simply needs to be a way to reach a human. I'm as happy as the next person to find that a no-queue computer system could solve my problem so I use it when my inquiry is a question and not a request, but a search function is all they are
Chatbots are loaded with issues. But I have also had a lot of issues with humans.
By the time I have an issue, I have usually covered basic ideas and FAQs already. Currently, I tend to use perplexity supported by ChatGPT before engaging online tech support, and I create a document for them before beginning.
There's a third case: dealing with folks who just aren't technically savvy enough to figure some things out on there own, no matter how intuitive, well documented, or fully featured your product is.
I think I'd rather troubleshoot with a well-scripted AI chatbot, than a human being who's forced into the role of an automaton - executing directly from a script. Just, FFS, let me escalate to an actual competently trained human being once I've been through the troubleshooting.
The only thing I care about is are my problems solved for minimal effort and time invested on my part. Whether it's AI or human doing the solving, I don't care.
uh, I beg to differ. I felt like an autocomplete with a knowledge base and "direct links to the right email forms" would have been faster than the fake chat interface that the "bot" uses.
(Also, if you own a home in NY and use lemondade -- do know that they don't cover cast iron piping (extremely popular in NYC). I found that out at renewal...)
I am implementing a support system for my side project, which combines the knowledge base (FAQ) with the chatbot. You can access all the answers by browsing the FAQs. If you want to contact me, you first talk to the chatbot, which has been prompted to only answer based on what the FAQ says. If it cannot answer based on that, it will make sure all the details and problem description is there, and then forward the ticket to me. In other words, chatbot is the first line of support.
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.
This will depend on your product. I have a side project where I get a few support calls per day. 95% of the calls can be handled by just quoting documentation/FAQ verbatim. The customers are typically not very sophisticated computer users.
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.
Even LLMs can do many of what I mention. Categorizing, grouping, assigning prios etc. maybe not as good as dedicated AI trained for this purpose only (I guess many could be "simple" bayesian filters even) but good enough and readily available.
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.
2.5 million users : 24 support staff
1 billion users : 9600 support staff
If it scales linearly, that's about 10k support per billion users. I was going to say that a 10,000 person department for handling customer support sounds like it doesn't scale, but maybe I'm wrong, given that that is only about 5% of google's headcount.
Also in terms of costs: if those support staff cost 100 grand a year in salary and other costs, staffing the 2.5M-user company with those 24 support crew 24/7 (3 shifts, let's pretend it's equally busy at 3AM) results in some 25 cents per month per user that need to be priced into the product. The transaction fees on a monthly billing system are likely higher than that of a skilled support team if this is a representative scale for the industry
I frankly doubt the numbers, surely it costs more than this for an average company?
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.
I've recently encountered one that just sends you in a loop, and there is literally no way to actually speak to a real person. Unless you want to give them more money; they're very responsive in that case.
This is a billion-dollar company you have definitely heard of.
There's a non-zero chance that real humans working as customer service agents will invent facts, too (whether to try and be helpful about something they're not completely sure, or just to get a problematic customer to leave them alone)
I've had exactly one AI chatbot point me to the right documents. All the other interactions were exercises in frustration, and I've canceled more than one product due to shitty AI support. When I have a question, if an automated system could handle it, I wouldn't have a question.
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.
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.
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).
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.
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.
> Why on earth would you bet your money on some random tool you don't even understand? ... I built a tool for people who knew what harmonic patterns were.
The tool is for drawing "technical analysis indicators", one of the most convoluted ways to ascribe meaning to a random process and something that will only ever be true in the self-fulfilling sense. I don't think it's a surprise that some users are willing to blindly trust the tool, when all users of it are blindly trusting concepts that are built on sand.
Although I'm sure the author is burnt out from the experience now, I'd be interested in hearing how their next side project venture goes- is the experience more enjoyable when you're dealing with a user base that self-selects differently? Or do all users suck equally, just in different ways?
At least half of the interactions that are presented as terrible, I feel are actually quite normal and potentially even pleasant. If you don't actually enjoy talking about your product with 'beginners' or even just normal people, then maybe reconsider the customer support role?
For me this reads as 'I don't enjoy voluntary customer support' rather than my customers suck.
I see only one single sentence - "others had very basic questions, answers to which were given in the description of each script" - that might be referring to situations where people were seeking either clarification (including cases where the answer was in the documentation, but not obviously so) or advice on how to use the tool more effectively, (I exclude bald requests for 'hot tips' or source code from those categories.)
For all I know, the author might have both received and responded substantively (with more than RTFM) to many such requests, but has not mentioned them here because they were not part of the problem.
> Others had very basic questions, answers to which were given in the description of each script.
Oh, I feel that from DayJob. If it wasn't for the possible arguments is might cause about professionalism, my standard response to a client question in DayJob would be a gif from TaskMaster, looping through instances of Alex Horne saying “all the information is on the task”.
> Somehow all those claims from 'people with large communities' never materialized beyond testing the trial.
Very few people ask for something for themselves, they think they'll get a better response if they can convince you they are part of a larger interested group, or by suggesting what they are asking for would benefit “the community”.
Neither of these things is new: I had some software out there in the late 90s¹ and it was much the same back then, just perhaps less intense.
--------
[1] initially shareware-ish, then when the amount I made wasn't worth the faf of dealing with people (and payment processors), and talks with the couple of people who were interested in buying ownership/copyright annoyed me by going round in circles, it became open source so others could build take it on (no one did, they just all wanted me to continue to add features they wanted), then when I got more sick of dealing with people I buried the thing.
Side projects have always been the most exciting banes of my existence.
I LOVE the initial rush of building and launching something. Even maintaining it is SUPER exciting for the first few months. The first customers are a rush of endorphins.
Then the shine wears off. Life can't be kept on pause. Your partner wants a date night, but you have a backlog to work though. You got a frantic email from a customer that they accidentally deleted something and you currently have no way to recover that data. So now you have to add more resiliency to the application. In the middle of the night, your cron server dies, backups stop, emails stop, customers on the other side of the world can't log in.
All for a few dollars a day in revenue. Then after a year of that, you get burnt on the project. Then after another year, you stop working on it as much, the bug reports build up until you are scared to even look at your reports.
Your partner goes away for the weekend to visit their family, you get a renewed sense of pride in this project that has been limping alone. You fire up your code editor, you pull the last commit down. You start to re-familiarize yourself with the code base. Day 1 was wasted with remembering how you did things. Day 2 starts with a coffee after only sleeping a few hours. You begin to work through the small tasks on your list, because you feel the snowball will work. About 8 hours in, you've made a SERIOUS dent in the backlog. You are feeling good and decide you should eat something finally. Your partner comes home while you are eating your breakfast at 4pm. They start to tell you about their family drama. You start to fade. You walk back to your office and try to get back into the groove. You can't. The weekend is over. Work starts again in 10 hours. You now feel angry that you wasted your weekend, and have to do real work in the morning.
I recently read an HN post where a LOT of people reported having the same rather specific dream that I have had many times (about being enrolled in a class they forgot about only to remember on the day of the final exam). It literally rocked my world to see evidence of how similar all of our 'wetware' is. And now I'm reading you describing a scenario I have experienced so many times, right down to 4pm breakfast and distracting stories of family drama. I am now pretty much convinced we live in a simulation and we're all subclasses of each other.
I have done this loop dozens of times, sometimes for pleasure projects that are released for free, sometimes for projects that make $100/week. It's hard to maintain motivation when you are working for less nothing.
I've actually stopped launching software now. I devote my passion projects to things where the customer is a one-time interaction. No support, no emails, no late nights working out why there is a 500 that only happens on this ONE user at 1:16AM.
Now, I make rolling trays, refinish antique furniture, and garden. In the new year, I will be converting half of my workshop into a CBD/hemp farm to grow my own hemp to make my CBD tinctures and oils (currently I buy CBD flower from Oregon).
Software has stopped being my only source of joy and income. After 2 decades of programming almost every single day, my brain is tired, and I don't even know what it was all for.
My garden provides nectar for bees, vitamins and minerals, for myself and my family, sunshine for my body. My woodworking provides that sense of pride that I had with software without all the bugs (well sometimes there are grubs in the wood). My CBD is "medicine", and it helps my dad with his phantom limb pain, me with my Hashimoto's flareups, and other's with their anxiety and stress.
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.
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.
I don't think that 'everyone an entrepreneur' would increase economic output and productivity, and the fact is that some people just want a paycheck because they don't really care about making more money than the paycheck gives them, and the work is fine.
Indeed. I love that my career is a minor sideshow of my life. I love the stability of working about 40 hours a week and then doing what I really want to be doing with life.
It’s a bonus that those 40 hours don’t feel like work.
I imagine that the creative class was revered and feared. Potters had very low status making a commodity product that everyone needed. Hard to say what was going on.
My solution largely came out of recognizing this reality. So I just don't do side gigs. I channel that energy into little tech projects that do not seek to be a salable product. So I make my living 40 hours per week, and then do the rest on my terms.
It was practically dogma ten years ago that the CEO that built the business was not the CEO that took you public. In the late '00s and a big chunk of the '10s they swapped board members in order to go big.
But if you kill the culture before the IPO, then you have nothing and nothing.
True. If you want to spend all day programming, be a contract programmer. Don't start a software business - you'll spend a lot of your timing doing admin, documentation, websites, newsletters, accounts, support etc.
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.
Also its easy to verify that it doesn't work but hard to verify that it does. So often it might take time to verify that and when you're confident about it you've lost the chat session or closed the browser, restarted the computer, went home already etc.
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!
> 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.
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.
And this is why I would make to sure to log all the time that I spend on that side job, so that I can make some estimate about what my hourly rate would be with the earnings I make.
This might then allow a better decision on whether it is a worthwhile endeavor or not.
It sounds to me like the really valuable product here isn't the harmonic charts but the little automation platform (based on n8n?). I can imagine there are plenty of devs with even less tolerance for customer service and actually running a business, but are happy to build software and sell it to people.
Over the years I have had some good (to me) ideas for side projects, but I have always hesitated to build them rationalizing that the potential market was way too small (a fraction of a fraction of a fraction of developers).
If anything, this post shows how wide - or deep - any internet niche is.
Well, this is interesting because what you described is the best way to start a project. Trying to build something too broad from the get-go is very likely to fail, starting small/specific and expanding from there usually works considerably better. If you research famous large companies you'll find that almost all of them did precisely this.
I've been in a similar boat running a small B2B Saas over the last 2 years.
Over the years I've learnt a lot of tricks in this area.
- 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.
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.
Idk. It’s totally ok to just ignore those types of requests. Even a lot of the requests the author was getting. They’re just fishing and there’s Practically zero chance they’ll even ever follow up to see why you never responded.
Mega corporations get away with awful support of paying customers, people don’t actually expect you to jump at their command as a startup or even as a toy side project. If you’re able to ignore a beggar on the street, you should be able to ignore a lot of these emails. Stop guilting yourself into a heavy administrative burden and don’t avoid consumer apps because of that fear.
I get it but main thing is you should know that's a choice and it shouldn't be a requirement/burden. For the common things I think I'd just setup an autoreply that said something like;
Thanks for your message, please know that we are limited on time and only respond to critical issues. However, also please know that we do eventually read and monitor these emails;
- Bug reports or issues on our current application: we will respond within a week, usually within 2 days
- Feature requests: we are unable to confirm when or if a feature will be added. We typically put it on a log and review them quarterly.
- Requests for source code or how our tool was built: we're glad you're curious however we do not share this information.
Taking up to a week to respond to a bug report sounds like a long time. I would wonder that anyone would bother to submit a bug report if they think they might have to wait a week to get a response. But I guess its acceptable, if you set customer expectations accordingly.
A week can be a long time, even 2 days might. If you want to respond sooner that's great, they will likely be pleasantly surprised. However, for those times when you're offline for the weekend or on holiday for a week - the messaging helps you out with no extra effort to update it. Always better to under promise and over deliver in my book.
I also think expectations are relayed based on the price and scale of your business. Being transparent about your operations is helpful. If you're running your business as a one person side project but pretending to be a large multinational corporation (which is common) or charging a larger sum of money for service then perhaps it's expected. Also if you're providing some mission critical application, then probably expected. The author is talking about a charting plugin to a trading app that he charges peanuts for and has no intention of continuing development on. I think most people's "businesses" fall into this camp, even if mildly revenue generating. In any case, it's mostly about setting and managing expectations. It helps if you are transparent if you are not actively making improvements or it's just a hobby/solo/side hustle thing for you. At the end of the day, they can decide if they want to discontinue using your thing or not and if your optimizing for "least amount of time invested" then you also just need to come to accept that some churn is the price of it. Obviously, if you can charge more or have a huge amount of users, that churn becomes negative ROI versus providing more attentive support and that would likely justify a change of strategy - for some.
> 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.
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.
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.
> 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.
This is a perfect example of how attaching money to a hobby is guaranteed to ruin it. Dealing with customers is a gigantic pain in the ass, it doesn't matter if it's a large product or some niche esoteric project.
I have the exact same issue regarding support with a simple app I have on the App Store, I can perfectly relate. Despite being a really simple app and extremely cheap, every once in a while I have to wake up to angry e-mails from disgruntled users.
No. I just checked the front page [1] for each August 21 from 2014 to 2024, and there is typically no or one complaint in the title. Some lamenting here and there, an uplifting tone every now and then, but most of it is neutral.
Perhaps you are running into some negativity bias? [2]
The other actually happened to me recently, my wife answered one of those automated bank texts checking on a transaction with no, which cancelled the card (and marked it stolen), and I tried to use it before she told me about it.
But yeah those are the only two I can think of and yours is the case 99.99% of the time.
Not all B2C is the same. If you make a product for professionals you won't get random chargebacks, incoherent emails, or general rudeness. One great way to filter for professionalism is by simply charging more. Another strategy is making it harder to purchase the product. For example by disabling the checkout process until people have completed the tutorial, or only allowing purchases after the free trial has expired.
These strategies don't maximize revenue, but you don't have to maximize revenue. You can optimize for revenue/agony instead.
Agree with all of those, and such a business has B2B potential also. That describes mine pretty well. And while I’d love to make more B2B sales, I hate dealing with purchasing departments. Dealing mainly with professionals definitely has its upsides.
That's a great way to put it. I'm going to start using that one.
Tangent: I'm a programmer at a small company, which has three programmers total. I make a decent wage, but one that's significantly smaller than I could make at a larger company. I often get questions from people who can't believe that I'm not jumping at these other opportunities, but I make nearly six figures, my team and bosses trust me, I have nearly unlimited flexibility to choose what I work on and shape my software the way I feel is best, and I get to work full remote and basically make my own hours, giving me all the time I want with my family. It would take an incredible raise to give this up just for better pay.
An agony-per-dollar ratio is a perfect way to frame the calculation, and it factors into so many places in life. Many forget that it's not just optimizing for the most revenue possible, but a balance of maximizing revenue and quality of life, and often getting diminishing returns when pushing hard on the former.
Sounds great. Also, if you went to work for BigCo and got a big pay rise, you would probably very soon get use to it and it wouldn't make you much happier. I wrote a bit more about this topic at: https://successfulsoftware.net/2013/11/06/lifestyle-programm...
It's better but this is not uniformly true. For one, people use random sites to test cards to see if they can get away with using stolen CC details at every stripe-integrated company I've seen, target audience irrelevant.
The proportion of negative/wild interactions with support and chargebacks is always going to be in an uphill battle with positive correspondance unless you are selling multi-seat deals with support as part of it. I speak a little out of my area of expertise here but from my friends experience, the downside to professional services is that a small proportion of people, or people on bad days, see it as a service, not a SaaS, and will willingly throw threats, insults, etc at you. A small error on your service can stop their whole business which is different for B2C - it's the difference between fear and frustration.
> people use random sites to test cards to see if they can get away with using stolen CC details
I already addressed this. By forcing people to use the product before allowing them to purchase you make drive-by fraud impossible. We use stripe and we have 0 fraud to deal with.
You didn't read my comment for what it meant, I think.
This isn't automated, it's people in 3rd world countries signing up to random sites that have CC as a method of payment and seeing if payment goes through.
You probably pay for Stripe Radar and don't see these payments but are also silently missing out on legitimate payments, or you run KYC or have too few or only western access to your site otherwise. Have you spoken to the people who manage your Stripe about the disputes and how many are fraud and the Fraudulent payment detection numbers you have? It won't be 0 for any substantial business.
You really are not hearing me. Our legitimate traffic looks nothing like fraud traffic. Legitimate users don't sign up for a free trial, ignore our application, zoom straight to the payment form and purchase. 0% of our legitimate customers do this. Everybody wants to try before they buy! You can literally lock the payment form making it impossible for people to purchase until they have used the product for multiple hours over multiple days.
Nobody in a 3rd world country is going to spend 5 hours clicking around in a product over multiple days just to test if a credit card works. If card testers don't find the payment form within 2 minutes they're going to move on to a weaker target.
People who struggle with fraud in SaaS usually make no attempt to distinguish real user behavior from fraud-y behavior.
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.
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.
Take my advice with a grain of salt, as I am a customer rather than someone running a product with customer support.
I would say this would only feel justified if the product pricing page already had clear tiers outlined for paid support. Putting a price per hour on customer support otherwise would make me feel like I am just being milked behind closer doors for more money, and non-paying customers are getting shafted. If a paid customer support tier is something you offer, imo it should be clearly outlined on publicly available pages with explicit explanation about the differences between free vs paid customer support. You suggesting it in private communications only would feel suspicious and shady to me as a customer.
However, if the customer themselves suggested to pay you extra for that personal support, that’s a different story.
I'd 100% expect that to be a template from someone who either has no clue and can't investigate, or has 200 other tickets to get to and couldn't be bothered to look into a case that isn't in the FAQ. It also does not say what makes you have this assumption and so it works only as a brick wall to alienate any customer goodwill you may have built up. Please never write this unless it's self evident why it's on the customer's side and you have good reason to think they're just trying to annoy you by reaching out despite that
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.
Just wanted to say thanks, I think you've given great advice. In particular this bullet point:
> But don't allow issues to go stale. To really wow customer service, reply as humanely quick as possible, especially for existing customers.
As a customer, the absolute worst possible thing for me is to be left in limbo, not knowing if my problem will be fixed in the next minute, hour, day, or never. While I may not be thrilled if the answer is "never", at least at that point I can move on and know that I'll need to solve the problem some other way.
But if you respond consistently quickly, then some lazy customers will email you rather than bothering to look in the documentation. So there can be a downside to being too responsive.
> 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.
This is the biggest thing I struggle with. I have a couple of semi-successful side projects. They bring in some money, but not enough to hire someone to help with support. I have never been at a place in my life where something like "I will response to all support requests within 48 hours" is remotely realistic for me. I'm lucky if I get to a support request within a week or two.
I don't know what the answer is beyond just "don't sell products", because I hate dealing with support more than I enjoy making stuff to sell.
Sometimes it's valuable to receive a (clearly non-automated) support response indicating that the message was received and a proper response is in the works, just to confirm that the support channel is actually still functional.
Even just confirmation that the website form isn't a black hole and that support tickets aren't now exclusively accepted through Twitter, Instagram, or a secret discord server can be very reassuring.
A large part of my job is end user support in a corporate environment. I always do this - even if I know an issue is going to take a while due to me having to reach out to other departments/a vendor, wait for an answer, and potentially go back and forth, I always reach out to let people know I got the email, that I'm working on it, and that I'll reach back out when I know more. If possible, I also suggest workarounds/alternatives for them to use/do in the time while I'm working on the problem.
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!
>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'm pretty sure it's because they're not paying full attention, even worse, sometimes already building an intense narrative with only few items internalized inside their brains.
I also feel that this is happening more and more, since there's more rewards for giving very small pieces of attention and energy to a bigger pool of people, instead giving extra energy or attention to a smaller pool of people seeking for one's help.
I'm just facing this with a contractor doing repairs in my house, a month ago was finding a decent mechanic to fix just 2 issues on my car.
The first promptly finds energy to discuss things it receives through social networks or messages, but can't provide a decent list of things that I need to provide him to finish his work faster.
The second case took a lot of time and discussing with 6 different mechanics, until th car broke and it was towed.
Or simply their priorities are not your priorities. They have encountered a problem, they asked for help, but they have 10 other things going on. By the time you answer, they have forgotten half the context of the issue. They try one thing, it doesn't work, they don't have more time right now so they answer that thing 1 didn't work. Repeat.
I find most people suffer from at least one (and more commonly two) of the following: insufficient attention to detail; poor time management; and bad organization skills.
This is especially true in the trades. If you're able to:
- be on time
- respond to emails/texts, and especially: phone calls
- give quotes
Then if you're even halfway competent, the world is your oyster. Please come do work for me!
If you can manage people and budgets, you can have more work than you'll know what to do with (assuming there's work available).
The inability of many people to focus their attention and prioritize their work is shocking to me. This isn't just for the stereotypical "younger adult" either, this seems to apply across the board (and especially to boomer-aged adults!).
That actually sounds like a good idea for a technical support app:
The only interaction possible is they can tell you the problem, then you can give them a list of things to try, and they can do nothing but give feedback on each step, in order, and you arent bothered until they at least respond something for each step
I'm starting to think Humanity's problems are not technical in nature. I don't see how to even think about forcing people to help themselves.
This is obviously satire, but we could make every internet app completely modal: once you start a flow on any site your computer prohibits you from starting any other flow on any other site before you complete the previous one.
.... I also found this link while looking for the above article, https://www.quantumbalancing.com/news/bluetape.htm . That's. ... just... well. Not what I was looking for, but was so remarkable that I thought I would link to it here. I suppose they have probably sold some of their devices. I'm curious to know what the insides are like, but not curious enough to spend $1k+.
Oh, no. It's not a shuffle. They unerringly identify the least important possible action item. Sometimes just a single clause of a single sentence in a list item.
You have to scour your communication of anything that can possibly be interpreted as an easy request. It has to be a curt, imperative, isolated, request to do something hard or it will be ignored.
In written communication it often works for me to create an explicit numbered list with indentations and plenty of white space between the items. It also makes it easier to refer to the items in the following communication.
I really wish there was a reliable way to ask people.
"I need your engagement level to be set to 10 for this communication. It's ok if you can't do that, but then just say you can't do that. I'm already set to 10 and rando guesswork / tidbits are only going to cause problems."
Even just "nope can't do it" responses would save me time.
I just got off a critical call with folks pulling stuff out of their ... and it was a nightmare / complete waste of my time.
I think that's unreasonable to ask for just about anyone. The only time that's going to work is if you're helping them with an issue that's critical to them. Otherwise you are never going to get their full attention, it even close.
Much easier and safer is to drill into your own head that your own engagement level may be at 10, but the other person's is probably going to be more like 2. And that's fine.
> I think that's unreasonable to ask for just about anyone.
Notice your parent doesn't say "you must be at 10," but rather "let me know if you can't be at 10." I think that's perfectly reasonable, as long as you're willing to accept almost always getting "no."
> Much easier and safer is to drill into your own head that your own engagement level may be at 10, but the other person's is probably going to be more like 2. And that's fine.
But sometimes that's not fine! For example, if you're giving a list of instructions for some safety-critical procedure, it's not fine to find out later that the nodding "uh-huh, uh-huh" actually meant "I'll do what I remember and what sounds easy," and it's much better to do nothing than to proceed with partial information.
I think this issue is a lot of why ChatGPT feels smart to me. It actually parses all the parts of what I say and tries to respond to it comprehensively. It doesn't always succeed, but it's usually better than my experience asking a multi-part question to a random real-life person in a support role.
This comment should be three paragraphs. As written, it’s very hard to read and I get lost.
If this was a professional communication and you had asked three questions, I might understand one or might not. Now I have no issues saying “dude, your writing is very hard to follow.” But what if your colleagues are nicer than I am?
Or just spitballing. You’ve admitted that you’re the kind of person who will set traps for your colleagues. What if they’re just sick of your shit but are too conflict avoidant to say that?
Okay, different person as the one you responded to. Your entire comment was reasonable up until the last line.
What is that even based on? Where did they admit to setting up traps? Is that your take on their comment about trying to ask three questions in one message?
Because, even without them creating paragraphs, it is abundantly clear they just mean that as something from experience. Not something they do as something to spring a trap on people.
“When confronted (constructively, much later) they usually get evasive and can’t explain.”
Confronted is a big word with a hostile intent. They’re incredibly measured in their language and use precise language. That sounds like a trap to me - it’s:
A.) Asking three questions and only get 1/3 answered.
B.) Waiting for a suitable period of time to elapse.
C.) Confronting them while expecting an explanation.
Letting time go by, “confronting them” and expecting an explanation is a trap. It assumes that they can even remember the conversation! Why not send a follow up email immediately and politely ask again? Heck, that’s a good excuse to use “circle back” in conversation. :)
If you missed that first read, no worries because so did I. I had to read the comment three times and then I kind of shaked my head because they are so measured and precise, and that’s an awfully big statement to make about colleagues.
Confronted isn't necessarily a hostile word. It is a very apt word to use for the action off asking someone about the other two points. They even made it clear that it was in a constructive manner.
May I ask, do you often feel like you are operating in a hostile environment?
You’ve admitted that you’re the kind of person who will set traps for your colleagues
We were all close and could discuss “meta” from time to time, in a friendly constructive manner. You’re probably reading more into this aspect than there is.
There is a Youtuber and AI safety researcher that I support on Patreon's "poor person tier" and they were gonna do a Q&A video so asked us to offer questions for the video, so I offered five in one post as a list.
They wound up answering every question in my list of five, spent enough time on some of them that I think that may have been part of the motivation for them to break it up into two videos, and even emailed me the answer to the one out of five points they didn't address in the video.
In contrast if I render a list at any of my colleagues or vendor dev teams there is a <20% chance that they will address or even acknowledge 2 whole separate items out of the list, so the points they don't address get frequently brought back up again and dropped again. :(
So AI researcher has..
..list comprehension.
(YEAAAH!!)
At my last job we had a customer who was famous for doing this. Since he generated a significant amount of sales, we couldn't just sideline him, so I learned to only ask one question at a time on email. Otherwise, if you asked e.g., three questions, it was a complete tossup as to which one he would decide to answer, all the while reminding you that this was a "hair on fire" issue for him.
Compounded with the fact that he was on another continent, multiple time zones away, this made debugging anything a difficult proposition.
We had another customer for the same product in the same country who had absolutely no problem answering whatever questions you asked him, in as much detail as he could supply. It has to be a personality thing.
Them: Don’t close the ticket, I hadn't had a chance to check that yet.
Life gets in between and this one library or project is usually hardly the only thing that person juggles. We need to accept, that sometimes issues remain open for an extended duration. The worst is, when you have the same error or issue someone else had already, but their issue got closed by an effin github bot, that automatically closes issues, because someone hasn't replied for a day or two. Like, you are not the center of the other person's life. Just like no one forces you to work at no cost for others and help them, they should not be forced to give undivided focus to your project's issues.
Having bots close issues, accompanied by a rude automated message is often contra-productive. It would be fine to instead post a reminder in the issue, asking for an update like shown in the example:
Me: Just checking in to see if this is resolved?
This is actually a very polite form of handling it.
I almost never see bots close issues that are less than 30 days old. Many projects can change a lot in 30-90 days and the bug may no longer exist, keeping issues open when they may no longer be relevant isn't helping anyone either. If it is still relevant, it can simply be re-opened. I don't see any downside to semi-aggressively closing stale issues. If it's easily reproduced then most good projects will mark it so that it won't be auto-closed.
Usually it can't be reopened because you can't even really get someone to look at it, because issues are wrongfully closed so frequently that they don't pay attention to complaints about the closures.
When I see some bug like this I do wonder why don't more people fix the issue themselves or think that it might be specific to their setup or accept a little random lag.
If I received a bug like that I would immediately think why are you telling me this... just fix it yourself and share your fix if you want. I probably have higher expectations from my users. You give the software away now they want you to fix it for them.
> If I received a bug like that I would immediately think why are you telling me this... just fix it yourself
Then you're part of the problem.
I am far less equipped to handle a bug like this than you'd think. It would take me so much more work and time than asking someone who already knows the project and how to work on it.
If I did this for every bug I reported, I wouldn't have a job because I wouldn't have any time left for one.
You know, this is also my issue with Linux. The attitude is generally that if you want to run Linux, you are expected to do anything you need completely on your own, including fixing bugs. This is why macOS is my preferred operating system. (Not that I can run it right now...)
I'm of course not entitled to anything from you (or anyone), but the one thing I won't do is fix it myself.
I don't really want to be a hacker right now. I've tried. I can be, but it rarely pays off for me. Not even financially, just emotionally.
> If it is still relevant, it can simply be re-opened.
I've seen places where tickets were not allowed to be re-opened. If a ticket was closed for any reason at all besides a misclick, a new ticket had to be opened with a link to the old ticket if necessary.
Automatic closing tickets is a solution looking for a problem. Humans should close tickets when they're resolved or no resolution is anticipated or planned. Putting an arbitrary number of days on it with a one way trip to the [closed] tag is like following a broken clock because it's right twice a day.
This. Usually if you are looking at tickets closed, that means you are using that as a metric, which is a BAD idea. Ticket lifetimes and movement are more appropriate metrics.
What I find really infuriating is when I was the last person to post on my issue, and I'm waiting on an update from the maintainer, and the github bot threatens to close the issue on me for not posting any updates!
I've started replying to it with "No updates here." to reset the timer.
Me: This very specific thing is broken in general for your product when I do a and b. Just like users x,y and z report on <random forum>.
(Siemens) Support: Before I can help you, please find the serial number via <tedious procedure>, and the exact version of subsystems <x, y and z>.
Me: Here you go, though I fail to see how my specific setup is relevant as the problem has been reported on forums for years, and it is easily reproducible
Support: Please update to latest version x.
Me: Version x has known regression which will break the machine for the customer. I did the 1 hour procedure anyway but the issue is still present.
Support: Please execute this <obtuse command that runs a trace> and download the log from <airgapped machine> with SCP
Me: O well, did that here is the file. Don't understand why you can't run it on your machine
Support: Please try <irrelevant thing>, reboot (wait 5 minutes) and run the trace again
Is Support just completely disconnected from Engineering? Do they not have a way to report issues and indicate that many customers are having a specific issue?
Does the company believe that giving a customer a runaround will make them less upset than saying "Sorry, this is a known issue. We're working on it but do not have a timeline"?
Certainly at some point, some support person is going to be like "Huh, we have a lot of customers complaining about an issue, and our usual flowchart script doesn't seem to resolve it" and try to work it up the chain, right? Or does it get to their manager who says "Meh, that's an engineering problem, not a support problem. Get back to your tickets!" and never pass it up?
If you're working with a large company, Support is outsourced to a bunch of people reading scripts in Manila/Bangalore, and the external company employing them is actively incentivized to never resolve the root cause of any issue, because doing so would mean less tickets and less billable hours.
In my first job in a software maintenance project, I was overenthusiastic and was closing issues left and right. My manager called me to his office and told me that if I solved all the issues, the project will need much lesser people when they renew the contract, which might lead me, the junior most person, to be sent to the bench until they get a new contract.
Sounds like something that could be turned into an opportunity. Immediately start looking for a different job, and on the interview explain “I left previous job because I was too efficient at solving problems. After X time, there were no outstanding issues so I was no longer necessary. I’m looking for the next place where I can make a difference”. There are plenty of places that see fewer issues a positive.
To give you the other side of this, I have had service providers obviously do this to us. It didn’t result in more billable hours at renewal. We just systematically moved teams leadership to a competitor - we have found that mixing companies of origin in teams keeps everyone more honest - and removed developers we thought were not meeting the productivity standard we were looking for.
Cheating your customer is a dangerous game. They are not dumb.
It’s not that we were inefficient, we got some 80+ tools to support without any knowledge transfer or documentation. We got regular issues, and I was digging to find the root cause and solve them for which apparently we weren’t paid.
Yes. Engineering time is expensive. Support exists to resolve problems without needing engineer time except when the company thinks that the problem is worthy of being addressed.
The tendency to wall off engineers is often taken to a counterproductive level.
Obviously, not every support ticket requires engineering attention. I would wager at least 90% don't. In the case of B2C businesses, likely 99.99% don't, considering 80% are customers that simply need a password reset and can't figure out how to do the most basic Reset Password -> Open E-mail -> Click link -> enter new password flow.
But there's a line SOMEWHERE. The few tickets that DO need engineering time REALLY NEED IT, and it's completely asinine that in some corporations, it's impossible.
If, for example, 100 people are talking to support for the exact same crash, and people in support are able to reproduce it, it needs to go to Engineering, rather than support telling customers "Have you tried formatting your drive and reinstalling everything from scratch?" when they already know it won't fix anything.
The best place I ever worked had fairly sophisticated, formal channels for noticing when a cluster of related-looking problems happened repeatedly, and escalating that to engineering for a fix. It also had open Slack channels with engineers and product managers in them, and some informal understandings about what type of problem was appropriate for support or professional services to bring up, there.
That combination kept the customer-frustrating bugs quite low, while still allowing engineering to keep developing new features at a fairly rapid pace.
(and then we got purchased by a PE firm and dismantled)
I think sometimes the company doesn't know what to do or doesn't care. But they have to make some response. So they just ask you to do a load of busywork, to keep you out of their hair for a while.
The other side of the coin is that support gets an ocean of lazy/unrelated/confused support requests that the engineer cannot help with, and responding and explaining that eats up a huge amount of time. I don't know that I agree with putting up barriers to reach support, but they are trying to address a real problem and I get where they are coming from
i remember we had similar issues at my 2nd to last job a bit ago. we would often times try to reduce the friction, but it built up and built up until, one day, there was zero chance of reaching anyone worthwhile. i wish we had gone back and really focused on providing as much support as we provide in product!!
sometimes we're aware of an issue and management has decided its not worth the effort to actually fix it, but also management doesn't want support to straight up tell people we wont help you, so they basically obfuscate
> Is Support just completely disconnected from Engineering?
Support is almost always tiered because $$$. In an ideal situation (hello GitLab!) tier 1 they are friendly and competent triage artists that can redirect lost customers and handle the common basic cases. Tier two is essentially an experienced and skilled tier 1. It's not until you get to tier 3 that you reach an engineer, usually one dedicated to support. That engineer is the one who reaches out to the operational engineering team if needed.
This is the usual response when a companies customer numbers start to scale up so far that the volume of users like the ones in Vegenoid's parent comment start to overwhelm the support staff. Keeping up the good/decent customer support that you could give to your first few hundred or perhaps even few thousand users eventually becomes ludicrously expensive or even impossible.
Then the original article's "Keeping this running and supported is shit. People are idiots and time wasters! Automate all the things!" stage kicks in.
So "first level support" is created, who's main objective is to get rid of support requests with the minimal effort by the least skilled staff possible. So everything is written into a script that call centre employees are required to follow. Low skill minimal wage staff are required to ask stupid things like "Have you tried reinstalling Windows?" and getting a confirmation that they have - before any support request is passed on to even a junior or intern developer. At this stage nobody gives a damn about users who need help, and they outsource that work to other users on the "community forums" and the entire support team is fired.
(Google, of course, being a world leader in both webtech and customer acquisition, completely skipped the "provide decent customer service" stage and went directly to the "don't give a damn about users" end game.)
As mentioned in another comment, support shouldn't be entirely disconnected.
If a customer seems to have discovered a legit bug in the software, there needs to be a path from support to engineering for the bug to get reported.
At the very least, support staff should be willing and able to attempt to recreate a bug that a user is reporting, rather than asking them to completely wipe their device and install everything from scratch for something that is easily reproduced.
Let's take a very simple example. Imagine you've got this Chess app, and whenever someone creates a checkmate involving two bishops, the game crashes, 100% of the time, but only in cases involving two bishops. Sure, maybe the first ticket you get, you go through the workflow of reinstalling, etc. But by the time you've got 100 tickets all saying their game crashed on a checkmate involving two bishops, that should have been escalated to engineering. At the very least, support should be saying it's a known issue. Honesty is going to be a lot less frustrating than to be told to take steps that both sides knows won't fix the issue.
These flows are intended to dissuade problem reports, because the business is too big to care.
I once reported a ui bug to Discord(the game chat). This is how it went.
- me wrote an elaborate email and screenshots of the problem with step-by-step guide to reproduce it
- support responded me by asking build version, my os version, device type
- me screenshot all the requested details + manually wrote down in response email so someone can also copy-paste somewhere directly from my email
- support responds by asking me to clear my iphone cache(sending me a guide for Android's App data cleaning process) and see if issue persists
- me respond that it is not Android and since I knew what they will ask, I have uninstalled, reinstalled, logged-out, logged in and documented the whole process by recording my screen while doing it
- support, please try to logout, then uninstall and reinstall again
- me begrudingly do it again(record screen), send them everything
- support, could you try updating your device OS?
- me check for updates, iOS says it is latest, me send screenshots
- support, can you try disconnecting and reconnecting to your network or rebooting your device?
- me follow the steps(by recording my device using another device) and send it back
- support, can you try factory resetting your device
- me get pissed off, I mean c'mon, the issue is that, the client is incorrectly handling the on-screen keyboard events and has nothing to do with my device,
but giveup anyways and write on twitter that I tried to report an ui bug, is there some engineers I can reach out to?
- twitter official DM me and what do you know, it was the same person who was responding to my emails and tells me, if I tried resetting my device to factory default, else they'll close my ticket as not reproducible
I just gave up and uninstalled discord. I mean, sure there are lot of useless problem reports, but when your user goes on to extreme lengths to document an issue and cooperates, please take it seriously.
In most cases, the whole script is intended to deter the less patient consumers/users and not actually solve any problems. In some cases, the support is just an outsourced team with no connect/contact with actual team or the product.
This is me almost every time I interact with ISP support.
Except… recently I completely misdiagnosed something. So while I was getting politely frustrated with the support clerk, he was stepping me through a set of irrelevant seeming procedures which, indeed, resulted in identifying that a piece of hardware was broken.
In this case it was the fiber to Ethernet adapter my ISP uses. He needed me to verify that, at every step of the way, pieces of my infrastructure were not the cause of my flaky connection (they weren’t). However, as a final step he had me reboot the adapter and it didn’t start back up. Turns out this is a rare failure mode and the flaky network I’d been seeing was an early, year long, symptom of this issue.
I had DSL with a router and modem. I never had problems with it, never required reset etc. Over the years somehow I forgot and thought it was a combo router and modem.
Then when I finally had a problem, I insisted to customer support I had done many power cycles already. They scheduled a tech to come out, but I realized my mistake before it went that far at least.
I went as far as going out to one of the local metro offices for my ISP in the city, to demonstrate some bizarre problem that I was experiencing with my combo router / modem.
I was actually able to demonstrate the issue in person, and everyone was scratching their heads trying to figure out what was going on.
I decided to try factory resetting it as a hail mary... and instantaneously I got a perfectly functioning ADSL connection.
It would have been far less embarrassing for me to have thought to try that and make the effort at home. lol
What do you do if you are incorrect? It has happened many times that a customer calls certain they know what the issue is and even if the customer is well versed in that field he may be wrong.
I hop on video and do screen share. It probably takes less aggregate time, they think they get special treatment when really I'm just saving time and I know how my stuff is being used more.
We had a Salesforce consultant who was like this. I'd send him a list of five things he needed to do to make his jitterbit connection work with our internal API.
He'd do one thing, report that it still didn't work. I'd ask if he did the other four things. He'd do the next thing, report that it still didn't work, etc.
God only knows how much that department was paying him.
_This_ is exact the place where a LLM could step in and could really help:
1. Customer describes the problem
2. You get the problem, parsed by the model, including a summary and a suggestion what could help.
3. You write "do that 3 things"
4. The model tells the customer to do the 1st, then the 2nd and so on
5. The model reminds the customer in intervals that things are not completed
6. the model notifies you after the 3 things are done and the issue is still there.
You don't need an expensive, opaque, antisocial system to run interference against your users. What you need is literally just a checklist.
Give the user a checklist instead of just freeform text -- where they can check off the three individual things to try. When they've checked them all off, they can go back to the well for another response from support.
I had this experience with an online game crashing. This is a game I play all the time, which recently recieved an update that adds a kernel level anticheat program. The game would start and then black screen, and I would get a null reference exception popup. Audio and input would continue without any graphics. To me this likely indicates a lack of init result check on some pointer that gets passed to a graphics init function, and then they try to access the pointer that was never assigned to. (my guess anyways)
I was punushed for "leaving" the game, banned for a couple weeks, and sent an obnoxious email about my bad behaviour. I reached out to them on customer support handfuls of times and was always given a list of three steps such as "upgrading graphics drivers", "ensuring i disable my firewall", "using a pc with high enough specs" (my machine is ridiculously overspecd) and things like that. I would follow the three obviously pointless steps, and then be given another set of obviously unrelated steps. This went on about five times over a month.
At some point I just told them, look im a fucking game developer, give me a log dump tool, or a build with debug symbols and I will fix it myself, and finally a real human showed up and actually sent me one. I recreated the bug and sent log captures but they wouldnt let me help beyond that. Then at the end they still scolded me for "leaving" the game.
I dont blame the average person for expecting customer support to be unhelpful or a robot by default, and not following steps.
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).
> - 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.
Recently, I canceled a subscription for a newspaper, they make you go through chat to cancel. The agent was so nice that it was annoying.
I don’t mind waiting in silence, but when they keep asking about weather, vacation plans, etc, I find it hard to not respond. This might part retention technique though.
Outsourced call centers obsessing over dumb metrics like "dead air" and "hold time". They think you are gratified by obsequious groveling and fawning reassurance. There is always some guy in management who gives pep talks about improving outcomes by avoiding words like "can't" or "impossible". He demands improvement to an already satisfactory situation, and so they scramble to out-customer-service themselves.
Is this very specific to the culture? In many cultures, there are standard written greetings that always appear at the start of a letter or even email response.
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.
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.
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.
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.
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!
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.
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.
> When I get an email, I try to answer it as best as I can. Years of working with clients taught me to explain things in a simple and easy-to-understand way. So, I spent hours patiently answering questions from potential customers only to never hear back from them.
I’m a big believer in choosing your battles when communicating online. I’ve found bad grammar, lack of focus, confusing content, etc are all signals that the sender didn’t put much effort into their communication, and if I respond to those at all I usually put in proportional effort. Rarely have I experienced low-effort comms leading to high-reward outcomes, and I found my mental health benefits from the “justice” of proportional response. I’m curious though, the writer seems to imply that lack of active communication led to a decrease in sales. I wonder if/how my approach could be sabotaging me.
What is the name for the economic fallacy or paradox where I see an article like this and thing "$15k over 4 years is not worth my time" but if you were to ask me if I wanted $15k or a small fraction of that right now with no recurring aspect I'd take it in a heartbeat? That's how I feel reading any of these side project pieces. I look at the total revenue and how long it took them to get there and I groan thinking how I'd hate to do that. Maybe I'm just too focused on hourly rate?
That's called rationality. The paradox is thinking it's worthwhile to squander the few free hours you have to make a number go up.
OP made $15K selling snake oil of a specific nature that, if it were a legitimate product, would have made far more than $15K if he simply used his tool himself instead of productizing it and selling it to rubes and crooks.
440 comments
[ 2.4 ms ] story [ 414 ms ] threadForum didn't last too long after that.
I still have the source code somewhere, which was about 25,000 lines of ASP in one file!
I have never envied any CEO, VP, or manager I've worked for their job. The hardest part of my day is crafting novel SQL queries or tricking C++ into compiling code that will work on all my target hardware in spite of an unknown number of undefined behaviors. I've never had to figure out how we're going to keep documentation in sync on our flagship project when the head documentation engineer is dying of cancer (and has chosen to finish out the week because he knows how screwed the project will be without him and he believes in it), or how to make payroll next quarter if the next investor says no, or how to keep the quarterly goals met when the President has just declared that all of our employees working in the country on a visa may suddenly not return to the country.
AI isn't an improvement for companies that already provide great customer support, but it has the ability to seriously raise the bar for companies that want to keep customer support costs low or that have a lot of trivial requests that they have to deal with cost-effectively
Or for really common cases (ie. turn it on and off, you're affected by an outage, etc), redirect them to an prerecorded message and then let them know that they are still in the queue and can wait for a person. 9/10 it'll solve everything, but also reduce friction of simple things that might be answered.
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.
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.
Everyone has some amount of common sense. The current state of the art does not, so it cannot make decisions. This is why these things can't currently replace real support beyond being a search function exceedingly capable of interpreting natural language queries and, optionally, rephrasing what the found document says to fit onto the query better
You can't even have these systems as first line support, verifiying whether the person has searched the docs because you can't trust it with a decision about whether the docs' solutions are exhausted and human escalation is needed. There currently simply needs to be a way to reach a human. I'm as happy as the next person to find that a no-queue computer system could solve my problem so I use it when my inquiry is a question and not a request, but a search function is all they are
By the time I have an issue, I have usually covered basic ideas and FAQs already. Currently, I tend to use perplexity supported by ChatGPT before engaging online tech support, and I create a document for them before beginning.
"We choose not to pay customer support well".
I've worked at companies where customer support was both strongly supported, paid well and given the tools to do their jobs well.
They were incredible.
I think I'd rather troubleshoot with a well-scripted AI chatbot, than a human being who's forced into the role of an automaton - executing directly from a script. Just, FFS, let me escalate to an actual competently trained human being once I've been through the troubleshooting.
- either it has no authority and is simply restating publicly available information
- it has authority but only after pressuring it. In which case I have to spend time to find the right combination of things to get what I want
If I’m calling it’s because I have a special need that is unlikely to be resolved by a flow chart.
(Also, if you own a home in NY and use lemondade -- do know that they don't cover cast iron piping (extremely popular in NYC). I found that out at renewal...)
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.
People who can't read the documentation aren't going to understand the AI's bad or even good summary of the documentation
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.
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.
I frankly doubt the numbers, surely it costs more than this for an average company?
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.
This is a billion-dollar company you have definitely heard of.
(It's not Amazon.)
https://arstechnica.com/tech-policy/2024/02/air-canada-must-...
Never has a chatbot been of help to me.
Bot: Welcome! Please tell me what you'd like help with.
Me: how do I X?
Bot: Please choose an option: [list of irrelevant things].
Me: None, I need to do X.
Bot: Okay, please try [instructions copy-pasted from the docs].
Me: I already read the documentation and it didn't answer my question, that's why I'm here.
Bot: I'm sorry, I don't know how to help.
Me: Can I speak to a human?
Bot: Welcome! Please tell me what you'd like help with.
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).
The tool is for drawing "technical analysis indicators", one of the most convoluted ways to ascribe meaning to a random process and something that will only ever be true in the self-fulfilling sense. I don't think it's a surprise that some users are willing to blindly trust the tool, when all users of it are blindly trusting concepts that are built on sand.
Although I'm sure the author is burnt out from the experience now, I'd be interested in hearing how their next side project venture goes- is the experience more enjoyable when you're dealing with a user base that self-selects differently? Or do all users suck equally, just in different ways?
For me this reads as 'I don't enjoy voluntary customer support' rather than my customers suck.
For all I know, the author might have both received and responded substantively (with more than RTFM) to many such requests, but has not mentioned them here because they were not part of the problem.
Oh, I feel that from DayJob. If it wasn't for the possible arguments is might cause about professionalism, my standard response to a client question in DayJob would be a gif from TaskMaster, looping through instances of Alex Horne saying “all the information is on the task”.
> Somehow all those claims from 'people with large communities' never materialized beyond testing the trial.
Very few people ask for something for themselves, they think they'll get a better response if they can convince you they are part of a larger interested group, or by suggesting what they are asking for would benefit “the community”.
Neither of these things is new: I had some software out there in the late 90s¹ and it was much the same back then, just perhaps less intense.
--------
[1] initially shareware-ish, then when the amount I made wasn't worth the faf of dealing with people (and payment processors), and talks with the couple of people who were interested in buying ownership/copyright annoyed me by going round in circles, it became open source so others could build take it on (no one did, they just all wanted me to continue to add features they wanted), then when I got more sick of dealing with people I buried the thing.
I LOVE the initial rush of building and launching something. Even maintaining it is SUPER exciting for the first few months. The first customers are a rush of endorphins.
Then the shine wears off. Life can't be kept on pause. Your partner wants a date night, but you have a backlog to work though. You got a frantic email from a customer that they accidentally deleted something and you currently have no way to recover that data. So now you have to add more resiliency to the application. In the middle of the night, your cron server dies, backups stop, emails stop, customers on the other side of the world can't log in.
All for a few dollars a day in revenue. Then after a year of that, you get burnt on the project. Then after another year, you stop working on it as much, the bug reports build up until you are scared to even look at your reports.
Your partner goes away for the weekend to visit their family, you get a renewed sense of pride in this project that has been limping alone. You fire up your code editor, you pull the last commit down. You start to re-familiarize yourself with the code base. Day 1 was wasted with remembering how you did things. Day 2 starts with a coffee after only sleeping a few hours. You begin to work through the small tasks on your list, because you feel the snowball will work. About 8 hours in, you've made a SERIOUS dent in the backlog. You are feeling good and decide you should eat something finally. Your partner comes home while you are eating your breakfast at 4pm. They start to tell you about their family drama. You start to fade. You walk back to your office and try to get back into the groove. You can't. The weekend is over. Work starts again in 10 hours. You now feel angry that you wasted your weekend, and have to do real work in the morning.
And the cycle repeats.
I've actually stopped launching software now. I devote my passion projects to things where the customer is a one-time interaction. No support, no emails, no late nights working out why there is a 500 that only happens on this ONE user at 1:16AM.
Now, I make rolling trays, refinish antique furniture, and garden. In the new year, I will be converting half of my workshop into a CBD/hemp farm to grow my own hemp to make my CBD tinctures and oils (currently I buy CBD flower from Oregon).
Software has stopped being my only source of joy and income. After 2 decades of programming almost every single day, my brain is tired, and I don't even know what it was all for.
My garden provides nectar for bees, vitamins and minerals, for myself and my family, sunshine for my body. My woodworking provides that sense of pride that I had with software without all the bugs (well sometimes there are grubs in the wood). My CBD is "medicine", and it helps my dad with his phantom limb pain, me with my Hashimoto's flareups, and other's with their anxiety and stress.
My software made people money...
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.
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 bonus that those 40 hours don’t feel like work.
https://en.wikipedia.org/wiki/Ptah
I imagine that the creative class was revered and feared. Potters had very low status making a commodity product that everyone needed. Hard to say what was going on.
https://reader.manabi.io
But if you kill the culture before the IPO, then you have nothing and nothing.
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!
Coupon? Careful phrasing? Sending puppies?
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 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%.
This is why I've always been scared to make any commitments to paid subs other than "I'll send you all my blogs early"
This might then allow a better decision on whether it is a worthwhile endeavor or not.
If anything, this post shows how wide - or deep - any internet niche is.
Silly me.
I've been in a similar boat running a small B2B Saas over the last 2 years. Over the years I've learnt a lot of tricks in this area.
- 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.
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.
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
Mega corporations get away with awful support of paying customers, people don’t actually expect you to jump at their command as a startup or even as a toy side project. If you’re able to ignore a beggar on the street, you should be able to ignore a lot of these emails. Stop guilting yourself into a heavy administrative burden and don’t avoid consumer apps because of that fear.
Thanks for your message, please know that we are limited on time and only respond to critical issues. However, also please know that we do eventually read and monitor these emails;
- Bug reports or issues on our current application: we will respond within a week, usually within 2 days
- Feature requests: we are unable to confirm when or if a feature will be added. We typically put it on a log and review them quarterly.
- Requests for source code or how our tool was built: we're glad you're curious however we do not share this information.
I also think expectations are relayed based on the price and scale of your business. Being transparent about your operations is helpful. If you're running your business as a one person side project but pretending to be a large multinational corporation (which is common) or charging a larger sum of money for service then perhaps it's expected. Also if you're providing some mission critical application, then probably expected. The author is talking about a charting plugin to a trading app that he charges peanuts for and has no intention of continuing development on. I think most people's "businesses" fall into this camp, even if mildly revenue generating. In any case, it's mostly about setting and managing expectations. It helps if you are transparent if you are not actively making improvements or it's just a hobby/solo/side hustle thing for you. At the end of the day, they can decide if they want to discontinue using your thing or not and if your optimizing for "least amount of time invested" then you also just need to come to accept that some churn is the price of it. Obviously, if you can charge more or have a huge amount of users, that churn becomes negative ROI versus providing more attentive support and that would likely justify a change of strategy - for some.
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.
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.
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!
I have the exact same issue regarding support with a simple app I have on the App Store, I can perfectly relate. Despite being a really simple app and extremely cheap, every once in a while I have to wake up to angry e-mails from disgruntled users.
Perhaps you are running into some negativity bias? [2]
[1] https://news.ycombinator.com/front?day=2014-08-21
[2] https://en.wikipedia.org/wiki/Negativity_bias
"My payment provider said you used a stolen credit card. Why did you do that? I've revoked your access."
But yeah those are the only two I can think of and yours is the case 99.99% of the time.
These strategies don't maximize revenue, but you don't have to maximize revenue. You can optimize for revenue/agony instead.
That's a great way to put it. I'm going to start using that one.
Tangent: I'm a programmer at a small company, which has three programmers total. I make a decent wage, but one that's significantly smaller than I could make at a larger company. I often get questions from people who can't believe that I'm not jumping at these other opportunities, but I make nearly six figures, my team and bosses trust me, I have nearly unlimited flexibility to choose what I work on and shape my software the way I feel is best, and I get to work full remote and basically make my own hours, giving me all the time I want with my family. It would take an incredible raise to give this up just for better pay.
An agony-per-dollar ratio is a perfect way to frame the calculation, and it factors into so many places in life. Many forget that it's not just optimizing for the most revenue possible, but a balance of maximizing revenue and quality of life, and often getting diminishing returns when pushing hard on the former.
The proportion of negative/wild interactions with support and chargebacks is always going to be in an uphill battle with positive correspondance unless you are selling multi-seat deals with support as part of it. I speak a little out of my area of expertise here but from my friends experience, the downside to professional services is that a small proportion of people, or people on bad days, see it as a service, not a SaaS, and will willingly throw threats, insults, etc at you. A small error on your service can stop their whole business which is different for B2C - it's the difference between fear and frustration.
I already addressed this. By forcing people to use the product before allowing them to purchase you make drive-by fraud impossible. We use stripe and we have 0 fraud to deal with.
This isn't automated, it's people in 3rd world countries signing up to random sites that have CC as a method of payment and seeing if payment goes through.
You probably pay for Stripe Radar and don't see these payments but are also silently missing out on legitimate payments, or you run KYC or have too few or only western access to your site otherwise. Have you spoken to the people who manage your Stripe about the disputes and how many are fraud and the Fraudulent payment detection numbers you have? It won't be 0 for any substantial business.
Nobody in a 3rd world country is going to spend 5 hours clicking around in a product over multiple days just to test if a credit card works. If card testers don't find the payment form within 2 minutes they're going to move on to a weaker target.
People who struggle with fraud in SaaS usually make no attempt to distinguish real user behavior from fraud-y behavior.
the way to get the doge project to not take your time is learning to hire for existing tasks while you figure out new ones.
Also if you can use some of the funds towards a required like a vacation that you and your partner can enjoy guilt free
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.
"Our premium support can investigate this for $XYhr. If the fault is at our end we will waive any fees. Please let us know if you wish to proceed."
I would say this would only feel justified if the product pricing page already had clear tiers outlined for paid support. Putting a price per hour on customer support otherwise would make me feel like I am just being milked behind closer doors for more money, and non-paying customers are getting shafted. If a paid customer support tier is something you offer, imo it should be clearly outlined on publicly available pages with explicit explanation about the differences between free vs paid customer support. You suggesting it in private communications only would feel suspicious and shady to me as a customer.
However, if the customer themselves suggested to pay you extra for that personal support, that’s a different story.
It was just an example, though.
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.
> But don't allow issues to go stale. To really wow customer service, reply as humanely quick as possible, especially for existing customers.
As a customer, the absolute worst possible thing for me is to be left in limbo, not knowing if my problem will be fixed in the next minute, hour, day, or never. While I may not be thrilled if the answer is "never", at least at that point I can move on and know that I'll need to solve the problem some other way.
This is the biggest thing I struggle with. I have a couple of semi-successful side projects. They bring in some money, but not enough to hire someone to help with support. I have never been at a place in my life where something like "I will response to all support requests within 48 hours" is remotely realistic for me. I'm lucky if I get to a support request within a week or two.
I don't know what the answer is beyond just "don't sell products", because I hate dealing with support more than I enjoy making stuff to sell.
Even just confirmation that the website form isn't a black hole and that support tickets aren't now exclusively accepted through Twitter, Instagram, or a secret discord server can be very reassuring.
or just pass all support responses through "business support LLM" for uniform “polite but curt” tone
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!
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 also feel that this is happening more and more, since there's more rewards for giving very small pieces of attention and energy to a bigger pool of people, instead giving extra energy or attention to a smaller pool of people seeking for one's help.
I'm just facing this with a contractor doing repairs in my house, a month ago was finding a decent mechanic to fix just 2 issues on my car.
The first promptly finds energy to discuss things it receives through social networks or messages, but can't provide a decent list of things that I need to provide him to finish his work faster.
The second case took a lot of time and discussing with 6 different mechanics, until th car broke and it was towed.
I'm seeing this more and more, unfortunately.
> insufficient attention to detail
I believe there's a cause effect scenario here.
- be on time
- respond to emails/texts, and especially: phone calls
- give quotes
Then if you're even halfway competent, the world is your oyster. Please come do work for me!
If you can manage people and budgets, you can have more work than you'll know what to do with (assuming there's work available).
The inability of many people to focus their attention and prioritize their work is shocking to me. This isn't just for the stereotypical "younger adult" either, this seems to apply across the board (and especially to boomer-aged adults!).
The only interaction possible is they can tell you the problem, then you can give them a list of things to try, and they can do nothing but give feedback on each step, in order, and you arent bothered until they at least respond something for each step
This is obviously satire, but we could make every internet app completely modal: once you start a flow on any site your computer prohibits you from starting any other flow on any other site before you complete the previous one.
Are you saying that you give your contractor a list of seven things to address, and find that they only address two and say they're done?
I can't remember where I heard of using painter's tape for this, but it's used as a metaphor in this article https://randsinrepose.com/archives/the-blue-tape-list/
.... I also found this link while looking for the above article, https://www.quantumbalancing.com/news/bluetape.htm . That's. ... just... well. Not what I was looking for, but was so remarkable that I thought I would link to it here. I suppose they have probably sold some of their devices. I'm curious to know what the insides are like, but not curious enough to spend $1k+.
// Fixme: address this later.
Oh, no. It's not a shuffle. They unerringly identify the least important possible action item. Sometimes just a single clause of a single sentence in a list item.
You have to scour your communication of anything that can possibly be interpreted as an easy request. It has to be a curt, imperative, isolated, request to do something hard or it will be ignored.
2. Wait
3. Update your XYZ
User: I tried the second option but nothing happened
I have to give every idea it's own sentence, and every sentence must be separated by double space at minimum.
And then I can't offer more than maybe four complete ideas, no more than one of which can demand a response.
"I need your engagement level to be set to 10 for this communication. It's ok if you can't do that, but then just say you can't do that. I'm already set to 10 and rando guesswork / tidbits are only going to cause problems."
Even just "nope can't do it" responses would save me time.
I just got off a critical call with folks pulling stuff out of their ... and it was a nightmare / complete waste of my time.
Much easier and safer is to drill into your own head that your own engagement level may be at 10, but the other person's is probably going to be more like 2. And that's fine.
Notice your parent doesn't say "you must be at 10," but rather "let me know if you can't be at 10." I think that's perfectly reasonable, as long as you're willing to accept almost always getting "no."
> Much easier and safer is to drill into your own head that your own engagement level may be at 10, but the other person's is probably going to be more like 2. And that's fine.
But sometimes that's not fine! For example, if you're giving a list of instructions for some safety-critical procedure, it's not fine to find out later that the nodding "uh-huh, uh-huh" actually meant "I'll do what I remember and what sounds easy," and it's much better to do nothing than to proceed with partial information.
I'm not asking them to be at 10, I'm asking they not engage unless they are.
This comment should be three paragraphs. As written, it’s very hard to read and I get lost.
If this was a professional communication and you had asked three questions, I might understand one or might not. Now I have no issues saying “dude, your writing is very hard to follow.” But what if your colleagues are nicer than I am?
Or just spitballing. You’ve admitted that you’re the kind of person who will set traps for your colleagues. What if they’re just sick of your shit but are too conflict avoidant to say that?
What is that even based on? Where did they admit to setting up traps? Is that your take on their comment about trying to ask three questions in one message?
Because, even without them creating paragraphs, it is abundantly clear they just mean that as something from experience. Not something they do as something to spring a trap on people.
“When confronted (constructively, much later) they usually get evasive and can’t explain.”
Confronted is a big word with a hostile intent. They’re incredibly measured in their language and use precise language. That sounds like a trap to me - it’s:
A.) Asking three questions and only get 1/3 answered.
B.) Waiting for a suitable period of time to elapse.
C.) Confronting them while expecting an explanation.
Letting time go by, “confronting them” and expecting an explanation is a trap. It assumes that they can even remember the conversation! Why not send a follow up email immediately and politely ask again? Heck, that’s a good excuse to use “circle back” in conversation. :)
If you missed that first read, no worries because so did I. I had to read the comment three times and then I kind of shaked my head because they are so measured and precise, and that’s an awfully big statement to make about colleagues.
Confronted isn't necessarily a hostile word. It is a very apt word to use for the action off asking someone about the other two points. They even made it clear that it was in a constructive manner.
May I ask, do you often feel like you are operating in a hostile environment?
We were all close and could discuss “meta” from time to time, in a friendly constructive manner. You’re probably reading more into this aspect than there is.
They wound up answering every question in my list of five, spent enough time on some of them that I think that may have been part of the motivation for them to break it up into two videos, and even emailed me the answer to the one out of five points they didn't address in the video.
In contrast if I render a list at any of my colleagues or vendor dev teams there is a <20% chance that they will address or even acknowledge 2 whole separate items out of the list, so the points they don't address get frequently brought back up again and dropped again. :(
So AI researcher has.. ..list comprehension. (YEAAAH!!)
At my last job we had a customer who was famous for doing this. Since he generated a significant amount of sales, we couldn't just sideline him, so I learned to only ask one question at a time on email. Otherwise, if you asked e.g., three questions, it was a complete tossup as to which one he would decide to answer, all the while reminding you that this was a "hair on fire" issue for him.
Compounded with the fact that he was on another continent, multiple time zones away, this made debugging anything a difficult proposition.
We had another customer for the same product in the same country who had absolutely no problem answering whatever questions you asked him, in as much detail as he could supply. It has to be a personality thing.
"Try this one thing: ....
If you are a detail-oriented person, you could also save us both some time and try these things also ..."
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)
Having bots close issues, accompanied by a rude automated message is often contra-productive. It would be fine to instead post a reminder in the issue, asking for an update like shown in the example:
This is actually a very polite form of handling it.So many software projects close bugs with bots, and they have an unrealistically rosy picture of how bug-free their software is.
Take a look at this issue to see what it takes to keep something open: https://github.com/oobabooga/text-generation-webui/issues/41...
(not especially proud of my reactions there, but I hate being abused, even by robots.)
If I received a bug like that I would immediately think why are you telling me this... just fix it yourself and share your fix if you want. I probably have higher expectations from my users. You give the software away now they want you to fix it for them.
Then you're part of the problem.
I am far less equipped to handle a bug like this than you'd think. It would take me so much more work and time than asking someone who already knows the project and how to work on it.
If I did this for every bug I reported, I wouldn't have a job because I wouldn't have any time left for one.
You know, this is also my issue with Linux. The attitude is generally that if you want to run Linux, you are expected to do anything you need completely on your own, including fixing bugs. This is why macOS is my preferred operating system. (Not that I can run it right now...)
I'm of course not entitled to anything from you (or anyone), but the one thing I won't do is fix it myself.
I don't really want to be a hacker right now. I've tried. I can be, but it rarely pays off for me. Not even financially, just emotionally.
If you're moving fast enough that you don't have time to close them manually, you're moving too fast (and breaking too much).
I've seen places where tickets were not allowed to be re-opened. If a ticket was closed for any reason at all besides a misclick, a new ticket had to be opened with a link to the old ticket if necessary.
This is the real problem an automated close addresses. They are are afraid to tell their customers this.
I've started replying to it with "No updates here." to reset the timer.
(Siemens) Support: Before I can help you, please find the serial number via <tedious procedure>, and the exact version of subsystems <x, y and z>.
Me: Here you go, though I fail to see how my specific setup is relevant as the problem has been reported on forums for years, and it is easily reproducible
Support: Please update to latest version x.
Me: Version x has known regression which will break the machine for the customer. I did the 1 hour procedure anyway but the issue is still present.
Support: Please execute this <obtuse command that runs a trace> and download the log from <airgapped machine> with SCP
Me: O well, did that here is the file. Don't understand why you can't run it on your machine
Support: Please try <irrelevant thing>, reboot (wait 5 minutes) and run the trace again
Me: (Gives up)
Is Support just completely disconnected from Engineering? Do they not have a way to report issues and indicate that many customers are having a specific issue?
Does the company believe that giving a customer a runaround will make them less upset than saying "Sorry, this is a known issue. We're working on it but do not have a timeline"?
Certainly at some point, some support person is going to be like "Huh, we have a lot of customers complaining about an issue, and our usual flowchart script doesn't seem to resolve it" and try to work it up the chain, right? Or does it get to their manager who says "Meh, that's an engineering problem, not a support problem. Get back to your tickets!" and never pass it up?
And so I was fired and could no longer support myself or my family, that's why I'm applying to a position with the lowest pay grade,
It's the capitalism, not a red cross
Cheating your customer is a dangerous game. They are not dumb.
The tendency to wall off engineers is often taken to a counterproductive level.
(Don't actualy do this unless you want to burn money)
But there's a line SOMEWHERE. The few tickets that DO need engineering time REALLY NEED IT, and it's completely asinine that in some corporations, it's impossible.
If, for example, 100 people are talking to support for the exact same crash, and people in support are able to reproduce it, it needs to go to Engineering, rather than support telling customers "Have you tried formatting your drive and reinstalling everything from scratch?" when they already know it won't fix anything.
That combination kept the customer-frustrating bugs quite low, while still allowing engineering to keep developing new features at a fairly rapid pace.
(and then we got purchased by a PE firm and dismantled)
Support is almost always tiered because $$$. In an ideal situation (hello GitLab!) tier 1 they are friendly and competent triage artists that can redirect lost customers and handle the common basic cases. Tier two is essentially an experienced and skilled tier 1. It's not until you get to tier 3 that you reach an engineer, usually one dedicated to support. That engineer is the one who reaches out to the operational engineering team if needed.
This is the usual response when a companies customer numbers start to scale up so far that the volume of users like the ones in Vegenoid's parent comment start to overwhelm the support staff. Keeping up the good/decent customer support that you could give to your first few hundred or perhaps even few thousand users eventually becomes ludicrously expensive or even impossible.
Then the original article's "Keeping this running and supported is shit. People are idiots and time wasters! Automate all the things!" stage kicks in.
So "first level support" is created, who's main objective is to get rid of support requests with the minimal effort by the least skilled staff possible. So everything is written into a script that call centre employees are required to follow. Low skill minimal wage staff are required to ask stupid things like "Have you tried reinstalling Windows?" and getting a confirmation that they have - before any support request is passed on to even a junior or intern developer. At this stage nobody gives a damn about users who need help, and they outsource that work to other users on the "community forums" and the entire support team is fired.
(Google, of course, being a world leader in both webtech and customer acquisition, completely skipped the "provide decent customer service" stage and went directly to the "don't give a damn about users" end game.)
The amount of times the software doesn't work because the HASP key [1] is plugged into a different machine is so many.
You just can't trust that they've done any basic troubleshooting and so have to start from a completely blank slate.
[1]: https://en.wikipedia.org/wiki/Software_protection_dongle
Yes.
Unless you want to drive engineering insane / waste a ton of money.
If a customer seems to have discovered a legit bug in the software, there needs to be a path from support to engineering for the bug to get reported.
At the very least, support staff should be willing and able to attempt to recreate a bug that a user is reporting, rather than asking them to completely wipe their device and install everything from scratch for something that is easily reproduced.
Let's take a very simple example. Imagine you've got this Chess app, and whenever someone creates a checkmate involving two bishops, the game crashes, 100% of the time, but only in cases involving two bishops. Sure, maybe the first ticket you get, you go through the workflow of reinstalling, etc. But by the time you've got 100 tickets all saying their game crashed on a checkmate involving two bishops, that should have been escalated to engineering. At the very least, support should be saying it's a known issue. Honesty is going to be a lot less frustrating than to be told to take steps that both sides knows won't fix the issue.
These flows are intended to dissuade problem reports, because the business is too big to care.
I once reported a ui bug to Discord(the game chat). This is how it went.
- me wrote an elaborate email and screenshots of the problem with step-by-step guide to reproduce it
- support responded me by asking build version, my os version, device type
- me screenshot all the requested details + manually wrote down in response email so someone can also copy-paste somewhere directly from my email
- support responds by asking me to clear my iphone cache(sending me a guide for Android's App data cleaning process) and see if issue persists
- me respond that it is not Android and since I knew what they will ask, I have uninstalled, reinstalled, logged-out, logged in and documented the whole process by recording my screen while doing it
- support, please try to logout, then uninstall and reinstall again
- me begrudingly do it again(record screen), send them everything
- support, could you try updating your device OS? - me check for updates, iOS says it is latest, me send screenshots
- support, can you try disconnecting and reconnecting to your network or rebooting your device?
- me follow the steps(by recording my device using another device) and send it back
- support, can you try factory resetting your device
- me get pissed off, I mean c'mon, the issue is that, the client is incorrectly handling the on-screen keyboard events and has nothing to do with my device, but giveup anyways and write on twitter that I tried to report an ui bug, is there some engineers I can reach out to?
- twitter official DM me and what do you know, it was the same person who was responding to my emails and tells me, if I tried resetting my device to factory default, else they'll close my ticket as not reproducible
I just gave up and uninstalled discord. I mean, sure there are lot of useless problem reports, but when your user goes on to extreme lengths to document an issue and cooperates, please take it seriously.
In most cases, the whole script is intended to deter the less patient consumers/users and not actually solve any problems. In some cases, the support is just an outsourced team with no connect/contact with actual team or the product.
Except… recently I completely misdiagnosed something. So while I was getting politely frustrated with the support clerk, he was stepping me through a set of irrelevant seeming procedures which, indeed, resulted in identifying that a piece of hardware was broken.
In this case it was the fiber to Ethernet adapter my ISP uses. He needed me to verify that, at every step of the way, pieces of my infrastructure were not the cause of my flaky connection (they weren’t). However, as a final step he had me reboot the adapter and it didn’t start back up. Turns out this is a rare failure mode and the flaky network I’d been seeing was an early, year long, symptom of this issue.
I had DSL with a router and modem. I never had problems with it, never required reset etc. Over the years somehow I forgot and thought it was a combo router and modem.
Then when I finally had a problem, I insisted to customer support I had done many power cycles already. They scheduled a tech to come out, but I realized my mistake before it went that far at least.
A power cycle fixed the modem, of course.
I was actually able to demonstrate the issue in person, and everyone was scratching their heads trying to figure out what was going on.
I decided to try factory resetting it as a hail mary... and instantaneously I got a perfectly functioning ADSL connection.
It would have been far less embarrassing for me to have thought to try that and make the effort at home. lol
ISP Support: Hi do you have a dial tone?
Me: No we don't have a land line phone at all and haven't for years
ISP Support: Can you please check your land line phone and let me know if you have a dial tone?
Me: I. HAVE. LINE. SYNC.
ISP Support: Yes but your line might not be connected yet. I need to know if you have a dial tone.
Me: ...
Me: drives 5km to the nearest shop that sells telephone handsets
Me: <twhoo hoours layter> YES. WE. HAVE. A. DIAL. TONE.
ISP Support: Okay so it looks like there's an outage in your area which is affecting your connection.
I noticed I do exactly this when troubling shooting problems with LLMs!
He'd do one thing, report that it still didn't work. I'd ask if he did the other four things. He'd do the next thing, report that it still didn't work, etc.
God only knows how much that department was paying him.
1. Customer describes the problem 2. You get the problem, parsed by the model, including a summary and a suggestion what could help. 3. You write "do that 3 things" 4. The model tells the customer to do the 1st, then the 2nd and so on 5. The model reminds the customer in intervals that things are not completed 6. the model notifies you after the 3 things are done and the issue is still there.
Give the user a checklist instead of just freeform text -- where they can check off the three individual things to try. When they've checked them all off, they can go back to the well for another response from support.
I was punushed for "leaving" the game, banned for a couple weeks, and sent an obnoxious email about my bad behaviour. I reached out to them on customer support handfuls of times and was always given a list of three steps such as "upgrading graphics drivers", "ensuring i disable my firewall", "using a pc with high enough specs" (my machine is ridiculously overspecd) and things like that. I would follow the three obviously pointless steps, and then be given another set of obviously unrelated steps. This went on about five times over a month.
At some point I just told them, look im a fucking game developer, give me a log dump tool, or a build with debug symbols and I will fix it myself, and finally a real human showed up and actually sent me one. I recreated the bug and sent log captures but they wouldnt let me help beyond that. Then at the end they still scolded me for "leaving" the game.
I dont blame the average person for expecting customer support to be unhelpful or a robot by default, and not following steps.
## Action Plan
- Read my comment
- Try it
- Comment on your experience
https://passo.uno/signs-need-tech-writer/
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.
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
I don’t mind waiting in silence, but when they keep asking about weather, vacation plans, etc, I find it hard to not respond. This might part retention technique though.
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.
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.
Not even the big giants manage to create LLM bots that work.
What kinda things did you automate?
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’m a big believer in choosing your battles when communicating online. I’ve found bad grammar, lack of focus, confusing content, etc are all signals that the sender didn’t put much effort into their communication, and if I respond to those at all I usually put in proportional effort. Rarely have I experienced low-effort comms leading to high-reward outcomes, and I found my mental health benefits from the “justice” of proportional response. I’m curious though, the writer seems to imply that lack of active communication led to a decrease in sales. I wonder if/how my approach could be sabotaging me.
OP made $15K selling snake oil of a specific nature that, if it were a legitimate product, would have made far more than $15K if he simply used his tool himself instead of productizing it and selling it to rubes and crooks.
This side of things doesn't get much coverage since it doesn't sell books or increase subscriber counts!