How a restaurant got its shift planning under control

The starting point

The restaurant did not have a software problem. It had a bottleneck problem that software happened to be able to solve.

The entire responsibility for the schedule sat with the manager. She sent the messages out to all the waitstaff, announced the new shifts, and found cover when somebody could not make it. The complete picture existed in one place only: in her head.

Shifts went out as text messages. A message with a long run of dates is hard to take in when you read it on a phone between two shifts. And it was out of date as soon as the first person replied yes. Then another message arrived, and another.

What annoyed the waitstaff most was not the absence of a system. It was not knowing. A waiter would ask whether she could have a particular shift, and then hear nothing. Had the message been seen? Had the shift gone to someone else? Should she count on having that evening off? It was written down nowhere, and all she could do was ask again.

What was built

We built Vagtflow: one system where the current schedule always lives. The waitstaff log in with their phone number and open the plan in the browser on their own phone. The page can be added to the home screen so it looks like an app. No app store and no installation, so the whole staff was up and running immediately.

The waitstaff see a calendar where every day is marked by colour: an open shift here, a shift you have bid on there, a shift you hold, a shift missing cover. That is the picture which previously had to be assembled from several text messages. Next to it sits a list of open shifts and an overview of your own, split into upcoming, pending bids and history.

The mechanism itself is a shift exchange. The manager posts the shifts, the waitstaff bid on the ones they want, and the manager approves or rejects. The decisive part is that the bid is visible to whoever made it: she can see for herself whether it is still pending, approved or rejected. Nobody has to ask again.

Standing down has its own flow. If a waiter stands down from a shift, that shift is still hers until a replacement has bid and been approved. She can undo it along the way. That means a shift cannot end up belonging to nobody without anyone noticing.

Rules are enforced on the server, not just in the interface. A waiter cannot hold two shifts on the same day, for instance, and that is refused by the system rather than merely hidden. On top of it sit notifications, so people are told when something happens to their bid, and the plan updates live for everyone at once.

The manager has her own panel: creating and editing shifts, an inbox of bids awaiting a reply, an overview of unfilled shifts over the next seven days, and management of which waitstaff have access.

How long it took

The system went into production in July 2026 and has run since. It was built in stages: the first version covered what hurt most, seeing the open shifts and bidding on them. It went live while the rest was still on the drawing board, and the restaurant ran real weeks on it before anything more was built.

Small corrections have been made continuously since then. Not because anything was broken, but because little things keep surfacing when a system is in use every week. They were agreed and made one at a time, as needed, not as a running arrangement.

Building in stages was deliberate. A shift planning system built to completion in a corner and only shown at the end always misses the mark. What mattered in practice was not what we had expected, and we would not have found that out without it being in use along the way.

What it cost

The system was invoiced as a one-off payment on the same model we sell on today. No subscription runs on it, and the restaurant pays nothing per month to keep it running. The price level for an equivalent system is on the pricing page.

What changed day to day

The biggest difference is for the manager. She still controls who gets which shift, but she no longer spends working time making the picture add up. Shifts are posted in one place, bids arrive in one place, and she approves them when she has a moment. It is not a number we can put a figure on, but it was the part of the job that used to eat the most time.

For the waitstaff, the uncertainty is gone. They can see the open shifts themselves instead of waiting for a message, and they can see the status of their own bids without asking. Nobody sends out text messages with long runs of dates any more.

And there is a less visible one: there are no longer several versions of the plan. The one in the system is the one that applies, and it is the same for everyone.

Want something similar?

This system was built for one restaurant and its way of working, but the pattern repeats anywhere a single person holds the whole overview and a phone. You can try the demo with test data, read about the shift planning system and what it costs, or about custom systems if your job looks different.