Using TouchBistro to Help Protect Against the Wagon Wheel Scam
Table Of Contents
Chapter 2. Example 1: Keeping a Guest Check Open
Chapter 3. Example 2: Transferring an Item to an Unoccupied Table
Chapter 4. A Bit of Example 1 and a Bit of Example 2
Chapter 5. The Wagon Wheel Reveals Itself
Chapter 6. What if the Item Does Not Get Reordered?
Chapter 7. Protecting Against the Wagon Wheel
Section 2. Look for Bills with Duplicate Order Numbers and Big Differences in Time
Chapter 8. Catching the Wagon Wheel When the Server Tries to Delete/Void Items
Chapter 1. Introduction
The Wagon Wheel scam involves a server sending an item paid for with cash to another table or keeping the guest check open using the seat splitting feature to close all the seats but one seat with the item paid for with cash.
This guide will show you how to watch for and protect against this scam. We’ll first examine a couple scenarios how a Wagon Wheel might be accomplished in TouchBistro without proper security settings. Then this guide will show you how to help guard against the Wagon Wheel scam.
Chapter 2. Example 1: Keeping a Guest Check Open
1. A server has a table of four. The bill is $45.20.
2. The server prints the guest check and leaves it on the table.
3. The table pays with a $50 bill and leaves.
4. The server knows, say, “Budhouser” beer is a popular beer. There’s a very good chance the next party to occupy the table will order one.
5. The server creates another seat (seat 5)
6. The server moves the beer to seat 5.
7. The server then joins seats 1-4.
8. The server proceeds to the Checkout screen and splits the bill by seats.
9. The server closes seats 1-4 to cash but does not close seat 5 with the beer.
10. The server taps < Back.
11. We can see the beer is still on the table waiting for the next group of guests.
12. Say two new guests are seated at the table. The server taps the Add icon to add two seats.
13. Let’s say Seat 1 orders a rum. Seat 2 orders a Budhouser.
14. The server uses the Move to Seat option to transfer the Budhouser beer to Seat 2.
15. The server deletes Seat 5.
16. If the second party pays with a credit card, the server closes the full order. The server is up the price of the beer plus the tax in his/her “bank”. If the second party also pays with cash, the server is up two beers plus tax.
Chapter 3. Example 2: Transferring an Item to an Unoccupied Table
1. A server has a table of four. The bill is $45.20.
2. The server prints the guest check and leaves it on the table.
3. The table pays with a $50 bill and leaves.
4. The server knows, say, “Budhouser” beer is a popular beer. There’s a very good chance the next party to occupy the table will order one.
5. The server uses the Move Item to Another Table option to transfer the beer to an unoccupied table.
6. The beer is now on table 6.
7. The server re-opens table 7 and closes it to cash.
8. If the next party at table 7 orders a Budhouser, the server can reverse the transfer, sending the beer already paid for back to table 7.
9. If table 6 is sat, the server can “park” the Budhouser at the empty table 7 or any other unoccupied table.
10. If the table doesn’t order the Budhouser beer, the server can leave it parked on an unoccupied table until it is ordered again. Then the server can bring the item back from the parked beer.
Chapter 4. A Bit of Example 1 and a Bit of Example 2
Servers may, of course, employ a combination of both examples to keep the paid for item “alive”. They may use the seat splitting option from Example 1 to see if the next party at the table orders the same item. If not, the server may then transfer the item to an unoccupied table using the method in example 2.
Chapter 5. The Wagon Wheel Reveals Itself
We can see from the two above examples why this server scam is called the “wagon wheel”. An item keeps getting rotated around the floor plan. The server’s game is to keep reselling the paid for item as many times as possible, each time padding out his/her float or bank with the price of the item plus the tax.
Chapter 6. What if the Item Does Not Get Reordered?
Let’s say the server has parked the item on another table. The server is coming near the end of his/her shift and it’s unlikely the item will be ordered again. The server needs to close the table with the parked item.
If the item was sent to a kitchen or bar printer, the server will need to void the item and then close the table.
If the server didn’t send the item to a kitchen or bar printer, the server will need to delete the item and then close the table.
Chapter 7. Protecting Against the Wagon Wheel
Section 1. Security Settings
The easiest way to protect against the Wagon Wheel is to access Admin | Admin Settings | Security and enable Require Passcode to Transfer Seats/Parties.
When enable, if the server tries to park the item to another table (see the method in Example 2), TouchBistro will require a manager or admin passcode to allow the item move. A manager, made aware of the Wagon Wheel scam, can quickly prevent the server from parking the paid for item at an unoccupied table.
On the security page, you may also want to enable manage passcodes for all other methods of transferring:
1. Require Passcode to Transfer Tables Between Staff: this will help prevent staff collusion, allowing staff to move sold items on each other’s tables.
2. Require Passcode to Transfer Tabs/Deliveries/Takeouts Between Staff: This will also help prevent staff collusion.
3. As well, you may want to enable Lock Staff to Assigned Tables and Lock Staff to Assigned Tabs/Deliveries/Takeouts. When these are enabled, staff members cannot open another staff member’s table or order. Again, it limits information sharing between staff members and helps prevent collusion.
Section 2. Look for Bills with Duplicate Order Numbers and Big Differences in Time
Enabling Require Passcode to Transfer Parties Between Tables will not, however, prevent a server from keeping the item alive on the same table hoping the next party orders it.
If you recall from Example 1, the server kept the table open with the Budhouser beer that was paid for. The next party ordered and their order included a Budhouser beer. The server collected for the second order and then closed the table.
Because the order was not closed after the first party paid and left, TouchBistro will have two guest checks in the system with the same order number. However, the times on the separate receipts will likely have significantly different times on the bill.
To check for this:
1. Access Admin | Bill / Guest Check History.
2. Look for closed orders with the same order number but the bills have very different times. The times represent when the order was actually closed. In the pictured example, we can see Order 48 has two bills. The second bill was closed almost two hours after the first bill was closed. Are you seeing a lot of bills like this, particularly by one server? Examine the second bill. Does the second bill have some common items like a popular beer, app, or soft drink?
3. Look at the original bill in the order. Was it paid for with cash?
4. If you start to see patterns (x server generates a lot of orders with multiple bills with significantly different close times, bills are always closed to cash), it’s a good idea to start monitoring that server.
Section 3. Monitoring
As a manager or admin, regularly check your floorplan.
Look for a table that is occupied on the TouchBistro floorplan but has no one at the table. As well, look for tables that have be occupied for an unusually long time.
For example, Table 7 has been open for 4 hours. Is that normal? Is there anyone actually at the table? Did a party just sit there and there’s no way the table should report its been open for 4 hours?
Open your tables and examine them, notably the tables of a server you feel needs to be more closely monitored. Look for unusual differences in time.
In the example above we can see many red flags. Why is there only one seat and it’s seat 5? This is an indication the server split off one seat to keep the item alive. Is the item a popular item that gets ordered a lot? If the item was sent to the kitchen or the bar, is the sent time significantly different from the current time?
Chapter 8. Catching the Wagon Wheel When the Server Tries to Delete/Void Items
Section 1. Deleted Items
If you recall from the section above called What if the Item Does Not Get Reordered?, a server may be forced to delete or void an item he/she was trying to keep alive.
To help you find severs deleting wagon wheel items they can no longer keep alive, run a Detailed Deleted Items report. This is a CSV only report and you will need to email it to yourself. Open it and look for items (notably commonly sold items) that have significant differences between the time they were ordered and when they were deleted.
For example, we can see server Susan M. deleted a Budhouser more than 3 hours after it was ordered. This should be a red flag that the server needs to be monitored more closely.
You may also access Admin | Admin Settings | Security and enable Require Manager Passcode to Delete Items. A manager, made aware of the Wagon Wheel scam, can quickly prevent the server from “cleaning up” the item being wheeled.
Section 2. Voids
Ideally, you should require servers to get manager approval to void items. Access Admin | Admin Settings | Security and enable Require Manager Passcode to Void Items.
If not enabled, you might want to check your closed bills under Orders. A table with a single voided item (like the wheeled item) that is closed will have a $0 figure, notably those at end-of-day or near a server’s end-of-shift. Again, look for patterns. Same server? Same popular item?
Finally, ask kitchen staff to be cognizant of voids that occur a long time after the original ticket was sent. Ask them to report such tickets to management.
Chapter 9. Related Articles
Security
Security Settings
Using TouchBistro to Help Protect Against Post Payment Adjustment Scams
Using TouchBistro to Help Protect Against Server Check Padding