Your organization sets the requirements. Your team shares what matters to them. Schedulewright brings it all together to create a better schedule.
| October | Day 7a–7p | Night 7p–7a |
|---|---|---|
| 5 Mon | Chen | Bennett |
| 6 Tue | Chen | Bennett |
| 7 Wed | Chen | Bennett |
| 8 Thu | Chen | Dubois |
| 9 Fri | Chen | Alvarez |
| 10 Sat | Ellis | Alvarez |
| 11 Sun | Ellis | Alvarez |
| 12 Mon | Ellis | Okafor |
A schedule where every shift has a name on it is the easy part. The hard part is that the names belong to people, and each of them wants something slightly different.
Someone wants five or six shifts in a row and then a real break.
Someone else is worn down by long runs and wants shorter ones.
One person genuinely prefers nights and would rather not rotate.
Another has a standing commitment on one weekday, every week.
The person who makes the schedule has to hold all of that in their head, keep every shift covered, and still be able to explain why the result came out the way it did. Usually on a weekend, in a spreadsheet, alone. Not every conflict can be avoided. But most of the guesswork can.
Schedulewright splits the job into three parts. Two of them belong to people. The third is the algorithm's.
Define your shifts and how many people each needs. Configure the rules, decide which are absolute, and set how much the rest count.
Each person has their own page: days off, availability, opt-ins like weekend nights, and standing preferences rated mild, moderate, or strong.
The algorithm evaluates a large number of possible schedules and settles on the one that best balances everything, according to the importance you set.
Every scheduling consideration falls into one of two groups. Knowing which is which is most of what you need to understand.
A schedule that breaks one of these isn't a schedule with a problem. It's rejected outright.
Each carries a weight you set. The more important it is, the more it costs the schedule to go against it.
When two preferences can't both be met, the algorithm compares the cost of each option and takes the cheaper one. Going against a strong preference costs more than going against a mild one; going against a rule with weight 30 costs more than one with weight 4. It keeps searching for the schedule with the smallest total cost that still satisfies every absolute requirement. You see the result and the reasons, and if a trade-off looks wrong, you change a weight and build again.
These are the rules a new schedule starts with, grouped the way they appear in Setup. Weights are the defaults; every one can be changed, turned off, or, where shown, made absolute. Weights are relative, not a currency: what matters is how they compare to each other.
A sample week, and what the algorithm had to weigh to get there. This is the same information the scheduler sees after a build.
| Date | Day 7a–7p | Night 7p–7a |
|---|---|---|
| 5 Mon | Chen | Bennett |
| 6 Tue | Chen | Bennett |
| 7 Wed | Chen | Bennett |
| 8 Thu | Chen | Dubois |
| 9 Fri | Chen | Alvarez |
| 10 Sat | Ellis | Alvarez |
| 11 Sun | Ellis | Alvarez |
Alvarez asked for weekend nights and got Friday through Sunday.Opt-in preferences pull shifts toward the people who want them, so nobody else has to be asked.
Chen works a block of five days, Monday to Friday, inside the target length.Block length is a low-weight rule, so it bends first when something with greater weight needs the room.
Bennett comes off nights on Wednesday and isn't placed on a day shift until well after the minimum rest.Night-to-day sequences are forbidden, so this arrangement was never possible.
Dubois works Thursday night despite asking for the 8th off.Everyone else was already on shift, past their maximum consecutive hours, or on approved leave. Honoring the request would have left the night uncovered, and all shifts covered is an absolute rule. The scheduler sees the conflict and the reason for it, and can override the assignment by hand if a better solution exists.
A trade-off like Dubois's isn't a mistake by the algorithm. It's a decision the schedule had to make, shown with its reason so the scheduler can accept it, adjust a weight, or handle it by hand. Nothing is buried.
From hospital units to restaurants and service teams, every workplace has its own scheduling challenges. Schedulewright adapts to the way your team works.



Name the shifts you use — morning, evening, overnight, on call, whatever they are — then set when each starts and ends and how many people it needs. Set your requirements, let your team share their preferences, and Schedulewright adapts to your operation, not the other way around.
Bring your team's preferences and your organization's priorities together in one scheduling process.
We're onboarding a few teams at a time so each one gets set up properly. Tell us about yours and we'll be in touch. Free while in beta. Prefer email? hello@schedulewright.com
Most scheduling tools assign people to open shifts and check availability. Schedulewright starts earlier: it collects what the organization requires and what each person prefers, gives each a weight, and then searches for the schedule that best balances all of it. The output isn't just a filled roster; it's a filled roster with the reasons attached.
Yes. Each person on the roster gets a sign-in and their own page, where they enter requested days off, availability, opt-ins such as weekend nights, and standing preferences (a weekday or shift type to prefer or avoid, rated mild, moderate, or strong). The scheduler sees all of it before building.
Completely. The scheduler defines the shifts, chooses which rules apply, decides which are absolute, and sets how much weight employee preferences carry relative to organizational priorities. After a build, the scheduler can pin any shift by hand and rebuild around it, and nothing is published until they say so.
The algorithm compares the cost of each option using the weights you set, and takes the lower-cost one. A strong preference outweighs a mild one; a heavily weighted rule outweighs a lightly weighted one. The result shows each trade-off it made and why, so you can accept it, change a weight and rebuild, or fix it by hand. Some conflicts can't be resolved to everyone's satisfaction; the aim is that they're decided consistently and visibly rather than by whoever asked last.
Yes. Shifts are whatever your operation runs: their names, hours, and how many people each needs on weekdays, weekends, and holidays. Overnight shifts, short shifts, and different headcounts by day of the week are all supported. Schedulewright isn't limited to a day/night pattern.
It was designed around clinical scheduling because that's a demanding case: round-the-clock coverage, rest rules, long blocks. But nothing in it is specific to hospitals. Any team that schedules people into defined shifts and wants to weigh preferences against requirements can use it.
Yes. After each build, the scheduler sees where the schedule went against a preference or rule, and what it would have cost to do otherwise. That's what makes it possible to answer "why did I get that shift?" with something better than "that's how it worked out."
Your data is stored in a database that belongs to your team, and you can export it at any time. Schedulewright holds names, shifts, and requested dates, nothing more. It's free during the beta.