I have switched scheduling software three times across two operating groups. Once because the POS integration broke every payroll cycle. Once because the forecast engine could not handle a catering-heavy unit. Once because the vendor got acquired and support fell off a cliff inside 90 days.
Every switch cost more than the sales rep said it would. Every one of them was worth doing. And every time I got smarter about how to pick the next one.
Here is the framework I use now, in the order I would use it if I were making the call this quarter for a group of five to fifty units.
Start from the labor problem, not the feature list
Before you take a single demo, write down the one labor number you want to move in the next twelve months. Not three numbers. One.
Cut variance to forecast by two points. Cut overtime by 30 percent. Cut general manager scheduling time from six hours a week to two. Move federal and state compliance from a manual audit to a rules engine. Pick one.
The one-number discipline decides everything downstream. It tells you which features are relevant and which are theater. It tells you which vendor's demo you are auditing for and which you are being sold to. It tells you what to measure in the pilot.
Operators who skip this step end up buying the tool with the best sales team. Operators who name the number end up buying the tool that moves the number.
The five features that actually matter
After the number, everything is scoring against a scorecard. Not against a feature grid. A scorecard, weighted, with a rubric.
Fig. 1 · Weighted scorecard for scheduling software evaluation.
POS integration depth
This is the one that decides whether the forecast ever learns. Not just sales pulling into the system, but sales by daypart, by menu category, by weather condition, by comp status. Toast, Square, and Micros all expose different depths of data. Ask the vendor to show you what fields actually pull, and how often, and from which POS builds. Live demos, not sales decks.
Cheap tools pull nightly totals and nothing else. Real tools pull ticket-level data and rebuild the forecast every night. The difference shows up on the labor line inside 60 days.
Forecast quality
This is the feature vendors most exaggerate and operators most fail to test. Do not accept the vendor's own forecast accuracy claims. Ask for six months of anonymized customer data at your ticket volume and menu type. Compare their forecast to your general manager's manual forecast on the same weeks. If their system does not beat a competent human, you do not need it.
Also test how the forecast handles the events humans forget. A holiday landing on a Tuesday. A local event you did not tag. Weather that pushes lunch inside. The best forecasting engines learn from these; the worst ones swing wildly around them.
Mobile shift-swap flow
Most labor drift happens after the schedule is published. Someone calls out. Someone picks up. Someone swaps. If that flow lives in a group text or on a printed schedule, half of it goes wrong and the general manager fixes it manually in the morning.
Test the swap flow with your worst-behaving crew member. Have them try to give away a shift on a Sunday night. If the tool makes it easy enough that they use it, you will save your manager hours a week. If it requires three taps and a manager approval that lives in email, they will just text.
State compliance rules
If you operate across states, this feature moves from useful to essential. California predictive scheduling, meal break penalties, overtime by day versus week, split shift premiums. New York fast-food specific rules. Oregon predictive scheduling. Illinois's One Day Rest In Seven Act. Every state has its own regime.
The tool should have these rules built in, not documented in a knowledge base. When a manager tries to schedule a shift that would violate California meal break rules, the tool should stop them, not warn them. That distinction is worth thousands of dollars in penalties per year per unit.
Multi-location visibility
This is where 7shifts, HotSchedules, and Deputy pull ahead of the smaller tools. A regional director should be able to open one view and see labor percent, overtime hours, and open shift counts across every unit in the market. Without that, you are running scheduling software one store at a time, which defeats the entire purpose of being multi-unit.
The three features to ignore
AI badges without proof
Every scheduling vendor sells AI now. Most of it is a linear regression with a marketing team. Ask for the model card, the training data, and the measured lift versus a naive baseline. If the vendor cannot show you those three things, the AI badge is decoration.
Employee engagement scores
Some tools bundle a chat feature and score how often employees message each other, then call it engagement. It is not engagement. It is chat volume. Cut this from the scorecard.
Gamified shift picking
Points, badges, and leaderboards for picking up shifts sound good in demos and produce almost no measurable impact after week three. Your best employees do not need to be gamified. Your worst ones will not be. Skip it.
Pilot in your worst-case store
Every operator I have watched pick scheduling software runs the pilot in their cleanest unit. The unit with the best manager. The most stable crew. The clearest labor pattern. The tool works great. They roll it out to the group. Six months later half the stores are back to spreadsheets because the tool could not handle the messy ones.
Reverse it. Pilot in the unit with the highest turnover, the most complex daypart mix, and the least consistent labor pattern. That is the acid test. If the tool works there, it will work in every other store. If it does not, you learned something in twelve weeks that would have cost you a year of pain.
The clean store proves your operator. The messy store proves your software.
The switching cost operators never count
Here is the invoice the vendor will not show you.
- Data migration. Employee records, availability, PTO balances, historical schedules for at least twelve weeks so the forecast has something to learn from. Two weeks of work by someone senior.
- Manager retraining. Schedule building is muscle memory. Every manager needs 20 to 30 hours of practice to hit the same speed on the new tool. A full month before the schedule is not the bottleneck again.
- Employee onboarding. Downloads, logins, availability setup, PTO requests. Sixty to ninety days before adoption crosses 90 percent.
- Parallel operation. Run the old tool alongside the new one for two payroll cycles. If you do not, you will miss something on payroll and you will hear about it.
- Integration debug. The POS integration will break. The payroll export will misalign. Budget two people-weeks of engineering or freelance time to fix these in the first quarter.
Add those up and you are looking at three months of soft cost that never shows on the invoice. Plan for it. Budget for it. And do not switch during your busy season.
Contract terms and the case against multi-year
Every vendor will offer you a 36-month contract with a 10 to 15 percent discount over the 12-month rate. Almost every time, taking the shorter contract is the better decision.
Reasons to keep the term short in multi-unit ops:
- Your unit count changes. What works at seven locations is often wrong at fifteen.
- The vendor gets acquired. It happens constantly in workforce management. Support quality can collapse overnight.
- A better tool ships. The category is competitive. Something meaningful comes out every 18 months.
- Your POS changes. If you switch POS, your scheduling stack usually needs to follow.
The 12-month rate buys you the option to reevaluate. That option is worth more than the discount, almost every time.
What I would pick today
If I were making the call this quarter for a group on Toast with 15 to 40 units across three or more states, I would put 7shifts, HotSchedules, and Deputy in a scored evaluation, in that order of my current bias. I would pilot the winner in the messiest store for twelve weeks. I would sign a 12-month contract. I would plan for a three-month rollout.
If I were on Square with five to ten units in one state, I would look at 7shifts and Homebase and pick the one with the better mobile flow for my crew's actual phone habits.
Either way, I would come back to the one-number discipline every 90 days. If the tool is not moving the labor number I named at the start, I would look at whether the tool is wrong, whether my rollout is wrong, or whether the number was wrong. Usually it is the rollout.
Scheduling software does not fix labor. It is a lever. The operator still has to pull it.