Manager approvals that do not stall a service

A server needs to void a steak that came back. The till asks for a manager. The manager is on the terrace dealing with a complaint, so the server waits by the till, then walks outside, then waits again. Six minutes later, the void is approved. Meanwhile, two tables have been waiting for their bills and a third for its drinks. The next time a void is needed, the server simply asks a colleague who knows the manager's code.

Manager approvals exist for good reasons: some actions on the till move money after the fact, and a second person should know about them. But an approval process that stalls service is an approval process that will be worked around, and one that is worked around is worse than none, because it gives a false sense of control.

This guide covers which actions need a second person, how to approve them in seconds, how to make approvals part of the shift rather than an interruption, and the one approval nobody should delegate. Every venue and figure in it is an example.

Approvals exist because some till actions take money away after a sale: voiding a dish that was sent to the kitchen, comping a check, giving a large discount, refunding a payment or changing a check that has been paid. Each is sometimes right, and each is also the easiest route to losses, honest or otherwise.

A second person's approval turns each of those into a shared decision. The server who asks knows someone else will see it; the manager who approves knows they are responsible for it. That alone prevents most misuse.

The aim is not to stop the actions, but to make sure someone with authority knows about each one.

Not every action needs approval. Requiring a manager for every change slows service and teaches staff that approvals are a formality. Keep approvals for the actions that matter most.

Most venues need approvals for five things: voids after an order has reached the kitchen, comps of a whole check, discounts above a set level, refunds, and any change to a check that has already been paid. Everything else, such as correcting an order before it is sent, splitting a check or moving a table, can be done by the server alone.

Write the list down and keep it short. A list of five is remembered; a list of twenty is not.

Comps need different treatment depending on their size. A single dessert for a birthday, or a coffee for a guest who waited, is a small gesture a server or supervisor can give alone, within a limit. A whole check comped after a serious problem is a manager's decision.

Set the line clearly: an item up to a set value can be comped by the server with a reason, anything larger by a supervisor, and a whole check only by a manager. Clear lines mean fewer approvals and less confusion about who decides.

The difference between a void before sending and a void after sending matters. A dish removed before it reaches the kitchen costs nothing, because nothing has been cooked. Servers should be able to do that alone, because it is usually a simple correction.

A void after sending may mean food has been cooked and thrown away, or a dish has been served and removed from the bill. That is where losses hide, and where a second person should know. Our guide to POS permissions: who can void, who cannot covers the difference in detail.

An approval should take seconds, not minutes. Where the till supports it, the manager enters their own code at the till where the server is standing. Where it does not, the manager carries a device that can approve from wherever they are, or the venue uses a simple rule for the busiest moments.

The key is that the manager is reachable and the approval is quick. A manager who is always on the floor during service, rather than in the office, can approve in seconds. One who is hard to find turns every approval into a delay.

For some actions, approval can happen after service rather than in the moment. A server records the void or comp with its reason during service, without waiting, and the manager reviews every one at close. If something looks wrong, it is discussed the next day.

That approach keeps service moving and still puts a second pair of eyes on every action. It works best where the till records each action against the person who took it, and where the manager actually reads the list every night.

Choose which actions need approval in the moment and which can be reviewed afterwards. Large comps and refunds usually need the first; small voids after sending can often be the second.

Discounts at the till need their own rules, because they are the action most often used as a favour. Decide which discounts a server can give alone, which need a supervisor and which need a manager. Our guide to discounts at the till: who, what and how much sets out four levels worth defining.

A discount above the server's level should need the manager's decision, made with knowledge of what happened, not a code entered without a question.

Voids and refunds are where money leaves after a sale, so they deserve the most care. A void after the bill has been printed, or a refund after payment, should always involve a manager, because both can hide money that was taken and not recorded.

Record every void and refund with its reason and both names: the person who asked and the person who approved. Review them every night at close. A pattern of voids after printing, or refunds to the same card, is worth a quiet question.

Bars move faster than dining rooms, and an approval that takes a minute at a table can hold up a queue of drinks at the bar. Give the bar its own approver for the busiest shifts, usually a head bartender or a supervisor, with the authority for the common approvals.

Keep the bar's rules the same as the floor's, so a void after pouring needs the same approval in both places. Different rules in different parts of the venue invite confusion and workarounds.

When a dish is sent back and remade, the original is usually written off. Decide whether remakes need approval. Many venues let the kitchen and the server agree a remake without a manager, because speed matters for the guest, and review all remakes at close.

What matters is that every remake is recorded with its reason. A pattern of remakes for the same dish points to the kitchen; a pattern for the same server may point to how orders are taken.

One approval should never be handed to someone else: changing a check after the guest has paid, including refunds. Money that has been received is the venue's; returning it or changing what it was for is a decision only a manager should make, in person, with their own code.

That means a manager's code is never given to a server, never written down near the till and never used by anyone else. A manager who shares their code to save walking to the till has given away the one control that matters most.

If there is any chance the code is known, change it at once.

Approvals only mean something if every action is recorded against the right person. If everyone signs in with a shared login, the approval shows that the manager's code was entered, but not who asked or who actually entered it. Our guide to staff logins: one till, eleven people covers why every person needs their own.

With individual logins, the record shows who asked, who approved, what was done and why. That is the record you need when a question comes up a week later.

POS permissions decide who can do what without approval. Set them by role: servers can take orders, correct before sending, split and move checks and record payments; supervisors can comp small items and give service recovery discounts; managers can void after sending, comp whole checks, give larger discounts and refund.

When permissions match roles, approvals are needed only for the actions above a person's role. That keeps the number of approvals low and each one meaningful.

Approvals depend on a manager being available. On a busy night, decide who holds the approving role for each part of the service: the manager on the floor, a supervisor for the bar, the head chef for kitchen remakes. Make sure everyone knows who to ask.

If the only manager is also running the pass or dealing with a large table, approvals will stall. Give a supervisor the authority for the most common approvals, such as small voids after sending, so the manager is needed only for the rarer, larger ones.

Some shifts have no manager on site: a quiet lunch, an early opening, a late close. Decide in advance what happens to approvals then. Either a senior member of staff holds the manager's role for that shift, with their own login and permissions, or certain actions wait until a manager is back.

What should never happen is a manager's code left with whoever is on shift. That is the moment when an approval system quietly stops working.

An approval with no reason tells you little a week later. Give every approval a short reason, chosen from a list where possible: entered twice, guest changed mind, sent back, complaint, staff meal, regular's agreed rate.

Review the reasons, not just the totals. A sudden rise in "complaint" approvals points to a problem in the kitchen or on the floor; a rise in "entered twice" may point to the till's layout or a new member of staff.

A server who asks for far more approvals than their colleagues is not necessarily doing anything wrong. They may be newer, working the busiest section or struggling with the till's layout. Look at the reasons before drawing conclusions.

Often, the fix is training: showing the server how to enter changes correctly, how to check an order before sending or how to split a check without voiding it. Fewer mistakes mean fewer approvals, which helps everyone.

Review approvals every night at close and every week as a whole. Look at who asked for approvals, who gave them and why. Look for patterns: one server asking far more often than others, approvals at the same time every shift, approvals with vague reasons, or one manager approving everything without question.

A manager who approves every request without asking what happened is not approving at all. Our guide to POS reports a manager should read daily covers the voids and comps report in context.

The principle behind approvals is the old idea of separation of duties: the person who takes an action that moves money should not be the only person who knows about it. In a large business, that means several departments; in a restaurant, it usually means a server and a manager.

Keep the principle in mind when designing your process. The goal is not bureaucracy, but making sure no one can move money after a sale without someone else knowing.

Explain approvals to every new member of staff: which actions need one, how to ask for one quickly and why they exist. Make it clear that asking for an approval is normal and never a sign of distrust.

Train managers too: how to approve quickly, what questions to ask, when to say no and how to read the approvals at close. A manager who understands why approvals exist uses them well; one who sees them as a nuisance approves everything.

The best approval systems feel like part of the shift, not an interruption. The manager walks the floor, approves as they pass, reviews the list at close and talks about patterns at the briefing. Staff ask for approvals as naturally as they ask for more bread.

When approvals are quick, fair and consistent, nobody needs to work around them. That is the whole point.

Sometimes an approval is needed and no manager is on site. Avoid approvals by phone that end with the manager reading out their code. If the action can wait, let it wait; if it cannot, the senior person on shift should hold an approving role with their own login.

Record every approval made in the manager's absence, with who made it and why, and review them first thing the next day.

In a group, approvals should follow the same rules at every venue, so staff who work at more than one site know what to expect and the reports can be compared. An area manager reviewing several venues should see the same kinds of approval recorded in the same way.

Where venues differ, such as a bar-led site and a restaurant, adjust the limits but keep the principle the same: the actions that move money after a sale need a second person's knowledge.

Many approvals can be avoided by deciding in advance. A large group that wants a set price, a regular with an agreed rate or a private event with a fixed menu can all have their price approved before the booking, rather than argued over at the till.

Write the agreed price on the booking, and charge it on the night as agreed. The server has nothing to ask, the manager has nothing to approve and the guest pays what they expected.

List every approval on the shift report: what was done, who asked, who approved and why. The manager closing the shift reads the list in a minute, and the owner can see the week's approvals at a glance.

An approval that appears on a report is an approval that someone checked. One that disappears into the till's history is easy to forget, and easier to misuse.

An invented brasserie requires a manager's code for every void, discount and comp, however small. Managers are often busy elsewhere, so servers wait at the till, and within months several servers know the manager's code. The reports show the manager approving dozens of actions a night, including some made while the manager was off site.

The brasserie changes the rules. Servers can correct orders before sending without approval. A supervisor can approve small voids after sending and service recovery discounts. Managers approve large comps and refunds, and nothing else needs them. The manager's code is changed, and voids and comps are reviewed every night at close.

Approvals fall from dozens a night to a handful, each one meaningful. Servers stop waiting at the till, and the voids report becomes something the manager actually reads.

servearound has no manager-approval step today. Anyone whose role lets them take orders on the till can void, comp or re-fire a line, or void or comp a whole check, each with an optional reason, and every member of staff signs in on the till with their own name and PIN, so each action is recorded against the person who took it. Roles are set module by module, with view, create, edit and delete, so the roles decide who can use the till at all.

Once any payment has been recorded against a check, the till will not void or comp it, and each void and comp raises a notification for the team. The review in this guide happens through the reports: payment analytics show voids and comps by member of staff, and order analytics show the void and comp rates and the value voided and comped. See Order Fulfillment.

Voids after sending, comps of whole checks, discounts above a set level, refunds and changes to paid checks.

Keep the list short, make sure a manager or supervisor is always reachable, and review some actions after service instead of in the moment.

For common, smaller actions, yes. Keep refunds and changes to paid checks for managers.

Never. A shared manager's code removes the control approvals are meant to provide.

Changing a check after the guest has paid, including refunds.

They record who asked and who approved, which is the record you need when a question comes up later.

Give a senior member of staff the manager's role for that shift with their own login, or let certain actions wait.

Every night at close and every week, looking for patterns by requester, approver and reason.

Manager approvals put a second person's knowledge behind the till actions that move money after a sale: voids after sending, comps, larger discounts, refunds and changes to paid checks. Keep the list short, make approvals take seconds, let some actions be reviewed after service, and give supervisors the common ones so managers are not stretched.

Never share a manager's code, never delegate changes to a paid check, make sure every action is recorded against individual staff logins, set permissions by role, plan for shifts without a manager and review every approval at close.