Assemble a New-Starter Enablement Pack

Tier: Foundation · Workflow area: Knowledge management · ~25 minutes per pack

This playbook generates a three-part enablement pack from exports you already have — a "top 20 tickets in this account" brief, an environment cheat-sheet, and a first-two-weeks guide — then routes it past a senior tech for the correction pass that turns generated text into trusted onboarding.

When to use

• Any new hire or internal transfer joining the desk or an account team — the pack pays for itself within their first week.
• MSP account onboardinga tech picking up an unfamiliar client account needs exactly this brief, and the ticket history for that account already encodes it.
• Rotations and coveragesomeone covering an unfamiliar area for two weeks needs the 20% of context that answers 80% of what they will face.

When NOT to use

• As a substitute for a human buddy. The pack answers the askable questions; the assigned buddy exists for the unaskable ones. Ship both.
• When ticket history is thin or wronga brand-new account or a queue with junk categorization produces a misleading "top 20"; build that section by interview instead.
• Set-and-forget. An enablement pack with no review date becomes onboarding misinformation in about a year; each pack gets an owner and a refresh trigger.

The recipe

1. 1.

   Export twelve months of resolved tickets for the scope. Subject, category, resolution notes (first lines), count-relevant fields. Volume matters more than detail — you want frequency signal.

   Copy

   # From a CSV export: top categories by volume, quick sanity view
   Import-Csv .\tickets-12mo.csv |
     Group-Object category |
     Sort-Object Count -Descending |
     Select-Object -First 20 Name, Count
   

2. 2.

   Generate the "top 20 tickets in this account" brief.

   Copy

   From this 12-month resolved-ticket export, produce a "top 20 issues"
   onboarding brief for a technician new to this queue.
   
   For each of the 20 most frequent distinct issues:
   - Issue name in user vocabulary + rough monthly volume
   - Typical cause (only if the resolution notes support it)
   - Standard fix in 2–4 steps, citing the KB article ID when a note
     references one
   - Gotcha: anything the notes show techs getting wrong repeatedly
   
   Rules: group true duplicates (password reset variants = one issue);
   write "cause varies — see linked articles" rather than inventing a
   single cause; mark low-confidence entries [SENIOR CHECK].
   
   Export: [paste]
   

3. 3.

   Generate the environment cheat-sheet from your systems docs. Feed it the current-state facts only you can supply — tenant names, RMM, ITSM, VPN, key servers, admin portals — and ask for a one-page cheat-sheet: system | what it is | URL | how you get access | who owns it. The model formats and normalizes; the facts come from you, because this is exactly where hallucinated URLs and wrong owner names would otherwise creep in.

4. 4.

   Generate the first-two-weeks guide. Prompt with your team's actual expectations: day-1 access checklist, which queues to watch first, the shadowing plan, "questions we expect you to ask", escalation etiquette, and where the KB, prompt library and handover channel live. Ask for it structured as a checklist the starter ticks off — checklists get used; prose gets skimmed.

5. 5.

   Run the senior-tech correction pass. A senior reviews all three artifacts against reality: every [SENIOR CHECK] resolved, every URL and owner verified, the gotchas confirmed or cut. Sample correction worth its weight:

   Copy

   Top-20 item 7 (VPN cert errors): fix steps correct BUT only for the
   AnyConnect profile — the sales team is on GlobalProtect, different
   procedure, KB0004412. Added split by team.
   

   Twenty minutes of senior time; it converts the pack from plausible to trustworthy.

6. 6.

   Deliver as living documents. Pack goes where the team already reads (wiki/KB section, not email attachments), each artifact carries an owner and a review-by date, and the new starter's standing assignment is to flag everything that turned out wrong or missing — the freshest possible QA.

7. 7.

   Refresh on trigger, not schedule alone. Re-run step 2 when the ticket mix shifts (new rollout, migration), and diff the new top-20 against the old — the diff itself is useful team news.

Make it yours

• MSPtemplate the whole pack per account: same prompts, per-account exports, one senior reviewer from that account team. The pack doubles as your account-knowledge insurance when a tech leaves.
• Enterprise desk with strong KBhave the brief cite KB IDs aggressively (the prompt already asks); the pack becomes a curated index into the existing KB rather than parallel content.
• Small team, no formal onboardingstart with only the top-20 brief; it is the highest-value third and needs nothing but the ticket export you can pull today.

Quality check

• Frequency claims match the export. Spot-check three volume figures against a pivot of the raw data; models miscount, and a wrong "most common issue" misdirects a new hire for months.
• Every URL and owner name verified. These rot fastest and embarrass hardest; the senior pass checks each one live.
• User vocabulary throughout. The starter will hear problems in user words on day one — the brief must use them (harvest per pb-17 if needed).
• The starter's feedback loop is real. Their flagged corrections get applied within the week — an ignored feedback assignment teaches them documentation here is decorative.