Solo founders should automate the questions that have one correct answer and never change: pricing, refunds, delivery times, how to reset a password. Those are usually 60 to 80 percent of the volume. Write them once as a public help centre, then let an AI support agent answer from it. Never automate anything that requires a judgement call, an apology, or a decision about money you have not already published.
You spend a year building something. You finally get the first people using it. And then you discover the part nobody warns you about: those people have questions, they have them at eleven at night, and you are the entire support team.
The short answer is that you should automate the questions with exactly one correct answer, and keep the ones where being wrong loses you a customer. That line is easier to draw than most founders expect, and drawing it early is what stops support from quietly eating the hours you were spending on the product.
What does customer support look like for a solo founder?
Customer support for a solo founder is the work of answering customers when there is no support team, no shift rota and no budget for either. It is the same job a support department does, compressed into whatever time is left after building, selling and running the company.
It has one property that makes it different from support at a larger company: every hour you spend on it is an hour taken directly from the product. A support agent at a fifty-person company costs the company an hour. A support reply from a solo founder costs the company an hour of engineering. That is why the instinct to answer everything personally, which feels like good service, is the thing that stalls the product.
It has a second property that cuts the other way, and most founders miss it. You are the only person who will ever answer support with the full context of why the product works the way it does. Early support is not a cost centre. It is the cheapest user research you will ever run, and it arrives unprompted.
The five questions your first hundred customers ask
Support volume in the first year is far less varied than it feels. It feels chaotic because the questions arrive in a random order, from strangers, at inconvenient times. Written down, the list is short:
- How much does it cost, and what happens when I go over the limit?
- How do I get my money back, and by when?
- It is not doing the thing the homepage said it does.
- How do I connect it to the other tool I already use?
- Is my data safe, and who can see it?
Four of those five have exactly one correct answer that never changes. You should have to write each one once. The third has a different answer every time, because it is not really a question, it is a bug report wearing a question's clothes.
This is the whole framework. Before automating anything, spend one evening reading your last fifty support messages and sorting them into two piles: identical answer every time, and depends. Most founders find the split is somewhere between 60/40 and 80/20 in favour of identical. That number is your ceiling for automation, and it is also the reason automating is worth doing.
Write the answers before you automate them
The most common mistake is buying a support tool first. An AI support agent is a retrieval system with a conversational front end; it can only be as accurate as the material it retrieves from. Point one at an empty help centre and it will improvise, which in support is the failure mode that costs you the customer rather than the failure mode that annoys them.
So the first artefact is a written help centre, even a thin one. Ten articles that answer the ten most common questions properly, in public, at a URL you can send someone. That document does four jobs at once:
- It answers the customer directly, with no software involved.
- It becomes the source an AI agent reads from, so the agent's answers are yours.
- It gets indexed, so people find the answer before they have to ask.
- It forces you to notice which answers are embarrassing to write down, which is usually a product problem rather than a documentation problem.
That fourth one is worth sitting with. If you cannot write the refund policy in two clear sentences, the problem is not the wording.
What to automate, and what to never automate
Once the answers exist, the decision about which to hand over is mostly mechanical.
| Question type | Automate? | Why |
|---|---|---|
| Pricing, limits, overage | Yes | One published answer, and the customer wants it instantly |
| Refunds within a stated policy | Yes | If the policy is public, stating it is not a judgement call |
| Setup, integrations, how-to | Yes | Step-by-step, identical every time, improves with every article you add |
| Where is my order, account status | Yes, if connected | Only if the agent can read the real record. Guessing here is worse than silence |
| Bug reports | Triage only | Collect the details, then hand to you. Never let software tell someone their bug is expected behaviour |
| Anything involving an apology | No | An automated apology reads as an insult, because it is one |
| Money decisions outside policy | No | A refund you did not publish is a judgement call, and judgement is the job |
| An angry customer about to leave | No | This is the conversation that saves the account. It is worth your evening |
The pattern underneath the table: automate retrieval, keep judgement. If answering correctly requires knowing something you already wrote down, software can do it. If it requires deciding something, it cannot, and pretending otherwise is how companies end up with the support experiences everyone complains about.
Choosing the tool
Answer on the channel they actually used
The channel question is the one founders get wrong most often, because they assume support means email. For a large share of products, and almost all of them selling outside North America and Western Europe, the customer's first instinct is WhatsApp or an Instagram DM. If your only support address is a mailbox, the questions do not stop arriving, they arrive somewhere you are not looking, and the customer concludes you ignored them.
Check before you buy anything. Look at where the last thirty inbound messages actually came from, including the ones that reached you personally rather than through a support address. That list, not a category page, is the requirement. A tool that handles email beautifully and cannot touch WhatsApp is the wrong tool for a business whose customers live in WhatsApp, however good the reviews are.
Once you have the written answers, the tooling question is narrower than the market makes it look. For a solo founder the criteria are roughly:
- It reads from your help centre and your docs, rather than needing a separate content system you now maintain twice.
- It hands off cleanly, with the conversation history attached, so you are not asking the customer to repeat themselves.
- It covers the channels your customers actually use, which for a lot of businesses is not email.
- It tells you which questions it could not answer, because that list is your documentation backlog.
- It costs less than the time it saves, which at solo-founder scale is a low bar but a real one.
Mando is a reasonable fit for that shape of problem. It trains an AI support agent on your help centre and docs, answers across WhatsApp, Instagram, Messenger and a web widget from one inbox, and hands conversations to a human with the history already attached. It is Arabic-first with English alongside, which matters if your customers switch language mid-sentence and most tools make you pick one. We know the team, we have no commercial arrangement beyond linking to each other, and we would still point you at a specialist here rather than pretend a sales agent does support.
That last point is the honest version of tool selection generally: a product built for the job usually beats a general-purpose agent you have configured into approximately the same shape.
Where this advice is wrong
Three situations where the framework above does not apply, and following it will cost you.
You have fewer than about twenty customers
Automate nothing. At that volume the support load is small enough to absorb and the information in each conversation is worth more than the hour it costs. You do not yet know what the common questions are, so anything you write down is a guess. Answer everything yourself, badly and slowly if necessary, and keep the transcripts.
Your product changes every week
An AI agent reading a help centre that is two releases behind will confidently give wrong answers, and a confident wrong answer damages trust more than no answer. If you are shipping breaking changes weekly, either accept the documentation burden that comes with automating, or wait until the surface stabilises.
Support is your differentiator
Some products win precisely because a human who knows the domain answers within the hour. If that is the thing customers tell their friends about, automating it is removing the reason they chose you. Automate the billing questions if you like, and leave the rest alone.
Read your support queue as a product roadmap
The reason to keep a hand in support, even after automating most of it, is that the queue is the only place where users tell you what is wrong without being asked. A question that keeps arriving is not a documentation gap. It is a piece of the product that fails to explain itself, and the permanent fix is upstream.
The counting matters more than the reading. Keep a plain tally of how many times each distinct question arrives, because memory over-weights the message that annoyed you and under-weights the one that arrived quietly forty times. The fix that saves the most hours is almost never the one you remember most vividly.
A practical habit: once a month, take the list of questions the agent could not answer and sort it into three buckets. Missing article, confusing product, genuine bug. The first goes to the help centre. The second two go to whatever you use for planning. Founders who do this find the support volume falls over time rather than growing with the customer count, which is the only version of support that scales for a team of one.
Where this sits next to getting the customers in the first place
Support is the second problem. The first is that nobody knows the product exists, and the two need different things from you. Operater's Sales agent handles the first: it reads your product, works out who would buy it, writes to each person and books the call, which is the job most technical founders have never done. Support is the job that arrives once that starts working.
It is worth knowing the second one is coming before it does. The founders who get blindsided are not the ones who get no traction; they are the ones who get some, and discover the week after that answering customers is now a part-time job they did not plan for. Ten written articles and a decision about which questions you will never automate is most of the preparation, and it takes an evening.
Key takeaways
- The first hundred customers ask roughly five questions, and they ask them in a different order every time.
- Automate the answers that are identical every time; keep the ones where being wrong costs you the customer.
- A written help centre is worth more than a bot, because the bot is only as good as the thing it reads from.
- The metric that matters is not deflection rate but how many escalations arrive with enough context to answer in one reply.
- Support is the earliest honest signal you will get about what is confusing in the product itself.