Role-specific onboarding
Objective. Sequence onboarding by role - administrator setup, manager routines and employee understanding - into a 30-day plan with owners, exercises and exit criteria, so each role gains what it needs in the order that makes the next role possible.
Onboarding fails when everyone is trained on everything at once. Admins need setup to be correct before managers can trust data; managers need a routine before employees see any benefit; employees need to understand what is captured and why before adoption sticks. This lesson teaches you to sequence onboarding by role with concrete exit criteria, so value appears in the first 30 days rather than month six.
See it in the demo
The customer problem
A customer buys the platform, schedules one big training session for forty people, and a month later usage is near zero. The reason is predictable: the admin had not finished mapping and coverage, so managers opened dashboards full of holes and stopped looking; employees were never told what was captured, so the deployment felt like surveillance rather than support; and no manager had a routine, so even good data changed no decisions. Business impact: the go-live window - the period when a sponsor is watching and attention is high - is wasted, and re-energising a stalled account costs far more than sequencing it right the first time.
How Time Champ addresses it - sequence by role
Sequence in dependency order. (1) Administrator first: agent/data coverage, process and client mappings, standards, productivity classifications and access scope (Employee Monitoring Administration; Work Output standards). Exit criterion: readiness checklist from C02 passes for the pilot team. (2) Managers next: teach them to read their own team - available hours and exceptions in Time and Activity, output and cost in Work Output - and to run one routine (the daily exception review, the weekly output review from C06). Exit criterion: the manager completes one real review and logs one action. (3) Employees last and lightest: what is captured, how it is used, and what is in it for them (fairer workload view, recognition of real output, not just hours). Exit criterion: employees can state what the tool does and does not do. Use the demo apps so each role practises on realistic data before touching their own.
What to say / do - build the 30-day plan
Draft a 30-day plan as a table: role, week, activity, owner, exercise, exit criterion. Days 1-7, admin setup and validation (owner: customer admin + you). Days 8-14, manager enablement on the pilot team only - resist going wide (owner: you, with the operational lead). Days 15-21, managers run routines live while you shadow and coach. Days 22-30, employee understanding sessions and a first mini-review of what the pilot learned. For each manager exercise be concrete: 'Open Time and Activity daily operations, find the one exception worth a conversation, and decide the follow-up' - not 'explore the dashboard'. The owner column matters: if an activity has no named owner it will not happen. The exit criteria are what let you tell the sponsor, honestly, whether onboarding is on track.
Employee understanding and trust
The employee layer is where goodwill is won or lost, so treat it as part of onboarding, not an afterthought. Be straight about what Employee Monitoring captures and the capture policy in force, who can see it, and the boundary - a non-productive application label is an input to a conversation, not proof someone did nothing. Frame the value to the employee honestly: workload is seen, real output is credited rather than just chair-time, and friction that slows them down becomes visible and fixable (Work Understanding). Do not oversell: do not promise employees the data will never inform a performance conversation if that is not true. An honest, specific employee briefing prevents the single most damaging adoption failure - a workforce that quietly resents the tool and games it.
Objections and honest limits
'Can we just train everyone together next week?' - explain the dependency: managers trained on unvalidated data lose trust immediately; keep the sequence. 'The admin is slow, can managers start anyway?' - they can learn to read screens, but do not have them run live routines on incomplete data; mark it as a dependency risk (C10). 'Employees don't need to be told, it's in the contract' - legally perhaps, but adoption depends on trust; a surprised workforce games capture. Honest limits: exact admin capabilities and classification options depend on the production entitlement - confirm with product rather than promising a specific setup screen. You own the plan and the coaching; the customer owns the actual setup and the decision about what to tell employees.
Interpretation check
Onboarding order is a dependency chain, not a preference. A manager trained on data an admin has not validated will distrust the product for good, so admin exit criteria must be met before manager enablement begins.
In the field
For OVO's contact-centre POC, sequencing matters: admins must map Salesforce case/AgentWork effort and telephony correctly before managers read effort-to-outcome, and agents must understand what desktop effort capture means before they trust it - skipping either step would sink the paid POC.
Practical task
Produce a 30-day onboarding plan for KnackGlobal or OVO as a table (role, week, activity, owner, exercise, exit criterion). Include at least one concrete manager exercise with a decision and a logged action, admin exit criteria tied to the C02 checklist, and an employee understanding session that states what is captured and the non-productive-label boundary.
Self-check
Why must administrator setup have an exit criterion before manager enablement starts?
Managers judge the product by the first data they see. If mappings, coverage and standards are not validated, their first impression is 'the numbers are wrong', and that distrust is expensive to reverse. The C02 readiness checklist passing is the gate.
A manager exercise reads 'explore the Work Output dashboard'. Rewrite it so it has an exit criterion.
For example: 'Open Work Output People, find the team whose cost per clean unit moved most this period, decide whether it is a real change or a data/standard issue, and log one follow-up action.' It names a task, a decision and a logged output.
Why is the employee understanding session part of onboarding rather than optional?
Adoption depends on workforce trust. Employees who are surprised by what is captured resent or game the tool, corrupting the very data managers rely on. An honest briefing about capture, access and the non-productive-label boundary protects data quality.
The admin is behind schedule but the sponsor wants managers started. What do you do?
Let managers learn to read screens on the demo, but do not start live routines on incomplete production data. Log the admin delay as a dependency risk and keep the sequence - starting managers on bad data trades a small delay for lasting distrust.
Verified vs demo. The role surfaces and routines are demo-shown. The specific admin setup screens, classification options and what a customer chooses to tell employees depend on production entitlement and the customer's own policy - confirm with product and with the customer's sponsor.