Playbooks

Process, run like software.

A playbook is a living runbook, not a laminated checklist: launch it against a real record and it assigns the work, branches on decisions, escalates what stalls, and automates the busywork — while you watch every run from one hub.

500 curated SOPs ready to clone Decision steps that prune their own branches Escalations that chase, so you don't
The runs hub: 80 active, 56 overdue, 150 completed, 83% completion rate, 6.4-day average duration, launch throughput chart, and run rows with anticipated progress
Playbooks → Runs Mission control: 80 runs in flight, 83% completion, 6.4-day average — and every run showing progress that counts steps not even deployed yet.

The problem

Your best process lives in a wiki nobody opens.

The library

Start from 500 SOPs, or encode your own.

A gallery of 500 curated templates across 15 categories — onboarding, offboarding, escalations, security, facilities, benefits — each one clone-and-adapt. Or author from scratch: every step gets dynamic assignment (a role, a person, a department, or whoever launched the run) and can require proof — a checklist, a file, or data — before it's allowed to complete.

The template gallery searched for offboarding: curated SOPs with steps, run mode and target type, each with a use-this-template button
Playbooks → Templates Search "offboarding" — ready-made runbooks, each showing its steps and what it runs against.

The living run

Launch it on a record, and the process runs itself.

Launch against a new hire, an account, a property, a case — or fan out across a whole cohort at once. Steps deploy stage by stage; decision steps fork the path and prune the branches that don't apply; every step collects its data and files in place. Stakeholders, owners, and collected information live on the run — so run #151 can answer for itself.

Inside a live run: staged steps with done and in-progress states, a DECIDE task, assignees with due dates, stakeholders, and data collected per step
A run, mid-flight Stage 3 is a decision waiting on its owner; stages 1–2 collected their proof; the overdue task is already red.

Automation

Steps that do things — and chase people.

Completing a step can open a case, assign or reclaim software, send a merge-tagged email, or launch a project — the busywork between steps is the automation's job. And when a step sits too long, time-based escalations kick in: notify the manager, reassign to a backup, or ping a chat channel after X days.

Dynamic assignmentSteps route to roles, people, departments, or the launcher — the right owner every run, without editing the playbook.
Required proofA step can demand a checklist, file, or data before it completes — "done" means demonstrated, not claimed.
Audited timelineEvery run keeps its step-by-step history, stakeholders, and analytics — average duration, completion rate, where things stall.

Playbooks power the rest of the platform. Benefits open enrollment, compliance remediation, handbook rollouts — the other pillars all launch their work through runs.

See the whole platform →

How it runs

From tribal knowledge to a process with a pulse.

  1. Pick or writeClone one of 500 SOPs, or encode the process only one person knows.
  2. PublishSteps, owners, requirements, decisions, escalations — versioned.
  3. LaunchOn one record, or across a whole cohort at once.
  4. It runsSteps deploy and decide; automations fire; stalls escalate.
  5. TrackEvery run on one hub, with anticipated progress and analytics.

The bottom line

The process stops living in someone's head and starts running the work.

Five hundred starting points, decisions that route themselves, escalations that never forget, and a run history that answers for every single execution — inside the platform that already runs your people, benefits, time, and compliance.