The problem
The spreadsheet works fine for a month. Then someone opens the shared file on their phone, fixes Tuesday, saves, and wipes out the change a supervisor made to Thursday an hour earlier. Nobody sees it until Thursday morning, when the person who was supposed to be off at noon shows up for a full shift.
The bigger problem is that the file stores the schedule but not the rules behind it. Minimum headcount per shift, who is trained on the packing line, who cannot open after a close, which site a shift belongs to: that knowledge lives in a manager's head or in cell colors that mean nothing to anyone else. Every edit is a judgment call made from memory.
Swaps happen in text messages. An employee asks a coworker to cover Saturday, the coworker says yes, the manager approves in a group chat, and the spreadsheet gets updated by whoever remembers. Days later payroll reconciles hours against a file that six people have edited, and nobody can say which version was live on Saturday.
Ask who is on the floor right now and you get a filter, a scroll and a guess. If the file lives on one laptop, you cannot even do that at 7am on a Sunday. The cost is small every day and large every few weeks, which is why teams put up with it for years.
What a good solution looks like
Two screens. The manager screen is a week grid: rows for people or roles, columns for days, blocks for shifts. The staff screen answers one question: when do I work next, and has anything changed. Same data, two very different layouts, and the staff view has to load fast on a phone.
Model shifts as templates plus instances. A template has a name, a start and end time, a location, the role or skill it needs, and a headcount. An instance is that template on a real date, with people assigned to it. Editing a template changes future schedules and leaves history alone. This one decision saves you from a rewrite.
Publishing is a real action, not a save. Drafts stay editable and invisible. Publishing takes a snapshot, notifies assigned staff, and marks later edits as changes with who made them and when. Staff can acknowledge the schedule, so a dispute about a no show has a record instead of a memory.
Requests become records. A swap request, a drop request and a claim on an open shift each have a state and an approver. Coverage checks run before publish: a shift under headcount, a person booked twice, a close followed by an open with too little rest. The app should refuse to publish a week with a hard violation and warn loudly on a soft one.
How to build it
Start with the tables. People, roles and skills, locations, shift templates, shifts by date, assignments, requests, and an audit table. Almost every query is a time range plus a location. Get the date and time columns right and the rest is forms.
Build in a fixed order: import from the spreadsheet, show a read-only week view, add assignment editing, add publishing, add requests last. Ship the read view in the first days. When people see their own shifts appear correctly, they start trusting the app and stop maintaining the spreadsheet in parallel.
Sign in through your identity provider and keep three roles: staff, supervisor, manager. Staff see only their own shifts unless you decide team-wide visibility is useful. Supervisors edit the schedule for their location. Managers edit templates, headcount rules and anything that changes money. Enforce scope on the server for every query, not by hiding buttons in the interface.
Handle time deliberately. Store the shift start and end as timestamps with the location's timezone, and store the local date of the shift separately so a 10pm to 6am shift sorts into the night it started. When daylight saving changes, compute the duration from the actual timestamps instead of assuming eight hours. Test that weekend in both directions before you go live.
Risks and how to manage them
Double booking is the failure everyone notices. Check for overlap when an assignment is written, and put a database constraint behind the check so two requests landing at the same moment cannot both win. Same for headcount: count assignments inside the transaction, not in the page that renders the grid.
Overnight shifts and timezones cause quiet errors. A shift that ends the next day needs an end timestamp on the following date, or reports will show negative hours. If you run locations in more than one timezone, show times in the location's zone and label it, and never trust the browser clock for server logic.
Adoption fails when the app is slower than the spreadsheet. The staff view has to open in one tap from a phone home screen, and the manager grid has to support keyboard entry for a whole week without reaching for the mouse. Export to CSV from day one so payroll and finance can pull hours without asking you.
Migration has a sharp edge. Pick a cutover date, freeze the spreadsheet as read only, and import from that snapshot. Keep edits made after a payroll cutoff visible on a report, so payroll sees late changes instead of finding them in a dispute. Decide early whether the app or your payroll system is the source of truth for hours, and write that down where both teams can find it.
How to measure success
Track how long it takes to publish a week, and how many edits happen after publish. Both should fall. Post-publish edits are the honest measure of how well your rules and checks match reality.
Track coverage: shifts that started under headcount, open shifts filled before start, and swaps that were completed in the app rather than in a chat. If swaps still finish in text messages, the request flow is too slow or too hidden to use.
Track payroll corrections per cycle and how often someone disputes being scheduled. Acknowledgements give you a record, and a falling correction count means the schedule and the hours worked have stopped drifting apart.
A small internal app is one route. You can also buy a scheduling product, or keep the spreadsheet with stricter rules about who edits it. If you want the middle option built for you, the Cloudverg Internal tool sprint is a fixed price of $16,500 over four weeks, with sign in, roles, change history, import and exports. Weigh that against the cost of your own engineering time before you choose.
Frequently asked questions
How do I stop employees from editing each other's shifts in a scheduling app?
Give staff a request flow instead of edit rights. They can ask for a swap, offer a shift or claim an open one, and a supervisor approves it. The schedule itself stays read only for anyone who is not a supervisor or manager.
Should shift scheduling store times in UTC or local time?
Store timestamps with the location's timezone and keep the shift's local date in a separate column. Show everything in the location's zone. Compute durations from the stored timestamps so daylight saving changes do not turn an eight hour shift into a seven hour one.
How long does it take to replace a shift scheduling spreadsheet?
A narrow first version with import, a week view, editing and publish can be working in a few weeks for a single location. Requests, swap approvals and coverage rules add time. What drives the scope is how many rules you need to enforce, not how many people you schedule.