Answering Support When You Are the Whole Company
Support is the highest-quality research channel a small product has, and the fastest way to burn out if you treat it as an obligation. How to answer, what to automate, and how to say no.
Posted by
RouzbehRelated reading
The Pricing Page: What to Put On It, and What to Leave Off
Picking the number is one problem, presenting it is another. Plan names, the free tier decision, trials and card-up-front, annual billing, and the things founders add that quietly cost them customers.
Why Users Do Not Come Back: Early Retention When You Have Twenty of Them
At twenty users churn is not a metric, it is twenty stories you can read individually. The most common cause is not a missing feature, it is that the problem does not happen often enough to build a habit around.
The First Five Minutes: Onboarding When You Have No Onboarding Team
Most onboarding advice assumes a product team and a tooling budget. At ten users the fix is not a guided tour, it is the empty state, one obvious first action, and doing it by hand while you still can.
Support is the part of running a small product that nobody warns you about and everybody underestimates. It is simultaneously the best research channel you will ever have, since these are paying customers describing real problems unprompted, and the thing most likely to quietly consume every evening if you let it. Both facts are true at once, and most advice only acknowledges one of them.
Table of contents
Your unfair advantage is being one person
Every customer who has ever emailed a large company expects a ticket number, a scripted apology, and three days. When the person who wrote the software replies in twenty minutes and says "you are right, that is a bug, I will fix it tonight", it is genuinely surprising, and people remember it for a long time.
So do not hide it. Sign with your name, write like a person, and say when something is your fault. The instinct to sound like a company (we instead of I, "our team is looking into it") throws away the only thing you have that your larger competitors cannot copy.
This is also the cheapest retention work available. Somebody who has had one good exchange with the founder is measurably harder to lose than somebody who has never spoken to you, which is worth knowing when you are reading the numbers in why users do not come back.
Speed beats polish
A two line reply in ten minutes is worth more than a thorough one tomorrow. Most support anxiety is not about the answer, it is about whether anybody is there at all, and a fast acknowledgement resolves that before you have solved anything.
When you cannot answer immediately, say so immediately:
Got it, thanks for the detail. I can reproduce this. Looking at it today, I will write back either way by tomorrow evening.
Three things happen there. They know a human read it, they know you believe them, and they know when to expect the next message so they do not have to chase. Then keep the promise, including when the answer is "still working on it", because a missed follow-up costs more than the original delay.
Do not buy a helpdesk yet
Your inbox is fine. A shared helpdesk solves problems you do not have: routing between agents, ownership, shift handover, reporting to a manager. What it adds is a second place to check and a layer between you and the person writing to you.
What is worth setting up early is much smaller:
- A dedicated address rather than your personal one, so support does not blur into everything else.
- A way for the message to reach you with context attached, so you are not asking which account they mean. A feedback form inside the product beats an email address for exactly this reason.
- Somewhere to record what people asked, so the pattern is visible in three months.
Move to a real tool when you genuinely cannot keep up, which is a good problem and a long way off. The comparison of the actual tools is in best product feedback tools.
The rule of twice
The first time somebody asks a question, answer it. The second time, answer it and then fix the cause. Not by writing a help article, which is the reflex, but by asking why the question exists at all.
Most repeated questions are interface bugs in disguise. "Where do I find my API key" is a navigation problem. "Did my email send?" is a missing confirmation. "How do I cancel" is a settings page nobody can find, and answering it politely twenty times is choosing to do manual work forever rather than a twenty minute fix.
Write documentation for the questions that survive the fix. Those are the genuinely complex ones, and there are fewer of them than you expect once the interface stops generating the easy ones.
How to say no to a feature request
Founders handle this badly in two directions. Either they say yes to everything, which is how a focused product becomes an unmaintainable one, or they go silent, which reads as contempt.
The move that works is to ask about the underlying job before answering the request. "What would you do with that once you had it?" resolves a surprising share of requests into something smaller that already exists or takes an afternoon.
When it really is a no, be plain and give the reason:
That is a fair request and I am not going to build it soon, so I would rather tell you now than leave it vague. It only makes sense with team accounts, which are not on the roadmap this year while I am working on this alone. If that is a blocker for you I completely understand, and I am happy to help you export everything.
Offering the exit is the part people leave out, and it is what makes the rest credible. Nobody resents a clear no; they resent a maybe that goes quiet.
Turning the inbox into the roadmap
Support is the only channel where people tell you what is wrong without being asked, which makes it the best raw material you have. It is also unrepresentative in a specific way worth remembering: you hear from the annoyed and the invested, and never from the person who quietly gave up. Everything in the inbox is real, and it is not the whole picture.
The habit that makes it useful is recording every conversation somewhere searchable with the person and date attached, so you can answer "how many people have actually asked for this?" with a number rather than a feeling. Six months of that is a better prioritisation input than any framework.
Once there is enough of it to be unreadable, reading it becomes its own job, which is what triaging product feedback with AI is about. Before that point, reading it yourself is not a chore to automate away, it is the work.
Boundaries, before you need them
The failure mode is not one bad customer, it is the slow assumption that you are always available because you have always answered. Nobody is being unreasonable; you trained them.
A few things that help, all of which are easier to set up before you resent anything:
- Say on the site when you answer. "Usually within a day, weekdays" is honest and sets the expectation you actually want.
- Answer in batches at fixed times rather than on every notification. The interruptions cost more than the replies.
- Do not offer a support channel you cannot sustain. A live chat widget nobody is behind is worse than an email address that gets answered.
- Be willing to refund and part ways. One customer consuming hours every week is not worth twenty dollars a month, and saying so kindly is allowed.
Frequently asked questions
Should I use canned responses?
For the mechanical parts, yes, and edit every one before sending. Canned text is fine; canned tone is what people detect. If a reply could have gone to anybody, it will read like it did.
Do I need a status page?
Not at first. What you need is to tell people when something is broken before they tell you, which at this size is an email to affected users. A status page matters when you have more customers than you can email.
How do I handle an angry message?
Answer the specific complaint, apologise once for the actual problem rather than for their feelings, and do not match the tone. Most anger is about having lost time. Fixing the time loss resolves it faster than any amount of empathetic language.
What if I do not know the answer?
Say that. "I do not know yet, I will find out" is a completely normal thing for a person to say, and it is more trustworthy than a confident guess that turns out to be wrong.
Should I answer support while on holiday?
No. Put an autoresponder saying when you are back and stick to it. The version of this that goes wrong is not taking a holiday, it is half-taking one and being available badly.
Support at this size is not a cost centre you are minimising, it is the most direct contact you will ever have with the people paying you. Answer fast, sound like yourself, fix the cause the second time you are asked, and be honest when the answer is no. Then protect the hours around it, because the version of this that fails is not the founder who answered badly, it is the one who answered everything until they could not face the inbox at all.
Lighthouse gives you a feedback inbox that arrives with the account attached, so a report comes with context instead of a question about which user you are talking to. From an indie dev, for indie devs and makers.