Table Service¶

Your servers run each table from the Badger app: open a tab when the party sits down, take the order seat by seat and course by course, send each course to the kitchen when the table is ready for it, then show the bill, split it however the table likes and take each guest's payment, with their tip, at the table. The admin keeps the records the law asks of you: every tip and service charge, your written tip policy, and every dish taken off a bill with the manager who approved it.

The floor¶

The app's Floor shows every table in the dining room, coloured by where it is in the meal: free, booked soon, seated, ordered, waiting for the next course, food ready at the pass, bill asked for, paying, and paid but still to clear. Each shows how long the party has been there and who is serving it. Tap a table to open its tab.

A party seated from a booking keeps the booking: the diary shows them seated, and the table frees up when the tab is cleared. Tables can be pushed together (the tab says "12+13"), a tab can move to another table, lines can move between tabs, and two tabs can be merged before anyone has paid. Only the table's own server or a manager can move, merge or hand over a table.

The menu a server orders from is the dining room's menu collection (its child collections are the sections), or the till's menu when none is set. A table's bill takes dishes, drinks and other goods, but not gift cards, top-ups, tickets, appointments, subscriptions or donations: those are greyed out and sold at the till.

Courses¶

Each line on a tab has a seat (or "shared", for the bread and the bottle of wine) and a course: drinks, starters, mains, desserts. Send sends what has been taken: drinks and the course being eaten go straight to the kitchen, later courses are held there, greyed out, so the kitchen can plan them. Away (also called "fire") tells the kitchen to start the next course. Each fire shows on the kitchen board with the table, the covers and the course, each dish with its seat and its allergens as icons (tap one for its name), and the server sees when it's ready at the pass and when it's served. The kitchen ticks off each dish as it's made with the small ring beside it; ticked, the dish is crossed through, and a second tap brings it back.

Taking things back¶

What happens when a guest changes their mind depends on how far the dish has got:

A manager approves on their own phone, or by typing their approval PIN on the server's phone. Five wrong PINs in a row lock it for 15 minutes. A manager's own void or comp approves itself. Each void and comp records the reason, who asked, who approved and when, and Voids and comps in admin lists them with what they took off bills, so you can see where food is being lost.

Clearing the table¶

When a paid table is cleared, anything still outstanding is closed off so the history doesn't say a dish is still being made: fires still on the kitchen board are marked served, and a course that was held back and never sent (but paid for) is marked served too. Nothing is sent to the kitchen at that point. Each step nobody took is recorded against the tab, as never sent to the kitchen (the server's step), the kitchen didn't mark it ready (the station's) or not marked served (the server's or runner's), so managers can see who isn't working the system. See Missed steps below.

The bill and splitting it¶

The bill shows the food and drink, the optional service charge (if you use one) and the total. A table can pay in one go or split it:

• Equally, between however many people;
• By seat, with shared dishes spread across the seats;
• By item, each guest picking what they had (a line of two can be split into two lines);
• By amount, for "I'll put £40 on mine".

Each share is paid on its own, by card on the reader or with Tap to Pay, or in cash, and is taken the moment it's approved, so a guest who has paid can leave. A paid share locks its dishes so nobody pays for the same thing twice. Shares always add up to the penny, and the service charge is shared out in proportion. When the shares cover the bill the tab closes itself and the table is marked for clearing.

Tips¶

Tips are never part of the bill. The guest chooses one after the bill and it is charged with their share. The choice always offers No tip and a custom amount, and nothing is chosen for them (the government said in 2026 that digital tip screens must work this way). Because tips sit outside the bill, they never count towards promotions, your sales figures or VAT: a tip freely given is outside the scope of VAT.

Where the guest chooses depends on what takes the card:

The app's tip screen shows the share, the suggested percentages with what each comes to in pounds, Custom and No tip. When the bill already has a service charge, the screen says so plainly and starts on No tip, so nobody tips twice without meaning to. A tip above the share's own amount is usually a slip, so the app asks the guest to confirm it ("That's more than the bill, are you sure?"); once confirmed there is no upper limit (tipConfirmed on the payment). Cash tips are taken as entered.

Two settings in Settings › Dining in shape the app's screen:

• Suggested tips (%) (dining-tip-suggestions): up to four percentages, each at most 50, for example 10,12.5,15 (the default). Blank offers only No tip and a custom amount.
• Suggested tips are worked out on (dining-tip-base): the food and drink before the service charge (the default) or the total after it.

Every tip record says where the tip was chosen (on the reader, in the app or in cash) and how the card was taken (reader or Tap to Pay).

Service charge¶

You can add an optional service charge, for example 12.5%, to every table or only to parties of a certain size. The bill and the payment screen call it "Optional service charge 12.5%", and the server removes it if the guest asks: who removed it, when and why are recorded. The percentage is taken from your settings when the table opens, so changing it mid-service doesn't move a bill already running.

Only an optional charge is offered, on purpose. Since April 2025 a charge the guest must pay has to be included in your menu prices rather than added at the bill, and a compulsory service charge is part of the price for VAT. If you want a compulsory charge, put it in your prices instead.

Tips and the law¶

The Employment (Allocation of Tips) Act 2023 (in force from 1 October 2024) and its statutory Code of Practice apply to every tip and service charge you, the employer, receive or control, which includes card tips and the optional service charge. In short:

• Pass on all of it. Tips and service charge go to your workers in full, without deducting card fees. They must be shared fairly among the workers at the place of business (an independent tronc counts), and paid no later than the end of the month after the guest paid.
• Have a written policy if you take tips more than now and then, saying how they're shared, and make it available to every worker, with each change. Badger keeps each version of your tip policy with the date it was made available, shows it to staff in the app, and can show it to guests at /tip-policy if you link to it.
• Keep records for three years of the tips and service charge received and how they were shared. Badger records every payment that carries a tip or service charge: the place of business, when it was paid, how (card or cash), the gross amounts kept apart from the bill, the table, the server and who took it. These records can't be deleted for three years, and they never travel with a site export.
• Answer workers' requests. A worker can ask for the tip records about them once every three months, and you have four weeks to answer. Their answer covers the totals you received and their own share, never other workers' amounts. Admin has a worker requests log that tracks the four weeks and downloads each worker's statement.
• An employment tribunal can order you to pay a worker up to £5,000 for money lost when the rules aren't followed.

A revised Code of Practice was withdrawn in July 2026 for a fresh consultation, so the 2024 Code still applies. This page is a summary, not legal advice; the Act and Code are on GOV.UK.

What Badger doesn't do for you (yet). Sharing the pool among your staff (by points, hours or role) stays in your payroll for now. The tips report gives the monthly pool for each place of business, and its CSV export is shaped to feed your payroll; the worker's statement says their share comes from payroll. A cash tip is recorded when the server enters it with the share's cash payment; cash handed straight to a server outside the bill isn't recorded.

The Manager section¶

Managers have a Manager screen in the Badger app at their dining room: floor managers (Approve voids and comps) and anyone who may give refunds (the POS supervisor role). It has two parts.

How today is going, refreshed every minute: covers seated, still booked, walk-ins, no-shows and cancellations; sales after voids, comps and refunds against the same weekday last week up to the same time; service charge, tips and the average per cover; open and free tables, with the five sat longest; the kitchen's average ticket time, late fires and dishes gone; voids, comps, walk-outs and refunds; and each server's tables, covers, sales and tips. No guest details.

Bills after they've closed. The day's paid, cleared and voided bills, newest first, searchable by table, order number or amount. Opening one shows the bill as it was paid, with any refunds. When a guest complains after paying, someone who may refund chooses an amount (or everything) and a reason (cold food, wrong dish, long wait, quality, overcharged, other):

• Card payments go back first, to the card they came from, with no tap needed. Then cash: the app says how much to hand back from the till, and it's recorded as paid out.
• Tips only go back when you refund more than the food, drink and service charge.
• The order's payment shows as part or fully refunded in Orders, and a refund on a booked table counts as a complaint on the guest's history.
• If a card refund can't be confirmed (Stripe didn't answer in time), the app says so and the amount is held as given back, so nobody can refund it twice; trying again finishes it. A card refund Stripe is still sending shows as pending until Stripe says it has gone. If Stripe or the bank can't send it, it stops counting and that amount can be refunded again. This needs the Stripe webhook to send the charge.refund.updated (or refund.updated and refund.failed) events: System, Stripe webhooks shows whether it does, and adds them.

Floor managers who can't give refunds see both parts but not the refund button.

Reports¶

The MCP tableService tool reads the same numbers for an assistant: open tabs (tabs), a day's covers and takings, and the tips totals (never per worker).

Underneath¶

Tip records, policies, requests and approvals are not part of the site data transfer: they're the employer's records for this site.