Case file № 001 · Process rebuild · Internal tool
The schedule that lived on a piece of paper
- 0
- logins required of staff
- 2
- ways to work a schedule
- hourly
- standby workbook snapshots
A hospital float pool ran its entire schedule on one physical sheet of paper. I replaced it with a mobile scheduling system staff use from a text-message link — while keeping the spreadsheet the source of truth.
The system
In
Staff phones personal no-login links
Scheduler edits roster & assignments
The system
Apps Script web app Day view · Grid · change flags
Google Sheet source of truth · fallback
Out
Calendar feeds live subscription · one-time download
Printable schedule still works in an outage
Before ✗
- The authoritative schedule was a physical piece of paper. Every other copy was a rumor.
- Changes were made in pen, on the sheet. Whoever held it held the truth.
- Updates went out as photos over text message — out of date the moment someone edited the original.
- Hours of admin work to build each schedule, then hours more answering questions, re-sending photos, and reconciling changes.
After ✓
- Staff submit availability from their phones through personal, no-login links. Typing saves itself; nothing has to be submitted.
- Schedulers work a Day view or a full-horizon Grid, with the roster managed in the same place.
- If someone edits their availability after a shift was booked against it, the shift is flagged for a second look.
- Shifts flow into the calendars people already use via a live subscription feed.
- The Google Sheet remains the database and the emergency fallback — readable, printable, and editable even if the app is down.
The verdict
The paper is gone. The schedule is authoritative everywhere at once, and the admin time that went into building, photographing, and defending it goes somewhere useful instead.
Bill of materials
| Google Apps Script | the application and its API |
|---|---|
| Google Sheets | database a human can read, print, and rescue |
| ICS calendar feeds | shifts in the calendars people already use |
| Node regression suite | service and UI checks before every deploy |
| Pinned clasp tooling | versioned, repeatable deployments |