CS Processes
Build Stage | $0-1M ARR | 1-10 headcount
Main challenge: Proving the business works. Founder-led everything.
Customer Success Processes
Onboarding
Stage-appropriate approach: Founder-led, white glove. Every customer gets personal attention — this is about learning, not optimizing.
What Build stage onboarding looks like:
- Founder runs onboarding — Critical to understand where customers get stuck, what confuses them, what delights them.
- High-touch, manual — Walk them through setup. Do things for them if needed. Unit economics don't matter yet.
- Document as it happens — Note what questions come up, what trips people up. This becomes the onboarding playbook later.
Minimum onboarding structure:
- Kickoff call — Align on goals, timeline, success criteria
- Setup/configuration — Help them get the product running
- Training — Show them how to use it for their specific use case
- First value checkpoint — Confirm they've gotten initial value (within first 1-2 weeks)
What qualification reveals:
- Time to first value — how long does it take?
- Common blockers — what slows people down?
- Success patterns — what do successful customers do differently?
Playbook reference: → Onboarding and Process Improvement (for later — when you have patterns to systematize)
Success Metrics
Stage-appropriate approach: Keep it simple. Track usage and satisfaction — don't build elaborate health scores yet.
What to track at Build:
| Metric | What It Reveals | How to Track |
|---|---|---|
| Login frequency | Are they using it? | Product analytics or CRM |
| Core action completion | Are they getting value? | Define your "aha moment" action |
| NPS or satisfaction | How do they feel about it? | Simple survey after 30 days |
| Support requests | What's confusing? | Email/Slack volume |
What NOT to track yet:
- Elaborate health scores (not enough data to calibrate)
- Predictive churn models (sample size too small)
- Segment-specific benchmarks (no segments yet)
How to use these metrics:
- Weekly: Scan for customers who've gone quiet (low login) — reach out personally
- Monthly: Review NPS responses — founder should read every one
- Quarterly: Look for patterns in who succeeds vs. who churns
Playbook reference: → Customer Lifecycle (for later — when you have volume)
Product Feedback Collection
Stage-appropriate approach: Founder is the feedback loop. Stay close to customers — don't delegate this yet.
How to collect feedback at Build:
- Weekly customer calls — Schedule regular check-ins with active customers. 15-30 min is enough.
- Founder on support — Handle support yourself (or be CC'd on everything). Every question is signal.
- Post-interaction notes — After every call/demo/support thread, capture: What did they ask for? What confused them? What delighted them?
- Design partner sessions — Deeper working sessions with your closest customers to validate roadmap.
What to do with feedback:
- Capture everything — Use a simple system (Notion, Linear, even a spreadsheet). Don't trust memory.
- Look for patterns — 1 customer asking for something is data. 5 customers asking is a signal.
- Share with product — If the founder isn't the product person, make sure they hear customer voice directly (recordings, quotes).
What NOT to do:
- Don't build elaborate feedback systems — speed matters more than process at this stage
- Don't delegate feedback collection — founder needs to internalize it
- Don't act on every request — patterns matter more than individual asks
Playbook reference: → NPS and Voice of Customer Launch (for later — when you have volume and want to systematize)
Renewal Process
Stage-appropriate approach: Manual and relationship-based. Founder touches every renewal — this is about learning what makes customers stay.
Build stage renewal process:
- Track renewal dates — Know when each customer is up. A simple spreadsheet or CRM field works.
- Start conversations early — 60-90 days out, check in. "How's it going? What would make next year even better?"
- Founder involvement — Personal conversations with every renewing customer. Delegate later, not now.
- Learn from every outcome — Win or lose, understand why.
When a customer churns:
- Always do a churn interview — Even 15 minutes of honest feedback is gold.
- Ask directly: "What would have made you stay?" and "What will you do instead?" (invaluable data)
- Document the pattern — Track reasons in your CRM. Look for themes.
What NOT to do:
- Don't automate renewal emails yet — too few customers, and you lose the learning
- Don't offer excessive discounts to save churning customers — understand the root cause first
- Don't ignore renewals until the last minute — late renewal conversations are desperate conversations
Playbook reference: → Renewal, Churn, NRR, GRR Reporting (for later — when you have volume to analyze)
Reference & Testimonial Generation
Stage-appropriate approach: Start asking early. Design partners signed up to be references — use that.
How to generate social proof at Build:
- Ask design partners first — They agreed to this when they signed up. Get a quote, logo, and reference availability.
- Time the ask right — After a win, after positive feedback, after a successful go-live. Strike when they're happy.
- Make it easy — Draft the quote for them. They can edit. "Here's what we heard — can we use this?"
What's needed:
| Asset | Why | How to Get |
|---|---|---|
| Logo | Social proof on website | Ask: "Can we include your logo on our site?" |
| Quote | Credibility in sales process | Draft it, send for approval |
| Reference call | For serious prospects | "Would you take a 15-min call with a prospect?" |
| Case study | Content + sales asset | Interview them, write it up, get approval |
Pro tips:
- Ask early, ask often. The worst they say is "not yet."
- One good case study > 10 weak quotes
- Video testimonials are powerful — even iPhone quality works
What NOT to do:
- Don't wait until you have a formal program — that's for later
- Don't over-ask the same 2-3 references — spread it out
- Don't publish without explicit approval
Support
Stage-appropriate approach: Founder handles support, or is CC'd on everything. Support is product feedback in disguise.
How to handle support at Build:
- Email or Slack — Pick one channel. Don't overcomplicate. Shared inbox or a dedicated Slack channel with customers.
- Fast response — At Build stage, fast support is a competitive advantage. Reply within hours, not days.
- Founder visibility — Even if someone else handles day-to-day, founder should see every ticket. Every question is signal.
What support reveals:
- Onboarding gaps — If customers ask the same setup questions, your onboarding is broken
- UX issues — If they can't find features, the product is confusing
- Feature gaps — If they ask "can it do X?" often, that's roadmap input
Recommended tools:
| Tool | When to Use | Pricing |
|---|---|---|
| Email (shared inbox) | Simplest option | Free |
| Slack Connect | If customers prefer Slack | Free |
| Intercom | Want chat + basic ticketing | Essential $29/seat/mo; Early Stage program: $65/mo total (93% off first year) |
What NOT to do:
- Don't build elaborate ticketing systems — overkill at this stage
- Don't hire support staff — founder needs to feel the pain first
- Don't ignore support volume as a metric — it's a leading indicator of product health
Expansion & Upsell
Stage-appropriate approach: Opportunistic. Notice when customers are ready for more, but don't build formal expansion programs yet.
Expansion signals to watch:
- Usage hitting limits (seats, volume, features)
- Customers asking about additional use cases
- New teams/departments at existing customers wanting access
- Positive NPS + strong usage = expansion candidate
How to approach expansion at Build:
- Listen for signals — Don't hunt for expansion. Notice when it comes up organically.
- Make it easy — If a customer wants to add seats or upgrade, don't make them jump through hoops.
- Learn the pattern — What drives expansion? Document it for later systematization.
What NOT to do:
- Don't build expansion playbooks yet — not enough data
- Don't pressure customers to expand — erodes trust
- Don't set expansion quotas — still finding product-market fit