<aside> 🔒
Recreated for this portfolio. The original rollout plan belongs to my former employer, a home care company, so this version shows the same structure without confidential details.
</aside>
Most rollouts train people on a finished product. This one didn't have that luxury.
We moved scheduling off Skedulo and onto a planner app the company was building in house, while it was still being built. Features changed between training sessions. The caregiver portal, also built in house, switched its data source to the new app at the same time. Four managers and seven coordinators had to change how they worked every day, and every caregiver's schedule depended on the new system being right.
In home care, a scheduling error isn't an inconvenience. It's a client who doesn't get their visit.
So the plan was built on one assumption: things will break. The job is to make sure no client pays for it.
<aside> ✅
Result: we hit the planned cutover date on a product that was still being built, then shut Skedulo off completely. Every user moved to the new system, with no old system left to fall back on.
</aside>
Before cutover, I mapped what could go wrong, how we'd catch it, and exactly what happens when we do.
| What could go wrong | How we catch it | What happens next |
|---|---|---|
| A visit disappears from the planner | Scheduling manager manually reviews the next day's schedule in advance | Restore the visit, confirm with the caregiver directly, log it |
| A visit disappears after the review | Caregiver, client or coordinator reports it | Coordinator calls the client, apologizes plainly, makes up the time at the end of the visit or refunds the missed portion |
| Caregiver portal shows wrong or missing data | Caregiver reports it through the single intake point | Coordinator confirms the schedule by phone; issue logged and routed to the product manager |
| A feature changes after people were trained on it | Release changes come through the product manager | SOP updated and the change communicated before it reaches users |
Both systems ran in parallel during the transition, so there was always a way back to a correct schedule while the new one proved itself.
Nobody should have to guess who to call when something breaks.
| Level | Who | Handles |
|---|---|---|
| 1 | Coordinator | Caregiver and client contact; confirms schedules by phone; client recovery |
| 2 | Scheduling manager | Schedule integrity; daily advance review; fixes inside the planner |
| 3 | Me (single intake point) | Every reported issue logged in one place; patterns spotted; priorities set |
| 4 | Product manager | Carries logged issues and requirements into development |