Restaurant Shift Handover Checklist for Small Hong Kong Restaurant Teams
Jul 17,2026 
By Tappo Team 
Reviewed by: Tappo Team Last checked: 17 July 2026 Source note: This guide presents a vendor-neutral operating method for small restaurant teams. It does not describe a Tappo shift-handover feature.
In short
A restaurant shift handover is complete only when every unresolved item has a clear current state, next owner and next action, and the incoming person has read it back and accepted what happens next. The next shift should not have to reconstruct a verbal story.
- Best for: small restaurant teams where responsibility changes while orders, menu updates or customer follow-ups are still open.
- Not designed for: cash control, refunds, payment reconciliation, staff performance management, legal procedures or compliance records.
What belongs on a restaurant shift handover
A useful handover does not repeat everything that happened during the shift. It isolates the work that is still open and could otherwise lose its owner when people change.
Record an item when it falls into one of these four groups:
| Item type | Include it when | Leave out |
|---|---|---|
| Unresolved order | Preparation, collection, correction or another agreed action is still pending | Orders that have already been completed with no follow-up |
| Menu change | A change has been requested or started but still needs checking, publishing or communication | Menu changes that are fully complete and verified |
| Customer follow-up | The team has promised an answer or action that has not yet happened | Full customer messages or personal details that are not needed for the handover |
| Other service exception | A specific service issue needs a named person to act later | General comments with no next action |
The point is not to create a longer shift report. It is to make each open item transferable.
Before, during and after the shift boundary
Before: turn open work into discrete records
The outgoing person should gather only unresolved items and write one record for each. A good record states what happened, what has already been confirmed, what is still open, who should act next and when the item should be checked again.
If information is missing, write the open question and who needs to confirm it. Do not fill the gap with a guess.
During: read back the next action
Work through the items in practical priority order. The outgoing person explains the current state; the incoming person repeats the next action and either accepts ownership or asks for clarification.
“The next shift will handle it” is not an accepted owner. Use a named person or a role that the team understands.
After: close it or hand it forward clearly
At the agreed checkpoint, mark the outcome as:
- completed;
- still open; or
- handed forward.
If the item remains open at the next shift boundary, record the new owner and the next observable action. Do not rewrite the history as if the earlier step had been completed.
Two-sided restaurant shift exception handover card
The card below can be used on paper or adapted to a generic shared document. It is deliberately separate from any POS screen, notification or automated workflow.
Side A: outgoing shift record
Handover header
| Field | What to record |
|---|---|
| Restaurant or location label | A plain identifier already understood by the team |
| Shift date and boundary time | When responsibility changes |
| Outgoing person or role | Who is handing over |
| Incoming person or role | Who is expected to accept the handover |
| Immediate service context | A short note such as `normal service`, `busy period` or `closing soon` |
One row for each unresolved item
| Field | What to record |
|---|---|
| Item type | `unresolved order`, `menu change`, `customer follow-up` or `other service exception` |
| Plain reference | A short internal reference the team already understands |
| What happened | One factual sentence without blame or speculation |
| Current state | What is complete, what remains open and what has already been confirmed |
| Customer promise or service impact | Only what the team actually told the customer or what the incoming person needs to know |
| Next owner | A named person or a clearly understood role |
| Next action | One observable action beginning with a verb |
| Next checkpoint | A practical time or event chosen by the team |
| Open question or dependency | The answer, person or evidence still needed |
| Existing evidence location | Where the existing note, message or paper record can be found |
Use the minimum reference needed to find the existing record. Do not copy a customer’s name, phone number, email address, payment details or full message into the card when the handover can work without it.
Side B: incoming acceptance and closure
| Field | What to record |
|---|---|
| Read-back | The incoming person restates the current state and next action |
| Acceptance | `accepted`, `needs clarification` or `requires manager / relevant owner confirmation` |
| First action and checkpoint | What the incoming owner will do first and when it will be checked |
| Priority reason | A short reason such as `customer waiting`, `menu accuracy` or `order completion` |
| Completion test | The observable result that means this item is complete |
| Outcome | `completed`, `still open` or `handed forward` |
| Handed-forward owner and next action | Complete this only if the item remains open at the next boundary |
| Acknowledgement | Initials or another simple acknowledgement chosen by the team |
This acknowledgement is only a practical team convention. It is not an audit, permission check or compliance control.
A worked example without customer details
Suppose an online self-pickup order needs one unavailable item replaced, but the customer has not yet confirmed the alternative.
The outgoing record could say:
| Field | Example |
|---|---|
| Item type | Unresolved order |
| Plain reference | Existing order reference ending `42` |
| What happened | One ordered item became unavailable after the order was received |
| Current state | Alternative item identified; customer confirmation still open |
| Next owner | Counter lead on the incoming shift |
| Next action | Check the existing message record and follow the agreed response path |
| Next checkpoint | Before preparation starts |
| Completion test | The order has one confirmed preparation instruction |
The incoming person reads the action back, accepts it and later marks the item completed, still open or handed forward. The example does not prescribe how refunds, payments or customer data should be handled.
When an item is incomplete or unclear
Do not force an unclear item into an apparently complete handover. Use three questions:
- What answer is missing? State the exact point that remains unknown.
- Who can confirm it? Name the appropriate person or role rather than guessing.
- When will it be checked again? Choose a practical event or time, without presenting it as a guaranteed response time.
If ownership is not accepted, the item remains open. If the task depends on a manager or another relevant owner, record that dependency instead of assigning authority the incoming person does not have.
Owner away? Use a simple stop-and-call note
For a very small shop where the owner normally decides unusual requests, write these three lines where the helper can see them:
- Stop and contact the owner for a refund, void or cancellation, price change, or unusual discount.
- Send only what the owner needs to identify the request: the order number, amount and a one-line reason.
- Do not guess. Leave the request pending until the owner replies, unless the shop has already written a different rule.
This is a reminder written by the shop. It does not describe Tappo permissions, refund handling, payment rules, audit logs or accounting treatment.
One opening-day use case
On an opening day, the same card can be used at the first real shift boundary to make any unresolved responsibility explicit before the next team takes over. Keep it to the live handover: if you need to test a complete order before choosing or committing to a POS, use a busy real-order trial instead.
What repeated handover problems may be telling you
The card helps transfer work; it does not repair the wider workflow by itself. Repeated items may point to a separate question:
- If orders repeatedly lose their next step, review the wider restaurant ordering system and order flow.
- If the same menu corrections keep crossing shifts, check the QR menu and POS menu-editing workflow.
- If the team is comparing systems, use the unresolved moments as real test cases in a restaurant POS system comparison.
- If you want to discuss product fit after mapping the workflow, start from the Tappo restaurant POS page.
These are different tasks. The handover card owns only the live transfer of unresolved work between shifts.
Who this checklist is and is not for
This checklist may fit:
- an English-speaking manager or shift lead in a small Hong Kong restaurant;
- a team that changes responsibility during the operating day;
- a shop that carries unresolved orders, menu changes or promised follow-ups into the next shift; and
- a team that wants a vendor-neutral paper or shared-document method.
It is not a substitute for:
- choosing or comparing POS suppliers;
- designing dine-in, takeaway, QR or self-pickup ordering channels;
- a cash, refund or payment-reconciliation procedure;
- product training or employee performance management;
- a legal, privacy, HR, safety or compliance process; or
- a restaurant-specific decision about what information may be recorded or retained.
FAQ
What is a restaurant shift handover checklist?
It is a structured way to transfer unresolved work from the outgoing shift to an incoming owner. A complete checklist records the current state, next owner, next action, checkpoint, acceptance and completion condition.
Should every order appear on the handover card?
No. Include only orders or service items that remain unresolved or require a later action. Completed work with no follow-up does not need to be repeated.
Can a small restaurant use the card on paper?
Yes. The method can be used on paper or in a generic shared document. The important part is accepted ownership and a clear next action, not a specific tool.
Is this a POS shift-handover feature?
No. This article describes a vendor-neutral operating method and does not claim that Tappo provides a shift-handover feature, automated owner assignment, alerts or escalation.
What should happen when the incoming shift cannot accept an item?
Keep the item open, record what clarification is needed and name the person or role that should confirm it. Do not make the handover appear complete while ownership is unclear.
Method and limitations
This guide is an operational checklist created for general information. It does not describe a Tappo product feature and does not provide instructions for cash control, refunds, payment reconciliation, permissions, legal matters or compliance. Each restaurant should decide what information is necessary, where its existing records are kept and who is authorised to act.
Does the same unresolved work keep crossing shifts?
Map the order, menu and customer-follow-up moments first. Then tell Tappo which part of the restaurant workflow you are trying to make clearer. We can discuss whether a POS setup is relevant to that specific workflow without treating this handover card as a product feature.