×workforce-scheduling.case
REDACTEDreal work, anonymized — category + problem naming · relative metrics only

Operations · onboarding at scale

Scheduling people without the spreadsheet wars

Onboarding slots, trainer capacity, time zones, and a CRM that doesn't talk to the calendar — coordinated by hand, until it wasn't.

role · Product lead — capacity-aware onboarding schedulerstatus · Working system integrated with CRM and calendars

§01The problem

Every new customer needs onboarding sessions; every onboarding session needs a trainer with a free slot in the right time zone. The coordination lived in exported CSVs, a shared calendar, and one heroic coordinator's memory. Double-bookings, dead slots, and reschedule chains were weekly weather.

The deeper cost was invisible capacity: nobody could answer 'how many onboardings can we absorb next week?' — which meant sales promises and delivery reality met only at the moment of collision.

[ interactive diagram loading… — four sources of truth, zero agreement ]
fig — four sources of truth, zero agreement

§02The thinking

This is a classic systems-integration product wearing an operations costume: the CRM knows who needs onboarding, the calendar knows who's free, and no one artifact knows both. Rebuilding either tool would be madness; the product is the join.

The design question that mattered: what is the unit the coordinator actually reasons about? Not events — capacity. So the system's core view became a capacity ledger by day and trainer, computed from calendars, with bookings drawing it down like a budget.

+ A capacity ledger computed from live calendars

another master spreadsheet

# spreadsheets fork; a computed view can't drift from the calendars it reads.

+ Reschedules as first-class flows with audit trails

treating them as cancellations plus new bookings

# reschedule chains were where trust died — the history had to survive the change.

+ Deep CRM integration, custom modules and all

asking staff to work in a new tool

# adoption lives where people already work. The system succeeded by being invisible.

§03What shipped

The scheduler reads trainer calendars and CRM pipelines, computes daily capacity, proposes conflict-free slots, sends invitations and reminders, and keeps reschedules traceable. The coordinator moved from assembling truth to approving it; capacity questions became a lookup instead of an investigation.

[ interactive demo loading… — the capacity ledger view ]
fig — the capacity ledger view

§04Outcomes

'Can we absorb next week?'

became a glance at a ledger, not a day of CSV archaeology

Double-bookings out

conflict-free proposals replaced manual cross-checking

Reschedules with memory

every chain is auditable; no more 'who moved this and why'

§05Reflection

Unglamorous integrations are where operations products live or die. The AI industry talks about agents; operations teams talk about 'does it put the right thing on the right calendar every single time'. Earning the second sentence is harder.

$ cat takeaways.txt

  • Find the unit the operator actually reasons about — then build the view of that unit.
  • The join between systems is a product in itself.
  • Invisible adoption (inside existing tools) beats impressive adoption (a new tool).