Administrator workshop
Objective. Run a working session that leaves the customer's administrator able to own access scope, definitions and data health - not just click around the product.
A ready-to-run agenda and exit-criteria sheet for the first administrator enablement session. It makes the admin the owner of the configuration decisions that determine whether numbers stay correct, with a hands-on task for each topic and a clear exit test. This is the tool version of the administrator track in C03 - copy the agenda, run it in a safe account, check the exits.
What it is and when to use it
An administrator workshop is the enablement session that transfers ownership of the account's configuration to the customer's admin. Run it once the readiness checklist (KIT-04) has the data and access blocks substantially in place, and before managers and employees come on. It matters because the admin owns the levers - access scope, definitions, rules, coverage - that keep numbers trustworthy; if they only watched a tour, the first config change breaks a report and nobody on the customer side can fix it. The session is hands-on in a safe account, not a slideshow.
The agenda - copy this
ADMIN(S): ____ ACCOUNT / SANDBOX: ____ DATE: ____
- ORIENTATION (10 min) - the application map and where admin settings live. Teach-back: admin names which app owns which number.
- ACCESS + ROLES (20 min) - organisation structure, role scopes, who sees what. HANDS-ON: set up one team and one manager role; confirm the scope is correct.
- DATA + COVERAGE (20 min) - sources, capture coverage, freshness; how to spot a gap. HANDS-ON: locate the in-scope population and check for a coverage gap.
- DEFINITIONS + RULES (20 min, confirm specifics with product) - completion/standard definitions, classification or productivity rules, time zones and calendar. HANDS-ON: review one rule and state what changing it would do to a number.
- DATA HEALTH ROUTINE (15 min) - what the admin checks weekly and what they escalate. HANDS-ON: run the one-number reconciliation from KIT-04.
- ESCALATION (5 min) - what the admin owns vs what goes to the implementation specialist or support.
EXIT CRITERIA: admin can set a role scope, find a coverage gap, explain one rule's effect, reconcile one number, and name the escalation path.
How to fill and run it
Prep by confirming which modules and settings the account actually has - do not demonstrate a control the customer is not entitled to. Run each block as explain, demonstrate, then let the admin perform the hands-on task - watching is not learning. Use a safe sandbox or a non-production scope so a mistake costs nothing. For the definitions and rules block, be explicit about what you are confident of and what is confirm-with-product; the admin should leave knowing which decisions are theirs and which need the specialist. Close only when every exit criterion is met by the admin doing it, not by you doing it while they nod. Record which exits passed and schedule a follow-up for any that did not.
The honest caveat
This workshop makes an admin competent to own configuration, not a replacement for the implementation specialist on setup, integrations or data-connection work - keep that boundary explicit so the admin does not attempt connection changes they should escalate. Do not teach configuration internals you have not confirmed; where a rule's exact behaviour is uncertain, say confirm-with-product rather than improvise, because an admin who learns a wrong mental model will make a confident wrong change. The exit criteria test capability, not adoption - an admin who can do the tasks still has to actually run the data-health routine, which is why it recurs in the weekly agenda (KIT-09).
Interpretation check
The administrator owns the levers that keep numbers trustworthy. Enablement is complete only when the admin can perform each configuration and data-health task themselves - watching a demonstration is not the same as being able to do it.
Practical task
Run the full administrator workshop against a sandbox or safe account with a real or role-played admin, require the admin to complete every hands-on task themselves, and record which of the five exit criteria passed. Schedule a follow-up for any exit not met rather than marking the session complete.
Self-check
Why is the workshop hands-on in a safe account rather than a product tour?
The admin owns the config levers; if they only watched, the first real change breaks a report and no one on the customer side can fix it. Performing the task is what transfers ownership.
What are the five exit criteria?
The admin can set a role scope, find a coverage gap, explain one rule's effect on a number, reconcile one number against a trusted source, and name the escalation path.
A rule's exact computation is unclear during the session. What do you do?
Describe it at app-logic level and mark it confirm-with-product; do not teach internals you have not verified, because a wrong mental model produces confident wrong changes.
Where is the boundary between the admin and the implementation specialist?
The admin owns ongoing configuration, access and data-health checks; setup, integrations and data-connection work stay with the implementation specialist and are escalated, not improvised.
Verified vs demo. The agenda is reusable; which modules, settings and rules exist are account-entitlement specific - do not demonstrate a control the customer does not have. Rule internals are confirm-with-product, and setup or integration work belongs to the implementation specialist.