Somewhere on your website — probably on a pricing page you wrote at midnight with more optimism than staff — there's a promise. "We respond within the hour." Maybe "15-minute response time," because a competitor said it and you weren't going to look slower. It was true the week you wrote it. Then came a product launch, a stomach bug, a Tuesday where forty tickets arrived before lunch, and the promise quietly became fiction. Nobody announced the change. Customers just noticed.

Here's what makes that expensive: customers don't actually rank support teams by raw speed. They rank them by whether reality matched what was promised. An answer in four hours against a promised four hours reads as reliable. The same answer against a promised fifteen minutes reads as failure — identical service, opposite verdict. When you inflate the promise, you don't buy a better reputation. You buy a worse one at the same cost.

The fix is to build your SLA in the only direction that works at small scale: backwards from capacity, not downwards from aspiration.

Start with arithmetic, not ambition

Before you promise anything, spend one week measuring three numbers. How many tickets actually arrive per day, and when — the hourly shape matters more than the total. How long a typical resolution takes, honestly, including the ones that need research. And how many hours of true support coverage exist — not headcount, coverage, because your "two-person team" is one person during standups, lunches, sales calls, and every Thursday someone works on the product.

Now the math is unavoidable. If thirty tickets arrive daily, resolution averages twenty minutes, and you have ten real coverage hours, you're at capacity before anything goes wrong — and something always goes wrong. Whatever response window survives that arithmetic with slack left over is your honest SLA. If the honest number embarrasses you, the answer isn't a braver promise. It's triage, automation, or different coverage — and until then, the honest number.

Tier by impact, not by mood

A single response time for everything is the second amateur mistake — it means password resets and production outages stand in the same line. Three tiers are plenty:

  1. Urgent — something is broken and blocking work. Outages, payment failures, data problems, locked-out accounts. Commit to your fastest honest window — for most small teams that's one business hour — and let this tier interrupt everything else. It's rare, which is precisely why you can afford to treat it seriously.
  2. Standard — a question or problem that isn't blocking. The bulk of your queue. Same business day if it lands in the morning, next business day if it doesn't. This is the workhorse window; set it where the arithmetic says, not where the competitor's website does.
  3. Low — feature requests, feedback, how-to curiosity. Two to three business days, stated plainly. Customers accept a slow lane without complaint when the fast lanes are real.

Note what the tiers are keyed to: impact on the customer's work. Not plan size, not how angry the email sounds. Anger is a signal about frustration, not urgency — and paying a premium to whoever shouts loudest teaches your politest customers to shout.

Publish the honest version — including the hours

Whatever the arithmetic produced, write it down where customers can see it, in clock terms, with your actual coverage stated. "Support hours: Monday–Friday, 9–5 Eastern. Urgent issues: response within 1 business hour. Everything else: same or next business day." That paragraph does more for perceived professionalism than any 15-minute claim, because it's the kind of paragraph a company that keeps its word writes. The after-hours question — what happens at 9pm Saturday — deserves its own design, and it's the one place automation can honestly extend your day rather than fake a human one.

Automate the clock, not the answer

Automation's job inside an SLA is to buy honest time, not to counterfeit attention. Three uses earn their keep. An acknowledgment that tells the truth — received, ticket number, and the real window for a human reply, not "we'll be right with you." Triage on arrival, so urgent-tier tickets surface immediately instead of waiting their turn behind password resets — this is the single highest-leverage automation a small queue can run. And instant resolution of the genuinely routine: the reset links, the where-do-I-find answers, the questions your docs already cover — handled immediately and clearly labeled, with a one-click path to a human. Every one of those makes the promise easier to keep. None of them pretends a person is awake who isn't.

Decide now what happens when you miss

You will miss. The flu, the launch, the Tuesday. Teams without a breach protocol miss silently, which converts one broken promise into a pattern of unreliability in the customer's mind. The protocol is one move: tell them before they notice. "This took longer than we commit to — here's where it stands and when you'll have an answer." A missed window plus a proactive note routinely leaves customers more confident than a met window ever does, because you've demonstrated the system notices its own failures. Track your hit rate weekly — one number, minutes to first response against promise — and when you beat the window for a full quarter, tighten it and say so out loud. Under-promise first; ratchet from evidence.

The bottom line

An SLA is not a marketing asset. It's a promise with a clock on it, and at two people the clock is unforgiving. Measure the real capacity, tier by impact, publish honest windows with honest hours, automate the acknowledgment and the triage rather than the relationship, and own every miss before the customer has to point at it. A small team that keeps a modest promise reads as more professional than a big one that breaks a bold promise — and unlike speed, that reputation is one you can afford.

— Tom

Keep the promise without staffing for it

CSByDesign triages on arrival, resolves the genuinely routine instantly with a clear path to a human, and surfaces urgent-tier tickets the moment they land — so the windows you publish are windows you keep.

See how CSByDesign works →

About the author

Tom Christian is the founder of CSByDesign, an AI-native customer support platform built for small teams — and the team of one.

He has spent twenty years inside customer service operations, training, and QA at scale — Guardian Life, ConnectiveRx, and Horizon Blue Cross Blue Shield's Service Division. He writes about running support as a team of one, de-escalation that holds under pressure, the AI-drafts/human-sends line, and the operating discipline of solo CS.