Schedule for coverage, not for hours

Two different questions that look like one

Building by hours means starting from people. Priya wants thirty hours, Daniel is part time and can do three evenings, somebody asked for Friday off. You fit them together until the week is full and everybody has roughly what they wanted. Then you look at it and think it seems about right.

Building by coverage means starting from the floor. Between six and nine on a weekday morning you need two people, one of whom must be able to open. Saturday afternoon needs four, including somebody who speaks Spanish because half the customers do. There must be a supervisor on site whenever the shop is open. Then you fill those requirements with the people available.

Both produce a grid of shifts. The difference shows up when something moves. When a schedule built by hours loses somebody on Thursday, you look for a person with hours left. When a schedule built by coverage loses somebody on Thursday, you know exactly what the hole is: it is nine to one, it needs somebody keyholder trained, and three people qualify.

Writing down what a covered week looks like

The work of switching is mostly one sitting, and the output is a short list of statements about your own business. Each one names a window, a day set, and what has to be true during it.

• Monday to Friday, 6am to 9am: two people, one keyholder.
• Saturday and Sunday, 11am to 4pm: four people.
• Every day the store is open: at least one supervisor.
• Saturday, 11am to 4pm: at least one Spanish speaker.

Most small businesses have between four and ten of these, and the majority of them have never been written down anywhere. They live in the head of whoever has been building the schedule longest, which is fine right up until that person is away and somebody else builds a week that looks reasonable and leaves Sunday morning with nobody who can open.

Two rules for writing them

Describe the floor, not the roster. “Two people between six and nine” is a requirement. “Priya and Daniel open on Mondays” is a solution you have already picked, and writing it as a requirement hides the fact that four other people could do it.

Say what a person must be able to do, not who they are. Requirements written against roles and skills survive somebody leaving. Requirements written against names have to be rewritten every time the team changes, which means they will not be.

One caution worth stating plainly, because it is easy to get wrong in software. A coverage requirement is a preference, not a law. Businesses make do, and a system that refuses to publish a schedule with a gap in it will be worked around by a manager on a Friday afternoon. Our own coverage findings warn and never block for exactly that reason, and the difference between a warning and a block is the difference between a tool people use and one they route around.

Copy forward is the whole game

Here is the thing nobody says about scheduling software: for a business with a stable team, next week is roughly this week. Not identical, but ninety percent the same. The work is not building a schedule. It is finding and fixing the ten percent that differs.

This is worth dwelling on because it is the single reason scheduling tools go unused. The first business we built this product for had scheduling available for years in their previous system and had never entered a single shift. When the owner explained why, it was not the price or the interface. It was that copying last week and then editing all the changes was more work than the paper they already had.

They were right. If copy forward drops a grid of shifts on you and leaves you to spot what needs changing by reading it, you have been handed a proofreading job. The value is in a copy that lands in a state where the differences are the thing you are looking at: who is on holiday now, who changed their availability, which shifts have nobody in them.

If you are evaluating scheduling software, this is the feature to test with your own data, and test it on a week where something changed. A demo on a clean week tells you nothing.

Why nobody submits their availability

Every scheduling product has an availability feature. In most accounts it is empty. On the account we studied most closely, every single employee had submitted nothing at all, for years.

That is not indifference. It is a rational response to three things.

1. It requires an account they do not have. If submitting availability means remembering a password for a system they use twice a year, it will not happen.
2. It is a form about the abstract future. “When are you generally available” is a hard question. “Can you do next Tuesday evening” is an easy one.
3. Nothing visibly happens. If somebody submits their availability and the next schedule ignores it, they will never submit again, and they will be right not to.

The first two are design problems. The third is a management problem and it is the one that actually kills the feature. If you are going to ask, you have to either honour it or tell the person why you could not. A single schedule that puts somebody on a shift they marked unavailable teaches the whole team that the form is decorative.

The practical version for a small business: ask for exceptions rather than a complete picture. Most people’s availability is the same week to week. What changes is the occasional Thursday. A system that lets somebody say “not this Thursday” in ten seconds will collect more useful information than one that asks for a full weekly grid and collects nothing.

Check before you publish, not after

The reason coverage requirements are worth writing down is that once they exist, a schedule can be checked against them before anybody sees it. That check should run at the moment the schedule is being built, not as a report afterwards.

Four things are worth checking, in descending order of how much trouble they cause.

1. Coverage gaps. Any window where a requirement is not met. These are the expensive ones because you find out on the day.
2. Double bookings. The same person in two places. Obvious in hindsight and easy to create on a busy grid.
3. Overtime you did not intend. Somebody scheduled past forty hours in a workweek, which is a cost decision that should be made deliberately rather than discovered at payroll. Watch the workweek boundary here rather than the pay period, since that is what overtime is calculated on.
4. Credentials lapsing mid schedule. If a certification expires on the Wednesday, the shifts after it may not be legal to work depending on your industry, and the record of who worked them is kept for years either way.

And when a gap is found, the useful output is not a warning. It is a list of who could fill it, split into the people who can take it now and the people who could be asked with a reason attached: not available on Mondays, would reach 43 hours, does not hold the role. A warning tells you that you have a problem. A candidate list is the answer to it, and it turns a ten minute puzzle into one click.

Two week cycles, and getting started

One structural point that matters more than it sounds. Many shift businesses genuinely operate on a two week rhythm rather than a one week one, because the rotation alternates: one weekend on, one weekend off. If your scheduling tool only thinks in weeks, you are building a two week pattern out of two one week views and holding the alternation in your head.

If that describes your business, look for a two week view as a first class thing rather than a setting. It is the difference between seeing the pattern and reconstructing it.

Where to start on Monday

1. Write down your coverage requirements. Windows, counts, and what a person must be able to do. Four to ten lines. Do it with whoever actually builds the schedule.
2. Check last week’s schedule against them. Not to blame anybody, but to see whether the requirements you just wrote are the real ones. Usually one or two are aspirational and one you forgot to write down entirely.
3. Build next week from the requirements rather than from the hours, once, as an experiment. It takes longer the first time and you will find at least one gap you have been quietly living with.
4. Ask for availability exceptions only, and honour them visibly the first time so the team learns the form is real.

None of this needs software. Coverage requirements on a printed sheet beside the schedule will catch most of what matters. Software is how you stop doing the checking by eye every week, and it is worth buying only once you know what you are checking for.