Employee onboarding
How to Onboard Customer Support Reps (Without Burning CSAT)
Onboarding a customer support rep has a constraint no other role has: the learning happens in front of customers. A new engineer's mistakes get caught in review; a new rep's mistakes ship as customer experiences. So support onboarding is the art of ramping exposure, from shadowing to reviewed replies to solo queues, at exactly the speed the rep's access to correct answers allows. That last clause is the whole game, and it is why the knowledge base, not the training deck, is the real onboarding infrastructure for support.
The exposure ramp
- Product training before the queue. Structured, hands-on product time first. Reps who learn the product purely from tickets learn it as disconnected fragments and never develop the map.
- Shadow real tickets. Several days reading and watching: the tone, the process, the shape of the common issues, how seniors de-escalate. Shadowing transfers the tacit half of support that no macro captures.
- Reviewed replies. The rep drafts real answers; every one gets reviewed before sending. This is the highest-value stage: speed builds, gaps surface, and customers stay protected. The mistake is rushing it.
- Solo on simple queues. Independence arrives by ticket type, not by date: simple categories first, complex ones stay reviewed until QA scores earn the expansion.
- Full scope by 60 to 90 days, product-complexity depending.
The support 30-60-90
| Phase | Focus | What good looks like |
|---|---|---|
| Days 1 to 30 | Learn and reviewed replies | Product fluent, drafting real answers, QA trending up |
| Days 31 to 60 | Solo on simple queues | CSAT at team baseline on owned categories, escalations falling |
| Days 61 to 90 | Full queue | Independent across types, contributing macros and KB fixes |
The general template is in the 30-60-90 guide; this is its support-shaped version, the same way sales and engineering got theirs.
The knowledge problem decides the ramp speed
Here is the moment that sets a support rep's ramp: a customer asks something the rep has not seen. The rep either finds the correct answer in seconds, pings a senior rep (who is mid-ticket themselves), or improvises. The first path scales; the second taxes your best people on every novel question; the third is how wrong answers reach customers with a confident tone.
Which means the real variable in support onboarding speed is not the rep, it is the findability of correct answers. A team with a current, searchable, trusted knowledge base ramps reps in weeks; a team whose answers live in senior heads and old threads ramps them in quarters, and burns the seniors doing it. The infrastructure case is the same one in internal knowledge base in Slack, with customer-facing stakes attached.
Measure the ramp, fix the gaps
Track time to first solo ticket, QA scores, CSAT versus team baseline, and the escalation trend. Then close the loop: every question the rep could not self-serve is a knowledge gap, and the gaps the whole cohort hits are your documentation roadmap. New reps are the best knowledge-base auditors you have, because they hit every hole in it personally.
How Sakha ramps support reps
Sakha delivers the support onboarding flow on schedule (the training sequence, the stage gates, the check-ins) and, more decisively, answers the in-the-moment questions: a rep mid-ticket can ask Sakha about a policy, a process, or an edge case and get the sourced answer in seconds instead of pinging a senior or guessing at a customer. The questions it cannot answer get flagged as knowledge gaps automatically, so the documentation improves with every cohort. The ramp constraint was always answer access; Sakha removes it, and the exposure ladder gets climbed as fast as it safely can be.
Curious how Sakha runs onboarding inside Slack? See how it works.