Onboarding Playbook

Onboarding Playbook defines a reusable process for bringing a new joiner into a business. Its recommended setup is a checklist with an owner and a due offset from the joining date. The same plan can therefore be reused rather than recreated as a separate document for each person. The workflow runs from offer acceptance through pre-boarding, day one and week one, then continues through the 30, 60 and 90 day checkpoints.

The default result is a short recommendation. A request to build, create or convert a process leads to artifact generation once essential facts are resolved. A review request is answered from the material supplied, while an advice question receives a direct answer and an offer to build only when that would help.

Use it to define an onboarding checklist, a steps tracker or a new-hire plan when setup questions recur and answers differ. It fits the Growth stage and the Onboard layer. Intake covers journey length, whether plans differ by role or person, day-one and week-one tasks, later checkpoints, step ownership, sign-off and what the current checklist misses. It also distinguishes requests for a checklist, a schedule and reporting.

Payroll calculation, tax filing and legal advice are outside its purpose. It generates empty templates and does not process real employee or customer records. It also does not chase tasks, notify owners, calculate leave balances or compute KPIs; automation belongs to a separate integration layer.

Questions are asked individually, skipping information already given in earlier messages. Unknown answers remain unknown, and questioning stops when another answer would not change the result. Confirmed facts, unresolved questions, intent and requested formats stay in internal context unless the user asks to see it.

The field model includes Onboarding Step, Phase, Order, Department, Owner, Linked SOP, Required, Notes and Step ID. Order is numeric, Required is boolean, Notes is long text and Linked SOP is a relation. Display names stay identical in CSV and JSON, while SQL uses documented normalized identifiers. An empty SQL table can use this supplied definition:

CREATE TABLE onboarding_playbook (
  onboarding_step VARCHAR(255),
  phase VARCHAR(255),
  sort_order NUMERIC NOT NULL,
  department VARCHAR(255),
  owner VARCHAR(255),
  linked_sop VARCHAR(255),  -- relation -> target record
  required BOOLEAN NOT NULL,
  notes TEXT,
  step_id SERIAL PRIMARY KEY,
  created_at TIMESTAMP DEFAULT NOW(),
  updated_at TIMESTAMP DEFAULT NOW()
);

CSV, SQL DDL, JSON Schema, Notion mappings and requested Excel workbooks derive from that field model. Machine-readable data stays separate from explanation. Excel-compatible CSV uses UTF-8 with a byte order mark, and columns requiring numeric or other formatting are identified separately. A CSV is not an .xlsx workbook. Example rows require an explicit request and must be synthetic.

Notion output is delegated to notion-manual-import for CSV rendering, property mapping, import instructions and verification. Manual files require no connection; workspace edits require verified tool access, an identified target and authorization. Relation properties need their linked databases imported first. people-directory supplies the employee master record, while notification-reminder-hub can turn due dates into reminders through the separate integration layer. Qualified review remains necessary before legal or HR decisions are acted on.