Setting a Solo Founder Support SLA | Coding Capybaras

Photo by Abdülkadir Vardi on Unsplash

A solo founder support SLA should be the slowest promise you're willing to defend on your worst week, not the fastest one you managed last Tuesday. That's the whole trick. Most founders either publish nothing — which lets every customer invent their own expectation — or publish "we reply within an hour!" and then break it the first time they get on a plane. The useful version sits in between: one number, scoped to hours you're actually awake, with your real timezone stated and a plan for the days you miss it. Here's how to pick that number and write it down.

TL;DR

• Publish something. With no stated target, customers invent one, and the one they invent is faster than yours.
• Most of what founders call an SLA is really an SLO — a target with no contractual penalty. Say "we aim to" rather than "we guarantee" unless money is on the line.
• Pick the number from your check-in cadence, not from your best week. If you sweep the inbox twice a day, you cannot honestly promise four hours.
• State your timezone and your working days in plain text. Vagueness reads as evasion; "I'm one person in US Central" reads as honest.
• Keep a private target tighter than the public one, so a bad day eats your buffer instead of your promise.

What a support SLA actually is (and why you want an SLO)

Borrow the vocabulary from site reliability engineering, because they've already had this argument and settled it well.

Google's SRE book separates three things that founders tend to smush together. An SLI is the thing you measure. An SLO is the target you're aiming at. An SLA is a contract with consequences. As Chapter 4 of the SRE book puts it, an SLA is "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain" — and the test for telling them apart is to ask what happens if you miss. If nothing happens, it's an SLO. The book notes in a footnote that "most people really mean SLO when they say 'SLA.'"

That distinction matters more for a solo founder than for a 200-person company, because you're the one who eats the consequence.

For a self-serve product at $19 or $97, you want an SLO: a stated aim, no penalty attached. Write "we aim to reply to every email within one business day" rather than "guaranteed response within 24 hours or your month is free." You get the expectation-setting benefit without creating a refund obligation that triggers every time you get the flu. Save the contractual version for enterprise deals where somebody's procurement team demands one and the deal size justifies the risk.

So the mapping for support:

• SLI: time from a customer's first message to your first human reply.
• SLO: the target — "90% of first replies within one business day."
• SLA: the same target with a refund or credit attached. You almost certainly don't want this yet.

The reason to publish anything at all is the sharpest line in that chapter: "Without an explicit SLO, users often develop their own beliefs about desired performance, which may be unrelated to the beliefs held by the people designing and operating the service." That's exactly what happens in a support inbox. Silence doesn't mean no expectation — it means an expectation you didn't get to set, formed by whatever else the customer used last week. If that was Intercom-backed live chat at a company with a night shift, you're being measured against a night shift.

And the cost of falling short of an invented standard is mostly invisible. Zendesk's customer service statistics roundup cites Coveo research finding that 56% of consumers rarely complain about a bad experience — they quietly switch to a competitor instead. You don't get an angry email telling you your response time cost you the account. You get a cancellation with no reason given, which is the least actionable signal in your entire business.

How fast do you actually need to be?

Fast enough that the customer doesn't wonder whether anyone is home. That's the real bar, and it's lower than the marketing content around support benchmarks implies.

The honest way to pick the number is to work backwards from your calendar, not forwards from an aspiration. If you check the support inbox twice a day — morning and evening — then a ticket that lands right after your morning sweep waits until evening. That's your worst case, and it's the only number you can promise without hoping.

The arithmetic is unforgiving in a useful way. Two sweeps a day across a sixteen-hour waking window gets you to eight hours — which is exactly "same business day," and which is a perfectly respectable public promise. Getting to a four-hour promise means four sweeps a day, every working day, forever. Getting to one hour means you are effectively on call, and you should be honest with yourself about whether you're signing up for that.

The Google SRE guidance on choosing targets applies here almost word for word. "Don't pick a target based on current performance," the book warns, because adopting a number without reflection "may lock you into supporting a system that requires heroic efforts to meet its targets." Your current performance, in month two with eleven customers, is unrepresentative. You're replying in nine minutes because you're refreshing the inbox out of anxiety. That is not a sustainable operating parameter and you should not publish it as one.

The companion rule is "don't overachieve." Users build on the reality of what you offer rather than what you say you'll supply — reply in nine minutes for six months and your customers now have a nine-minute expectation regardless of the sentence on your contact page. The SRE fix for this at Google is deliberately taking Chubby offline to flush out unreasonable dependencies. The founder version is less dramatic: don't reply at 11pm just because you saw it. Let the reply go out in the morning. You're not being lazy; you're keeping your published number true.

Two more from the same list that translate directly:

• "Perfection can wait." Start with a loose target and tighten it. Going from "one business day" to "four hours" is a nice email to send your customers. Going the other way is an apology.
• "Keep a safety margin." Run a tighter internal target than the one you publish. If you tell customers one business day, aim privately for four hours. The gap absorbs the dentist appointment, the deploy that goes sideways, and the ticket that needs an hour of investigation before you can say anything useful.

One nuance worth stealing from the same chapter: measure percentiles, not averages. A mean first-reply time of five hours can hide a handful of tickets that sat for three days, and those are the ones that churn. "90% within one business day" is a more honest target than "average response time of X" — and it's the shape of promise you can actually check.

What to promise when you sleep and your customers don't

This is the part founders fudge, and fudging it is worse than the constraint itself.

You are one person in one timezone. Some of your customers are twelve hours away. There is no wording that makes those facts go away, and every attempt to obscure them — passive voice, "our team," a support address that implies a rota — reads as exactly what it is. Customers are remarkably forgiving of a small operation being small. They are much less forgiving of being misled about it, and the tell is always the same: the reply arrives signed by the same name every time.

State it plainly. "I'm a one-person company based in US Central. I answer support Monday to Friday, and I aim to reply to everything within one business day." That sentence does more work than any SLA table.

Then decide the shape of the promise. Three options, and only one of them is usually right:

| Model | What you publish | Worst case for the customer | Honest for a solo founder? | | --- | --- | --- | --- | | Business hours | "Within 1 business day, Mon–Fri, US Central" | Friday 5pm ticket answered Monday | Yes — the default | | Follow-the-sun | "Within 4 hours, any time" | 4 hours | No, not without a second human | | Tiered by plan | "1 business day standard, 4 hours on Pro" | Depends on plan | Yes, once you have a paid tier |

Business hours is the right default and it's what most indie SaaS should ship. The weekend gap is real and you should say so rather than hoping nobody notices: "Tickets that arrive over the weekend get answered Monday morning" is a sentence that costs you nothing and prevents a Saturday of someone refreshing their inbox.

Tiering by plan becomes reasonable once you have a paid tier that can justify it — faster support is one of the few upgrade incentives that costs you nothing until someone actually uses it, which is worth thinking about when you're structuring what each plan includes. But don't tier before you can hit the base tier reliably. A Pro SLA you miss is worse than no Pro SLA, because now you've broken a promise someone paid for.

The exception to all of this is downtime. When the product is broken, the response-time promise is the wrong instrument entirely — nobody wants a personal reply to "is it down for everyone?", they want a page that already says so. A status page answers the whole inbox at once and turns twenty tickets into zero. Set your incident communication expectations separately from your support SLO; they're different promises with different mechanics.

The autoresponder that doesn't annoy anyone

An autoresponder is how the promise gets delivered at the exact moment the customer needs it, and most of them are a waste of an email.

The bad ones say "we have received your message and will get back to you as soon as possible." That sentence contains zero information. The customer already knows they sent an email. "As soon as possible" is not a time. It reads as a machine acknowledging a machine, and it slightly lowers the customer's confidence that a human will ever appear.

Help Scout's guidance on writing an auto-reply email is the right shape: set expectations for what response time to expect, name any windows when you won't respond, and point at self-serve options for the meantime. Three jobs, one short email.

The version I'd send:

Thanks for writing in — this is an automatic note to confirm it arrived.

I'm Justin, and I'm the whole support team. I answer email Monday to Friday
from US Central, and I aim to reply within one business day. Messages that
arrive over the weekend get answered Monday morning.

If it's urgent and you're stuck, these cover about half of what I get asked:
  → [three or four links to your most-asked docs]

You don't need to reply to this — I'll be in touch.

Four things that email does that the generic version doesn't. It names a human, which lowers the temperature of an angry ticket immediately. It gives a real number tied to real working days. It surfaces the docs at the moment of highest motivation, which is the only time anybody reads documentation. And it tells the customer not to reply, which stops the polite "thanks!" that reopens the ticket in most helpdesk tools.

Two things to avoid. Don't include a ticket number unless you have a system where that number means something to the customer — it signals bureaucracy you don't have. And don't send an autoresponder to a thread you're already in; nothing undermines a support relationship faster than a robot interrupting a live conversation. Most tools have a setting for this; check it, because the default is often wrong.

The other half of the work isn't an email at all: it's making the answer available before the question. Every ticket you answer twice should become a docs page, and the autoresponder should link to it. That's the compounding loop, and it's the only way response-time pressure gets easier as you grow instead of harder. The support tooling worth setting up as a solo founder covers the mechanics of getting canned replies and a help center in place without spending a fortune.

One habit that makes the whole thing sustainable: batch the inbox. Two or three fixed windows a day, closed the rest of the time. Answering support continuously feels responsive and destroys your ability to build anything, because every reply costs you a context switch you don't get back — which is the core argument for time-blocking as a solo founder. Batching is also what makes your published number honest, because it's the cadence the number was derived from.

Missing it well

You will miss it. The question is what happens next, and this is where a solo founder can beat a support department outright.

Acknowledge the delay in the first line. "Sorry — this sat for three days" before anything else. Don't explain, don't lead with the fix. Customers are not tracking your response time in a spreadsheet; they're tracking whether you noticed. Naming it yourself resolves it. Burying it under a helpful answer reads as hoping they didn't notice.

Never justify with your circumstances. "I've been swamped" invites the customer to weigh your problems against theirs, which is a comparison you lose. One clause of acknowledgement, then the answer.

If you know in advance, say so in advance. Going somewhere without signal for a week? Change the autoresponder before you go and put the date you're back in it. A stated week is fine. A silent week is a churn event. This is the single highest-return five minutes in solo support operations.

Track your own misses, roughly. Not a dashboard — a note. If more than one in ten tickets blows past your published target for a month running, the target is wrong, not your effort. Loosen the published number or change your check-in cadence. Continuing to publish a number you miss weekly is worse than publishing an honest slower one, because now every customer has direct evidence that your promises are decorative.

And a reframe worth holding onto: the thing customers actually want isn't speed, it's certainty. Zendesk's benchmark data finds that 70% of customers expect anyone they interact with to have full context on their situation — the underlying want is don't make me explain this again, and don't make me wonder if anyone is reading. A slower reply from someone who obviously read the whole ticket and knows the account beats a fast reply that asks for information already in the thread. That's the advantage you have as a founder answering your own support, and what founder-led support actually teaches you is mostly about not giving it away too early.

A corollary that founders resist: a fast, clear "no" is a good support outcome. Some of the tickets are feature requests you're not going to build, and hitting your response target with an honest decline is better than a slow maybe. Saying no to feature requests is its own skill, but the timing part belongs here — a decline delivered inside your SLO is respectful; the same decline three weeks later is not.

Frequently asked questions

What's a realistic support response time for a solo founder?

One business day, measured Monday to Friday in your stated timezone, is defensible and achievable if you sweep the inbox twice a day. Four hours is achievable but requires roughly four check-ins a day, every working day. Anything under an hour means you're on call, and you should decide that deliberately rather than drift into it.

Should I promise a response time publicly or just try to be fast?

Publish it. With no stated target, customers form their own expectation based on whatever else they use, and that expectation is almost always faster than yours. A published number you hit is better for trust than an unpublished one you usually beat.

Do I need an SLA to sell to businesses?

Usually not below about $500/month. Smaller business customers accept a stated response-time aim on your support page. Once procurement gets involved you'll be asked for a contractual SLA with credits attached — at that point negotiate the number down to something you can hit on your worst week, because the penalty is real.

How do I handle support when I go on vacation?

Change the autoresponder before you leave, state the exact date you're back, and say plainly that replies will be delayed until then. Optionally leave a genuine emergency path — a form or an address you'll check once daily. What you must not do is leave the normal promise up and quietly miss it for nine days.

Should I measure average response time or a percentile?

A percentile. An average hides the tickets that sat for days, and those are the ones that cost you customers. "90% of first replies within one business day" is both more honest and easier to check than a mean, and it matches how SRE teams have measured latency for years.

Is live chat worth it for a one-person company?

Only if you're willing to turn it off. Chat sets a minutes-not-hours expectation the moment the widget appears, and a chat bubble nobody answers is worse than no bubble. If you run it, run it during stated hours and let it fall back to email outside them.

Wrapping up

A solo founder support SLA is not a customer-service artefact, it's a constraint you write down so you stop negotiating it with yourself at 11pm. Pick the number from your actual check-in cadence. Say your timezone and your working days out loud. Keep a private target tighter than the public one so bad days eat the buffer instead of the promise. And when you miss, lead with the acknowledgement.

The one that took me longest to accept was "don't overachieve." Every instinct says answer immediately, every time — and every immediate answer quietly raises the bar you'll be measured against six months from now, when you're busier.

If you're building the product those tickets are about, Coding Capybaras is the free boilerplate I write about here — the same one running this site, with the billing, auth, and lifecycle email pieces already wired up so support is about your customers instead of your infrastructure.