A Solo Founder Does Not Need a Help Desk Yet

Support tooling is sold as a maturity signal. The pricing pages show a dashboard, a satisfaction score, and a smiling agent with a headset, and the implication is that a real company has one. A company with one person answering forty emails a week does not have the problem those products solve.

The problem a solo founder actually has is narrower: the same handful of questions arrive repeatedly, the answers are not written down anywhere, and every reply is composed from scratch at the moment it is needed.

Three products wearing the same label

A shared inbox is a mailbox with a second pair of eyes on it. Multiple addresses land in one place, assignment exists so two people do not reply to the same message, and internal notes sit next to the thread. It solves coordination between people.

A help desk is a workflow engine. Tickets get categories, priorities, SLAs, statuses, canned responses, satisfaction surveys, and reporting. It solves measurement and process, which are problems you have when support is a function with a manager.

An FAQ is a document. It solves the repeat question, which is the only one of the three problems that gets cheaper over time instead of more expensive.

Read the last row. Only one of these reduces the number of people who need help, and it is the one that is not really software.

The arithmetic of a solo support desk

Sixty tickets a week, six minutes each, is six hours of the week. That number is real and it feels like the thing to optimize.

Break it down instead. Suppose forty percent of those tickets — twenty-four a week — are four recurring questions: how do I reset this, where is my invoice, does this work with X, how do I cancel. Twenty-four tickets at six minutes is two and a half hours a week spent answering questions whose answers already exist somewhere in your head.

A help desk with canned responses cuts handling time on those to maybe three minutes. Saving: roughly seventy minutes a week. A shared inbox at solo scale saves nothing, because there is no second person to coordinate with.

Now the documentation fix. Write four articles, link them in the auto-reply, in the app, and in the receipt email. If that deflects two-thirds of the repeat tickets, you go from twenty-four to eight, saving about an hour and forty minutes a week — more than the help desk, without a subscription — and it keeps working next month, because the article does not get tired.

Treat the figures as illustrative; your mix will differ. The shape holds: at solo volume, deflection beats triage, and triage is the only thing you can buy.

The five-times rule

Count how often the same question arrives in a week. At five, it stops being a support problem and becomes a product or documentation problem, and answering it faster is treating the symptom.

Five password resets a week is a confusing settings page. Five "where is my invoice" is a receipt email that does not arrive. Five "does this work with X" is a homepage that does not say. The support reply is the cheapest possible place to learn this and the most expensive place to fix it.

This is also why the FAQ is worth writing before the tooling. Each article is a decision about the product, written down where a customer can find it, and it compounds. A help desk full of saved replies is a pile of decisions nobody can find.

Write the answer as it was asked

The most common FAQ mistake is writing in the company's vocabulary. Customers search for "my export is empty," not "data pipeline configuration." If the article is titled after your internal name for the feature, it will not be found, and you will conclude that documentation does not work.

Three habits fix most of it. Title the article with the sentence the customer used. Put the fix in the first two sentences and the explanation after. And keep one article per question rather than a comprehensive guide, because a long page is a page people skim and leave.

Where this lives matters less than whether it is linkable and fast. Notion is fine and most founders already have it; the requirement is a public URL, no login, and a search box. An article behind a workspace login is not a support article.

One more habit worth stealing from support teams that charge more than you do: put the article link in the place where the question occurs, not only in the help center. The reset article belongs next to the reset button. The billing article belongs in the receipt email. Every step a customer has to take to find the answer is a step where they give up and email you instead, which returns you to the six-minute reply you were trying to avoid.

The invisible failure: email that never arrives

There is a support failure mode that no ticket queue will show you, because the ticket never gets created. Password resets, receipts, and verification emails that land in spam produce customers who conclude the product is broken, and they either email you in anger or leave silently.

Before buying any support software, check three DNS records on your sending domain: SPF, DKIM, and DMARC. Transactional email — resets, receipts, notifications — should go through a provider built for it rather than through your personal mailbox or a marketing platform, because the deliverability requirements are different and the failure is silent.

If you route support email through a shared inbox provider, confirm that forwarding does not break authentication. A forwarded message that fails DMARC looks, to the receiving mail server, exactly like a spoofed one.

What to buy, in order

A public FAQ and an auto-reply that links to it. That is free and it is most of the benefit.

A shared inbox when a second person starts answering, or when support email arrives at three addresses and one of them gets forgotten for a week. This is a coordination purchase, so buy it when coordination is the problem.

A help desk when you have a support hire, a contractual response time, or more volume than one person can hold in their head. Even then, the useful features are assignment, saved replies, and a view of what is unassigned. The satisfaction survey is a metric that mostly measures whether people got what they wanted, which you already know.

A ticket tracker you already own is a legitimate intermediate step. Putting support requests into a Linear project, with a label and a due date, works surprisingly well below a few dozen tickets a week, and it keeps support next to the engineering work that fixes the cause. It is a bad long-term home — no customer-facing history, no email threading — but it is honest about how much process you actually need.

Rule of thumb: if you cannot name the second person who will answer tickets, you are not buying a support tool, you are buying a dashboard. Write the four articles instead, and revisit when the same question stops arriving.