A guest-recovery control has to solve two problems at once. Staff need a prompt, credible way to repair an incorrect order, a charge that does not match the meal, or another ordinary service failure.
The restaurant also needs to know later what value was given, why it was given, and who was responsible for the decision.
A comp button that solves only the first problem becomes an unreviewed release of value.
A control that solves only the second can turn a routine recovery into a public argument at the terminal.
The goal is a gentle default: the ordinary route is fast enough for service, specific enough to preserve the transaction record, and limited enough that unusual value still reaches an authorised role.
The guest should experience a remedy, not a debate about permissions. The later reviewer should find a record, not an unexplained hole in sales.
Separate the events before assigning permission
The POS should not use one generic adjustment path for every disappointment. A line entered before production may need a void. An order served incorrectly may need a documented comp.
A guest whose payment has settled and who is due money may need a refund. Those events differ in check stage, value delivered, tender consequences, and evidence.
A void review asks whether food was produced and whether cash had been received; a refund review starts with the source transaction and ends with evidence that the authorised return was completed.
This distinction is also a service design. The employee facing an upset guest should be able to select the event that describes the situation rather than searching for the broadest available button.
A check may remain open while preparation occurs, and a completed order and a completed payment are separate states. The permission design should follow those states.
A pre-production error can have a different approval route from a post-tender change without forcing staff to explain the difference in front of the guest.
Give ordinary recovery a coded route
The initial comp path should present a limited set of reason codes that correspond to actual recovery decisions.
When the available code fits, the employee selects it, identifies the affected item or order, and completes the route within the authority configured for that role.
When the value or event falls outside that authority, the system calls the authorised role before finalization.
The approver views the original check, listens to the reason, selects the code, and records the decision under an individual credential.
Free text should add precision rather than replace the structured event.
Where the system permits it, the exception note uses four fields: what happened, why the restaurant owes the adjustment, who approved it, and what the guest received.
A description such as an allergy alert after an entrée was fired, followed by a replacement and comped original line, is reviewable.
“Guest unhappy” does not say what failed, what the restaurant did, or why the value given fits the failure.
The requester and approver should remain separately visible. The server or cashier stays identifiable as the check owner even when a manager authorises the comp.
Moving the check to a manager account before the adjustment can hide a recurring staff-level pattern that needs coaching.
Letting a server use a borrowed manager credential erases the evidence of approval. A recovery process can be generous without making the people and decision disappear.
Preserve the original transaction
The comp is not a detached entry in a report.
It belongs to the original check and should remain traceable to the check ID, original lines and modifiers, entry user, timestamps, final tender allocation where relevant, receipt, and later adjustment record.
A report total can surface a pattern, but it cannot explain one guest’s experience. The individual transaction record is where the reviewer tests whether the reason, item, and remedy match.
This is particularly important when the operational history is imperfect. A sent order is not proof that preparation began, and an approved card authorisation is not proof that the restaurant has received bank funds.
The POS can preserve the request and payment state; it cannot create facts that the record did not capture.
The recovery record should therefore say what the restaurant knows, identify the original transaction, and avoid unsupported claims about kitchen execution or payment settlement.
Set approval bands around risk, not embarrassment
Approval bands should reflect the transaction state and the restaurant’s own value threshold, not a desire to make ordinary service recovery difficult.
A reasonable configuration can let staff complete common, coded corrections while requiring a manager for events outside their privilege, post-tender voids, refunds, or adjustments above the local threshold.
The policy needs a route for a manager who is occupied, because a permission design that works only when a manager is standing beside the terminal is not a service design.
The counter-failure is important.
Requiring a visible managerial interrogation for every small recovery makes staff reluctant to correct genuine problems and signals suspicion to the guest.
The opposite failure is a broad comp default with blank reasons, shared sign-ins, and no later review.
Neither produces a reliable record.
Individual sign-ins, role-limited access, and a clear escalation path allow the employee to act promptly without treating authority as an open drawer.
Review exceptions as evidence, not as a verdict
The review begins with a report map, not a total-comp dashboard. For a comp, the chain is the original check, item or order, reason, authorizer, value given, and employee or manager involved.
The wider control map has at least six report families: cash over/short by drawer and custodian; voids by employee and check stage; refunds by issuer and source check; comps and discounts by reason and authorizer; no-sales and cash paid-outs; and access or privilege changes.
Each family needs an owner, a review frequency, a population, and a retention location.
Counts require context.
The basic rate is exceptions divided by opportunities. Seven voids against 214 checks is 3.27%, and that is a usable observation; a count of seven alone is not.
The same applies to a comp value of $96 against $4,800 in net sales, which is 2.0%.
Checks or items fit entry and void errors, sales dollars fit financial exposure, and manager approvals fit an approver’s comp behaviour.
A stronger review generally uses at least two denominators when both frequency and value matter.
Comparisons must also be like for like. A bartender on a late cash-heavy shift, a host handling deposits, and a lunch server should not share a single expected rate.
Segment by service channel, daypart, role, and known conditions such as a menu outage or training week.
Four documented guest-recovery incidents during a kitchen outage are not a reason to ignore the records.
They are a reason not to compare that shift casually with a lunch shift that had no outage.
Reason-code quality is itself a measure.
If most comp value sits in “other,” the report cannot distinguish product failure from unauthorised generosity. Creating dozens of codes is not the remedy.
Use a limited menu of decisions that actually occur and require a narrative for uncommon events.
Review approver concentration too: an approver responsible for most high-value comps may be covering most busy shifts, or may be an unchallenged bypass.
Shift coverage, reasons, values, and later outcomes determine which explanation holds.
Open selected records before drawing conclusions
An effective review queue can use three bands: review every post-tender void and refund, review all events above the restaurant’s value threshold, and sample a rotating share of lower-risk corrections.
If a dozen pre-tender voids occur in a shift and three carry no reason, the manager might inspect all three and a random sample of the rest.
This is a test of record quality, not a claim that every correction is misconduct.
For each selected comp, the reviewer asks whether the stated service failure occurred, whether the item and amount fit the remedy, who approved it, and whether the guest received the promised value.
A possible sweethearting review asks additional questions: whether someone received food or value, whether a permitted employee-meal or promotion rule applies, whether the check shows the actual items, and whether the authorizer can identify a guest relationship.
Evidence should be preserved before detailed questioning, so the transaction history cannot be rewritten after concern is raised.
Four weeks of cleanly coded data can establish a provisional baseline. A material change then receives inspection and an explanation; the baseline changes only when the operation changes.
A sharp increase after new permissions or a promotion may identify a configuration problem rather than conduct.
An alert is not a finding, and a finding is not an automatic disciplinary decision.
Useful dispositions include explained and closed, policy or training correction, system defect, unresolved pending evidence, and substantiated misconduct.
Test the route before relying on it
Configured permissions are not enough.
A monthly audit can test a cash drawer, a post-tender void, a comp, a refund, a paid-out, and a recent privilege change.
This six-event walkthrough asks whether the system or file can provide the person, time, original record, authority, reason, and result.
It should also confirm that a known legitimate exception appears in the exported review data. The point is to test control operation, not to stage an accusation against the worker observed.
When a review supports a control failure, management removes the narrow access that enabled it, such as void authority or sole drawer custody, while the investigation and applicable employment process continue.
The corrective record identifies the evidence reviewed, decision-maker, access change, and whether policy, training, staffing design, or system configuration needs revision.
It does not repair a report by suppressing the event or treating a variance as proof against a person.
The strongest recovery control is almost invisible. Staff see a clear path to make a genuine guest problem right.
Guests receive a remedy without being asked to wait through a permissions dispute.
The system quietly keeps the original check, reason, approval, and result so the restaurant can learn from recurring failures and investigate a meaningful exception fairly.
The operating measures are straightforward:
- Separate void, comp, and refund events by transaction state.
- Retain the original check, reason, authorizer, value, and result for every exception.
- Use reason-coded routes, individual credentials, and approval bands suited to the event.
- Review rates with relevant denominators, comparable operating conditions, and transaction-level evidence.
- Test the configured route through a monthly six-event walkthrough and record corrective dispositions.