Customer Support

Support is not a cost centre to minimise. Early on it's your highest-bandwidth product-research channel, every ticket is a user telling you exactly where your product confused, failed, or disappointed them. Founders who do their own support early build better products.

The concept

Support does three jobs, and their priority inverts as you grow:

 EARLY   product research    every ticket reveals a real defect or gap
 ALWAYS  trust and retention a good support experience recovers churn
 SCALED  cost management     efficiency matters once volume is real

The mistake is jumping to job three too early, optimising for deflection and cost before you've learned what job one has to teach.

⭐ Do your own support early

For your first users, you answer every ticket. Not because you can't afford help, but because you can't afford to not hear it. Patterns you'd never see in analytics surface in the first fifty conversations: the feature nobody can find, the wording that misleads, the step that always fails.

Every recurring ticket is a product bug or a documentation gap. A support queue that keeps asking the same question is your roadmap telling you what to fix or explain.

The channels

Start with email plus a small FAQ. A support email on your own domain is often store-required anyway (Chapters 35, 36). Add richer channels when volume justifies them.

The FAQ is a product surface

A good help centre deflects the repetitive questions so you can spend attention on the novel ones. Seed it from your actual tickets, the questions people actually ask, in the words they actually use. Writing a good FAQ answer is also a signal that the product should probably make the answer unnecessary.

Response quality that builds trust

• Reply fast, even if only to acknowledge. Silence reads as "they don't care."
• Solve the actual problem, not the literal question. Ask what they were trying to do.
• Own failures plainly. "That's a bug, we're fixing it, here's a workaround" beats deflection.
• Close the loop when you ship a fix, "you reported X, it's fixed in the latest update" turns a frustrated user into a loyal one.
• Be human. Early support is a relationship, not a ticketing SLA.

Turning support into product

Make the loop explicit:

 ticket → categorise → recurring? → yes → product fix OR FAQ entry
                                  → no  → one-off resolution
        → close the loop when shipped

Tag tickets by theme. When a theme recurs, it's not a support problem, it's a product problem wearing a support costume (Chapter 4). This is the same discipline as converting findings to tracked items (Chapter 30): a ticket that isn't turned into a fix or an FAQ entry is a lesson thrown away.

Scaling support

Only once volume is real:

• Macros/templates for genuinely repetitive answers.
• A help centre that deflects the top questions.
• AI-assisted triage and drafting, with a human check; never let an unsupervised model make promises or handle sensitive cases (Chapter 23).
• A community so users help each other.
• Hire when support consistently eats the time you need for the product (Chapter 52).

Never scale away the learning before you've learned it. Deflection is for known problems; your early queue is full of unknown ones.

📐 A ticket you don't turn into a fix or an FAQ entry is a lesson thrown away. Early support is the same discipline as converting review findings to tracked items (Chapter 30): the value isn't answering the question, it's routing the recurring ones into the product before you automate them away.

📐 Best practice

Do your own support for the first users.

Treat every recurring ticket as a product bug or doc gap.

Start with email + a small FAQ on your own domain.

Reply fast, even just to acknowledge.

Solve the real problem, not the literal question.

Own failures plainly and offer a workaround.

Close the loop when you ship a fix.

Tag tickets by theme and route recurring themes to the product.

Seed the FAQ from real tickets, in users' words.

Scale (macros, help centre, AI, community, hires) only when volume is real, never before you've learned from the queue.

💀 Common mistakes

Outsourcing or automating support before learning from it. You lose your best product signal.

Treating support as pure cost. Optimising deflection before understanding.

Slow or no response. Silence reads as indifference and drives churn.

Answering the literal question, not the underlying goal.

Deflecting blame instead of owning a bug.

Not closing the loop on fixes, a missed retention opportunity.

Not tagging tickets, so recurring themes never reach the roadmap.

A stale FAQ that doesn't match the product.

Unsupervised AI support making promises or mishandling sensitive cases.

No support channel at all, often a store rejection, always a trust failure.

Hiring for support too early, before you've extracted the learning yourself.

The professional workflow

 1. SET UP EMAIL + a small FAQ on your own domain (Chapter 35)

 2. DO IT YOURSELF for the first users

 3. FOR EACH TICKET
    reply fast · solve the real problem · own failures ·
    tag by theme

 4. RECURRING THEME? → product fix OR FAQ entry

 5. CLOSE THE LOOP when a fix ships

 6. SEED THE FAQ from real tickets

 7. SCALE ONLY WHEN VOLUME IS REAL
    macros → help centre → AI-assisted (with human check) →
    community → hire

 8. REVIEW ticket themes monthly as product input

Tools, websites & costs

Early support costs $0, a forwarded email and a Notion FAQ. Tooling arrives with volume.

Alternatives & trade-offs

Email vs live chat. Email is async, low-pressure, and universal; chat is fast and sets an expectation of immediacy you must meet. Start email; add chat when you can staff it.

Self-serve vs high-touch. A great help centre scales and can feel impersonal; high-touch support builds loyalty and doesn't scale. Early: high-touch (you learn). Later: self-serve for common cases, high-touch for the rest.

In-house vs outsourced. Outsourcing scales cost-effectively and loses product signal and brand voice. Keep it in-house until you've learned what the queue teaches; outsource routine tiers later, never the founder's early listening.

AI support vs human. AI drafts and triages well and can mishandle nuance, make false promises, and fail sensitive cases badly. Use it to assist a human early; automate only well-understood, low-risk cases, with escape hatches to a person.

Reactive vs proactive. Reactive answers what's asked; proactive (in-app tips, status updates, follow-ups) prevents tickets. Proactive scales better but requires knowing your common failure points, which you learn from being reactive first.

Checklist

• A support channel exists on my own domain (often store-required)
• I do support myself for the first users
• I reply fast, even just to acknowledge
• I solve the real problem, not the literal question
• I own failures and offer workarounds
• I tag tickets by theme
• Recurring themes become product fixes or FAQ entries
• I close the loop when fixes ship
• The FAQ is seeded from real tickets
• I scale (macros, AI, hires) only when volume is real
• Ticket themes feed my roadmap

📓 Case Study: the infrastructure without the conversations

Project: SOLIS. This case study is unavoidably about what didn't happen, because the product never launched and therefore never had a single support ticket. But the infrastructure was built, and the gap between infrastructure and use is itself the lesson.

The support surface was set up properly. A support address on the product's own domain (support@ via free email routing, forwarding to a real inbox, with replies going out authenticated, Chapter 35) plus a support page with contact details and an FAQ, which doubled as the store-required Support URL (Chapter 36). The store requires a support channel, so building one was non-negotiable, and it was done to a good standard, on-brand, with real deliverability rather than a throwaway address.

The FAQ, however, could only be guessed. With no users and no tickets, the FAQ was seeded from what the founder imagined people would ask, not from what people actually asked, because nobody had. That's the fundamental limitation: the single richest source for a support FAQ is real tickets, and a pre-launch product has none. The FAQ that shipped is a hypothesis about user confusion, not evidence of it.

⚠️ The deviation is total, and honest: there was no support, because there were no users. Everything this chapter is actually about, doing your own support to learn, treating recurring tickets as product bugs, tagging themes, closing the loop, letting the queue drive the roadmap, none of it could happen. The product-research value of support, which is the whole point of the chapter, was never available.

What generalises from a project that never supported anyone:

1. The store forces you to build the channel before you have anyone to support, which is the right order for the channel, wrong order for the FAQ. Build the pipe early (it's required and it's cheap); write the FAQ from real tickets later.
2. A support email is part of your infrastructure stack, not a launch afterthought, it depends on domain and deliverability work that takes time (Chapter 35).
3. A pre-launch FAQ is a placeholder. Treat it as v0, and rewrite it from the first fifty real tickets, which will not match your guesses.

🚩 Everything the chapter teaches is untested here. The most honest framing: SOLIS built the ability to receive support and never received any, so it demonstrates the setup and nothing about the practice. The practice, support as product research, only exists once real people have real problems, and that's precisely what a never-launched product lacks.

Lessons

1. ⭐ Do your own support early. It's your highest-bandwidth product-research channel, and it only exists once you have users.
2. Every recurring ticket is a product bug or a doc gap. The queue is a roadmap.
3. Build the support channel early, it's often store-required and depends on domain/deliverability work.
4. Seed the FAQ from real tickets, not guesses. A pre-launch FAQ is a placeholder that won't match reality.
5. Reply fast; solve the real problem; own failures plainly.
6. Close the loop when you ship a fix, it converts frustration to loyalty.
7. Tag tickets by theme and route recurring ones to the product.
8. Scale support only when volume is real, never automate away the learning before you've learned it.
9. AI assists; a human decides on nuance and sensitive cases.
10. Infrastructure without conversations teaches you nothing. The value of support is the users, not the tooling.

Next: Chapter 43: Messaging and Copywriting →

This completes Part VIII, The company.