## TL;DR
Onboarding to a technical product takes four weeks: product fundamentals, then the common ticket types, then supervised tickets, then independence with a safety net. Each week ends with a demo or sign-off, never with "read the docs and good luck." Agents who ramp this way answer from understanding instead of script-hunting.

## The query

```text
how to onboard a support agent to a technical product
```

## Use this when

- A new agent is joining a dev tool, API, or technical SaaS product
- Onboarding is currently "read the wiki and shadow someone"
- Ramp time to solo tickets is longer than two months
- Agents can quote docs but cant explain concepts

## Not for

- Onboarding to non-technical consumer products
- Engineering or sales onboarding
- Support process and tooling training (ticketing systems, QA)
- Contractor crash-courses under two weeks

## Steps

### 1. Week one: use the product like a customer

They build something real with the product. For an API, that means authenticating, making calls, and hitting a real error. No tickets, no docs deep-dives yet.

Expected output: the agent has a working thing and one genuine "aha, thats how it fits together."

### 2. Week two: study the top ten ticket types

Pull the ten most common ticket categories from the last quarter. For each one, the agent reproduces the problem in a sandbox and writes the fix in their own words.

Expected output: a personal cheat sheet covering most of what the queue throws at them.

### 3. Week three: answer supervised tickets

They take real tickets with a mentor reviewing every reply before it sends. The mentor asks "why did you choose that answer" twice a day.

Expected output: twenty to thirty reviewed tickets and the mentor's sign-off.

### 4. Week four: go solo with a safety net

They work the queue alone but flag anything unfamiliar instead of guessing, and a senior reviews a sample daily. The net comes off when the flags get rare.

Expected output: independent tickets with quality scores matching the team average.

### 5. End every week with a demo

Friday demo: show what you built, explain one ticket type to the team, answer questions. Teaching is the proof of understanding.

Expected output: four demos, each one harder than the last.

## Ready-to-use week plan

```text
Week 1: BUILD. Make a real thing with the product. Break it once on purpose.
Week 2: STUDY. Top 10 ticket types. Reproduce each in the sandbox.
Week 3: SHADOW-FLIP. Take real tickets, mentor approves every send.
Week 4: SOLO+NET. Work alone, flag the unknown, daily sample review.

Gate rule: nobody moves to the next week without the Friday demo.
```

## Variant phrasings

### training new support hires on a technical product

Same four weeks. The Friday demo gate is what makes it training instead of orientation.

### support agent ramp plan for saas

Compress to three weeks for simpler products by merging weeks two and three. Never skip week one.

### how long should it take to onboard a support agent

Four weeks to solo on a technical product. Faster than that usually means the agent is pattern-matching replies, not understanding the product.

## Why it happens

Sink-or-swim onboarding produces agents who search the knowledge base for keywords and paste whatever ranks first. Building with the product first builds a mental model, and a mental model is what lets an agent reason about the ticket they have never seen before.

## Edge cases

- Experienced hires from a competitor: let them test out of week one with the Friday demo early, not by skipping it.
- Fully remote onboarding: pair the agent with a buddy in an overlapping timezone for week three, async review is too slow there.
- Products with no safe sandbox: use a demo account with fake data and a strict "never touch prod" rule in week one.
- Agents hired for language skills over technical: add a pre-week on fundamentals before week one starts.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_K4TN87H6FAAs9dUiHFNa9g