Where the money falls between your systems.
A seam is where a person carries an order, a booking or a number from one system to the next by hand. Here is how to watch one during a real shift, and a blank map to record what you saw.
Daniel M. Ortiz · September 2026
Ask an owner where the money goes and you get a list of software. Ask where it actually leaks and the answer is usually a place between two of those systems: the phone and the book, the book and the POS, the delivery tablet and the kitchen, the close and the accounting file. Nothing on the software bill has that place's name on it.
This piece names it, shows you how to watch one order cross every seam in the building, and gives you the blank map we fill in on a walkthrough. Run it on one shift. The record is the finding.
What is an operational seam in a restaurant?
An operational seam is every place a person carries information from one system to another by hand or by memory: the phone to the book, the book to the POS, the online order to the kitchen, the delivery portal to the POS, the close to the accounting file. No vendor sells the seam, so no vendor stands behind it. On one site the seam usually runs through the owner, which is why it looks like a habit and not a defect.
The gap where a party of eight is taken on the phone, written in the book, and later keyed into the POS as a table belongs to no vendor. It belongs to whoever is standing there, and that person gets so reliable at carrying it that nobody writes it down. The seam becomes visible the week they are out, when the party of eight is in the book and nowhere else, and the kitchen finds out at seven.
Watch one order cross every seam.
This is the same-order-twice test from the walkthrough, followed further than the receipts. Place two orders: one through your own ordering, one through the third-party app, the same items at the same hour. If the team knows your voice, have someone else place them. Then follow each order from the guest's first touch to the accounting file, and stop at every boundary.
The first touch
Where did each order arrive: your ordering page, the app's tablet, a printer at the pass, a phone at the host stand? Who noticed it, and how? A tablet chiming on a shelf is a boundary, and so is a phone nobody can reach at seven-fifteen.
The kitchen ticket
Follow both orders to the pass. Did each one print on its own, or did someone read it off a screen and key it into the POS by hand? Time the re-keying. Check the modifiers on the ticket against the modifiers the guest chose. A dropped allergy note is a seam finding before it is a kitchen finding.
The floor
Who ran the order out or handed it to the driver, and what told them it was ready? If the answer is a shout across the pass, write that down. The shout is the handoff, and it leaves no record.
The close
At the end of the night, find both orders in the POS close-out. Is the third-party order in the POS at all, or only on the portal? At which price, the menu's or the portal's? Where did its tip and its fees land? If the close-out and the portal disagree, note who is expected to notice, and when.
The accounting file
A week later, find both orders in the books. The direct order arrived as card revenue on the next settlement. The third-party order arrived inside a payout, on the portal's own schedule, net of commission: DoorDash's published merchant pricing puts commission on delivery orders at 15, 25 or 30 percent by plan, and pickup orders carry lower fees. So the POS figure and the bank deposit disagree by design, and someone reconciles them from a statement the POS never sees. Write down who, and from what.
Four things to write at every boundary
- Owner tonight
- The person who actually carried it on this shift. A name, not a role. If the answer is whoever was closest, write that.
- Handoff
- How the information physically moved: printed, re-keyed, shouted, texted, remembered. Remembered counts, and it is the one to worry about.
- Exception path
- What happens when it goes wrong: the modifier that did not print, the portal order that never reached the POS, the party of eight booked twice. Who catches it, and how long after.
- Evidence left behind
- What a stranger could find the next morning that proves the handoff happened: a ticket, a line in the close-out, a note in the book, or nothing. Nothing is a finding too.
Why doesn't a vendor own the seam?
Each vendor stands behind its own product, and its support contract ends at its own login. The boundary between two products belongs to nobody: the reservation company did not sell you the POS, and the POS company did not sell you the delivery tablet, so neither is on the hook for what happens when a booking walks from one to the other. Fewer vendors does not change that. A merged company still ships two products with a seam between them, and the seam is still yours.
The consolidation is real. DoorDash acquired SevenRooms for approximately $1.2 billion in an all-cash transaction, announced May 6, 2025 and completed June 13, 2025. American Express acquired Resy in 2019, price undisclosed, and acquired Tock from Squarespace for $400 million, announced June 21, 2024 and completed October 15, 2024. A delivery company now owns a reservation book, and a card company owns two.
None of that moved the boundary between your book and your POS onto anyone's support contract. The seam is where it was. The map below is the only record of it that exists, and you are the one who can draw it.
The blank seam map.
One row per boundary the two orders crossed, filled in during a real shift, in pen. Leave a cell blank where nobody could answer; a blank cell is a finding, and usually the first one worth fixing.
| Boundary | Owner tonight | Handoff (how it moves) | Exception path | Evidence left behind |
|---|---|---|---|---|
How the walkthrough and the twelve tests use the record.
The twelve outside-in tests read the operation from the guest's side: six calls, two bookings, a large-party inquiry, the same order placed twice, a signup, a review check. They tell you which seams leak. The seam map tells you why, because it records who was standing at the boundary and what they had to carry across it.
On a walkthrough we fill in this map for every boundary in the building, across two observed services and five interviews. Every re-keyed handoff gets a name, a duration and an evidence line, and the report prices the seams beside the software bill, so fixing the handoff and replacing the tool can be weighed as the same kind of decision.
When the tool is not the problem.
Most seams survive a POS replacement untouched. The new POS prints tickets the way the old one did, the party of eight is still taken on the phone and keyed into the book by hand, and the payout still lands on the portal's schedule. Replacing the tool moves the seam's furniture and leaves the seam.
The fix that holds is ownership and a written handoff: one named person for each boundary tonight, one written way the information moves, one written path for when it goes wrong, and one piece of evidence that shows it happened. Decide that first. Then read the software bill line by line, and decide the tools with the map in your hand.
If the map came back with more blank cells than names, and you'd rather have the whole building walked than draw it alone: