Micro-SaaS Customer Support: A Solo Founder Playbook
Solo SaaS founders handle support without burning out by running a three-tier system: deflection, async batching, and selective escalation. This guide covers the response-time targets that actually match customer expectations, the four reply templates that resolve roughly 80% of tickets, the tools that work at each MRR stage, and the signals that say it is time to bring in help.
A solo micro-SaaS founder handles support with three layers: deflection (good docs and a clear FAQ), async (one shared inbox, checked at two fixed times a day), and escalation (refund, pause, or a Loom). Aim for a first reply under 24 hours under $5k MRR, under 12 hours from $5k–25k, and under 4 hours above. Use one tool that fits your stage, four reply templates that resolve roughly 80% of tickets, and one rule: support does not own your calendar. You do.
- Why solo SaaS support breaks people
- The three-tier support system for a team of one
- Tools by MRR stage (no affiliate links)
- Response-time targets that match what customers expect
- The four reply templates that handle 80% of tickets
- When to escalate, when to ignore, when to refund
- Async by default: the rule that protects your day
- Signals you have outgrown solo support
- Frequently asked questions
Support is the part of a micro-SaaS nobody plans for, and it is the part that quietly decides whether the business survives its second year. Pricing gets thought about, growth gets thought about, support gets done at 11pm in pajamas with the tab open behind a half-finished feature. That works for a month. Past a month it eats the founder.
The fix is not working harder. Customer expectations have moved faster than any solo founder can keep up with manually, and trying to fake a team of five with a single inbox is what burns people out. The way through is structural: a tiered system that filters work down to the part only you can do, a small set of templates that handle most replies, and a few clear rules about what you actually owe a customer at every MRR stage. For where this fits in the broader picture of running a one-person product, the complete micro-SaaS guide for non-technical founders covers the rest.
Why Solo SaaS Support Breaks People
The numbers say two things, and they pull in opposite directions.
The first is that customer expectations have moved faster than most solo founders realise. HubSpot’s State of Service report finds that the share of customers who expect a response in under an hour has climbed steadily, and that response speed is now the single biggest driver of satisfaction across SaaS, retail, and B2B. The same pattern shows up in Zendesk’s annual CX Trends report: more than half of customers will switch to a competitor after a single bad service experience.
The second thing the numbers say is that solo founders cannot meet those expectations the same way teams can, and trying to fake it is what burns them out. Help Scout’s research on small-team support consistently finds that the cost of context-switching, not the volume of tickets, is what kills productivity in tiny teams. A founder who answers tickets continuously throughout the day produces less product work than one who batches.
The pattern across public founder accounts. Solo founders writing milestones on Indie Hackers between roughly $1k and $25k MRR consistently report support volume in a similar range: between 5 and 15 inbound tickets per week, with bursts during onboarding flows and feature launches. Past $25k MRR the volume rises faster than revenue, and that is the breakpoint where the founders who post tend to either hire, automate, or quietly shut things down.
This is the trap of solo support. The expectations are real and rising. The capacity is fixed and small. Closing the gap by working harder does not scale; it postpones the breakage. The way through is structural: a system that lets you ignore most things, batch what is left, and reserve sync time for the few cases that actually matter.
Most support advice does not translate to a team of one. The standard playbook tells you to staff your inbox, define SLAs, build a knowledge base, hire your first CX rep. None of that helps if you are the entire company. The translation is to build a tiered system that filters work down to the part only you can do, and stop treating every ticket as if it deserves the same attention.
The Three-Tier Support System for a Team of One
Tiered support is not a new idea. The version that works for a solo founder strips it down to three layers, each with a clear job. Most tickets should never reach the layer where you actually have to think.
Tier 1: Deflect. Before a customer writes to you, they have a chance to find the answer themselves. A search-indexable docs page, a short FAQ that uses their actual words, and an in-app help link cover the questions that get asked again and again. The goal of Tier 1 is not zero tickets; it is that every ticket you do get is one you genuinely have not answered before. Plain’s public writing on modern SaaS support describes this as deflection rate: the share of inbound questions that never become tickets because the user resolves them on their own. A small-team product with even an average docs page typically deflects 40 to 60% of what would otherwise become inbound mail.
Tier 2: Async. What gets through Tier 1 lands in one inbox. Not Slack, not Twitter DMs, not your personal email, not Intercom and Help Scout at the same time. One inbox. You answer it in batches: once in the morning, once in the afternoon. Most replies are template-based (we will get to those) with one or two custom sentences on top. Tier 2 is where the bulk of the work lives, and where the discipline of not answering immediately is the entire game.
Tier 3: Escalate. A small share of tickets need real time: an outage, a billing dispute, a bug that touches multiple users, an angry customer who is asking to leave. Tier 3 is where you stop, drop the batch rhythm, and either fix the thing, refund the customer, or send a Loom that resolves the situation in five minutes of recorded video instead of fifteen minutes of typed-out back-and-forth.
The point of three tiers is not bureaucracy. It is permission. You are giving yourself permission to leave the inbox closed, because you have made it explicit that almost nothing in there is an emergency. The flip side is that you owe Tier 3 a real response, fast, when it actually fires.
Tools by MRR Stage (No Affiliate Links)
Tooling choices for solo support have changed a lot in the last three years. The old default of "buy Intercom when you can afford it" is no longer obvious, because purpose-built solo-friendly tools have appeared and big-team tools have grown more expensive. The right pick depends on your stage. The criteria below are pricing and free tiers as of the date this article was last reviewed; check the vendor sites before buying.
| Stage | What you actually need | Reasonable picks (no affiliates) |
|---|---|---|
| $0–$1k MRR | A shared inbox, a docs page, an in-app help link. That is it. | Crisp (free tier), Tawk.to (free), Notion or GitBook for docs. Your personal email forwarding to support@ is fine until it isn’t. |
| $1k–$10k MRR | One inbox you actually like, a search-indexable docs site, a way to send Loom replies, and basic tagging. | Help Scout starter, Crisp paid, or Front basic. Pair with Loom for any reply that takes more than three sentences to type. |
| $10k–$25k MRR | Lightweight automation (canned replies, simple triage rules), a real status page, billing dispute workflow. | Plain, Help Scout, or Front. Statuspage or Instatus for incidents. Stripe for billing disputes; the built-in tools are better than most CX tools’ equivalents. |
| $25k MRR+ | This is the breakpoint. Either invest in serious automation (AI deflection, real ticket workflow) or hire your first part-time CX person. | Intercom, Plain, or Help Scout at higher tiers. Or a VA on a 5–10 hour/week contract. |
A note on AI support bots. The marketing for AI deflection is several years ahead of the reality. Intercom’s own research on Fin and similar agents shows decent resolution rates on narrow product surfaces and much worse rates on anything novel or edge-case. For a small product with limited docs, an AI bot mostly produces wrong-but-confident answers, which is worse than no answer. Wait until you have a real corpus of FAQ content for a bot to draw from, and even then expect to spend significant time correcting it.
Response-Time Targets That Match What Customers Expect
There is an industry-wide habit of quoting "respond within an hour" as the gold standard. That comes from HubSpot and similar vendor research, and it is true on average across categories. For a solo SaaS founder it is the wrong target. The right target is predictable, not fast.
What the published research consistently shows is that customer satisfaction depends more on whether the response time matches the expectation set than on the absolute number. A product that promises "next business day" and delivers it scores higher than a product that promises "instant" and delivers four hours later. The lesson for a solo founder is to make the promise modest, then keep it.
| Stage | First-reply target | Resolution target (where applicable) |
|---|---|---|
| $0–$5k MRR | Under 24 business hours | Under 72 business hours |
| $5k–$25k MRR | Under 12 business hours | Under 48 business hours |
| $25k MRR+ | Under 4 business hours | Under 24 business hours |
| Any stage: Tier 3 incidents | As fast as you can. Aim for 1 hour | Same day where physically possible |
These are first-reply targets, not resolution targets. Even a reply that says "I saw this, I am looking at it, I will get back to you by [time]" counts as a first reply and almost always increases customer satisfaction more than waiting until you have the full answer. Help Scout’s research on small-team support is unambiguous on this: acknowledging a ticket within a stated window matters more than resolving it quickly.
Two practical rules:
- State your hours on the signup page and the support page. "Replies within one business day, Monday to Friday, [your timezone]." Customers who buy after seeing that have agreed to the contract. Customers who never see it assume 24/7.
- Match the slow target on weekends. Do this deliberately. A solo founder who answers tickets on Saturday teaches customers that the inbox is open on Saturday. The compound effect over a year is brutal. The right move is silence on weekends with the autoresponder explaining when you will be back.
The Four Reply Templates That Handle 80% of Tickets
The single highest-leverage thing a solo founder can do for support is to write four templates and use them shamelessly. The patterns that emerge from public founder accounts and from Help Scout’s research on canned responses agree: four cover most ground.
Template 1: Acknowledgement. Used for any ticket where you do not yet have the answer but want to set expectations. Two sentences. The first acknowledges the specific problem. The second commits to a follow-up time.
Thanks for writing, I saw this. I am looking at the issue with [the specific thing they mentioned] and I will get back to you by [a real time, usually next business day].
Template 2: Bug confirmation and workaround. Used when a customer hits a real bug. Acknowledge, give them a workaround they can use today, give a realistic timeline for the fix, ask one thing that helps you debug.
Confirmed, this is a bug on our side. In the meantime, you can [workaround]. The fix is on the list for [this week / next release], and I will email you when it ships. One thing that would help: could you send me [browser, screenshot, the exact URL, what you clicked just before]?
Template 3: Feature request triage. Used for the constant flow of "can the product do X?" tickets. Most of these are not bugs and most of them will not get built. The honest reply is short.
Good idea. We do not have this today and it is not on the short-term roadmap, but I have added it to the backlog and I will email you if it ships. If you want to see what is shipping next, the public roadmap is at [link].
Template 4: Refund, pause, or cancel. Used when a customer asks to leave. Do not negotiate, do not ask why. Process the refund or cancellation immediately and ask exactly one question afterwards, framed as optional.
Done, I have processed [the refund / cancellation] just now. You will see [the refund land in 3–5 business days / no further charges]. If you have a minute and feel like sharing, the one thing that would help me improve the product is to know what you were hoping it could do that it did not. Thanks for trying it.
The case for “refund first, ask later.” Generous refund policies are usually the right call for a small product. The total dollar cost of refunds in a typical micro-SaaS sits in the low single digits as a share of revenue, and the reputational cost of even one public “they refused to refund me” thread on Twitter or Reddit is dramatically higher. Process the refund, save the goodwill, learn the reason as a bonus.
When to Escalate, When to Ignore, When to Refund
Not every ticket deserves the same attention. The decision of how to handle one comes down to three questions, in this order:
- Is the customer affected right now, or describing something that already passed? A live outage is Tier 3; a "by the way, this happened yesterday and it is fine now" is Tier 2.
- Does the issue affect more than one customer? A single isolated bug for one user is Tier 2. A bug that other users are about to hit, or have already hit silently, is Tier 3 even if only one person has surfaced it.
- Is money or trust on the line? Billing disputes, accidental charges, and threats to publicly complain are Tier 3. They get answered today, regardless of which day today is.
The mirror question is when to actively ignore something. The honest answer is that some tickets are not worth answering: feature requests for things that contradict the product’s scope, abusive messages, free-tier users demanding behaviour that is reserved for paid tiers, and bug reports that are clearly user error after you have politely explained twice. Silence is a valid response to a small share of inbound; the trick is recognising the share is small.
Refunds are cheap. Attention is expensive. The mistake solo founders make is the reverse: spending an hour negotiating a $19 refund out of guilt or pride and then going back to the inbox with nothing left for the customer who actually has a problem. Set a default of yes on refunds under 90 days, and save the hour for the bug fix.
Async by Default: The Rule That Protects Your Day
There is a difference between being responsive and being available. The first is a service decision: customers get clear, accurate, well-timed replies. The second is an availability decision: customers can reach you at any moment. The first is good business; the second is how solo founders lose their evenings.
Async by default means three things:
- No live chat by default. A widget that says "we typically reply within a few hours" produces wildly different expectations than one with a green dot saying "online." The widget’s job is to capture a message, not to start a conversation.
- Two batched check-ins, not continuous monitoring. Morning and afternoon, fixed times. Close the inbox in between. The work of answering tickets is interruption-bound; one 30-minute batch produces more replies than four 7-minute interruptions.
- An autoresponder that is honest. "Thanks for writing. I will reply within one business day. If this is urgent, here is what to do in the meantime [link to docs or status page]." That single line removes 80% of the anxiety that drives follow-up emails.
Async is also the reason Loom works so well as a tool in this stack. A three-minute screen recording often does more work than fifteen minutes of typed back-and-forth, and it preserves the asynchronous shape of the conversation. The customer watches it at their own time, you record it once.
Signals You Have Outgrown Solo Support
At some point the structural fix stops working and the answer becomes a person, not a system. The signals that you have reached that point are both quantitative and qualitative.
The quantitative ones, drawn from the pattern across founder accounts past roughly $25k MRR:
- Inbound tickets are sitting above 30 per week for four consecutive weeks.
- First-reply time is creeping past your stated target despite batched workflow.
- Time spent on support is consistently above 15 hours per week, with no sign of plateau.
The qualitative ones are softer but more important:
- You have skipped product work on more than two consecutive weeks because the inbox demanded it.
- You are answering tickets on weekends, even though your autoresponder says you do not.
- The thought of opening the inbox produces a physical reaction.
The first move is almost never to hire a full-time CX person. The first move is a virtual assistant on a five-to-ten hour weekly contract, handling Tier 1 and the easy part of Tier 2 (Template 1 replies, Template 3 replies). The escalations stay with you. If you are unsure how to scope the work, our guide on how to outsource tasks as a small business owner covers the contracts and oversight cadence that work for first-time delegation. For the broader question of when adding people changes the economics of the product, see our breakdown of the economics of micro-SaaS businesses.
The deeper question that sits underneath this whole guide is whether the support burden is masking a different problem. Often it is. High inbound support volume in a small product is sometimes a churn signal in disguise: users writing in because the product is not delivering the promised value, not because there is a discrete bug. If you are working the system in this guide and the volume keeps rising, the answer might not be more support. It might be the work in our companion guide on how to reduce churn for a micro-SaaS. The same is true for pricing: low price tiers attract the customers who generate the most support per dollar, and revisiting how to price a micro-SaaS product often does more for the support load than any tool ever will.
