An onboarding management system for a real-estate investment CRM.

Onboarding a new client onto a US real-estate investment CRM ran through a 46-task spreadsheet split between the CRM's onboarding manager and the client company. Tasks blocked on each other. Nobody could see who was waiting on whom. New team members had to be walked through the spreadsheet convention. Things fell through the cracks weekly.

Every new company being onboarded got a fresh copy of the same spreadsheet. Forty-six discrete tasks. Eleven owned by the CRM's onboarding manager. Thirty-five owned by the client company. Cross-role dependencies threaded through the whole thing. Some manager tasks could not start until the client company completed a specific sub-form. Some client tasks could not start until the manager sent an invite. Some phases could not begin until billing configuration finished.

The failure mode was quiet and constant. Client tasks marked done that were not actually done. Manager tasks blocked that had already been unblocked. Emails asking "did you get to the setup form?" bouncing back and forth for a week because nobody could see the current state. New CRM team members took two weeks to learn the spreadsheet convention, and half of them left "temporary" notes in the cells that stayed forever.

The client company got the worst of it. No self-serve portal. No progress bar. They responded to emails and hoped they were doing the steps in the right order. When a step blocked, they did not know it, and neither did anyone until someone thought to check.

Three roles, three surfaces, one shared state. Super admin sees every company being onboarded, overall stats, and reassigns companies between managers. Onboarding manager sees only their assigned companies and owns the eleven admin-side tasks per company. Onboarded company sees their own thirty-five tasks in a clear order with a progress bar, and nothing else.

Task states are locked, ready, in-progress, and complete. Locked tasks show up but are visibly disabled with a specific "waiting on X" reason. Ready tasks are unlocked and actionable. In-progress tasks have been started by their owner. Complete tasks cannot be reverted except by the super admin, and every revert is itself logged.

The blocking logic runs in real time. When the client company signs the service agreement, the manager's "Receive signed contract" task auto-transitions from locked to complete. When the client fills the setup expectation form, "Setup expectation review" auto-completes on the manager side. No one has to notify anyone. The state machine handles it.

The dashboard surfaces every company at a glance: assigned manager, start date, percent complete on the client side, percent complete on the manager side, blocked tasks and their blockers, days elapsed, estimated days to complete. When the last task on either side flips to complete, the onboarding finalizes and a survey form auto-fires to the client's contact. Responses record against that company's onboarding record and feed a rolling improvement signal for the team.

The portal is live and in daily use by the CRM's team. New client companies get onboarded through it, not through a spreadsheet. The onboarding manager's job shifted from spreadsheet-keeper to actual coordinator. New CRM team members can be added and be productive on day one because the process is legible in the interface without institutional knowledge.

The old spreadsheet still exists somewhere as an archive. Nobody opens it anymore.

State-machine correctness is where the reliability posture shows. Every state transition is explicit, unit-tested, and audit-logged. When "Setup expectation" on the client side flips to complete, the log records who did it, when, and which dependent tasks were unlocked as a result. Multi-tenant isolation keeps each company's uploaded documents, signed contracts, and form responses scoped to a tenant boundary. Cross-tenant leakage in an onboarding system means one client sees another client's contract, which is a shutdown-tier incident.

Notification reliability is queued and retried. The initial user invite, the survey trigger, and mid-flow reminders all go through a queued email service with delivery receipts. If a delivery fails, the responsible manager sees a red status pill on the corresponding task, not a silent lost email. The one-time migration from the old spreadsheet mapped every mid-flight row into the corresponding task state so nothing already done had to be redone.

Every task has an owner, a state, and a reason. That is the whole difference between a spreadsheet and a system.

Anas