The Shift Swap That Never Got Recorded

The roster goes up on Sunday. By the following Saturday it is wrong, and everyone knows it is wrong.

Two people traded Thursday. Someone covered a Friday and is taking a Monday off in exchange. A third person swapped with a fourth and told the floor manager verbally at 23:40 on a busy night.

None of it is on the roster, and the roster is what payroll runs from.

What this actually costs

Three things, and only one of them is obvious.

Payroll disputes. Someone worked a shift the system says they did not, or was paid for one they traded away. The dispute is resolved by whoever remembers more confidently, which is not the same as whoever is right.

No-shows that were not no-shows. A shift shows uncovered. Someone did cover it — the swap just never got written down. The manager who chases it burns an hour and finds nothing wrong.

The number you cannot compute. This is the expensive one. Once the roster stops matching who actually worked, every per-shift metric you have is measuring the wrong person.

Sales per server, section performance, pour cost by shift, incident rates — all of them join on "who was working," and that field is now fiction for a portion of your shifts.

You do not notice, because the numbers still come out. They are just quietly wrong for the shifts that got traded, which tend to be the busiest ones.

Why banning swaps does not work

Some venues respond by requiring management approval for every trade.

It fails, reliably, for a simple reason: the swap is going to happen anyway. Someone has a family thing, a second job, an exam. If the approved route is slow, the unapproved route is used, and now the trade is not just unrecorded — it is hidden, because admitting it means admitting a rule was broken.

A rule that pushes the behaviour underground is worse than no rule, because you lose the information along with the control.

The venues that handle this well make recording a swap easier than not recording it, and they approve by exception rather than by default.

The minimum that works

Three properties. Anything with these three holds up.

One — either party can record it. If only the person giving up the shift can log it, half of them will not, because they are the one with the problem to solve and they solved it the moment someone said yes.

Two — it takes under thirty seconds, on a phone, without a login they have forgotten. The competing option is a message in a group chat, which takes five seconds. You will not beat five seconds, but you can get close enough that the recorded route is not annoying.

Three — it updates the thing payroll reads. A swap log that management has to manually transcribe into the roster will be transcribed for two weeks and then not.

That third one is where most attempts die. The swap gets recorded somewhere — a form, a chat channel, a whiteboard — and the roster stays wrong, so nothing downstream improves.

Approval by exception

You do not need to approve every trade. You need to catch the small number that matter.

The exceptions worth flagging:

• A trade that puts someone over a legal or policy hours limit
• A trade that leaves a shift without anyone holding a required certification or key-holder role
• A trade that puts two people who should not work together on the same shift
• A trade into a section or role the person has not been trained for

Everything else can be automatic. That is usually 90% or more of trades, and letting them through without friction is what makes the other 10% actually get seen.

A system that flags four things well beats one that requires approval for everything and gets ignored.

The pattern that shows up once you can see it

Venues that start recording swaps properly usually find the same two things within a month.

A small number of people do most of the giving away. Not a discipline problem — usually a scheduling mismatch. Someone is rostered for a day they consistently cannot work, and has been solving it privately every week. Fixing the roster removes the swaps entirely.

A small number do most of the taking. These are the people who want more hours. That is useful information you did not have, and it is cheaper to give hours to someone already asking than to hire.

Both are invisible until swaps are recorded, and both are directly actionable once they are.

What to do about the shifts you cannot reconstruct

If you are starting from a roster that has been drifting for months, do not try to fix history.

Draw a line at a date. Everything before it is what it is. From that date forward, the roster is expected to match reality, and per-shift metrics only get trusted from that point on.

Trying to reconstruct three months of swaps from memory produces a record that is confidently wrong, which is worse than an acknowledged gap.

The check that keeps it honest

Once a month, take four shifts at random and ask the manager who was on: does the roster match who actually worked.

Four shifts, ten minutes. If it matches, the system is holding. If it does not, you have found the drift early rather than during a payroll dispute.

This is the entire audit. It does not need to be more than this, and doing it monthly is what stops the slow return to the group chat.

Where the record has to live

The roster in one place, the swaps in a chat, and payroll in a third means the join is manual, and manual joins stop happening.

tasteck lets either party record a swap from the shift itself, applies it to the roster that payroll and reporting read from, and flags the exceptions rather than gating every trade.

The swaps are already happening. The only question is whether your numbers know about them.