What to ignore, up front
A short list, because most of the time saved in solo support is saved by not doing things.
- First response time as a target. It is a department metric that exists to manage agents. You are not being managed.
- Ticket statuses. A ticket is a unit of work that can be handed between people. You never hand anything over, so the fields that record the handover are dead weight.
- A knowledge base, at first. Write documentation when the same question arrives for the third time, not in anticipation. Guessing which questions people will ask is a reliable way to write pages nobody reads.
- Chat widgets, at first. A chat bubble is a promise to be present. Email is a promise to reply, which is one you can actually keep while shipping.
The setup worth doing once
A dedicated support address
Not your personal mail. It keeps support separable, it survives being handed to someone else later, and it lets a tool read support mail without reading everything else. It costs nothing on any mail host, and it is far more annoying to introduce after two years of history than before.
Billing context next to the conversation
Knowing whether the person writing in is on a $9 plan, a $900 plan or a trial changes how you answer, and looking it up in another tab every time is friction you will stop paying. A read-only Stripe key is enough: you never need write access to answer an email.
Two windows a day
Support is cheap in minutes and expensive in interruptions. Answering continuously costs you the deep work that makes the product worth supporting. Two fixed windows, notifications off in between.
The model: two questions, four states
Ask two things of every conversation and nothing else. Is the work done, and does the customer know. That gives four states, and only one of them means you are finished.
| State | What it means |
|---|---|
| Needs you | You owe them work, a reply, or both. This is the list you open in the morning. |
| Waiting on them | The ball is in their court. It comes back on its own if they go quiet. |
| Reply owed | You fixed it. They still don't know. This is the one that used to slip. |
| Closed | Handled and told. Only now does the customer leave your list. |
“Reply owed” is the state that costs money, and no mail client has a name for it. It is where the person whose bug you fixed sits while you think the matter is closed.
Writing the replies
- Say what happened, not how you feel about it.“This is fixed in the build that went out this morning” beats three sentences of apology.
- Do not write like a company.“We apologise for the inconvenience” from a one-person business reads as a smaller company pretending to be a bigger one, which is the opposite of the advantage you have.
- Answer the question they asked before the one you wish they had asked.
- Send the shipping note.“You asked for this in June, it is in today’s release” is the highest-return email you will ever write, and almost nobody sends it because nothing ties the shipped feature back to the person who wanted it.
- Refund quickly and say so in words. A Stripe receipt is a transaction record, not an answer. Someone who asked a human for their money back and got only an automated email was not replied to.
The only two things worth measuring
- How many people are currently owed a reply. If this number is ever unknown, that is the problem to fix before any other.
- How many support conversations turned into a product change. This is the number that tells you whether the direct line is working, and it is the one a support department cannot report at all.
Response times, volume and satisfaction scores can wait until you have staff.
Questions people actually ask
How much time should a solo founder spend on support?
Less than you fear and more deliberately than you probably do. Two fixed windows a day beats a notification-driven day, because support interrupts deep work far more expensively than it takes time. The founders who burn out on support are usually the ones answering continuously rather than the ones answering a lot.
Should I write canned responses?
Write a handful for the genuinely repetitive facts, like IMAP settings or how to find a licence key. Do not template empathy. The single competitive advantage a solo founder has in support is that the person replying can actually change the product, and a canned voice throws that away.
When should I hire someone for support?
When support is stopping you shipping for more than about a day a week, and not before. Hiring earlier removes the direct line between customer complaints and product decisions, which for a small product is the most valuable feedback loop you have.
Do I need a separate support email address?
Yes, and set it up before you need it. A dedicated address keeps support out of your personal mail, survives you handing it over later, and lets a tool read it without touching everything else you receive. It costs nothing on any mail host.
What is the biggest mistake solo founders make in support?
Treating "I fixed it" as the end of the conversation. The work and the telling are two separate acts, and only one has a system behind it. The customer whose problem you silently solved churns as quietly as the one you ignored.