Not everyone can cover every shift

Not everyone can cover everything. A swap process that ignores this will eventually approve a trade that leaves a shift without a keyholder, a trained opener, or someone qualified to handle a required task.

Qualifications are the least interesting part of scheduling right up until they're the reason a shift can't legally or practically run. Modelling them properly is what allows swaps to stay open and fast without someone reviewing every trade by hand.

Not all qualifications are the same

In practice, teams track several different concepts under the single heading of “qualifications”, and they behave quite differently:

• Certifications — a formal credential with an expiry date. Food handling, first aid, a licence, or a machinery certification.
• Trained roles — internal competence with no paperwork attached. Opener, closer, till, keyholder.
• Authority — permissions tied to a role: approving, voiding, opening, or unlocking things.
• Preferences — what someone is willing to work. Not a qualification, and it shouldn't block a swap in the same way.

The common failure is putting all four into one flat list of tags. Preferences then behave like hard requirements, while certifications that expire behave like permanent traits.

The result is either too many swaps being blocked or, worse, a swap being approved without checking what the shift actually needs.

Model the shift, not just the person

Tagging people is only half the job. The other half is recording what each shift requires — something most teams carry in a manager's head rather than anywhere written down.

Take a simple example: a Saturday close might require one keyholder, one till-trained person, and someone with current first-aid training on site. A single employee could satisfy two of those requirements at once.

Written down, a proposed swap becomes checkable: does the roster still meet every requirement after the trade?

Left unwritten, every swap depends on someone remembering.

“A trade can look perfectly reasonable on paper and still leave a shift without the one person who can lock the door.”

That's the difference between checking whether two people can exchange shifts and checking whether the resulting roster still works.

Block if you must, but explain why

When a trade would break a requirement, a silent rejection isn't much use.

A clear reason is: this shift needs a keyholder, and you'd be the only one scheduled.

That turns a dead end into something the employee can act on — usually by finding a different swap partner without involving a manager at all.

Blocking without explanation teaches people to route around the system. That's how teams end up back in the group chat, where the trade may happen without anyone checking the consequences.

The goal isn't to approve every swap. It's to make the reason for a rejection clear enough that people can solve what is actually wrong.

Keep the records current

Certifications expire, and an expired certification that still reads as valid is worse than having no record at all.

Two habits usually suffice: put an expiry date on anything that has one, and review a person's qualifications when their role or responsibilities change rather than waiting for an annual review.

The same applies to trained roles and authority. If someone stops being a keyholder or takes on a new responsibility, the record needs to change with them.

Done properly, this is the groundwork that lets you say yes to swaps by default.

The system knows what each shift requires, checks whether the proposed trade preserves those requirements, and explains when it doesn't — which is also what makes an approval decision quick to make.

“The manager doesn't have to hold the constraint in their head. They only need to step in when the system finds a decision that actually requires them.”