Norra POS (Point of Sales)

When a guest wanted to merge tables, the waiter had to write it down on paper first. Then the waiter told the cashier and the manager. At payment, the cashier had to check whether the bill had already been updated for the right table. If not, the cashier fixed it by hand.

The mistake did not show up at payment. It could happen when a table was moved or merged and the system did not know.

When tables are merged, the bill moves with the table. Nobody has to do it by hand. It only has to be updated in the POS, and every other role in the system sees it too.

When a table or a bill is split, the system supports 3 ways: 50/50 (equal), by percentage, and by hand.

At first, the developers suggested equal and percentage splits. They thought these were simple and helped staff split bills faster.

But guests do not always want an equal split, because there are cases where:

1. A guest wants to split a bill to get a separate invoice
2. A guest only wants to split off the takeaway dishes and pay for them separately
3. A guest wants to split off the pricier dishes and pay for those on their own

And in these cases, an equal split or a percentage split cannot do what the guest wants.

Merging, splitting, and moving tables (the bill) was a requirement for the POS. So nobody argued about whether to build it.

I took the guest stories above to the team. After that, adding the manual split was approved.

The developers did not mind building more. In the end, it is just picking dishes and moving them to another bill.

With the table-split stories approved, the dev team also understood how important this feature was and did not object to the extra work.

I tested it directly with restaurant staff, using the wireframe version. Before, staff who often split bills had to fix the dishes and the bill by hand. What impressed them most was splitting by percentage or in half. But when they saw they could split however the guest wanted, they found it much handier. It helped them get the job done faster.

Before this, if a guest wanted certain dishes split off, staff had to create a new table first. Only then could they note the dishes to split off. This is why I needed to make it simpler.

At peak hours, some guests came in to eat without booking a table. At that time, the system had no floor map. So the manager could not see which tables were free. The manager had to walk around the restaurant to check.

The system also could not estimate how long until a busy table would be free. For example, table A started service at 5 pm. With the number of guests and the dishes ordered, the system could have worked out when the table would be free. But at that time, the system did not go that far.

This is something most POS users need. They want to know the state of the whole floor, so they can make decisions in time.

The system is designed with 9 table statuses: empty, reserved, guest arrived, guest arrived late, being served, served, waiting for payment, paid, and cancelled or no-show.

The main screen is a list of tables, with a button to switch to the floor map.

I chose the list as the main screen because most staff use it to serve guests when they arrive. The list shows which tables are being served, based on what the guest booked.

The floor map is for when you need to know which tables are free or reserved. It lets the manager see the state of the whole restaurant.

At first, the dev team did not agree with having so many statuses in the system. But each status helps staff see what is really happening at the table. That helps staff do their work as well as they can.

Right now, statuses update with a reload button. I once suggested adding an in-app notice to say something new arrived, and to remind staff to reload. But I still think the system should update by itself. Staff should only reload when the network or the system has an error. Real‑time is still in the plan for later. It was not dropped.

In a restaurant, several roles look at the same order. If everyone can edit it, mistakes are easy and it is hard to control. If the manager can only look, they cannot handle the real situations that come up.

I saw that I needed to separate the right to see from the right to act. I also set one general rule: the person who does an action cannot be the person who approves it. On top of that, each role gets its own rights to see and to act.

Each role does only its own part of the job. Waiters create and edit their own orders, and merge, split, and move tables. Managers can see everything and approve the sensitive actions. Cashiers have full control of the money. The kitchen stays outside the POS and uses its own KDS screen. The full details are in the permission table below.

At first, the product team wanted the manager to know everything and to edit directly.

I argued the opposite. Whoever does the job owns it. The manager should only confirm and watch how staff work. The manager must not edit on their own.

The reason: at that time, the system had no audit log (a record of every action). If managers could edit or delete dishes, a manager could quietly delete dishes for a table they know. Then, when a problem came up, the blame would go back to the staff. A manager could also apply a discount code to a table they like, without anyone confirming it. The safest way was to not give them any power that could lead to that.

When a guest changed their mind, the waiter had to go down to the kitchen to ask if the dish was made yet. Order slips also had to be passed back and forth between the kitchen and the cashier.

This idea came from my own experience eating out.

When I want to change a dish, I ask the waiter if it has been made yet. If not, it can be changed. If it has, I usually wait. But if the wait is too long, for example over 30 minutes after ordering, I can ask to cancel. Then it is up to the manager, the staff, and the kitchen to sort it out.

I realized the kitchen already knew the answer to "how far along is the dish?". The POS just never asked.

I did not build a separate "change dish" flow. Instead, I let the dish status on the KDS decide if it is cancelled or changed:

• A dish that has not been started: it can be cancelled or changed, with the manager's confirmation code.
• A dish that is being made: the system says it cannot be cancelled.
• A dish that is ready to serve or already served: it becomes a void. The manager confirms and writes a reason.

The KDS status shows right on that table's dish line. The system also counts the time since the order. A guest may wait too long, like the 30 minutes above. Then you can check right in the POS if the time has really run out. That way the manager, the staff, and the kitchen each handle their own part.

Nobody on the team argued against this direction.

The void flow (the flow for a dish that was already served) now has its screens designed. It is no longer just an idea.