The Post Office

How to set up customer support as a founder

Connect support@, write a few help articles, put a widget where people already are, train the AI, then give it a job every day, every week, and every month.

You do not need a support team on day one. You need an address people can write to, a few articles the AI can learn from, a widget where they already are, and three loops so the inbox does not rot.

This is the order I would use if I had to start again. Email first, because people are already writing. Then the docs, then the widget, then the training. The agent in chat comes after that. Not before.

1. Connect a support email

support@yourdomain.com or help@. One address on your domain, forwarded into a shared inbox, not a personal Gmail. If the inbox lives in one person's Gmail, the week they travel, nobody answers.

Do not split sales@, help@, and billing@ yet. People pick at random, and mail goes missing. Live chat can wait fifteen minutes. Email is already happening.

2. Write the first articles

If you already have a help center, import it. If you do not, do not sit down to write a documentation project. Ask your agent.

Point it at the repo, the site, and last month's mail if you still have it. Ten short articles beat a hundred empty ones. Login. Failed payment. The bug you already fixed three times. How to export. How to cancel. These are what you paste, what the widget can search, and what the AI will invent a refund policy for if you skip them.

Ours ships on the free plan, on your domain. Empty docs make a confident agent. That is worse than no agent.

3. Add a widget

Chat on the marketing site is "what is this." Chat in the product is "this button did nothing." Different questions. Put a support widget on both.

Same queue as email, or you have two products. If the widget cannot hand off to a human, people type, hear nothing, and write to support@ anyway, without the screenshot.

If the bubble fights your UI, headless customer support is the same inbox behind your own components. We did not start there. The snippet on the two pages where people get stuck was enough.

4. Train the AI

An agent trained on nothing will make up a refund policy. So before you turn it on in chat, feed it.

Crawl the website. Add the help articles you just wrote. Add the messy stuff: how refunds actually work, how you handle a bug, what "we'll look into it" is allowed to mean. PDFs, a Notion export, a URL. Fernand AI takes the site, the docs, and anything you want to give it. The training guide is short.

Look at the bill on other tools before you turn theirs on. Fin is $0.99 every time it closes a conversation. Help Scout is $0.75. Small in a demo. I wrote the numbers down in what AI resolution actually costs. Ours is included, which is why this step is not a pricing decision.

5. Write the instructions

Training is what it knows. Instructions are how it behaves.

Tone. When to answer. When to offer a human. What it must never promise. Fernand splits this by where the AI shows up: the widget, the composer, the knowledge base. Settings, then AI Instructions. Included.

Do not write them from a blank box. Ask the same agent that just wrote your articles.

Read what it gives you once. Cut anything you would not send yourself. Then paste it.

6. Turn it on in the widget

Now. Not in step 2.

The chat agent answers from the training and the instructions. There is always a way through to a human. Leave that visible. Watch it miss for a day in the inbox drafts before you let it talk to people on the marketing site at 2am.

If you already live in Cursor or Claude Code, the widget agent and an agent on the API are two different jobs. The first one talks to customers. The second one works the inbox for you. You can use both. We turned the widget on after the docs existed. The loops came next.

7. Every day

The inbox still needs a pass, even with the widget answering. Once a day is enough when you are two people.

Draft the easy replies. Tag what is actually done as Resolved, or your reporting will be fiction. Clean up the noise. Follow up on the thread that went quiet.

You can do this by hand. Or you give an agent a key with drafts and tags, not reply, and you read a briefing with coffee.

More of these jobs, with the permissions each key needs, are on AI agents.

8. Every week

The help center you wrote in step 2 will be wrong by Thursday. New question, old article, a sentence that used to be true.

Once a week, the same agent reads the inbox against the docs. It should come back with edits, and with new articles written from the gaps, not a vibe. You publish. It does not.

If the same bug is the gap, that is a product problem. Knowledge base insights will show you the searches that hit nothing. The agent should be looking at the conversations, not only the dashboard.

9. Every month

Volume, what got Resolved, what the widget absorbed, which tags grew. Inbox insights is the page. The loop is reading it and changing something.

An article you are still typing from memory. An instruction that lets the agent promise a date. A tag nobody uses. One or two changes. Not a redesign of support.

That is the whole setup. One address, a few articles, a widget, an agent that knows the product, and three loops. We did not hire a support lead while we still had ten conversations a day. We also did not buy a desk built for hundreds of agents. Those notes are in eight help desks for SaaS. If the only constraint is price, I compared free plans that include email.

Fernand is free to start. 100 conversations a month, email included, no card. We left Gmail open beside it until the old tab felt unnecessary.

Continue reading