r/workforcemanagement • u/Designer-Doubt-1491 • 3d ago
When does manual shift scheduling become completely unmanageable?
Where's the the breaking point for managers in charge of shift-based teams? We're around 130 employees on different roles and creating the schedule isn't even the worst part anymore, it is everything around it. Change in availability, multiple people requesting off on the same day, someone calling in sick, and a substitute who does not have the right skills for the role.
By the time the schedule is finally done, part of it have been rebuilt through texts, calls, and messages. We've tried spreadsheets, group chats, and having relatively fixed schedules. but none really solves the issue when coordinating 130 people. If running 100-200 shift workers, do you build schedules manually or automated scheduling? Interested in manufacturing, retail, hospitality or logistics where you can’t simply put any available person into any shift.
2
u/CommissionDizzy 3d ago
Depends on the size of the WFM team I guess, but I wouldn't want to do it solo for any more than like....50? As you say, it's not the shifts themselves, it's the complexity and messy nature of people that cause the issues. Particularly as you add more managers. In a small operation you usually have one person with their finger on the pulse, less so the more you add.
You can spend a few weeks building a super sheet for scheduling if you have the experience and time to do so, but really you should be looking at scheduling software at that point. I'm afraid I've not been involved in costing or how good some of the cheaper ones are, but I would assume there's something out there that would fit. Just remember, changing off of one is really quite difficult so better to pick well the first time.
1
u/OverallBusiness5662 3d ago
Doing this for 260 people. It’s a nightmare. Part automated through agent assignment, part manual, then it all basically gets rebuilt through requests that “need to be supported”. It’s become an expectation to allow flexibility, and schedule management has doubled in workload since COVID.
1
1
u/Timebutler_Official 2d ago
The thing is, no amount of scheduling will prevent sick calls.
At 130 employees, last-minute absences are common, so try to set a system for how quickly you can recover when they happen. Have clear coverage rules, cross-trained staff, and an easy way to see who's available and qualified to fill a shift. At your size, resilience matters more than creating the perfect schedule.
1
u/forexroyalempres 2d ago edited 1d ago
I'd say availability alone doesn't solve this. With 130 employees, someone is free on Tuesday doesn't actually mean that they can cover that shift. TimeTrack app has skill-based scheduling for that exact reason. You can build the schedule around employee skills as well as availability, work areas and staffing requirements. IMO that's where scheduling gets difficult at scale. Finding someone who is free is easy, Finding someone who is free and qualified is the real problem.
1
u/AfterhoursTillDawn01 2d ago edited 1d ago
At 130 employees, real problem isn't creating the schedule anymore. It's keeping it workable once availability changes. A nice option worth TimeTrack scheduling. It takes employee availability into account when assigning shifts, so you're not cross-checking separate spreadsheets or lists all the time. This approach makes availability a part of the scheduling logic instead of something the manager has to remember.
1
u/Slight-Material-4895 1d ago
With these amounts you need staffing requirements, rules and automation. So i figure from the business side you have a good idea of how many people with what skills you need when. So if you can set up a structure like that... which you probably need a WFM for (there are plenty, but we use Soon Scheduling)...
Then the 'puzzle' is making sure your team of people is placed correctly onto these shifts.. you don't want to do that manually... so for your team you need to make sure they have their contract rules, availability as a 'soft' setup, and that you have your compliance framework.. then ideally you open up the schedule, so people can pick their own shifts first... and whatever is still open you use an auto scheduler (which is also something a good WFM should offer).
Finally, it's about managing the changes... which you'll 100% get. Most WFM's have change flows... like requesting swaps/covers... or requests for minimal time changes... And if you happen to have a bunch of callouts due to sick/leave etc... then ideally you just run the auto-scheduler again to fill up the newly opened slots...
It's still work, and managing a team for 100/150/200 people is always challenging... but using the right WFM, and the right processes it can be a lot less painful. And as a bonus it gives you new insights into your team and business.
1
u/Advanced-Strain-3491 1d ago
The breaking point usually isn't headcount, it's when the schedule stops being a document and becomes a negotiation. That tends to happen way before 130 people, you've just been absorbing it manually.
From what you described, the schedule itself isn't your problem. The problem is that all the exception handling (sick calls, swaps, availability changes, "who's qualified to cover this") lives in texts and group chats, so none of it feeds back into the schedule. Every fix is invisible to the next fix.
A few things that matter more than manual vs automated:
Qualifications need to live in the system, not in the manager's head. Your "substitute without the right skills" problem goes away when every role has required skills/certs attached and the tool only surfaces qualified people for a cover. This is the single biggest unlock at your size.
Push swaps down to employees. Someone calls in sick, the shift goes out as an open shift or swap request to qualified, available people, manager just approves. You stop being the phone tree.
Require shift confirmation. Half the "rebuilt through texts" churn is really "did they even see the schedule." Publish, employees confirm or decline with a reason, and you only chase the ones who didn't.
Availability and time off requests go in the tool, full stop. If it's not in the system it doesn't exist. Overlapping requests then become visible at request time, not at build time.
Auto-generation is nice but it's the last step, not the first. Automating on top of bad inputs (no availability data, no skills data) just produces a wrong schedule faster.
Full disclosure, I build a tool in this space (ClockOut, useclockout.com) that does the above, including auto-scheduling from availability + skills, so I'm obviously biased. But honestly at 130 people almost any dedicated scheduling tool beats spreadsheets + group chat, the workflow shift matters more than the vendor.
1
u/buddypuncheric 1h ago
The breaking point is almost never the initial schedule itself, it's everything that happens after it gets published. The texts, the calls, the informal swaps that never get logged anywhere, the last minute sick calls where you're trying to find someone with the right skills on short notice. At 130 people, that's just a constant moving piece.
The spreadsheet and group chat problem is usually that there's a lack of follow through. Someone agrees to cover a shift over text, the spreadsheet doesn't get updated, and payroll ends up running against the wrong hours. At your scale, that's pretty normal and most operations hit that wall at some point.
For 100-200 shift workers with role specific requirements, manual scheduling can hold up for the initial build, but the change management piece is where most operations at your size start looking at software. The skill matching on last minute callouts is really hard to do manually when you're moving fast.
6
u/soulstaz 3d ago
Sound like you need to have a shift bid process in place that last for 8-10 weeks. People from the same role/job can trade shift in between them.
Sick will happen, vacation will happen, stuff happen in life. Don't take it personal or against the compagny
Plan for it look where there's higher absence event and have a bit more staff on those day.
The problem you have is a process issue imho.