Onboarding readiness checklist
Objective. Confirm, before go-live, that the data, access, definitions and people needed for correct numbers are in place - and triage what is missing to the right owner or specialist.
A readiness checklist a CSM runs before an account starts trusting Time Champ numbers. It separates what the customer owns, what the implementation specialist owns and what simply is not ready yet, so the first value conversation rests on validated data rather than a demo-shaped assumption. This is the tool version of C02 - copy it, work it item by item, and hold go-live until the data-trust block passes.
What it is and when to use it
A readiness checklist is the pre-go-live gate that keeps a customer from building decisions on numbers that are not yet trustworthy. Use it during the first one to two weeks of onboarding, before the first manager routine or QBR. It exists because the fastest way to lose a new account is to let them see a figure that is wrong - missing agent coverage, an unconfirmed completion definition, a time-zone mismatch - and conclude the product does not work. The checklist makes missing data visible and routes it, rather than letting it surface as a disputed number later.
The checklist - copy this
ACCOUNT: ____ CSM: ____ GO-LIVE TARGET: ____
A. SCOPE + GOALS
[ ] Contracted applications and seat count confirmed against the handover (KIT-03)
[ ] The business outcome and baseline from the pilot charter carried in
B. DATA + CAPTURE
[ ] Data sources connected and their freshness known
[ ] Agent / capture coverage validated for the in-scope population (no silent gaps)
[ ] Capture policy and employee communication confirmed as done, not assumed
C. DEFINITIONS + CONFIG (confirm with product on specifics)
[ ] Completion / standard definitions agreed and written down
[ ] Productivity or classification rules reviewed with the customer
[ ] Time zones and working-calendar set correctly
D. ACCESS + PEOPLE
[ ] Roles and access scope set (who sees what)
[ ] Administrator identified and trained (KIT-05); managers identified (KIT-06)
E. VALIDATION
[ ] One real number reconciled against a source the customer trusts
[ ] Known gaps logged with an owner: customer / CSM / implementation specialist
GO / NO-GO: ____ OPEN ITEMS + OWNERS: ____
How to fill it
Work top to bottom and treat each box as pass or not-yet, never 'probably'. For data and capture, validate coverage against the actual in-scope population - a silent gap (an un-agented team, a disconnected source) is the most common cause of a wrong number. For definitions and config, describe at the app-logic level and mark specifics 'confirm with product' rather than asserting how a rule is computed. The validation block is the one that earns trust: reconcile one real figure against a source the customer already believes (their roster, their claims count), and only then is a number safe to show. Anything unchecked is logged with an owner - customer action, CSM action, or escalation to the implementation specialist - and a go / no-go is an explicit decision, not a date that just arrives.
The honest caveat
A passed checklist means the inputs are ready, not that every downstream number is correct forever - coverage and definitions drift, so the validation habit continues past go-live (KIT-09). Do not describe configuration internals or integration mechanics you have not confirmed; those are confirm-with-product and, for connection work, the implementation specialist's scope, not the CSM's to improvise. If a block cannot pass by the target date, the honest move is to delay the value conversation for that scope, not to show a number you cannot defend. A checklist with open high-impact items and a green go-live is how an account starts distrusting the product in week three.
Interpretation check
A number is only trustworthy once its inputs are validated - coverage, definitions, time zone and source. Readiness is a gate on the inputs, not a calendar date; an unchecked data-trust item means the number is not yet safe to show, whatever the go-live plan says.
Practical task
Run the full checklist against a seeded or real onboarding account, mark every box pass or not-yet, reconcile one real number against a customer-trusted source, and produce an open-items list with an owner for each (customer / CSM / implementation specialist) and an explicit go / no-go recommendation.
Self-check
Why validate agent / capture coverage against the actual in-scope population?
A silent coverage gap (an un-agented team or a disconnected source) produces a number that looks real but is wrong, and that is the fastest way a new account concludes the product does not work.
What does the validation block require before a number is safe to show?
Reconciling one real figure against a source the customer already trusts (their roster, their claims count), so the first number they see holds up.
An item is unchecked at the target date. What are the options?
Log it with an owner (customer / CSM / implementation specialist) and either delay the value conversation for that scope or escalate - never show an undefendable number to hold the date.
A specific classification rule's formula is unclear. What do you write?
Describe it at app-logic level and mark it confirm-with-product; do not assert internals you have not verified.
Verified vs demo. The checklist structure is reusable; coverage, definitions and the reconciled number are account-specific and must be validated, not assumed from the demo. Configuration and integration specifics are confirm-with-product and, where they involve connection work, the implementation specialist's responsibility.