SaaS founders at 2-10 people: how are you actually handling customer support right now?
Genuine question I keep running into while building Velor.
At 2-10 people, "customer support" usually means: whoever is closest to the keyboard answers. No dedicated support person, no ticketing system, just Slack/email chaos.
The options I see most founders try:
- Intercom / Zendesk: $300-500/mo, built for teams with a support org — massive overkill at this stage
- A basic chatbot: deflects to help articles, doesn't actually resolve anything
- Just… answering everything manually: works at 10 customers, breaks at 100
What I've noticed: the inflection point where support becomes a real tax on founder time usually happens faster than expected. One product hunt launch, one viral tweet, and suddenly you're spending 3 hours a day on "how do I reset my password" while your roadmap sits untouched.
Curious what's actually working for people here. Are you:
- Using a specific tool? (and which one)
- Just powering through it manually for now?
- Building something custom?
- Waiting until it's truly painful to solve it?
If anyone's building in a space where support is unusually high-volume (compliance, finance, HR — anything where customers have lots of questions), especially curious to hear from you.
(For context: Velor is what we built to solve this — AI support agent that grounds answers in your docs and takes actions instead of just linking to articles. Live demo at velorplatforms.com if curious.)
First of all, collect the most popular questions and cover them in text format on your FAQ or documentation page. Put a good search field on this page where people can search for exact words(not just related topics) to ease the searching process. After that, you will have fewer support requests.
I know that it will not cover all support topics, but at least you will not waste your time answering the most frequent questions.
The exact-word search point is underrated. Most doc search gets tuned for semantic recall -- finding "related" content -- but when someone is debugging, they're searching for the exact error string or the exact phrase they're stuck on. Related topics don't help when you need the specific answer.
The one wrinkle at very early stage: you often need to answer the same question 5 or 6 times before you recognize the pattern clearly enough to write an FAQ entry that actually maps to how people ask it. The docs improve fastest if you log the exact phrasing customers use, not the rephrased version in your head.
One pattern nobody's mentioned yet: at this size, a big chunk of "support" volume is actually pre-purchase, not post-purchase. Across a handful of small digital products, we found more time going to "does this include X" and "will this work for my case" emails than to actual bugs or how-tos. The fix wasn't a tool, it was front-loading those answers into the pricing page / FAQ itself so the question never becomes a ticket. Worth separating the two buckets before picking a solution - a doc-search or AI agent solves the post-purchase bucket well, but it won't touch the pre-purchase one, that's a page-copy problem.
Your point about the template creating the artifact that automation learns from is the exact thing most teams miss. The doc is not just an answer, it is training data the next loop can use. The split you drew between stable answers and live data ones is the right line, because caching the wrong type is how support bots give confident outdated replies. Curious which question type fills your cache fastest, the how to ones or the account specific ones.
How-to ones fill considerably faster. The phrasing varies across customers but not by much -- 3-5 examples usually cover 80%+ of the variation, and the answer is stable enough to cache without worrying it'll go stale.
Account-specific questions have the same underlying structure (why did X happen to me) but the answer depends on live account state, so they don't actually cache well as answers. What caches is the pattern -- you learn which signals to look up and in what order. The useful cutoff we found: if the same answer would be correct for any customer asking that question, it belongs in the KB. If the answer requires pulling their specific data, it's an action pattern, not a cached answer.
I would start by instrumenting issue volume, first-response time, resolution time, and repeated causes before choosing a support tool. At that size, the repeated questions are also product research and should feed a weekly fix-or-document decision.
Totally agree on instrumenting before picking a tool. The challenge at this size is that you're often tracking in your head -- issue volume is a vague feeling, first-response time is estimated, and repeated causes only surface when you notice yourself typing the same answer twice in one week.
The weekly fix-or-document decision is the right forcing function though. It's the teams who skip that loop who stay in permanent triage mode. What we found building Velor is that even just logging support volume by topic for 2 weeks reveals clusters you wouldn't have guessed -- usually 2-3 questions accounting for 60%+ of the load. Once you see that, the "which tool" question becomes much clearer.
Your point about the inflection point being faster than expected matches what we saw. The part that hurts most isn't volume, it's that every answer lives in someone's head or a Slack thread, so the second person to answer has to reconstruct context from scratch. What worked for us was forcing a short answer template with a link to the doc or the fix, so even the manual phase left a trail we could later automate from. Do you find your customers ask the same question multiple times before it gets resolved, or is it mostly one and done?
The knowledge-in-heads problem is the real bottleneck before tooling can even help. Your template approach -- short answer + link to the doc -- creates the artifact that automation needs to actually learn from. Most teams skip that step and go straight to tooling, which is why the tooling never knows anything useful.
On the repeat pattern: it splits by question type. How-to and feature questions come back from different customers over time -- same question, different person, repeatable answer. Account-specific questions (why did my charge fail, what's my usage at) tend to be one-and-done per customer but recur across the whole user base. The useful distinction is whether the answer is stable enough to cache or whether it needs live data each time.
We stayed manual until the same questions started showing up every day. That was our signal to automate frequency, not volume.
Frequency of a specific question is the right signal -- volume can spike from one unusual case. When the same question shows up daily from different people, the answer is stable by definition. That's actually the criterion: not how many tickets, but whether the answer you're about to give is one you've given before to someone different. If yes, it's a knowledge asset worth systematizing.
This isn't my thing, but I'm doing it anyway—good luck finding staff.
The staffing path usually comes later -- the earlier unlock tends to be getting the repetitive volume down so it stops feeling like a second job. Once the same-question-different-person stuff stops landing in your inbox, what's left are the novel problems that are actually worth a founder's time. That part tends to be more tolerable even when support as a whole isn't your thing.
I wonder if the trigger is less about hitting a certain volume and more about the kind of questions founders are answering.
Twenty questions that require judgment may still belong with the founder. Twenty repetitive questions with known answers suddenly feel like a system problem.
Right -- and the judgment questions are actually worth the founder's time in a way the repetitive ones aren't. Judgment questions reveal what the product isn't explaining, where the edge cases are, where customers are confused about scope. That signal belongs upstream. The repetitive ones are pure overhead: same answer, different person, every time.
The goal isn't "less support" -- it's preserving the valuable signal while eliminating the overhead. Those are different problems with different solutions.