How to handle support@ as a solo or 3-person SaaS founder (without hiring, and without a bot that traps people)

Run support@ as a sorted queue with written promises. Sort every email into four categories: pre-sales, how-do-I support, billing and bugs. Give each category an owner, a reply-time promise and an automation level. Let software answer only from a facts sheet you wrote. Send money, security and angry emails to a founder. Tell the customer the time a person will reply. Plan for about two hours of setup and 30 minutes of review each week.

The weak point is the handoff nobody owns. In Gorgias platform data (October 2025 to April 2026), 55% of AI-touched tickets went to a human, and one-third of those never got a human reply⁴.

Who should use this support@ runbook?#

This support@ runbook fits SaaS teams of one to three people who answer customer email themselves. One founder in r/EntrepreneurRideAlong put the job plainly (thread with 20+ comments, mid-2026): "I am one person. I write code, I do support, I handle billing issues." A solo founder on Ask HN in 2022 reported an average of 15 to 20 user emails a day².

Use this runbook if:

• A founder answers support@ between other work, up to about 50 emails a day.
• Customers write from more than one time zone.
• You want some automation, but not a widget that blocks the way to a person.

Do not use it if:

• A full-time support hire already owns the queue. Use their process.
• Most support happens in shared Slack channels with customers.
• Customer contracts set response times. Copy those in first.

What do you need before you start?#

Prerequisites for this runbook are access, a sample of real email and one written page. Collect them first.

• Mailbox admin access. You need the right to add forwarding and filters on the host that receives support@ (Google Workspace, Microsoft 365 or your email host).
• DNS access, if any tool will send replies as support@.
• A sample. Pull the last 90 days of support@, or at least the last 50 threads.
• Your source documents. Pricing page, refund policy, plan limits, docs and status page URL.
• Named owners. One person per category. Solo? Write your name anyway.

Dry run: the support@ audit#

The support@ audit is a one-hour count of what your inbox already holds. Do it before automating anything.

1. List the last 50 to 100 threads. Verify: your count matches the mailbox count.
2. Tag each thread. Use pre-sales, support, billing, bug or other. Verify: "other" holds under one in ten. If it holds more, add a category.
3. Note the hour. Mark each thread that arrived outside your working hours.
4. Mark doc-answered threads. Flag every thread your FAQ or docs answer word for word. Verify: you can paste the exact link.
5. Mark dropped threads: no reply, or stopped after one.

You now have four numbers per category: volume, after-hours share, doc-answered share and dropped share. One former support lead who ran Fin rollouts wrote that "~50% of the inbounds I receive are fully written out in plain language in an FAQ"¹. Your share will differ. Measure it. Do not borrow it.

How to set up support@ in eight steps#

Setting up support@ for a small SaaS team takes eight steps, in order. Each step has a check and an exit.

1. Keep one address. Forward sales@, billing@ and help@ into support@. Verify: a test to each alias lands exactly once. If not, fix forwarding before step 2.
2. Create the four category labels. Add filters on subject words as a first pass: "invoice", "refund", "pricing", "error". Verify: rerun the filters on your audit sample. If fewer than seven in ten land right, tag by hand for one week and try again.
3. Write the facts sheet. Use one page: plans, prices, limits, trial length, refund policy, integrations, approved security answers, status page URL, known bugs. Date it. Verify: every line has an owner and a date. Do not proceed if the refund policy is unwritten. No software touches billing without a written rule.
4. Set a reply-time promise per category. Use the starting values in the runbook below. Verify: would you have kept each promise on last month's sample? If not, loosen it. A kept eight-hour promise beats a missed one-hour one.
5. Pick an automation level per category. Use three levels: Autopilot (software sends answers from the facts sheet), Draft (software drafts, a founder approves) and Always you. Start one level more careful than feels right. Verify: list the exact questions each Autopilot category may answer. Anything off the list routes to Draft.
6. Write the handoff line. Every email that waits for a person gets a reply naming the reply-by time. Verify: a test that must hand off shows a time and a time zone.
7. Set the overnight rule. See the next section. Verify: send a test at 23:00 your time and read what goes out.
8. Book the weekly review. 30 minutes, same day each week. Verify: the first review has a written log.

How do you cover nights and other time zones with one to three people?#

Overnight support for a small SaaS team comes down to two choices: what may be answered at 3 a.m., and what time you promise for the rest. A founder thread in r/indiehackers ("International expansion almost killed my startup", 10+ comments) opens with "Customer in Japan has problem at 3am."

Gorgias found 53% of pre-purchase questions on its e-commerce platform arrive outside business hours, with a median first response of about 15 hours, against 2.2 hours in hours (July 2026)⁵. Those are store numbers. Treat them as a warning.

• Answer at any hour: anything the facts sheet covers word for word.
• Hold for a person: money, security, outages, angry tone, and anything not on the sheet.
• Promise in their time zone. "Tomorrow morning" means nothing to a customer eight hours away.
• Split by hours, not by topic. With founders in two zones, each owns the whole queue in their waking block. Hand over a written list of open threads and reply-by times.
• Outages go to the status page. Reply with the link. Never let software guess a cause or a fix time.

The support@ runbook#

The support@ runbook maps each category to an owner, a promise, an automation level and an escalation rule. Adjust the starting promises after two weekly reviews.

Handoff line (paste into every reply that waits for a person):
"I'm [Company]'s AI assistant. A founder handles [refunds / this question].
[Name] will reply by [time, customer's time zone, day].
If anything changes before then, reply here and it goes straight to them."

Overnight rule: sheet facts go out at any hour. Everything else gets the
handoff line with a reply-by time at the start of the next working block.

What should software never answer on its own?#

Software answering support@ should never state a rule, a price or a promise that is not on your facts sheet. Cursor showed the cost in April 2025. Its email support bot, "Sam", told a user the product was "designed to work with one device per subscription as a core security feature." No such policy existed³.

Users posted cancellations. About three hours later a Cursor rep called it "an incorrect response from a front-line AI support bot"; the user was refunded³. Put these on the never list:

• Refunds or credits outside the written policy.
• Discounts of any size.
• Security and compliance claims not on the sheet.
• Roadmap dates, outage causes and fix times.
• Legal requests and data deletion.
• Any change to a customer's money or data without a written rule.

Unsure whether to automate? Read should a startup use AI for customer support.

Failure modes and rollback#

Support@ runbooks fail in six known ways. Each has a check, a fix and a rollback trigger. Run the checks weekly.

Failure 1: the customer cannot reach a person#

A trapped customer is the most common founder complaint about support bots. A thread in r/micro_saas titled "We lost 56 customers after I tried to save money with AI" drew 240+ comments in September 2026. Its stated fix was to "escalate to a human when it detects the AI is stuck on a loop." On Ask HN in May 2026, one commenter wrote: "The worst part is when the AI keeps repeating the same thing again and again instead of just connecting you to a real person"⁶.

Five9 surveyed 1,006 consumers in the US, UK and Canada: "72% of consumers are open to AI-powered interactions, provided they can escalate to a human when needed"⁷.

• Check: search sent mail for threads with three or more automated replies.
• Fix: route to a founder on the words "person", "human", "cancel" or "refund", or on a second email about the same issue.
• Rollback trigger: one thread where a customer asked for a person and got another automated answer.

Failure 2: software states a policy you do not have#

An invented policy is the Cursor failure: software fills a gap in the facts sheet instead of handing off.

• Check: read every automated reply that mentions money, limits, devices, seats or security. Each must match a line on the sheet.
• Fix: add the missing line, or move the topic to Always you.
• Rollback trigger: any reply with no matching line. Pause the topic, and have a founder email a correction within one working day.

Failure 3: the handoff goes nowhere#

An unowned handoff is the failure the numbers show most clearly. In Gorgias data from accounts with 200+ AI-touched tickets (October 2025 to April 2026), the median wait after handoff was 10 hours and the 90th percentile was 71 hours. 30% of email handoffs and 42% of contact-form handoffs were abandoned⁴. These are e-commerce figures.

• Check: each morning, filter "waiting on founder" for anything past its reply-by time.
• Fix: every handoff carries a reply-by time and a backup owner.
• Rollback trigger: two missed reply-by times in one week. Loosen that promise before you add more automation.

For a full handoff standard, see how to hand off from AI to a person without trapping anyone.

Failure 4: the autoresponder promises a time you miss#

A generic autoresponder is the lone founder's default. One r/shopifymerchantgrowth thread describes an "auto responder… we will be back in 24 hours." Gorgias's benchmark puts the median email first response at "12+ hours." Brands automating close to zero percent averaged 736-minute response times⁸.

• Check: compare last week's promised and real first-reply times.
• Fix: state the real time, then shorten it by fixing the queue.
• Rollback trigger: the promise was missed more than once.

Failure 5: the facts sheet goes stale#

A stale facts sheet produces confident wrong answers. A founder of a human-powered support service wrote on Hacker News: "The tech isn't the hard part, the AI needs access to high quality context"⁹. A builder in another thread named the hard parts as "reviewing the logs of actual usage" and "tuning human escalation procedures"¹.

• Check: compare the sheet's date with your last pricing, plan or policy change.
• Fix: change the sheet the same day as the change ships.
• Rollback trigger: the sheet is older than the last change. Drop affected topics to Draft until it is updated.

Failure 6: the bill grows on resolutions you cannot check#

Per-resolution billing counts different things by vendor. Fin charges "$0.99 per outcome · 50 outcomes per month minimum," and one counted outcome is "No further help is requested after Fin's last answer"¹⁰. Help Scout charges $0.75 per AI resolution and does not count it if the customer escalates or clicks "I still need help"¹¹. Prices checked 1 October 2026.

• Check: each month, read 20 billed resolutions.
• Fix: if several were customers giving up, move that category to Draft.
• Rollback trigger: you cannot see what was billed. See what counts as an AI resolution.

Rollback sequence#

The rollback sequence works for any category after any failure. Run it in order.

1. Drop the category to Always you. Verify: a test email gets the handoff line, not an answer.
2. Pull every automated reply in that category since the last review.
3. Email each affected customer from a founder. Say what was wrong and what you will do.
4. Fix the sheet line or routing rule.
5. Send five test emails. Only then move the category up one level: Always you to Draft, never straight to Autopilot.
6. Log it. Write the failure and the fix in the weekly review log.

The 30-minute weekly support@ review#

The weekly support@ review keeps the other seven steps honest. Run the same agenda each time.

1. Count. Volume by category against last week.
2. Promises. List each missed reply-by time, and why.
3. Read ten automated replies. Each must match a sheet line.
4. Repeats. Name the top three repeat questions. Fix the product first, then the docs. One popular r/SaaS comment (August 2026) put it: "Repeated questions -> think about product design first, then if not add FAQs."
5. One decision. Move one category up or down one automation level. Write it in the log.

Where Valet fits#

Valet is one way to run steps 3 to 7 without moving to a helpdesk. You forward support@ to a private Valet address, and replies go out from support@ once your domain is verified. Valet answers only from your own facts and never invents a price, discount or policy. Each topic runs on Autopilot, Ask me first or Always you, the same three levels as this runbook. Money, complaints and legal questions go to you with one-tap replies, and the customer is told when you will reply. Every reply says it is AI and comes with a Valet receipt: what was asked, the rule used, the sources. To see where your inbox stands today, start with the free lead check: forward 10 to 20 recent emails and see what went unanswered.