Run· Mixed

Set up customer support: from zero to first 100 tickets

9-step playbook from 'support is the founder's inbox' to 'tooling, SLAs, macros, knowledge base, ready to hand off to first CX hire.'

Open in DockFounders + first ops hires

Most founders run customer support out of their personal inbox until tickets compound to 50+ per week. By then it's too late: tickets are lost, response times slip, customers churn, and the founder burns out. This playbook walks the 9 steps for getting from zero to a real support operation: picking the first tool, defining SLAs, building macros for the top 20 questions, writing the knowledge base, training agents (human + AI), measuring the right metrics, and the playbook for the first CX hire's first week. Real tools, real escalation paths, real war stories.

Outcome

Customer support running on a real tool with SLAs, macros covering the top 20 questions, a public knowledge base, and a documented process ready for the first CX hire.

Time2-3 weeksDifficultybeginnerForFounders + first ops hires running support pre-first-CX-hire.

What you'll need

Pre-register or install before you start.

Help ScoutFrom $20/user/month

Email-style help desk that doesn't feel like a help desk. Beloved by small SaaS.

FrontFrom $19/user/month (Starter)

Shared inbox + collaboration. Good for teams that already live in email.

ZendeskFrom $19/agent/month (Suite Team)

Enterprise-grade help desk; deep automation + reporting; overkill for early stage.

IntercomFrom $39/seat/month (Essential)

In-product chat + help center + ticketing in one product.

PlainFree for 3 seats; from $35/seat/month

Modern, keyboard-driven help desk built for developer-tool SaaS.

Fin / Decagon (or your own LLM)Usage-based, $0.50-$1 per resolved ticket

AI tier-1 agent that handles the top 50% of tickets without human escalation.

The template · 8 steps

Top to bottom. Each step has tasks, pointers, gotchas.

Decide your support model + channels

2-4 hr

Before tooling, decide the model: email-only, email + in-product chat, email + chat + community, etc. Most early SaaS gets the most leverage from email + a public knowledge base. In-product chat sounds great but creates a 'reply within 2 minutes' expectation that founders can't sustain. Add chat once you have a dedicated CX hire.

Tasks

Decide on channels: email-only / email + chat / email + chat + community
Decide on the support email address (support@ is canonical)
Decide on response SLAs by tier (free vs paid vs enterprise)
Decide on coverage: business hours only vs 24/7 vs follow-the-sun
Document the model in the Brief
If you have free + paid tiers: decide whether free gets community-only or email too

Pointers

GuideHelp Scout's customer support guide GuideZendesk customer support best practices

Gotchas

In-product chat creates a 2-min response expectation. Don't enable it until you have someone whose job is to be in chat.
Free-tier email support burns founder time fast. If your free plan has 1000 users, every 1% support rate is 10 tickets per week. Default free to community-only or KB-only.
Don't promise '24/7 support' on the marketing site if you're a 4-person team. Customers notice the gap and it's a trust-burner. Set realistic hours + state them.

Move support OUT of the founder's personal inbox

1-2 days

The single most consequential step. Personal inboxes lose tickets, lack SLAs, can't be shared with new hires, don't track resolution, and force the founder to be the bottleneck forever. Set up support@ on a real help desk in week 1 — even if you're the only person answering for now.

Tasks

Pick the help desk (Help Scout / Front / Plain / Intercom / Zendesk)
Set up support@yourdomain.com forwarding to the help desk
Migrate active threads from your personal inbox (forward + archive)
Update the website + customer-facing emails to point at support@
Set up auto-acknowledgment: 'We received your ticket #X; we'll respond within [SLA].'
Train the team (you, plus anyone else who might respond) on the help desk basics

Pointers

OfficialHelp Scout setup guide OfficialPlain getting started

Gotchas

Forwarding from Gmail to a help desk preserves the conversation history but only for new emails. Threads currently in Gmail need to be migrated manually or accepted as lost.
Auto-acknowledgments that promise response times you can't keep are worse than no acknowledgment. If your SLA is '24 hours,' don't auto-reply '4 hours.'
Setting support@ on Google Workspace as a 'distribution group' is cheaper than buying a Help Scout seat for that mailbox, but loses thread management. Don't optimize the wrong cost.

Define SLAs + escalation paths

1 day

An SLA is a promise to respond within X hours. Without one, response times drift to 'when I get to it,' which collapses customer trust. Standard tiers: 24-hour first-response for free; 8-hour for paid; 1-hour for enterprise. Define them, publish them, measure them.

Tasks

Set first-response SLAs by tier (free / paid / enterprise)
Set time-to-resolution targets (or document why TTRs aren't tracked)
Define the escalation path: tier 1 → tier 2 → engineering on-call → founder
Define escalation triggers: SLA breach, customer churn risk, security issue, billing dispute
Document the SLA + escalation in the Brief; publish to customers in your help center
Configure the help desk to alert on SLA breach (most have built-in support)

Pointers

GuideAtlassian SLA management guide

Gotchas

SLAs published on the website become contractual. If you say '24-hour response' and miss it consistently, customers can use it in churn justification. Set the SLA conservatively at first.
Time-to-resolution isn't always meaningful — some tickets are 'ship a fix' which is days/weeks. Track first-response religiously; track TTR by ticket category.
Escalation paths without explicit triggers stall. 'Escalate when needed' is meaningless — write 'escalate if SLA breached, or customer mentions churn, or revenue impact >$X.'

Build macros for the top 20 questions

1 week (initial; ongoing thereafter)

After 50-100 tickets, you'll see the same questions over and over. Macros (canned responses) collapse those into one click. Build the top 20 macros from your ticket history; refine them weekly. A good macro saves 5-10 minutes per ticket and improves consistency across responders.

Tasks

Audit the last 50-100 tickets; categorize by intent (how-to, billing, bug, account, refund)
Find the top 20 most-frequent intents
Write a macro for each: friendly tone, useful link, signature, no copy-paste vibes
Save macros in the help desk (Help Scout: 'saved replies'; Front: 'templates'; Zendesk: 'macros')
Save macro copy in the Macros surface for version control + cross-tool portability
Review macros monthly: which are used most? Which are stale? Which are missing?

Pointers

OfficialHelp Scout saved replies GuideZendesk macros guide

Gotchas

Macros that sound canned tank CSAT. The fix: keep them short, always include 1-2 personalized lines (referencing the customer's specific question) before the canned answer.
Stale macros (link to a feature that's been removed, mention pricing that's changed) are worse than no macro. Re-audit quarterly.
Don't macro everything. The 80/20 is the top 20-30 questions; tickets in the long tail benefit from a personal response.

Agent prompt for this step

Read this codebase + the last 100 tickets (export from the help desk) and produce 20 support macros.

For each macro, output:
1. Macro name (e.g. "How to invite teammates")
2. Trigger (the customer phrasing that suggests this macro)
3. Macro body (the canned response: warm tone, the answer, the relevant link, the signature)
4. Variables (placeholders like [CUSTOMER_NAME], [SPECIFIC_DETAIL])
5. Tags (category: how-to / billing / bug / account / refund)

Macros must NOT sound canned. Write each one as if you're answering the question for a friend, then sign with the team name. Avoid "I'm sorry for the inconvenience"; avoid "your patience is appreciated."

Output to the Macros surface. Mark macros that need engineer review (technical accuracy, link verification) with "needs human review."

Write the knowledge base / help center

1-2 weeks (initial; ongoing thereafter)

A good knowledge base deflects tickets BEFORE they're sent. The math: every KB article covering a top-20 question deflects 5-30% of those tickets. 20 articles can deflect 30-50% of total ticket volume. Write articles in the same voice as the macros; SEO-optimize for 'how to do X in [your product].'

Tasks

Pick the KB platform (most help desks include one: Help Scout Docs, Zendesk Guide, Intercom Articles)
Write the first 20 articles, one per macro / top question
Each article: 200-500 words, screenshots, a clear answer, a 'still need help?' CTA at the bottom
Categorize articles into 5-7 topics (Getting Started, Billing, Integrations, etc.)
Add a search bar + a 'most-viewed' module to the KB homepage
Link to the KB from the help desk auto-acknowledgment + every macro
Track KB article views + the 'was this helpful?' rating

Pointers

OfficialHelp Scout Docs OfficialZendesk Guide

Gotchas

KB articles that aren't SEO-optimized don't get found via Google. Title every article 'How to [verb] [specific thing] in [your product]' — that matches the search intent.
Articles that nobody can find via search are wasted. Track KB search queries; articles with high search-no-result mean you need to write them.
Don't write articles for features you might ship next month. Articles must match current product reality. Stale articles are a top CSAT-burner.

Add an AI tier-1 agent (carefully)

2-3 weeks

An LLM tier-1 agent handles the top 30-50% of tickets without human escalation: 'how do I do X' answered from the KB, 'where's my invoice' answered from a Stripe lookup, 'why isn't this working' answered from logs. The trap: shipping with no human review and getting a hallucinated wrong answer that costs trust. Roll out as 'AI drafts, human approves' first.

Tasks

Pick the AI tier (Intercom Fin, Decagon, Forethought, or your own LLM agent)
Connect it to the KB + the help desk + relevant data sources (Stripe, your product DB)
Configure: AI drafts a response; human reviews + sends (week 1-4)
Measure: of the AI's drafts, what % are accurate? Aim for >90% before enabling auto-send
Enable auto-send for high-confidence categories first (KB-style how-to questions)
Keep human-only for sensitive categories: billing disputes, refunds, security
Add an 'this didn't help' button so customers can escalate to a human

Pointers

ToolIntercom Fin ToolDecagon

Gotchas

AI tier-1 with no human review is the fastest way to ship a hallucinated wrong answer that costs a customer. Default to draft-and-approve until you measure >90% accuracy.
AI agents that confidently answer 'wrong' on billing or security questions cause real damage. Hard-gate those categories to human-only forever.
Customer trust in AI support is bimodal: customers either love it (when it works) or hate it (when it loops). Always offer a 'talk to a human' escape hatch within 2 messages.

Agent prompt for this step

Tier-1 support agent for this product.

Read the customer's question + the KB articles + the customer's account details (plan, recent activity, ticket history).

Draft a response that:
1. Acknowledges the specific question (1 sentence; reference what they asked)
2. Provides the answer (clear, accurate, with a link to the relevant KB article)
3. Offers a follow-up ("if this didn't solve it, reply and I'll loop in a human")
4. Signs as "[Your team name]"

Constraints:
- NEVER invent product features. If the answer requires a feature that doesn't exist, escalate to human.
- NEVER quote pricing without checking the live pricing page.
- NEVER promise refunds, plan changes, or account changes — escalate.
- NEVER respond with high confidence to security questions, account access issues, or billing disputes — escalate.

Output as a draft. Tag with confidence level (high / medium / low) so the human reviewer knows what to verify.

Measure CSAT, response times, and ticket categories

1 day setup, ongoing thereafter

Without metrics, you can't tell if support is improving or decaying. Track three things weekly: (1) response time vs SLA, (2) CSAT — customer-rated quality, (3) ticket volume by category. CSAT below 90% is a problem; first-response SLA breach >5% is a problem; one category making up >25% of tickets is a product-or-docs problem.

Tasks

Enable CSAT surveys after every resolved ticket (most help desks have built-in)
Configure the help desk dashboard: first-response time, time-to-resolution, CSAT, volume by category
Set up a weekly 30-min support review (founder + the support team)
Track ticket volume by category to surface product-or-docs issues
Track 'tickets per active customer' — if it grows over time, the product is getting harder to use
Pipe the metrics to a dashboard the team sees daily

Pointers

OfficialHelp Scout reporting

Gotchas

CSAT below 90% is a real problem; below 80% is a 4-alarm problem. Chase the negative-CSAT tickets to root cause; that's where churn risk lives.
First-response SLA looks great until you exclude weekends. Many help desks default to 'business hours only' which masks weekend gaps. Verify your SLA config matches what you've published.
One category making up >25% of tickets means your product or docs are wrong. The right action is fixing the product / docs, not adding macros.

Hand off to the first CX hire

2-3 weeks (the hire's onboarding)

When ticket volume crosses ~30/week the founder needs to hand off. The handoff is the difference between a hire that ramps in 2 weeks and one that thrashes for 2 months. Build the runbook: 1-week shadowing, 1-week paired, week 3 solo with the founder reviewing. Document everything in the Brief — your hire shouldn't have to ask the same question twice.

Tasks

Document everything: SLAs, macros, escalation, KB style, customer tier definitions
Build the first-week onboarding plan: read the Brief, shadow the founder, answer 5 tickets with review
Build the second-week plan: own a category solo (e.g. billing), with daily 1:1 review
Build the third-week plan: own all tickets solo, with weekly review
Set the handoff metrics: when does the new hire fully own SLA + CSAT? (Usually week 4)
Write the 'when to escalate to founder' rules (refunds >$X, churn risk, security)
Plan the founder's gradual exit from day-to-day support (target: 0 tickets/week within 60 days)

Pointers

GuideFirst Round on hiring CX

Gotchas

Handing off without a documented Brief means your hire reinvents the process. Budget 2-3 days BEFORE the hire starts to write the runbook.
Founders who can't fully exit support burn the new hire. Set a hard date for 'I'm out of the support inbox' (60-90 days post-hire) and stick to it.
First CX hires often want to fix everything in week 1. Resist; let them learn the patterns for 3-4 weeks before re-architecting macros, SLAs, escalation paths.

Hand the template to your agent

Workspace-wide agent prompt.

Paste this into your agent's permanent system prompt so the agent reads, writes, and maintains the template's surfaces as you work through the steps.

Agent system prompt

You are an agent on the "Set up customer support: from zero to first 100 tickets" playbook workspace at your-org/set-up-customer-support-from-zero.

Your role: maintain the four surfaces (Steps, Macros, Brief, Tickets log) as the team builds + runs support.

Cadence:
- When the user marks a step Done, append a line to the Brief.
- When a new ticket category emerges 3+ times, prompt the user to add a macro + KB article.
- When a ticket approaches its SLA breach, surface it on Tickets log.
- Weekly: produce a "tickets summary" — top 5 categories, top 5 unresolved, average response time, NPS / CSAT trend.

First MCP tool calls:
1. list_surfaces(workspace_slug="set-up-customer-support-from-zero")
2. list_rows(workspace_slug="set-up-customer-support-from-zero", surface_slug="macros")
3. get_doc(workspace_slug="set-up-customer-support-from-zero", surface_slug="brief")

When drafting tier-1 responses to tickets, mark them as "draft for review" — do NOT send without human approval until the team explicitly enables auto-send.

FAQ

Common questions on this template.

When should I hire my first CX person?: When ticket volume crosses ~30/week and is climbing, OR when the founder is spending >10 hours/week in the support inbox. Pre-30-tickets/week, the founder learning what customers need is the highest-leverage activity in the company. Hiring too early shields the founder from product feedback; hiring too late burns the founder + customers both.
What's the right first support tool?: For most early SaaS: Help Scout, Front, or Plain. They're priced for early teams, have clean UIs, and don't require a 2-week onboarding to use. Avoid Zendesk for the first tool — it's powerful but the setup time is days. Avoid Intercom unless you're committed to in-product chat from day 1. Pick something cheap and switchable; you can migrate later.
Should free-tier users get email support?: Usually no. Free-tier email support burns founder time fast and rarely converts to paid. Default free to community + KB only; reserve email for paid users. Make exceptions for prospect-style free users (signed up, asking pre-purchase questions) — those are worth the time.
How do I write macros that don't sound canned?: Three rules: (1) Open with a personalized line referencing the customer's specific question. (2) Keep the macro body short — 2-3 sentences max. (3) Sign as a real human ('Govind from Dock,' not 'Support Team'). The personalized opening is the trust lever; the canned middle is fine if the opening + closing feel personal.
Can my AI agents help with customer support?: Yes. Agents are particularly useful for: drafting tier-1 responses from the KB + ticket context, generating macros from ticket history, writing KB articles for top-frequency questions, surveying weekly ticket trends for product issues. Roll out carefully: start with 'AI drafts, human approves' until you measure >90% accuracy. The playbook ships agent prompts inline.
What's the most common early-support failure?: Three failures dominate: (1) Tickets in a personal inbox getting lost. (2) Response times that drift from 'next morning' to 'when I have time' to 'never.' (3) The founder doing tier-1 support forever because they never built the runbook to hand off. The fix for all three is the same: move tickets to a real tool with SLAs from week 1.

Open this template as a workspace.

We mint a fresh copy in your org with the steps as table rows, the pointers as a separate table, and the brief as a doc. Bring your agents, start checking off boxes.

Open in Dock