How ShiftWiz's Scheduling Engine Actually Works

Most scheduling software fills shifts the way a first-year employee fills out a form: one field at a time, top to bottom, stopping when it runs out of space. The result is technically complete but often unfair, unbalanced, or just wrong.

ShiftWiz uses a different approach. Here is what actually happens when you click "Generate Schedule."

Phase 1: Gather constraints

Before assigning anyone to anything, the engine collects every relevant piece of information from your account:

• Which employees are available on which days and times
• Approved and pending time-off requests (both are blocked)
• Minimum and maximum weekly hours per employee
• Opener and closer certifications
• Scheduling priority and skill ratings
• Employee pairings (buddy pairs who should work together, conflict pairs who should not)
• Cross-week hour history for fairness tracking
• Labor budget limits for the week
• Historical sales data for demand forecasting
• Day notes written in plain English, parsed to detect events like "brunch rush" or "catering pickup"
• Rest period requirements (at least 8 hours between shifts)
• Minor employee restrictions (federal and state hour caps for employees under 18)

All of that is loaded before the engine touches a single shift.

Phase 2: Most-constrained-first ordering

The engine does not start with Monday morning and work forward through the week. It starts with whatever is hardest to fill.

A Saturday closing shift that requires a closer-certified employee, when two of your three closers have time off, is extremely hard to fill. A Wednesday mid-shift with five eligible employees is easy. If the engine solves the easy shifts first, it risks painting itself into a corner on the hard ones.

Every shift gets a constraint score based on how many eligible employees exist for it, what certifications are required, and what time-off blocks are in effect. The hardest shifts get solved first. This prevents most of the "I filled everything except Saturday night" failures you see with simpler approaches.

Phase 3: Forward-checking backtracking

Once the engine starts assigning shifts, it does not take the first available employee and move on. It checks ahead.

If assigning someone to Thursday mid would leave them ineligible for a required Friday opener (because of their max hours or rest period requirement), the engine detects that conflict before making the assignment and tries a different path. This forward-checking prevents dead ends before they happen.

When a dead end is unavoidable, the engine backtracks to the last decision point and tries a different combination. It will find a valid schedule if one exists in the constraints you have set.

Phase 4: Simulated annealing

A valid schedule and a good schedule are very different things. Simulated annealing is a technique borrowed from materials science for improving a solution past its first valid state.

The engine takes a working schedule and starts swapping pairs of shift assignments. If a swap improves the quality score, it keeps the change. If a swap makes things slightly worse, it might accept the change anyway, based on a temperature parameter that decreases over time. This willingness to temporarily accept worse solutions is what lets the engine escape local minimums and find genuinely better ones.

Thousands of swaps happen per run. The result is a schedule that has been optimized, not just generated.

Phase 5: Multi-seed selection

The engine does not run once. It runs several times with different starting conditions (called seeds) and keeps the best result.

Because the search process involves randomness, different seeds explore different parts of the solution space. Running multiple seeds dramatically increases the chance of finding a high-quality schedule. The one you see is the winner from several independent attempts.

Phase 6: Scoring

Every generated schedule gets a score from 0 to 100 across 8 dimensions:

1. Coverage — Are all shifts filled?
2. Fairness — Are hours distributed equitably across the team?
3. Compliance — Are labor law constraints met?
4. Skill match — Are skilled employees on the right shifts?
5. Seniority — Are priority rankings respected?
6. Preference — Does the schedule respect shift preferences inferred from swap history?
7. Cost — Is the schedule within your labor budget?
8. Balance — Are weekend shifts distributed fairly over time?

The final score is a weighted average across these dimensions. You see it displayed on the schedule detail screen before you publish anything.

What happens after generation

The engine returns a draft schedule, not a final one. You review it before publishing. The interface shows you the score, any coverage gaps, any constraint violations it could not fully resolve, and a breakdown of hours per employee.

You can drag shifts around to make manual adjustments, regenerate a single day, or regenerate the whole week. Once you are satisfied, you publish. Employees see their shifts in the app.

Why this approach matters

The engine does what a careful, experienced scheduler would do if they had hours to think through every combination. The difference is it does it in about 30 seconds.

The schedule it produces will have considered fairness across your whole team, not just this week. It will have blocked time-off requests you might have missed. It will not have scheduled a closer to open the next morning. It will have put your best people on your busiest shifts.

You still review it. You still adjust where your judgment is better than the data. But you start from a schedule that is already good rather than one you built entirely from scratch.