Support

Customer Support & Documentation

The best support interaction is the one that never happens. This skill helps you build self-serve documentation that eliminates tickets, set up efficient support workflows, and scale from 10 to 10,000 customers without a support team.

Core Principles

• The best support interaction is the one that never happens. Invest in self-serve before staffing.
• Documentation is not a chore — it's the highest-leverage support tool you have. One good help article prevents thousands of tickets.
• Support is research. Every ticket reveals a product flaw, a UX failure, or a documentation gap. Track and fix the root cause, not just the symptom.
• Tone matters more than speed. A warm, helpful reply in 4 hours beats a robotic auto-response in 4 seconds.
• A solo founder can support 500+ customers if the product, docs, and onboarding are good. If support is crushing you at 50 customers, the product has problems.

Minimal Support Setup

What You Need at Launch

Tier 1: Absolute minimum (launch day)

• Contact email (support@yourdomain.com) routed to your inbox
• 5-10 FAQ entries on a /help or /faq page
• In-app "need help?" link that opens email compose

Tier 2: First 100 users

• Help center with 15-25 articles covering common questions
• Canned responses for the 5 most common questions
• Simple ticket tracking (even a spreadsheet or Notion board works)

Tier 3: 100-500 users

• Dedicated help center tool (Intercom, Crisp, HelpScout, or Plain)
• In-app chat widget (live during business hours, async otherwise)
• Knowledge base with search
• Response time target: <4 hours during business hours

Tier 4: 500+ users

• All of above + automated responses for common issues
• Status page for incidents
• Community forum or Discord for peer-to-peer support
• Consider first support hire (or contractor)

Tool Recommendations by Stage

$0/mo:       Email + Notion/Google Docs help page
$0-50/mo:    Crisp (free tier) or Tawk.to (free)
$50-100/mo:  HelpScout Starter or Intercom Starter
$100-300/mo: Intercom or Plain (for developer tools)

Help Center Architecture

Information Structure

Organize by user journey, not by feature:

Getting Started
  ├── Creating your account
  ├── Setting up your first [core object]
  ├── Inviting team members
  └── Connecting your data source

Core Features
  ├── [Feature 1]: How to [outcome]
  ├── [Feature 2]: How to [outcome]
  ├── [Feature 3]: How to [outcome]
  └── Working with [key concept]

Account & Billing
  ├── Changing your plan
  ├── Updating payment method
  ├── Understanding your invoice
  ├── Canceling your account
  └── Exporting your data

Integrations
  ├── Connecting [Integration 1]
  ├── Connecting [Integration 2]
  └── API documentation

Troubleshooting
  ├── [Common error 1]: How to fix it
  ├── [Common error 2]: How to fix it
  └── Something else not working?

Writing Help Articles

Structure for every help article:

# [Task the user is trying to accomplish]

[One sentence: what this article helps you do.]

## Before you start
[Prerequisites — what the user needs before following these steps.]

## Steps

1. [Action verb] [specific instruction].
   - [Sub-detail if needed.]
   - [Screenshot or note if helpful.]

2. [Next action verb] [specific instruction].

3. [Continue until task is complete.]

## What to expect
[What happens after they complete the steps. What they should see.]

## Common issues

**[Issue 1]**
[Cause and fix in 1-2 sentences.]

**[Issue 2]**
[Cause and fix in 1-2 sentences.]

## Related articles
- [Link to related topic 1]
- [Link to related topic 2]

Writing rules:

• Title = the task, not the feature. "How to invite team members" not "Team Management."
• One article per task. Don't combine "setting up billing AND inviting users."
• Use screenshots only when the UI is non-obvious. Don't screenshot every click.
• Write for the user who is mildly frustrated and in a hurry.
• Test every article by following the steps yourself on a fresh account.
• Keep articles under 500 words. If longer, split into multiple articles.

FAQ Page

Write FAQ entries for these universal SaaS questions:

Getting Started:
  - How do I sign up?
  - Is there a free plan / trial?
  - How long does setup take?

Product:
  - What does [Product] do?
  - Who is [Product] for?
  - What integrations do you support?
  - Can I import my data from [competitor]?

Pricing & Billing:
  - How much does it cost?
  - Can I change plans?
  - Can I cancel anytime?
  - Do you offer refunds?
  - Is there a discount for annual billing?

Security & Data:
  - Is my data secure?
  - Where is my data stored?
  - Can I export my data?
  - What happens to my data if I cancel?

Support:
  - How do I get help?
  - What are your support hours?
  - How fast do you respond?

Support Response Templates

Canned Responses (customize, don't copy-paste robotically)

Acknowledgment (use when you need time to investigate):

Hi [Name],

Thanks for reaching out — I can see the issue and I'm looking into
it now. I'll get back to you within [timeframe] with an update.

[Your name]

Bug confirmed:

Hi [Name],

You're right — this is a bug on our end. I've identified the cause
and I'm working on a fix. I expect to have it resolved by [timeframe].

I'll email you as soon as it's deployed. Sorry for the trouble,
and thank you for catching this.

[Your name]

Feature request (saying no):

Hi [Name],

Thanks for the suggestion — I can see how [feature] would help
with [their specific use case].

Right now I'm focused on [what you're prioritizing and why], but
I've logged this and I'll revisit it when we get to [relevant area].
In the meantime, here's a workaround that might help: [workaround].

Appreciate the feedback — it genuinely shapes where the product goes.

[Your name]

Churn response (someone cancels):

Hi [Name],

Thanks for letting me know. I'm sorry [Product] didn't work out.

If you're comfortable sharing, I'd really appreciate knowing what
prompted the switch — even a one-line answer helps me make the
product better for others.

Either way, your data will be available for [X] days if you change
your mind. Thanks for giving us a try.

[Your name]

Confused user (unclear how to do something):

Hi [Name],

Great question — here's how to [do the thing]:

[2-4 numbered steps]

I've also added this to our help docs so it's easier to find next
time: [link].

Let me know if you run into anything else.

[Your name]

Reducing Support Load

The Support Reduction Loop

1. Track ticket topics (tag every ticket by category).
2. Find the top 5 topics by volume.
3. For each:
   a. Can the product fix it? → File bug/UX improvement → fix it.
   b. Can docs prevent it? → Write or improve the help article.
   c. Can onboarding prevent it? → Add tooltip, empty state copy, or setup step.
   d. Can an automated response handle it? → Create auto-reply or chatbot flow.
4. Repeat monthly.

Ticket Tracking Template

| Date | User | Category | Summary | Root Cause | Action Taken | Preventable? | Prevention Action |

Common categories:

• How do I...? (documentation gap)
• This doesn't work (bug)
• I expected X but got Y (UX confusion)
• Can you add...? (feature request)
• Billing question (pricing/plan confusion)
• Can't log in (auth issue)

In-App Self-Service

Reduce tickets by building these into the product:

• Contextual help links: "Need help with this? [link to specific article]" next to complex features.
• Empty state guidance: Every empty screen tells the user what to do and why.
• Inline error messages: Explain what went wrong and how to fix it (see Copywriting skill).
• Onboarding checklist: Prevents "I signed up but don't know what to do" tickets.
• Status indicators: Show system status in-app so users don't email asking "is it down?"
• Changelog / what's new: Prevents "when did this change?" confusion.

Support Metrics

Track monthly:

| Metric                      | This Month | Last Month | Target   |
|-----------------------------|------------|------------|----------|
| Total tickets               |            |            | Trending↓|
| Avg first response time     |            |            | <4 hours |
| Avg resolution time         |            |            | <24 hours|
| Tickets per 100 users       |            |            | <10      |
| Top ticket category         |            |            |          |
| % resolved by docs (no reply)|           |            | >30%     |
| CSAT (if measured)          |            |            | >4.5/5   |

The key ratio: Tickets per 100 users. If this is rising, your product is getting harder to use. If it's falling, your docs and UX improvements are working.

Related Skills

• community — Build a community that supplements support
• feedback — Turn support tickets into product improvement insights
• copywriting — Write clear help articles and canned responses
• retention — Support quality directly impacts churn