Sample deliverable — Role transition & onboarding guide
Pineglass Regional Utilities has five weeks before its Operations Support Coordinator retires after 14 years. The incoming coordinator starts one week in, leaving a planned four-week overlap. The individual procedures already exist in pieces — the sequence, the exceptions, and the judgment mostly live in one person's head. This sample shows what it looks like to pull that out and hand it to someone else.
The complete sample is the portfolio piece — cover, capture notes, and closing approach included. The client-facing guide is what Pineglass would actually receive: the 11-section role guide on its own, branded for their organization.
Experienced employees rarely speak in finished procedures. They speak in fragments — because the missing context is obvious to them. None of these statements is wrong. Each one just leaves a follow-up question a new hire has no way to ask.
The Monday report is easy. Just use last week's and refresh the numbers.
What it really means: the template is reusable, the data is not — every report has to start from a fresh export.
I usually build tomorrow's field list after lunch.
What it really means: late enough to catch same-day changes, early enough for the supervisor to resolve conflicts before handoff.
If an order says pending, check the note. Pending can mean two different things.
What it really means: a pending order isn't actionable until the note names what it's waiting on and who owns it.
Don't change the location record just because a caller says the map is wrong.
What it really means: a caller's description doesn't authorize a technical record change — conflicts get preserved and escalated, never resolved from memory.
None of these fragments is useless. But a new employee would have to reconstruct the role by asking the right follow-up question at the right moment — usually while the work is already happening.
The pages that follow turn those fragments into a system someone else can use.
Eleven sections take the role from "how it works" to "how you'll know they're ready" — organized around performance, not a table of contents nobody will read straight through. A few of the sections that do the most work:
Section 01 · Role at a glance
The role gets defined by what it owns — requests are complete, work is routed correctly, status stays current — rather than an inventory of duties. Each outcome ties to the people who depend on it: customer service, the field supervisor, finance, the operations manager.
Sections 02–04 · The first 30 days
Three phases with named milestones (Day 10 route, Day 15 report, Day 25 recognize + escalate), each with a "ready when" standard stated in terms of demonstrated performance — never a date on the calendar.
Section 06 · Core work map
A trigger-based table — new request, status change, record conflict — that tells the coordinator where to start, what to do next, and exactly when to stop and escalate instead of guessing.
Section 07 · Judgment + exceptions
Most errors don't start with someone ignoring a rule — they start when a situation almost fits the normal path and someone quietly decides what the missing piece probably means. This page gives four categories, from Normal to Unknown, and the exact language to use with a customer, a coworker, and a supervisor when the answer isn't clear yet.
Section 09 · Worked example
A single customer call carrying three overlapping problems — an unowned "pending" status, an unrecorded field visit, and a reported record conflict — shows exactly what the coordinator did, what they deliberately didn't do, and what changed once it reached the right person.
Section 11 · Readiness check
A supervisor scorecard across six performance areas, each with an observable standard — plus an explicit note that landing on "still guided" at Day 30 isn't a failed onboarding — it's a named gap with a next check date.
The point of the capture interview isn't a transcript. It's surfacing the sources — a routing table, an approval map — that were never written down, or stopped being current years ago.
Every checkpoint ties a specific piece of work — route a request, prepare a report, handle an exception — to the resources available and a visible standard for "ready."
The guide doesn't pretend every situation can be proceduralized. It shows where normal work ends, what facts to preserve, and who owns the next decision.
Observation, guided practice, and sign-off are designed together — so the handoff doesn't quietly depend on the retiring employee staying reachable after their last day.
In a smaller operation, a "source" might just be a shared spreadsheet or a practice nobody's written down yet. The same structure still applies — it just gets shorter.
Paired with the sample SOP, the sample decision job aid, and the sample training package, this shows the same discipline applied to a fourth kind of moment: an entire role changing hands.
Pineglass Regional Utilities is a fictional organization created for this sample. The guide demonstrates structure, knowledge capture, and instructional design — not a validated operations framework for any real utility. A production version is built against your actual roles, systems, and people.
