Distinguishing Support, Customer Success, and Customer Onboarding

This article is a work in progress. I was sharing this with several people so I figured I might as well make it public.

Customer Support, Customer Success, Customer Onboarding, and Customer Experience are often conflated terms. For one company, it’s the same thing. In another company, it’s different. I may use “Customer Success,” and you may use “Customer Experience.” Our industry will continue to refine the language we use to describe each role, and to help, here are a few ways of thinking about it. 

Note: I’m excluding Customer Experience for two reasons: 1) brevity and 2) because it can be quite complex. Is it Product-focused? Does it oversee Support and Customer Success? Other?

No matter what, here are guiding principles that all customer-facing teams should find agreement. Just like any other principle, one held onto too tightly and not held in tension by something else can go too far. A maniacal focus on the customer experience sounds good, but pursued to its logical end is not a good plan.

Guiding Principles

  1. Best for the customer, not for us.
  2. Leverage your expertise, not weakness.
  3. Everyone is busy. Don’t adopt a victim mentality.
  4. Teamwork.

Examples of Guiding Principles

  1. Best for the customer: if you’re on the phone/email with the customer and know the answer, help them.
  2. Leverage your expertise: each of us develops specializations, we should play to our strengths. If my weakness is sales, I should support others in selling. If my strength is technical, then I should utilize that and help others.
  3. Everyone is busy: helping customers is our job, and yet many things can get in the way. It’s common in fast-paced environments to adopt a victim mentality. At the same time, voice your concerns—don’t bottle them up!
  4. Teamwork: let’s honor our teammates, help them out, and make sure we ask for help.

Departmental keywords

These are examples of descriptive (not prescriptive) terms for each team. There will — and should be! — overlap.

TransactionalTimeline: first X daysNo endpoint
Product expertiseImplementation expertiseRenewal expertise
Break/fixEngage usersBest practices
Cases (problem & incident management)Develop habitsProjects

Team Objectives


  • Reactive. Respond to customers (live chat, email, phone).
  • Product experts.
  • Problem/Incident management (manage bugs and coordinate with engineering).


  • Proactive/reactive. Reach out and respond to customer needs (email and phone).
  • Present high-level business case of the product to new customers. 
  • Generate revenue. Through hitting customer success milestones, generate referrals and upsells.
  • Share resources, best practices, tips with customers.
  • Not product experts. 

Customer Success

  • Long term care team for customers exceeding $X ARR.
  • Proactive. Reach out before the customer is thinking of it.
  • Renewal manager. They are the primary owners of renewals (this is sometimes its own team).
  • Upsells. After the customer has surpassed onboarding, the CS team will take over.

Note: sometimes it makes more sense and is more efficient to combine Onboarding and Customer Success. As they say, mileage may vary.

Product Knowledge Goals

While each industry, company, and manager may see it differently, here’s a framework to think about the level of knowledge for a CSM (note: I fully expect plenty of disagreement on the percentages applied to each category, that there should be more/fewer categories, and the definitions.

Let’s assume this is about Acme, Inc., which sells an AI tool to help inbound Support reps understand if a customer is likely to be agreeable, scream/cuss at them, cancel their account, etc.

Customer Success Product Knowledge Goals

  • Know 100% of the internal processes
    • Examples: how to sell, upsell, cancel, downgrade, pass customers to appropriate sales reps
  • Know 100% of product functionality
    • Examples: How the product functions, navigation, best practices, selling points
    • Metric: should know almost everything in the Help Center, but NOT necessarily [internal wiki] or institutional knowledge
  • Know 20% of product methodology
    • Examples: fundamental methodology, assumptions, calculations
    • Does NOT include: in-depth knowledge on the algorithms at play
  • Know 40% of industry knowledge
    • Examples: understand broad terminology
      • The typical tooling of a Support rep, their average day, and the structure and handoffs between teams
    • Does NOT include: nitty-gritty detail about the Support industry (helpful, but not required for  — can be learned on the job)
      • Specific tooling in, say, Zendesk, or how the phone system connects to XYZ

The lines between these teams are blurred and will continue to be so. For instance, when a customer has a need, who helps them? Below are general guidelines. If a customer needs help, we should help them.

Published by Jeff Beaumont

I love helping companies scale and grow their organizations to delight customers and employees, enabling healthy teams, fast growth, and fewer headaches. Scaling quickly is wrought with potholes and plot twists. When you’re running a company, losing customers, and employees are on their way out, and don’t have your systems running smoothly, then you’ll be at your wits' end. I've been there and hate it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: