Your first support workflow: why a solo founder should not automate it yet

Paying customers come with a thing the free trial never did: a steady trickle of "hey, quick question". A login that will not stick. A confusing button. An invoice that did not arrive. You have a dozen customers, three or four messages a week, and every blog post and every tool vendor is already telling you the answer: buy a help desk for twenty quid a month, or spend a weekend wiring up an AI agent that triages and replies to tickets on its own.

Do not. Not yet. At three to thirty customers, automating support is the most expensive mistake you can quietly make, because it deletes the single richest source of product feedback you will ever have, and it does it before you have read it.

This post is the opposite of the standard advice. It is a deliberately manual support workflow for the stage you are actually at: small, unglamorous, an afternoon to set up, and built so that every ticket teaches you something instead of disappearing into a queue. Claude Code has a role here, but it is a back-office helper for you, not a bot pointed at your customers.

Your first tickets are your roadmap, not your overhead

Here is the reframe that changes everything. At your scale, a support ticket is not a cost to be minimised. It is a free, unsolicited, specific piece of product research from someone who cared enough to write to you.

Every message falls into one of three buckets, and all three are gold:

• A missing or unclear doc. "How do I export my data?" means the feature exists but is undiscoverable. Cheap fix, high value.
• A confusing bit of the product. Three people asking the same "where is X" is a UI problem wearing a support-ticket costume. The fix is in the product, not the reply.
• A bug. The customer just did your QA for free and told you exactly how to reproduce it.

Read fifty tickets at twelve customers and you will know more about what to build next than any survey, any roadmap-voting widget, any "let us know your feedback" form ever gave you. The whole point of staying close to support at this stage is that the tickets and the roadmap are the same document. The moment you put an autoresponder between you and that signal, you are paying to not learn the thing your competitors would kill to know.

That is the case against premature automation in one line: an AI agent that resolves a ticket without you reading it has not saved you work, it has hidden your roadmap from you.

The one rule: stay manual on purpose

So the rule for the next few months is uncomfortable and correct: handle support by hand, deliberately, until volume forces you to stop.

This is not laziness or a lack of ambition. It is the same logic as doing things that do not scale early on. You are not trying to run an efficient support operation. You are trying to extract maximum learning from minimum volume, and the way you do that is by reading every single ticket yourself while there are still few enough to read.

"Manual" does not mean chaotic, though. There is a difference between answering support out of a personal inbox where it drowns under newsletters, and running a tidy, intentional manual process. The second one is what we are building. It just stops short of the automation everyone is trying to sell you.

The afternoon setup

You can stand the whole thing up in an afternoon. Four pieces, no more.

1. One shared inbox, separate from your personal email. Not your day-to-day Gmail where a customer's "I cannot log in" sits three rows below a Stripe receipt and a newsletter. A single dedicated address, something like help@yourdomain or hello@yourdomain, that exists only for customers. You can run it through any plain shared-inbox setup; you do not need a help-desk platform yet, just one address you check on purpose rather than one you stumble across. The goal is simple: when you sit down to do support, everything that is support is in one place, and nothing that is not support is in it.

2. A response-time promise you can actually keep. Put one line on your contact page and in your welcome email: "We reply within one working day." Then keep it. An honest, modest promise you hit every time builds more trust than an ambitious one you miss. Under-promise, over-deliver, and never set an expectation your solo-founder week cannot honour.

3. Five saved replies for the top eighty per cent. Track your first twenty or thirty tickets and you will see the same handful of questions over and over. In almost every early SaaS, five canned answers cover the bulk of the volume:

• Billing and invoices ("where is my receipt", "how do I update my card")
• Login and password ("I cannot get in")
• A how-do-I for your core action ("how do I do the main thing your product does")
• Feature requests ("can it also do Y")
• Bug reports ("X is broken")

Write a clear, friendly, reusable draft for each. Keep them somewhere one keystroke away. These are starting points, not finished messages.

4. A rule you never break: personalise before you send. A saved reply gets you eighty per cent of the way; the last twenty per cent is reading the actual message and adjusting. Use their name, reference their specific situation, delete the bit that does not apply. Customers can tell instantly when they have been pasted at, and at your size a single human, clearly-read reply is a competitive advantage the funded competitor with the chatbot literally cannot buy. Speed matters, but read-then-reply beats fast-and-generic every time.

That is the whole front end. One inbox, one promise, five drafts, one rule.

The weekly fifteen-minute support review

The setup handles individual tickets. The compounding comes from what you do with them in aggregate, and that is a fixed fifteen minutes a week. This is the same discipline as your weekly metrics review, applied to support.

Once a week, same slot, do four things:

1. Read the week's tickets in one sitting. Not to reply, you already did that. To see the shape of the week.
2. Tag each by theme. Billing, login, confusion-about-feature-X, bug, feature-request. Tally them. A tag with three marks against it is a pattern, not an incident.
3. Pick the single most common ticket and kill it at the source. This is the entire game. If "how do I export" came up four times, the fix is not a faster reply, it is a visible export button or a one-paragraph doc linked from the right screen. If a bug came up twice, fix the bug. You are not trying to answer support faster; you are trying to make this week's most common ticket never arrive again.
4. Write down the one fix you are making. One line, somewhere durable. Next week, check it worked and the ticket volume for that theme dropped.

Do this for two months and your support load does not grow linearly with your customers, because you are continuously deleting the reasons people write in. That is the opposite of what an autoresponder does. An autoresponder makes the symptom cheaper to handle. The weekly review removes the cause.

Where Claude Code actually helps right now

None of this means you write everything by hand with no tooling. It means you point the tooling at yourself, not your customers. The line is simple: Claude Code is allowed in the back office, not on the front line.

Two genuinely useful, human-in-the-loop helpers you can build in a short session:

A ticket tagger and summariser. A thin internal script that takes the week's incoming messages and, for your eyes only, suggests a theme tag and a one-line summary for each. It turns your weekly review from "read twenty emails" into "skim twenty pre-tagged one-liners and correct the tags it got wrong". You still read everything; the machine just does the clerical first pass. Ask Claude Code to read the messages, classify each into your existing tag list, and output a simple table. Nothing customer-facing, nothing sent automatically.

A draft-from-your-docs assistant. Point Claude Code at your own help docs and let it produce a first-pass reply to a tricky ticket, grounded in what your documentation actually says, which YOU then edit and send. The value is that it drafts from your real docs rather than inventing an answer, and the human-in-the-loop step is non-negotiable: you read and adjust every draft before it goes out. If your docs cannot answer the question, that gap is itself a finding for the weekly review.

The shared rule across both: the customer always hears from a human who has read their message. The AI compresses your clerical time, it does not replace your judgement, and it never speaks to a customer unsupervised at this stage. If you keep the human in the loop you get the time saving without going blind to the patterns, which is the entire trap of the weekend-built support bot.

One practical note if you do build these: keep them simple and keep your data tidy. If your tickets land in a shared inbox and your customer records live in Supabase, a small read-only helper that joins the two for your weekly review is plenty. Resist the urge to build a full internal help-desk product. You are saving yourself fifteen minutes of clerical work, not launching a second SaaS.

When to graduate to real support tooling

This manual workflow is right for now, not forever. You will feel the moment it stops fitting. Concretely, graduate when:

• Tickets no longer fit in a single weekly read because there are simply too many to look at one by one.
• You bring on a first person to help with support and need shared ownership, assignment, and a record of who replied to what.
• The five saved replies have ballooned into twenty and you need a proper knowledge base and macros to manage them.

That is roughly the hundred-customer zone, give or take, and it is the right time to adopt a real help desk and, only then, to consider customer-facing automation for the genuinely repetitive tier-one questions. By that point you will have something the weekend-bot crowd never built: a documented taxonomy of your top twenty recurring issues, the standard answers, and the root-cause fixes you already shipped. That taxonomy is what makes a help desk and any later automation actually work, and it is the direct product of having stayed manual long enough to read your own support.

For now: one inbox, a promise you keep, five drafts, a fifteen-minute weekly review that kills one ticket at the source, and Claude Code kept firmly in the back office. Read your support while it is still small enough to read. It is the cheapest market research you will ever get, and the day you automate it away is the day you stop hearing your customers.