Chapter 26: Technology: POS Systems, Online Ordering, Delivery Platforms, Reservation Tech, and the Digital Restaurant

"The salesman will spend fifty minutes on the software and ninety seconds on page eleven. Page eleven is the whole deal." — constructed; what a veteran operator tells a first-time buyer

Overview

Here is a question almost no operator can answer, and it is worth roughly seventy-three thousand dollars a year: what does your technology cost you, all in, as a percentage of sales?

Not what the point-of-sale subscription costs. All of it. The POS, the kitchen screens, the reservation platform, the scheduling app, the inventory software, the accounting sync, the online ordering module, the internet line and the backup internet line, the camera storage, the website, the hardware you will have to replace in five years — and the single largest piece, the one that hides in plain sight on every statement you have never actually read: payment processing.

Ask an operator what their food cost is and they will give you a number, right or wrong. Ask what their technology costs and you get a shrug and a guess that is invariably low by half, because the pieces arrive one at a time, on different billing cycles, from different vendors, and the biggest one is netted out of the bank deposit before the money ever lands. A cost you never see is a cost you never manage. By the end of this chapter, Bellwether's technology stack will have a number attached to it — \$73,273, or 4.73% of sales — and you will know how every dollar of it was built.

There is a second reason this chapter matters, and it is larger than the money. Every technique in this book resolves to a number, and every one of those numbers comes out of the POS. Menu engineering (Chapter 12) needs item-level mix. Ideal-versus-actual food cost (Chapters 11 and 13) needs theoretical usage, which is recipes multiplied by items sold. Sales per labor hour (Chapter 19) needs sales by hour matched to labor by hour. Ticket times against Chapter 14's 22-minute not-to-exceed need timestamps. RevPASH (Chapter 24) needs honest cover counts. The weekly flash report (Chapter 31) needs clean exports. Choose the stack badly and you pay twice: once in fees, and again in every decision you then make blind.

This is not a chapter about software for people who love software. It is a chapter about a cost line and a data supply chain, written for a manager who will never write a line of code and does not need to.

In this chapter, you will learn to:

• State what a POS must capture to serve as the restaurant's system of record, and name what breaks downstream when each field is missing or wrong.
• Compare cloud and legacy architectures, read the four clauses in a POS agreement that actually matter, and identify where the lock-in is buried.
• Explain how a kitchen display system converts a paper ticket into a measurable ticket time — and the two ways cooks quietly defeat it.
• Judge whether your inventory, scheduling, and accounting systems genuinely talk to each other, and price the labor cost of every boundary where they do not.
• Separate interchange, assessments, and processor markup on a merchant statement, and compute the effective rate two ways — the processor's way and your P&L's way.
• Build a complete technology budget, foot it inside the other-operating line, and defend it.

Learning Paths

🏗️ Opening — §26.2 and §26.8 are yours, and they are the most consequential pages in the chapter. You choose this stack once, under time pressure, in the middle of a build-out, and you live inside the choice for years. Read the contract sections twice and compute the switching cost in §26.8 before you sign anything. 📋 Managing — you inherited the stack; you cannot change it this quarter. Weight §26.1, §26.3, and §26.7. Your job is to make the system produce clean data (which is a training problem, not a software problem) and to be the first person in the building who has ever read the merchant statement. 🍸 Beverage — §26.1's void-and-comp trail and §26.7's per-transaction arithmetic. Bar tickets are small, numerous, and reopened constantly, which makes the bar simultaneously the leakiest place in the audit trail (Chapter 15) and the most expensive place per dollar to process. The tab discipline in §26.7 is free money. 🚚 Small Format — §26.6 and §26.7. A truck or a pop-up is close to 100% card, runs on cellular data, and has low monthly volume, which flips several of this chapter's conclusions: flat-rate pricing usually wins for you, and connectivity is not an IT question, it is your entire revenue.

26.1 The POS as the system of record: what it must capture

A point of sale (POS) system is the software and hardware through which orders are entered, routed to the kitchen and bar, priced, totaled, tendered, and recorded. That is the job description every vendor puts on the first slide. It is also, and much more importantly, the wrong emphasis.

The POS is not primarily an ordering tool. It is the restaurant's system of record — the single authoritative account of what was sold, to how many people, at what time, by whom, at what price, with what discounts, paid how. Everything downstream is a derivative of that record. If the record is incomplete or dishonest, the derivatives are worthless, and you will not find out for months because the reports will still generate. They will simply be wrong, confidently, in a font.

What it must capture

Here is the minimum specification. When you evaluate systems, this is the checklist — not the touchscreen animations.

FIGURE 26.1 — What the POS captures, and what breaks without it        [the Bellwether plan]

  WHAT THE TERMINAL CAPTURES              WHAT IT FEEDS                        WHERE
  ──────────────────────────────────────────────────────────────────────────────────
  item sold, by item, by check     ──▶  menu mix %, contribution ranking      Ch. 12
                                   ──▶  theoretical (ideal) food usage        Ch. 11, 13
  cover count, entered per check   ──▶  average check / PPA, RevPASH          Ch. 1, 24
  time rung, time fired, time paid ──▶  sales by hour, ticket time, turn time Ch. 14, 22
  server / bartender identity      ──▶  per-server mix, upsell, comp pattern  Ch. 18, 34
  void / comp / discount + reason  ──▶  the audit trail                       Ch. 34
  authorizing manager on each one  ──▶  separation of duties                  Ch. 34
  tender type, tip, and batch      ──▶  card volume, tip records, the DSR     Ch. 20, 26, 31
  table and seat number            ──▶  turn time, table mix, pacing          Ch. 22, 24
  ──────────────────────────────────────────────────────────────────────────────────
  Anything not on this list has to be reconstructed by hand later, or guessed at.
  Guessing is what the restaurant in Chapter 1 did for eleven months.

Read that middle column again and notice what it is: it is the table of contents for Parts III, IV, and VII of this book. Menu engineering, food cost variance, labor productivity, ticket times, turn times, the audit trail, the flash report. Every one of them is a query against the same record. This is why the POS decision is not an IT decision. It is the decision about whether the rest of your management system is possible.

Three ways the record gets corrupted, all of them human

The software will do its job. The people will not, unless you train them, and the failures are depressingly consistent.

The open-item button. Every POS has some version of "MISC FOOD" or "OPEN ITEM," where a server types a dollar amount because the thing the guest ordered is not on the screen. It exists for good reasons — a special that was 86'd and replaced at four o'clock, a guest paying for a broken glass, a half-portion for a child. It is also a black hole. Every dollar rung through it is a dollar with no recipe attached, which means it never appears in theoretical usage (Chapter 13), never appears in the menu mix (Chapter 12), and inflates your food-cost variance for reasons nobody can trace. If specials are being rung as open items three nights a week, your ideal-versus-actual variance is measuring the POS, not the kitchen.

The fix is boring and it works: every item that will be sold more than twice gets built into the system before service, including specials, and the open-item button requires a manager code.

The cover count. This one is nearly universal and it corrupts more numbers than any other single error. Servers are supposed to enter the number of guests on each check. Under load, they don't, or they enter the number of entrées instead, or they enter one.

🧮 Run the Numbers

What a 10-cover undercount does to a Saturday.

Bellwether's biggest night is planned at 123 covers and **\$5,658** of sales (123 × \$46). Suppose the floor enters 113 covers instead of 123 — a routine, unremarkable, entirely accidental 8% undercount on a busy night.

• Reported average check: \$5,658 ÷ 113 = **\$50.07, against a true \$46.00. The PPA is overstated by 8.9%**, and the FOH partner concludes the check-average initiative is working.
• Reported covers per labor hour: understated by the same ten covers — roughly 8.1% low. The chef concludes the kitchen is less productive than it is and adds an hour of prep.
• RevPASH (Chapter 24) moves the wrong way for the same reason.

Notice the cruelty of it: the errors run in opposite directions across the two metrics, so neither number looks obviously broken, and the two managers reading them reach two wrong conclusions that never collide. A single untrained keystroke has quietly falsified both halves of the business.

The cheapest control in this chapter: the POS is configured so a check cannot be tendered without a cover count, and the manager on duty compares the POS cover count to the reservation platform's seated count every night before running the daily sales report. Two minutes. It catches the drift in a week instead of a quarter.

The reopened check and the after-the-fact void. Chapter 34 owns the theft patterns; the technology point here is simply that the POS must record who did it and when, and the record must not be erasable by the person who did it. If a server can void their own closed check without a manager code, you do not have an audit trail. You have a suggestion box.

👨‍🍳 On the Line

Ringing in, correctly, at 7:40 on a Saturday.

Watch a good server enter a four-top at Bellwether's peak. They open the check, enter 4 covers, and select table 12. They ring two Caesars and a bread as course 1, then four entrées as course 2, and they modify the steelhead as no butter, allergy — which routes an allergen flag to the pass screen, not just to the printed ticket. They fire course 1 and hold course 2. They do not fire everything at once, because the hearth queue at 7:40 is eleven items deep against a rate of 28 an hour (Chapter 14), and dumping four more entrées into it now would push table 12's ticket time past 22 minutes and drag the two tables behind it with them.

That is four seconds of extra work per check and it is the entire difference between a system of record and a cash register. The server who skips the cover count, rings the entrées as one course, and writes "no butter" on a chit that stays in their apron has produced a correct check, a correct tender, and a useless record.

Where it actually fails: week three of a new hire, on a night that gets away from them, when the shortcut works fine and nobody says anything. Train the sequence in the certification checklist (Chapter 18), audit ten checks a week, and correct it the first time. It never gets easier to fix later.

The POS is also a legal record

Two obligations, both easy to forget until they are urgent. Your sales-tax filing is built from POS sales data, and sales tax is not your money (Chapter 31). Your tip records — declared tips, charged tips, tip-pool distributions — are wage-and-hour records under the Fair Labor Standards Act, and Chapter 20 explains what depends on them. Retention matters. Before you sign, know how long the vendor keeps your transaction detail at your subscription tier and whether it is longer than the record-retention period your accountant and your attorney require.

26.2 Choosing a POS: cloud vs. legacy, contracts, hardware, and the lock-in question

You will choose a POS once, badly informed, in the middle of a build-out, while three other things are on fire. Here is how to make that choice survivable.

Cloud versus legacy

Legacy (server-based) systems run on a computer in your office. You buy the license outright, you pay an annual support contract, and the system keeps working if the internet dies because it never needed the internet. The costs are capital-heavy, remote visibility is limited or absent, updates are events rather than background processes, and if your office server dies on a Friday you are in real trouble.

Cloud systems run on the vendor's infrastructure and you subscribe. You get remote access — the chef-owner can look at Tuesday's mix from home, which sounds trivial and is not — automatic updates, easier integration with everything else, and a much lower entry cost. You also get a permanent monthly obligation and a dependency on your internet connection.

For a restaurant being built today, cloud is the default and legacy is the exception. But the dependency is real and it has one non-negotiable requirement:

👨‍🍳 On the Line

The night the internet goes down.

It is 6:50 on a Friday. The fiber circuit drops. What happens next is entirely determined by decisions you made months ago.

With no offline capability: the terminals stop. You cannot open a check, cannot fire a ticket, cannot run a card. The KDS is blank. You have 123 covers on the books and a room full of people who ordered forty minutes ago. Bellwether's Saturday is \$5,658 of sales; you have already paid the labor and much of the prep is a write-off, so you are looking at something in the neighborhood of \$4,000 of contribution walking out the door, plus the reviews.

With offline mode and cellular failover: the router switches to LTE inside thirty seconds and most of the room never knows. If the failover also fails, the POS caches orders locally and store-and-forwards the card authorizations when the line comes back — which means you are accepting the risk that some of those cards decline after the guest has gone home.

What the disciplined operator actually has: an LTE failover line at roughly \$40 a month (\$480 a year — the cheapest insurance in the building), offline mode confirmed in writing by the vendor and tested before opening, a stack of paper tickets and a written manual procedure taped inside the office door, a stated cap on the card amount you will accept offline, and a manager who knows to batch and reconcile the next morning rather than hoping.

Compare \$480 a year against \$4,000 on one bad Friday. This is not a close call, and almost nobody does it.

The four clauses that matter

Most of a POS agreement is boilerplate. Four things are not, and they are where the money is.

1. Term and termination. How long are you committed? Twelve, twenty-four, and thirty-six months are all common, and the longer the term the better the headline price. What is the early termination fee — the remainder of the term, a flat amount, or nothing? Does the agreement auto-renew, and how many days before the anniversary must you give notice to stop it? Chapter 8 warned you about auto-renewing contracts generally; this is the one that bites hardest, because the notice window is often 60 or 90 days and it passes silently.

2. Hardware ownership. Are you buying the terminals, leasing them from the POS vendor, or financing them through a third party? The third option is the trap. A separate equipment finance agreement is frequently non-cancellable and independent of the software contract, which means you can fire the POS company and still owe four years of payments on hardware you are no longer using. Read the hardware paperwork as a separate contract, because legally it usually is one. And ask the plain question: if I leave, does this hardware work with anything else?

3. What the subscription actually includes. Per-terminal or per-location? Are handhelds extra? Is the KDS module extra? Online ordering? Loyalty? Reporting beyond the basic set? Is support included, and is it 24/7 — because your emergencies are at 7:30 on a Saturday, not at 10:00 on a Tuesday morning. Get the fully configured monthly number, in writing, for the exact device count you will actually run.

4. Payment processing. Is it bundled, and can it be unbundled? This is the lock-in question and it gets its own section.

The lock-in question

Several modern POS companies make most of their money on payments, not software. That business model produces genuinely attractive software pricing — sometimes startlingly attractive — and it is not inherently a bad deal. It is a bundle, and bundles must be priced as bundles.

⚠️ Where the Money Leaks

The "free" POS.

A vendor offers the software at a steep discount, or free, on the condition that you process payments through them. Do the arithmetic before you feel grateful.

Bellwether's POS software budget is \$4,800 a year**. Its card volume is **\$1,743,750. A processing rate that is 0.28 percentage points higher than the alternative costs \$4,883 a year — more than the entire software subscription it was supposed to save you.

(1,743,750 × 0.0028 = \$4,882.50.)

Twenty-eight basis points is not a large number. It is inside the noise of a sales conversation. It is also, at this volume, the whole giveaway plus a tip.

This does not mean bundled processing is bad. It is often competitive, and the integration is genuinely tighter — one vendor, one settlement, one support call, no gateway fee, and tip adjustments that cannot fall out of sync. What it means is that you cannot evaluate the software price and the processing price separately when they are sold together, and the vendor is counting on you doing exactly that. Ask for both numbers. Add them up. Compare the total against an unbundled POS plus an independently quoted processor, on the same volume, over the same term.

And ask the question that ends the conversation honestly: if I want to change processors in year three without changing my POS, may I? Get the answer in writing.

Real vendors in this category — Toast, Square, Lightspeed, Clover, TouchBistro and others in the cloud tier; Micros and Aloha lineages in the legacy tier — are named here only as examples of the categories. Their pricing, contract terms, and bundles are negotiated, differ by market and by operator, and change. Any number in a book about them would be wrong by the time you read it. Get current written quotes for your own volume, and get at least three.

🧾 Read the Numbers

```text FIGURE 26.2 — "The proposal" [constructed teaching example] THE ARTIFACT A three-page POS proposal for Bellwether, dated ten weeks before opening. Page 1 is the monthly software price. Page 2 is the hardware quote. Page 3 is a separate "Equipment Finance Agreement" with its own signature block. THE CONTEXT Pre-opening. Two other quotes on the desk. The build-out is three weeks late, the hood upgrade ate the contingency, and this vendor's headline monthly price is the lowest of the three.

                 PAGE 1 — SOFTWARE
                   Core POS, per location .................. $ 89 / mo
                   Additional terminals, 4 @ $35 ........... $140 / mo
                   Host stand tablet ....................... $ 35 / mo
                   Handheld devices, 2 @ $30 ............... $ 60 / mo
                   Kitchen display module, 2 screens ....... $ 76 / mo
                   Online ordering module .................. $ 79 / mo
                   Loyalty & gift ......................... included w/ processing
                   24/7 support ............................ included
                   ─────────────────────────────────────────────────────
                   MONTHLY .......................... $479   ANNUAL $5,748
                   Promotional rate, months 1-6 ..... $239   (saves $1,440 yr 1)
                   TERM: 36 months.  Auto-renews 12 mo unless cancelled 90 days out.
                   Early termination: remainder of term, payable on cancellation.

                 PAGE 2 — HARDWARE                          $ 9,250
                 PAGE 3 — EQUIPMENT FINANCE AGREEMENT
                   48 months @ $214/mo .................... $10,272 total
                   "This agreement is non-cancellable and is independent of any
                    software or processing agreement."

                 PROCESSING (verbal, not in the proposal): "about 2.6%, all in."

WHAT IT SHOWS A software price that is competitive on the headline and a total cost of ownership nobody has added up. Over 36 months: software $17,244 less the $1,440 promotion = $15,804, plus $10,272 of financed hardware = $26,076, against $9,250 of hardware bought outright and $17,244 of software = $26,494. The financing looks near-neutral. It is not, because of page 3's last sentence and its 48-month term against a 36-month software term. WHAT IT DOESN'T It does not contain the processing rate at all, which on Bellwether's volume is worth roughly nine times the software line. "About 2.6%, all in" is not a quote; it does not say whether that is flat-rate or a markup over interchange, what the per-transaction fee is, or what monthly fees attach. It does not state the data export format on termination. It does not say whether the hardware runs any other vendor's software (it does not). THE DECISION Do not sign page 3 at all — buy the hardware outright out of the FF&E budget. Send back three written questions before signing pages 1 and 2: the processing quote in interchange-plus form with per-item fees and all monthly charges; the termination data-export clause; and a 24-month term at the 36-month price. Get all three answered in writing or take quote two. THE LESSON The headline monthly price is the smallest number in a POS deal and the only one the salesperson wants to discuss. Price the TERM, the HARDWARE, and the PROCESSING together, or you have not priced it. ```

26.3 The kitchen display system and the death of the paper ticket

A kitchen display system (KDS) is a set of screens that replaces printed kitchen tickets: orders route from the POS to the station that makes them, cooks clear ("bump") items as they are fired and finished, and the system timestamps every step.

Paper tickets are not primitive. They are tactile, they survive a power flicker, cooks can arrange them physically in fire order, and a good expo reads a rail faster than any screen. Plenty of excellent kitchens still run them. But paper has one fatal deficiency for a manager:

A paper ticket produces no record. It is thrown away at the end of the night. There is no timestamp on when it printed, no timestamp on when the food left the pass, and therefore no ticket time — which means Chapter 14's 22-minute not-to-exceed standard is not a standard at all. It is a feeling. You cannot manage to a number you do not have, and the number does not exist unless something records it.

That is the whole case for a KDS, and it is sufficient.

What the screens actually do

FIGURE 26.3 — The pass screen at 8:05 on a Saturday          [the Bellwether plan, modeled]

 ┌─ T12 ───── 8:14 ─┐ ┌─ T7 ────── 6:02 ─┐ ┌─ BAR4 ──── 3:41 ─┐ ┌─ T19 ───── 0:52 ─┐
 │ 4 cov    COURSE 2│ │ 2 cov    COURSE 2│ │ 2 cov    ALL     │ │ 6 cov    COURSE 1│
 │ 2 HEARTH CHICKEN │ │ 1 STEELHEAD      │ │ 2 BURGER   MR    │ │ 3 CAESAR         │
 │ 1 STEELHEAD  *ALG│ │ 1 HEARTH CHICKEN │ │ 1 FRIES          │ │ 2 SQUASH         │
 │ 1 SQUASH         │ │                  │ │                  │ │ 1 BREAD          │
 └──────────────────┘ └──────────────────┘ └──────────────────┘ └──────────────────┘
   * ALG = allergen flag, routed from the server's modifier, not written on a chit

 ALL DAY   hearth chicken 7 · steelhead 4 · burger 5 · squash 6 · caesar 9 · bread 4
 OLDEST TICKET  8:14        NOT-TO-EXCEED  22:00        HEARTH QUEUE  11 items
 HEARTH RATE    28 items/hr  →  11 items is 23 minutes of hearth. Do not fire T19 yet.

Four things on that screen are doing real work, and none of them is available on paper.

The clock on each ticket is the ticket time, running live. The expo does not have to remember which table has been waiting; the screen sorts by age. Chapter 14's standard becomes enforceable in the moment rather than diagnosed afterward.

The all-day line is Chapter 14's "all-day" count, computed continuously instead of shouted. The hearth cook knows there are seven chickens in the building without counting rails.

The allergen flag travels as structured data from the server's modifier to the station, rather than as handwriting on a chit that may or may not be read. Chapter 25 explains why this is a safety control and not a convenience.

The queue against the rate is the sentence that prevents the disaster. Eleven items in the hearth queue against a sustained 28 an hour is 23 minutes of hearth already committed. Firing table 19 now does not make table 19 faster; it makes tables 12 and 7 later. This is the arithmetic Chapter 14 teaches and Chapter 24 monetizes, made visible on a screen at the moment the decision is being taken.

The two ways cooks defeat it, and one way managers do

Early bumping. If ticket time is a number anyone is judged on, the fastest way to improve it is to bump the ticket when the food is plated rather than when it is actually running. Or when it is nearly plated. Or when it is going to be plated shortly. The metric becomes the target and stops measuring anything. The countermeasure is not a policy, it is a pairing: watch ticket time next to guest complaints about cold food and next to the runner's actual pickup, and audit by standing at the pass for two services a month. If the screen says 14 minutes and the food is sitting under a lamp for four of them, your real ticket time is 18.

Screen overload. A screen showing sixteen tickets is showing none of them. Configure the display so the station sees what the station cooks, cap what is visible, and put the overflow count in a corner. A cook who has to scroll during a rush will stop looking.

And the manager's failure mode: installing a KDS and then never opening the ticket-time report. The screen is a data-collection device. If nobody reads the data on Monday, you have bought an expensive way to print tickets electronically.

The fallback

Screens fail. Controllers overheat in a kitchen — they are sitting in a hot, greasy room and they are not built for it. Keep one impact printer alive as a fallback, keep paper in it, and write the manual procedure down. Bellwether's hardware budget carries two kitchen and bar printers for exactly this reason. A KDS with no fallback is a single point of failure standing between 123 guests and their dinner.

🔍 Check Your Understanding

1. A restaurant runs paper tickets and its chef says ticket times are "usually about fifteen minutes." What, specifically, is wrong with that sentence?
2. Why does an allergen modifier entered in the POS represent a food-safety control rather than a convenience?
3. The pass screen shows an eleven-item hearth queue against a 28-item hourly rate. A six-top's entrées are waiting to be fired. What does the expo do, and what would firing them now actually accomplish?

(1: It is not a measurement — nothing recorded it, so it is a recollection weighted toward recent and memorable tickets, and it cannot be trended, compared by night, or audited. 2: Because it travels as structured data to the station that plates the dish, is visible to every cook who touches it, and is recorded — rather than depending on one person's handwriting and one person's reading of it. 3: Hold. Firing now adds items to a queue that is already 23 minutes deep; it delays tables 12 and 7 without advancing the six-top, because the constraint is the hearth's rate, not the fire order.)

26.4 Inventory, scheduling, and accounting software — and whether they talk to each other

Three more systems, one question. The question is not "is this software good." It is "where does its data come from, and where does its answer go?"

Inventory management software

Inventory management software maintains item and recipe records, imports vendor invoices, holds count sheets in shelf-to-sheet order, and computes usage, theoretical cost, and variance. It is what makes Chapter 13's weekly count survivable and Chapter 11's cost cards maintainable when a protein price moves.

The value is not glamorous and it is entirely real:

🧮 Run the Numbers

What the inventory subscription actually buys.

Bellwether's weekly count, done manually: two people with clipboards for 2.5 hours each in the walk-in, the dry storage, and the bar, plus roughly 1.5 hours of the chef entering numbers into a spreadsheet and chasing formula errors. Call it 6.5 hours a week.

With count sheets on a tablet in shelf-to-sheet order and vendor invoices importing automatically: two people at 1.5 hours each, plus 15 minutes of review. Call it 3.25 hours a week.

• Saved: 3.25 hours × 52 weeks = 169 hours a year
• At a blended loaded cost of \$24/hour (a mix of chef and sous time): **\$4,056**
• Less the subscription: \$4,056 − \$2,400 = \$1,656 of net saving

But the \$1,656 is not the point, and you should not sell it to yourself that way. The point is that a count taking 6.5 hours gets skipped — first when someone calls out, then when it is a busy week, then most weeks. A count taking 3.25 hours happens. And a skipped count is precisely Chapter 1's counting problem, which is the single most expensive habit in this industry.

What the software cannot do: it cannot count. If the count is sloppy — a case counted as a case when it is two-thirds full, a bar bottle eyeballed instead of weighed — the software will produce a confident, precise, beautifully formatted wrong answer faster. Chapter 13's discipline is unchanged. The software removes the excuse, not the work.

Scheduling and payroll software

Scheduling software builds shifts against a forecast, publishes to staff phones, manages availability and swaps, tracks the time clock, and warns on approaching overtime. Chapter 19's staffing guide is what it should be built from, and Chapter 20's compliance obligations — break tracking, overtime, and predictive-scheduling rules where they exist — are what it should be protecting you against.

Its usefulness depends on one thing: does it receive sales history from the POS? A scheduling system that knows last year's Tuesday-in-February by hour writes a different schedule from one that starts blank every week. Sales per labor hour (Chapter 19) requires sales by hour and labor by hour in the same place. If they live in two systems, someone builds that report by hand, which means it gets built for three weeks and then does not.

Accounting software

General-purpose accounting software with a foodservice chart of accounts (Chapter 31) is the standard answer for an independent. What matters operationally is the daily sales report (DSR) — the day's sales by category, tenders, tips, comps, voids, taxes, and deposits — moving from the POS into the books as a journal entry. Done natively, it is automatic and reconciles itself. Done by hand, it is fifteen minutes of somebody's morning, every morning.

The boundaries, priced

Every place two systems fail to talk is a place a human moves numbers. That human is not free.

FIGURE 26.4 — What an un-integrated boundary costs, a year        [the Bellwether plan, modeled]

  boundary                          the manual work         hrs/yr   loaded    cost
  ────────────────────────────────────────────────────────────────────────────────────
  POS ──▶ accounting (DSR entry)    15 min/day, 364 days      91.0   $25/hr   $2,275
  POS ──▶ scheduling (sales fcst)   30 min/week               26.0   $32/hr     $832
  time clock ──▶ payroll            45 min/pay period (26)    19.5   $32/hr     $624
  invoices ──▶ inventory            60 min/week               52.0   $32/hr   $1,664
  inventory ──▶ recipe costing      45 min/week               39.0   $32/hr   $1,248
  ────────────────────────────────────────────────────────────────────────────────────
  TOTAL                                                      227.5            $6,643

  227.5 hours is five and a half full working weeks a year, spent moving numbers
  between systems that could have moved themselves — and every one of those hours
  is a chance to transpose a digit that nothing downstream will catch.

\$6,643 is more than twice the inventory subscription and more than the POS subscription. It never appears on the P&L as technology cost. It appears as labor, which is why nobody attributes it to the software decision that caused it.

And now the honest limit, because this is the part the vendors leave out. Integration is not free either, and it is not permanent:

• Certified integrations frequently carry their own monthly fee — on both sides.
• They break. When either vendor ships an update, the connection can fail.
• They break silently. A nightly sync that stops running does not send anyone a text. It simply stops, and the first person to notice is whoever wonders in five weeks why the food cost report looks stale. A broken integration nobody monitors is genuinely worse than a manual process, because a manual process fails loudly the day the person doing it is on vacation.

The countermeasure is a two-minute item on the Monday checklist: does the number in system B match the number in system A for last Friday? If it doesn't, you found it in three days rather than five weeks.

26.5 Reservations, waitlist, and guest data

A reservation platform manages bookings, waitlists, table assignments, service pacing, guest records, and confirmations. It is where Chapter 22's host stand actually operates and where Chapter 24's revenue management is enforced.

It is how the caps become real

Chapter 22 set Bellwether's pacing discipline: a peak-hour cap of 32 covers and a quarter-hour cap of 8. Those numbers exist because the hearth sustains 28 items an hour (Chapter 14) and a room that seats faster than the kitchen can cook produces a 40-minute ticket time and a dining room full of people looking at the door.

Here is the thing about those caps: a host cannot enforce them by hand. Not at 6:50 on a Saturday with a phone ringing, a walk-in party of five at the stand, and a two-top being seated. Enforcing a quarter-hour cap by hand means tracking rolling arrival counts in fifteen-minute buckets across a five-hour service while doing three other things. Nobody does that reliably, which is why unpaced rooms are the norm and why the first Friday of a new restaurant so often falls apart at 7:15.

A reservation platform enforces it structurally: the slot simply does not appear as available once the cap is reached, whether the booking is coming from the phone, your website, or the platform's app. The technology is not what creates the pacing discipline — Chapter 22 does that. The technology is what makes it survive contact with a Saturday.

The guest record

The second job is memory. Allergies and dietary restrictions. Seating preferences. Visit history. Occasions. Previous no-shows. Notes from the last visit, entered by the manager who took the table touch (Chapter 23).

Two cautions, and they run in opposite directions.

🤝 Hospitality

Remembering, without being unsettling.

Guest data enables the single most powerful move in hospitality: being known. The guest who is greeted with "welcome back — we have you at the corner two-top again, and I've noted the shellfish allergy" has been given something that costs nothing and cannot be copied by a competitor. Chapter 23 explains why the second visit is where the profitability actually is; the guest record is the mechanism.

But there is a line, and the platform will happily let you cross it. A note that says "prefers the corner, drinks Sancerre, celebrating an anniversary in October" is hospitality. A note that catalogues a guest's appearance, their companions, their spending relative to other guests, or a personal detail they did not offer you is surveillance, and a guest who ever sees the screen will feel it as such.

The test that has never failed me: would you be comfortable if this guest read this note over your shoulder? If not, do not write it. Train it in onboarding, audit it occasionally, and delete what fails the test. The guest record is a hospitality instrument that is one careless entry away from being a liability.

Marketplace bookings and the incrementality question

Some reservation platforms are also consumer-facing marketplaces: diners browse the app, find you, and book. That is genuinely an acquisition channel, and it is not free — historically these platforms have charged per-cover fees on bookings that originate in their marketplace, alongside or instead of a flat subscription. Pricing models vary by platform and by market, they are negotiated, and they change; this book will not quote a number that will be wrong next year.

What the book will tell you is the question to ask, and it is the same question Chapter 28 asks about delivery marketplaces: is this cover incremental? If a guest who was already going to book you directly instead books through the marketplace, you have paid a fee to acquire a guest you already had. If the guest genuinely discovered you in the app, the fee bought you something.

You can partially answer this. Bookings that come through your own website, your Google Business Profile (Chapter 27), and the phone are your channel and cost you nothing per cover. Watch the mix month over month. If the marketplace share rises while total covers stay flat, you are converting free bookings into paid ones, and the platform's marketing is working on your existing guests rather than on new ones. That is worth a conversation about which placements you pay for.

Real platforms in this category — OpenTable, Resy, Tock, SevenRooms and others — differ substantially in whether they are primarily a marketplace, primarily an operations tool, or primarily a prepaid ticketing system. Named here as categories only; get current quotes.

Who owns the guest record?

This is the question in this section, and almost nobody asks it before signing.

If you leave the platform in year three, do you get your guest list — names, contact details, visit history, notes, allergies — in a usable, importable format? Or do you get a PDF, or nothing? The answer belongs in the contract, before you sign, not in a support ticket after you have given notice. §26.8 gives you the language to ask for.

26.6 Online ordering: first-party vs. marketplace, and who owns the guest

Two structurally different things wear the same name.

First-party ordering is a guest ordering from your website or your app. Your menu, your prices, your photographs, your confirmation email. You pay a software fee and payment processing. You learn the guest's name, email, phone, and order history, and you may market to them (subject to the consent rules — Chapter 27 covers email and SMS lists properly).

Marketplace ordering is a guest ordering from a third-party app that lists many restaurants. Their menu presentation, their promotions, their driver, their customer service, their guest. You pay a commission. Chapter 28 owns the economics of that channel — commission structures, incrementality, menu strategy, packaging, price parity, refunds, and the commission-cap ordinances several cities passed after 2020 — and this chapter will not duplicate it.

What belongs here is the structural difference, which is not primarily about the fee.

FIGURE 26.5 — The same $52 order, two channels                 [constructed teaching example]

                        FIRST PARTY                    MARKETPLACE
  ────────────────────────────────────────────────────────────────────────────
  who found the guest   you did (or they knew you)     the app did
  menu shown            yours                          theirs, reformatted
  price shown           yours                          often marked up
  cost to you           platform fee + processing      a commission — see Ch. 28
  guest name            yours                          usually not usable
  guest email/phone     yours                          usually not
  order history         yours                          theirs
  who fixes a mistake   you do, directly               their support, then you
  who owns the second   ────────────────────────────────────────────────
    visit               YOU                            THE PLATFORM
  ────────────────────────────────────────────────────────────────────────────

That last row is the whole chapter compressed. Chapter 23 established that the second visit is where restaurant profitability actually lives. On a marketplace order you do not acquire a guest. You rent a transaction, and the relationship — the name, the address, the email, the reason to come back — belongs to someone else. That may still be a perfectly good trade, because the marketplace brings demand your website does not. It is simply a different trade from the one most operators think they are making.

What first-party costs, honestly

First-party is not free, and its costs are shaped differently from a commission: a fixed platform fee plus per-transaction processing. Fixed costs are brutal at low volume and cheap at high volume, which is exactly backwards from a commission.

🧮 Run the Numbers

First-party ordering at Bellwether's takeout volume.

The plan carries takeout at \$600 a week — \$31,200 a year (Chapter 28 owns that forecast), which is roughly 693 orders at about \$45.

Takeout sales	\$31,200
Sales tax collected (illustrative 7%)	\$2,184
Tips on takeout (illustrative 8%)	\$2,496
Card volume through the channel	\$35,880
Processing at a card-not-present blend (≈2.69% + \$0.23/order) | \$1,125
Online ordering platform fee	\$1,800
All-in channel technology cost	\$2,925
As a percentage of takeout sales	9.4%

Nine and a half points. That is not nothing, and an operator who assumed "first-party is basically free" has just been corrected.

Now watch the fixed cost do its work. Run the same math at \$100,000 of annual takeout: processing of about \$3,317 plus the same \$1,800 platform fee is \$5,117 — 5.1% of channel sales. The rate nearly halved without a single negotiation, because the platform fee did not move.

The lesson is about shape, not level. A commission is a variable cost: it is the same percentage at \$31,200 and at \$100,000. A first-party platform fee is a fixed cost: it gets cheaper per dollar the more you sell through it. Which means the honest question is not "which is cheaper today" but "which channel am I building?" — and that question is Chapter 28's to answer.

(A note on precision: card-not-present transactions carry roughly half a point more interchange than card-present. Bellwether's master processing model in §26.7 blends everything at the card-present rate, which understates the total by about \$179 a year at this volume. Disclosed rather than hidden, because for an off-premise-heavy operation that simplification would be material.)

The one thing that is genuinely free

Your Google Business Profile, your website's menu, and your hours. Chapter 27 covers this as marketing; the technology point is narrow and worth stating: an out-of-date menu or the wrong hours on the internet costs you covers every week and costs nothing to fix. Assign it to one person and put it on a monthly checklist.

26.7 Payments: processing, interchange, surcharging, tipping screens, and the fee line

This is the section that pays for the chapter.

Payment processing is the service that authorizes a card at the terminal, settles the transaction, and deposits money in your account. Interchange is the largest component of what it costs you: a fee, set by the card networks and published in their rate schedules, that is paid to the bank that issued the guest's card.

At Bellwether's volume, processing will cost roughly \$43,573 a year. That is more than the POS subscription, the KDS, the reservation platform, the scheduling software, the inventory software, the accounting software, the online ordering module, the internet, the website, the cameras, and the hardware reserve — combined, and then some. It is the fourth-largest single line in this restaurant's entire other-operating budget. And it is the one operators examine least, because it never arrives as a bill. It is deducted before the deposit lands.

First: the base is bigger than you think

Every operator who has ever estimated their processing cost has estimated it as a percentage of sales. That is the wrong base, and the error runs in the expensive direction.

🧮 Run the Numbers

Building Bellwether's card volume from the top.

Net sales, year 1	\$1,550,000
Share paid by card (illustrative 90%; cash, checks for events, gift-card redemptions make up the rest)	\$1,395,000
plus sales tax collected on those sales (illustrative 7%)	\$97,650
plus tips added on card (illustrative 18% of card sales)	\$251,100
TOTAL CARD VOLUME PROCESSED	\$1,743,750

The processor charges you on \$1,743,750**, not on \$1,395,000 and certainly not on \$1,550,000. The volume you pay fees on is 1.25 times the card sales you actually made**, because the card also carried the sales tax you are holding for the state and the tip you are holding for your staff.

At Bellwether's effective rate, the fees charged on that pass-through money come to \$8,715 a year — exactly one dollar in five of the entire processing bill. You are paying roughly \$8,700 annually for the privilege of collecting other people's money and handing it over.

This is not a scandal and there is no trick to avoid it — the network charges on the transaction amount, and the transaction amount includes the tax and the tip. It is simply a fact that almost no operator has ever computed, and it is why the "2.5%" in your head is never the number on your P&L.

Where the money actually goes

Three parties are paid on every card transaction, and understanding who gets what is the difference between negotiating effectively and negotiating theatrically.

• The issuing bank — the guest's bank — receives interchange. This is the largest share by far. Interchange is set by the card networks, published in rate schedules that run to dozens of pages, and revised periodically (commonly twice a year). Your processor does not keep it and cannot discount it.
• The card network — Visa, Mastercard, Discover, American Express — receives assessments, also called dues and network fees. Small, non-negotiable.
• Your processor / acquirer receives its markup plus whatever monthly fees it charges. This is the only piece that is actually negotiable.

FIGURE 26.6 — Where a processing dollar goes                     [the Bellwether plan, modeled]

  INTERCHANGE ── to the bank that issued the guest's card
    ████████████████████████████████████████████████████████    $31,905    73.2%
  ASSESSMENTS ── to the card network
    █████                                                        $2,954     6.8%
  PROCESSOR ── markup plus monthly fees; the name on your statement
    ███████████████                                              $8,713    20.0%
  ─────────────────────────────────────────────────────────────────────────────
  TOTAL ANNUAL PROCESSING COST                                  $43,573   100.0%

  The company whose logo is on your merchant statement keeps twenty cents of every
  dollar you pay it. The other eighty it collects and passes on. That is why
  "shopping processors" has a ceiling — and why CARD MIX and PRICING MODEL move
  more money than any sales call ever will.

Interchange itself varies enormously by card type, and this is the part operators find genuinely surprising: your effective rate is substantially determined by which cards your guests happen to carry, and you do not control that at all.

(Illustrative only. Interchange schedules are published by the networks, are far more granular than this, differ by merchant category, and change. Use this table to understand the shape of the problem, never as a quote.)

Look at the rewards row. A guest paying with a card that earns them airline miles costs you materially more than a guest paying with a plain debit card, and the difference is the miles. The rewards program on your guest's card is partially funded by your food cost. There is nothing you can do about it, and it is worth knowing when someone tells you your rate is high.

The three pricing models

How your processor bills you matters as much as who you choose. There are three structures.

Flat rate. One posted rate for everything, e.g. "2.6% + 10¢, card present." Simple, predictable, usually no monthly fees, no statement to decode. The processor absorbs the mix risk — and prices for it. Excellent for low volume and for small formats; increasingly expensive as you grow.

Interchange-plus (cost-plus). Interchange and assessments are passed through at cost, and the processor adds a disclosed markup: "interchange + 0.35% + 10¢." The most transparent structure and almost always the cheapest at meaningful volume, because you capture the benefit of every low-cost debit transaction instead of the processor capturing it. This is what you should ask every quote to be restated in.

Tiered (bundled). Transactions are sorted into "qualified," "mid-qualified," and "non-qualified" buckets at three different rates. The buckets are defined by the processor, not by the networks. This is the least transparent model and the one where downgrades disappear — and a full-service restaurant generates more downgrades than most businesses, which we will get to.

FIGURE 26.7 — The identical volume, priced three ways         [the Bellwether plan, modeled]
                          $1,743,750 of card volume · 17,100 transactions

  FLAT RATE          2.60% + $0.10, no monthly fees
    45,337.50 + 1,710.00 ...................... $47,048     effective 2.70%
  INTERCHANGE-PLUS   interchange + 0.35% + $0.10, $75/mo
    31,905.34 + 2,954.25 + 7,813.13 + 900.00 .. $43,573     effective 2.50%
  TIERED             1.85%/2.65%/3.45% at a 45/30/25 mix, $75/mo
    15,286.22 + 14,632.31 + 15,894.84 + 900 ... $46,713     effective 2.68%
  ────────────────────────────────────────────────────────────────────────────
  SPREAD, best to worst ......................... $3,475 a year

  Same restaurant. Same guests. Same cards. Same terminals. Different contract.

  Note the honest caveat: flat rate carries NO monthly fees and NO downgrade risk,
  and below roughly $30,000-$40,000 a month of card volume its simplicity usually
  wins outright. Bellwether runs $145,313 a month. Above that line, interchange-plus.

Downgrades, and why restaurants get more of them

A downgrade is a transaction that fails to qualify for the interchange category it should have earned and is billed at a worse one. Restaurants — full-service restaurants especially — generate downgrades in ways a retail shop does not.

⚠️ Where the Money Leaks

The tip adjust and the unclosed batch.

Two operational habits, both invisible, both costing real money every week.

1. The tip adjust. In full service, the card is authorized for the check amount and the tip is added afterward, when the guest signs. The settled amount is therefore larger than the authorized amount. Card networks tolerate this for restaurants — it is why the restaurant merchant category exists — but the tolerance has limits, and transactions settled well above their authorization, or settled late, can drop to a worse interchange category. Modern processors handle this well when the POS integration is correct. When the integration is not correct, or when tips are being adjusted two days later, you pay for it silently.

2. The unclosed batch. Transactions must be settled — "batched out" — promptly, typically within 24 hours of authorization. A closing manager who forgets to batch, or a system set to batch manually that nobody checked, produces a day of transactions settled late. Late settlement is a classic downgrade trigger, and it is caused entirely by a checklist item nobody performs.

What it costs, in round terms: suppose 4% of Bellwether's volume downgrades by an average of 0.60 points. That is \$1,743,750 × 4% × 0.60% = **\$419 a year** — small, and worth having, and it compounds if the habit is systemic rather than occasional. On a restaurant three times this size with a genuinely broken tip-adjust workflow, the same arithmetic runs into four figures.

What the disciplined operator does: confirm the batch closes automatically every night at a set time; put "batch closed" on the closing checklist as a verified item, not an assumed one; adjust tips the same night, never the next week; and ask the processor once a year for the interchange category detail — the pages that show what actually qualified — rather than the summary page.

Reading the statement

Almost no operator can read a merchant processing statement. They are designed by people who are not trying to make it easy, they arrive as a PDF nobody opens, and the money has already been taken. Here is one, read properly.

🧾 Read the Numbers

```text FIGURE 26.8 — "The merchant statement" [the Bellwether plan, modeled] THE ARTIFACT A monthly merchant processing statement, October, page 1 of 7. Pages 2-7 are the interchange category detail and are rarely opened. THE CONTEXT Bellwether, modeled year 1. A strong month: patio still open, two private events, one week of unusually good weather. Interchange-plus pricing.

                 SUMMARY
                   Gross card volume ......................... $158,400.00
                   Transactions ..................................... 1,545
                   Average transaction .............................. $102.52

                 FEES
                   Interchange (passed through) ............... $2,897.25
                     - percentage component ......... $2,713.39
                     - per-item component ............. $183.86
                   Assessments / network dues ................... $268.11
                   Processor discount (0.35% + $0.10) ........... $708.90
                   Monthly service / statement fee ............... $15.00
                   PCI compliance program fee .................... $19.95
                   Gateway / software fee ........................ $40.05
                   Chargeback fee (1) ............................ $25.00
                   ────────────────────────────────────────────────────────
                   TOTAL FEES .................................. $3,974.26
                   EFFECTIVE RATE (fees / gross volume) ............ 2.51%
                   NET DEPOSITED .............................. $154,425.74

WHAT IT SHOWS A correctly priced, correctly billed interchange-plus statement with no junk on it. The 2.51% effective rate is real and competitive. Interchange is $2,897.25 of the $3,974.26 - 73% of the bill goes to card-issuing banks and cannot be negotiated with anyone on this statement. WHAT IT DOESN'T Three things, all of them expensive. (a) THE BASE. That $158,400 is not sales. It is $126,720 of net sales plus $8,870 of sales tax plus $22,810 of tips. Against the restaurant's own October card sales the same fees are 3.14%; against October's total net sales including cash, 2.82%. The P&L will show 2.82%, not 2.51%, and the operator who budgeted "about two and a half" is short every month. (b) WHAT DOWNGRADED. Page 1 shows one interchange total. Pages 2-7 show the categories. Without them you cannot tell whether tip adjustments or late batches are costing you, and the summary will never reveal it. (c) WHAT THE $40.05 IS. "Gateway / software fee" is the least examined line on any merchant statement. It may be a real service. It may be a legacy charge for a gateway you stopped using when the POS changed. THE DECISION Four things, this week. Request the interchange category detail for the last three months and read it. Ask, in writing, what the gateway fee buys and whether it is removable. Verify the batch closed every night in October. Then send this exact statement to two competing processors and ask them to quote interchange-plus against it - not against a hypothetical, against this. THE LESSON The effective rate is the only number that matters, you compute it yourself, and you compute it TWICE: total fees over card volume, which is what the processor is selling you, and total fees over your own net sales, which is what lands on your profit-and-loss statement. They are never the same number. ```

The formula, because you will use it monthly:

$$\text{Effective rate} = \frac{\text{total fees for the period}}{\text{total card volume for the period}}$$

And its more useful sibling, the one that goes on the P&L:

$$\text{Processing as \% of sales} = \frac{\text{total fees for the period}}{\text{total net sales for the period}}$$

For Bellwether, over a full year, those two numbers are 2.50% and 2.81%. Both are correct. Budget the first one and you are short \$4,823 for the year.

What a point is worth

Because the volume is large, small rate movements are large dollars. Keep this scale in your head.

FIGURE 26.9 — What a basis point is worth at Bellwether       [the Bellwether plan, modeled]
                                     on $1,743,750 of annual card volume

   0.10 points off the effective rate .......  $1,744 / yr   ≈ the website + cameras
   0.25 points .............................   $4,359 / yr   ≈ the whole POS subscription
   0.50 points .............................   $8,719 / yr   ≈ POS + KDS + ordering + accounting
   1.00 point ..............................  $17,438 / yr   ≈ 379 dinner covers
                                                              ≈ three full Saturday nights

Three Saturdays. That is what one percentage point of processing rate is worth at this restaurant, and it is why the annual re-quote is not optional.

The bar: small tickets are expensive tickets

Per-transaction fees do not care how big the transaction is, which makes small tickets structurally expensive.

⚠️ Where the Money Leaks

The single-drink card swipe.

A guest at Bellwether's bar orders one \$9 cocktail and pays for it with a card. With tax and tip the transaction is about \$11.25. At the blended rates above — roughly 2.20% plus about \$0.25 of combined per-item fees — that transaction costs about \$0.50 to process. On a \$9 sale, that is 5.5% — nearly double the house average of 2.81%.

The same guest, running a tab and closing four drinks at once: a \$45.00 transaction costing about **\$1.24 — 3.4%** of the \$36 of sales. Four separate swipes would have cost \$1.99.

Roughly \$0.75 per guest, and it is free to capture. Bartenders open tabs, not tickets — which they should be doing anyway for Chapter 15's pour-cost control and Chapter 34's audit trail. Card minimums are permitted for credit cards under federal law up to \$10, but they read as ungenerous in a bar and I would not use one; the tab habit gets you the same money without the friction.

The same arithmetic is why quick-service and coffee operations feel processing so much more acutely than a \$46-check dining room does. If your average ticket is \$6, the per-item fee alone is a meaningful percentage of the sale before any rate applies.

Surcharging, cash discounting, and the fee line

You will be pitched a program that "eliminates your processing costs" by passing them to the guest. Understand what is actually being proposed, because it is heavily regulated and it is a hospitality decision before it is a finance decision.

Surcharging adds a fee to credit-card transactions. It is subject to card-network rules that cap the surcharge, require advance notice to the networks and your acquirer, require clear disclosure at the entrance and at the point of sale, require the surcharge to appear as a separate line on the receipt, and — importantly — prohibit surcharging debit cards entirely, whether run as debit or credit. The cap has changed over time and currently sits at 3% for the major networks; verify the current rule with your acquirer rather than with a book.

Cash discounting is structurally different: you post the card price and offer a discount for cash. The federal law that regulates debit interchange expressly preserves merchants' ability to offer discounts for cash and for different payment methods. Some programs marketed as "cash discounting" are in fact surcharging with the labels swapped, which is a compliance problem wearing a costume.

⚖️ Code and Compliance

Four bodies of rule sit on top of the payment terminal.

Surcharging law varies by state, and this is genuinely a state-by-state question. Several states have restricted or prohibited credit-card surcharges, some of those restrictions have been litigated, and others regulate exactly how the price must be disclosed. Card-network rules apply on top of state law, and the two are not the same. Verify locally, with an attorney, before you turn a surcharge on.

PCI DSS — the Payment Card Industry Data Security Standard — is a contractual obligation you accept in your merchant agreement, not a statute. Practically it means: complete the annual self-assessment questionnaire, run the scans if your setup requires them, do not store card numbers anywhere (including on paper in a drawer), keep the payment network separate from the guest Wi-Fi, and change default passwords. Most processors charge a monthly PCI program fee and a non-compliance fee if you never complete the questionnaire — a fee that is pure waste and appears on thousands of statements. Beyond the fee: a card-data breach at a small restaurant is a genuinely business-threatening event, and Chapter 8's cyber-liability coverage exists for it.

The EMV liability shift (United States, October 2015) moved liability for certain counterfeit-card fraud to whichever party has the less secure technology. If you accept a counterfeit chip card by swiping the magnetic stripe, the loss is likely yours. Use the chip reader; use contactless.

Tip records are wage-and-hour records. Charged tips, declared tips, and tip-pool distributions come out of the POS and are governed by the Fair Labor Standards Act and by state law. Chapter 20 owns the substance. The technology point: configure it correctly at setup, because reconstructing tip records after the fact is close to impossible.

All of this varies by jurisdiction and changes. Verify with an attorney and your processor before you rely on any of it.

Tipping screens

The tip prompt on your terminal is a design decision with revenue and reputational consequences, and it is now genuinely contested territory with guests.

The mechanical choices: whether to prompt at all; whether to offer percentage buttons or dollar buttons; what three defaults to show; whether the percentages compute on the pre-tax subtotal or the post-tax total; and how prominent the "no tip" or "custom" option is. Every one of these moves the average tip, and operators broadly report meaningful swings from changing them. Give ranges, not promises — no honest number exists that transfers across concepts.

Three positions worth holding:

• Compute suggested percentages on the pre-tax subtotal. Prompting a percentage of a total that includes sales tax means suggesting the guest tip on the state's money. It is a small thing that reads badly when a guest notices, and guests do notice.
• Do not hide the no-tip path. A tip prompt that requires a guest to hunt for the exit is a hospitality failure that buys you a few dollars and costs you a review.
• Do not aggressively prompt in contexts where the guest received no service. The public backlash against tip prompts on counter transactions is real, well documented, and has made guests warier in every context. Whatever you gain by prompting a takeout customer who stood at your counter for ninety seconds, you lose somewhere less visible.

One arithmetic note that connects back: tips increase your processing cost, because the fee is charged on the settled amount. That is not an argument against tipping and it is emphatically not an argument for shorting anyone; it is simply a line in the \$8,715 computed above, and Chapter 20 governs everything about how tips are handled once collected.

Settlement, funding, and cash

Two mechanics that belong to Chapter 33 but originate here.

Gross versus net settlement. Under net settlement the processor deducts fees from each deposit, so the money that arrives is already reduced — convenient, and it makes the fee effectively invisible and reconciliation harder. Under gross settlement the full amount is deposited and fees are debited once monthly — one lumpy cash event, and a number you cannot help but see. Ask for gross settlement if it is offered. A cost you look at once a month is a cost you manage.

Funding time. Card batches typically fund the next business day. A Saturday night's batch closing at 11:40 p.m. is generally not cash on Sunday, and depending on the processor and your bank it may not be cash until Tuesday. Chapter 33's timing calendar has to account for that, particularly around holidays. And be aware that processors may delay funding or hold back a portion of settlements as their own risk management, especially for a new merchant selling gift cards and taking deposits — ask about that policy before you sign, not after your first busy week.

26.8 Integration, data ownership, and what happens when you switch vendors

Integration is the general term for two software systems exchanging data automatically. The mechanism usually named is an API — an application programming interface, which is simply a published set of rules by which one program asks another for data and receives it in a predictable form. You will never touch one. What you need to know is that when a vendor says "we integrate with that," the word covers about five very different things.

FIGURE 26.10 — The integration ladder                          [constructed teaching example]

  RUNG 5  NATIVE           one vendor, one database, nothing between the modules.
          ───────────────  COST: you are married to that vendor's weakest module.

  RUNG 4  CERTIFIED        two vendors, a supported connection, a joint support path.
          INTEGRATION      COST: often a monthly fee; can break on either side's update.

  RUNG 3  SCHEDULED        a nightly file lands somewhere and is imported automatically.
          FILE EXCHANGE    COST: silent failure. Nobody is notified when it stops.

  RUNG 2  MANUAL EXPORT    a person downloads a report and uploads it somewhere else.
          ───────────────  COST: 10-40 minutes a day, every day, forever.

  RUNG 1  RE-KEYING        a person reads one screen and types the numbers into another.
          ───────────────  COST: the 227 hours in Figure 26.4, plus transcription errors
                                 that nothing downstream will catch.

  RUNG 0  NOTHING          the number is simply never produced.
          ───────────────  COST: you manage without it. This is the most expensive rung
                                 on the ladder, and it is where most restaurants live.

When a vendor says "we integrate," ask which rung, ask what it costs on both sides, ask what happens when it breaks, and ask for the name of one operator running that exact pairing who will take your call. That last request is the most informative question in the entire evaluation, and a vendor who cannot answer it has told you something.

Data ownership

Here is the question that ought to be asked on the first sales call and is almost never asked at all: if I leave, what do I get, in what format, and how fast?

The data that matters:

Ask for a contract clause that guarantees, on termination for any reason, a complete export of your transaction, guest, employee, and configuration data in a standard machine-readable format, within a stated number of days, at no charge or at a stated charge. Vendors will often agree to some version of this if you ask before you sign, and will very rarely help you after you have given notice. If the answer is "you can print reports," treat that as the answer to a different question.

Note also that guest data is personal data, that privacy law increasingly regulates it, and that a vendor holding your guest list is holding an obligation as well as an asset. Chapter 27 covers consent for marketing use; the ownership point stands on its own.

What switching actually costs

Before you sign a contract, compute what it will cost to undo. This is the single most clarifying exercise in the chapter.

🧮 Run the Numbers

What it costs Bellwether to change POS systems in year three.

Component	Basis	Cost
Menu, modifier, and system rebuild; configuration; testing	64 hours × \$34 loaded | \$2,176
Staff retraining, 20 POS users	40 hours × \$22 loaded | \$880
Vendor-specific hardware that does not transfer	4 terminals, 2 handhelds, 2 KDS screens, printers, drawers, host tablet	\$9,250
Two weeks of slower service during cutover	~28 covers at \$46 | \$1,288
One month of overlapping subscriptions		\$700
TOTAL		\$14,294

\$14,294 — very nearly three years of the \$4,800 subscription you were trying to escape. Plus three weeks of the general manager's attention during which nothing else improves.

Now hold that number next to a routine event: your vendor raises the subscription 15% at renewal. That is \$720 a year. Your practical alternative costs \$14,294 up front. You will pay the \$720. Everyone does. That is what lock-in is — not a clause in a contract, but an arithmetic that makes leaving irrational long before it makes staying pleasant.

The vendor knows this number too. Which is exactly why the leverage you have is all before the signature, and none of it after. Negotiate the renewal terms, the data export, and the hardware ownership at the beginning, when you are the one who can walk away.

Two structural mitigations worth building in from the start. Prefer non-proprietary hardware where the choice exists — a printer or a tablet that works with more than one system is worth a premium. And export your own data on a schedule, quarterly, into files you keep. It is an hour a quarter and it converts the export clause from a promise into a possession.

26.9 What the stack costs, all in, as a percentage of sales

Now we add it up. Here is Bellwether's complete technology budget for year one.

FIGURE 26.11 — The Bellwether stack, and which way the data moves      [the Bellwether plan]

                                  GUEST-FACING
   ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
   │ RESERVATION  │  │ FIRST-PARTY  │  │ THIRD-PARTY  │  │  GIFT CARD   │
   │  & WAITLIST  │  │   ORDERING   │  │ MARKETPLACE  │  │  & LOYALTY   │
   │  §26.5       │  │   §26.6      │  │   (Ch. 28)   │  │              │
   └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
          │ covers,         │ orders +        │ orders,         │ balances,
          │ guest notes     │ GUEST DATA      │ NO guest data   │ visit history
          ▼                 ▼                 ▼                 ▼
   ╔═════════════════════════════════════════════════════════════════════╗
   ║                  P O S   —   T H E   S Y S T E M   O F   R E C O R D ║
   ║    items · covers · timestamps · server ID · voids & comps · tenders ║
   ╚═══╤════════════╤═════════════╤═════════════╤══════════════╤═════════╝
       │            │             │             │              │
       ▼            ▼             ▼             ▼              ▼
  ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌───────────┐ ┌──────────────┐
  │   KDS   │ │ PAYMENT  │ │ INVENTORY │ │ SCHEDULING│ │  ACCOUNTING  │
  │ ticket  │ │PROCESSING│ │ & RECIPE  │ │ & PAYROLL │ │  DSR ──▶     │
  │  times  │ │ + gateway│ │  COSTING  │ │ time clock│ │journal entry │
  └────┬────┘ └────┬─────┘ └─────┬─────┘ └─────┬─────┘ └───────┬──────┘
       │           │             │             │               │
       ▼           ▼             ▼             ▼               ▼
    Ch. 14      §26.7         Ch. 11, 13     Ch. 19       Ch. 31, 32, 33
  ticket time  the fee line   ideal vs.       SPLH,       P&L, flash report,
  vs. 22:00    2.81% of sales  actual      the schedule    break-even, cash
  ─────────────────────────────────────────────────────────────────────────
  UNDERNEATH ALL OF IT:  fiber + LTE failover · firewall · guest Wi-Fi on a
  separate network · cameras · the website · and one person whose job it is
  to notice when a connection stops working.

The budget

Three observations before we place it on the P&L.

One: processing is 59% of the entire technology budget. Every hour you spend agonizing over which POS has the nicer reporting screen is an hour not spent on the line that is one and a half times larger than all the software combined.

Two: the hardware is capital, not operating. Bellwether's terminals, screens, printers, network gear, cameras, and cabling total \$17,800**, and they sit inside the \$45,000 smallwares-and-FF&E line of the \$620,000 project budget (Chapter 5), not in this table. What sits in this table is the \$3,600 replacement reserve** — \$17,800 over a five-year life — because that hardware will need replacing and a restaurant that has not reserved for it will be replacing it out of a month's cash flow instead. Chapter 33 will thank you.

Three: this is a plan, not a contract. Every number above is a quote or a modeled estimate. The processing figure in particular is a model built from illustrative rates; the real number will be whatever the signed agreement and Bellwether's actual card mix produce.

Where it lands on the P&L

Technology does not have its own line on a standard restaurant profit-and-loss statement. It lives inside other operating expenses, which Chapter 4's plan set at 14.0% of sales — \$217,000. Chapter 8 already put \$29,300 of insurance in there. Here is the whole line, opened up.

FIGURE 26.12 — The $217,000 other-operating line, opened up          [the Bellwether plan]

  technology, all in       ███████████████████████     $73,273   4.73%  ← this chapter
    of which processing    ██████████████              ($43,573)  2.81%
    of which software      █████████                   ($29,700)  1.92%
  utilities                █████████████               $40,000   2.58%
  insurance (Ch. 8)        █████████                   $29,300   1.89%
  supplies, linen, uniforms,
    chemicals, paper       █████████                   $27,900   1.80%
  marketing (Ch. 27)       ███████                     $23,250   1.50%
  repairs & maintenance    █████                       $15,500   1.00%
  waste, grease, pest, hood
    cleaning, music licence ██                          $7,777   0.50%
  ────────────────────────────────────────────────────────────────────
  OTHER OPERATING, TOTAL                              $217,000  14.00%

  Technology is the single largest occupant of this line - a third of it (33.8%) -
  and it did not exist as a category on a 1995 restaurant profit-and-loss statement.

Three comparisons that make the number mean something:

• Technology at 4.73% is smaller than occupancy (6.1%) but larger than general and administrative (3.0%). It is a major cost category wearing no name.
• It is 28.1% of the plan's operating profit. At a projected 16.8% operating margin — \$261,020 — technology consumes better than a quarter of it.
• Per unit of the thing you actually sell: \$1.94 a cover**, or about **\$201 a service.

Is 4.73% right?

Honest answer: it is unremarkable, and there is no authoritative benchmark to check it against. Practitioner and consultant guidance generally puts the software portion of an independent full-service stack somewhere between roughly 1% and 3% of sales, and processing between roughly 2% and 3.5%, which makes an all-in figure anywhere from about 3.5% to 6% ordinary. Bellwether sits mid-range. Treat that as orientation, not as a target — it is a range assembled from operator experience, not a published study, and a restaurant with heavy off-premise volume, a low average check, or a marketplace-dependent channel mix will run higher.

What is not in doubt is the direction. Technology is one of the few cost categories on a restaurant P&L that has grown steadily for two decades, and there is no reason to plan on that reversing.

The four levers that actually move it

Ranked by how much money they move, at Bellwether's volume:

1. The pricing model. Interchange-plus rather than tiered or flat, above roughly \$30,000–\$40,000 a month of card volume: \$3,100–\$3,500 a year (Figure 26.7). Requires one afternoon and three phone calls.
2. The markup, re-quoted annually. Taking the processor's markup from 0.35% to 0.20% is \$2,616 a year. Nothing about this improves on its own; a rate you negotiated three years ago is a rate you are no longer negotiating.
3. The subscription audit. Pull twelve months of bank and card statements, list every recurring charge, and ask of each one: what number does this produce, and who reads it? The two most common findings are two subscriptions doing one job and one subscription doing no job at all. In my experience this is worth several hundred to a couple of thousand dollars a year in almost any restaurant that has been open more than two years, and it takes ninety minutes.
4. Operational discipline. Batch every night. Adjust tips the same night. Open tabs at the bar rather than running singles. Individually small; collectively about a thousand dollars a year here, and free.

Notice what is not on the list: switching POS systems to save on the subscription. At \$14,294 of switching cost against \$4,800 of annual subscription, that trade almost never pays. Switch because the system cannot do something you need. Do not switch to save money on software.

🔍 Check Your Understanding

1. A processor's statement shows total fees of \$3,974 on \$158,400 of card volume. The operator's net sales for the month were \$140,800. State the two effective rates and explain which one belongs on the P&L.
2. Why is a first-party ordering platform fee a fixed cost while a marketplace commission is a variable one, and what does that imply about which one you should prefer as volume grows?
3. Your POS renewal comes with a 15% price increase — \$720 a year. Switching costs \$14,294. What do you do, and what does the answer tell you about when leverage exists in a vendor relationship?

(1: \$3,974 ÷ \$158,400 = 2.51% on card volume, which is what the processor is selling; \$3,974 ÷ \$140,800 = 2.82% of net sales, which is what appears on the P&L. Budget the second. 2: The platform fee is the same dollars whether you sell \$31,200 or \$100,000, so its percentage falls as volume rises; a commission is a constant percentage at any volume. First-party therefore improves with scale and marketplace does not — but marketplace supplies demand, which is Chapter 28's question. 3: You pay the \$720, because \$14,294 up front to avoid \$720 a year is irrational. Leverage exists only before the signature; negotiate renewal caps, data export, and hardware ownership at the beginning.)

🍽️ The Business Plan

Checkpoint 26 of 40 — the Technology section.

The plan gets a section it did not previously have, and the other-operating line gets its second audited occupant.

The stack

Bellwether — Technology (the Bellwether plan; constructed)

System of record. A cloud POS on a location licence plus four fixed terminals (two service stations, the bar, the office), one host-stand tablet, and two handhelds. Offline mode confirmed in writing and tested during the soft open (Chapter 9). Every menu item, including specials, built before service; the open-item button behind a manager code; cover count mandatory to tender; voids, comps, and discounts require a manager code and a reason.

Kitchen. Two KDS screens — one at the hot line, one at the pass — with one impact printer held live as a fallback and a written manual procedure. Ticket time reported nightly against Chapter 14's 22-minute not-to-exceed; the hearth queue displayed against its 28-items-per-hour rate.

Room. A reservation and waitlist platform configured to Chapter 22's 32-cover peak-hour cap and 8-cover quarter-hour cap, with a guest record carrying allergies, preferences, and visit history, and a written standard for what may and may not be entered in a guest note.

Back office. Inventory and recipe costing feeding Chapter 11's cost cards and Chapter 13's weekly count; scheduling and payroll receiving POS sales history so Chapter 19's sales-per-labor-hour targets are computed rather than estimated; accounting receiving the daily sales report as a journal entry. Certified integrations at every boundary that offers one, and a Monday checklist item that verifies each connection actually ran.

Channels. First-party online ordering on Bellwether's own site. Gift cards and a simple loyalty mechanism. Third-party delivery marketplaces are not committed in this section — the channel decision and its economics belong to Chapter 28.

Underneath. Business fiber with LTE failover; a firewall with the payment network separated from guest Wi-Fi; PCI self-assessment completed annually; a camera system with cloud retention; quarterly self-serve exports of sales, guest, and employee data held by the restaurant.

The number

**\$73,273, or 4.73% of sales.** It sits inside the \$217,000 other-operating line alongside Chapter 8's \$29,300 of insurance, and the line still foots at 14.0% with \$114,427 remaining for utilities, supplies, marketing, repairs, and waste services — an allocation the plan now states explicitly rather than leaving as a percentage nobody built.

That is the number every later chapter will use. Chapter 31's flash report carries it. Chapter 32's break-even treats the software portion as fixed and the processing portion as variable — a distinction that matters, because \$29,700 of this is owed whether you sell anything or not, and \$43,573 only happens if you do. Chapter 33's cash forecast has to account for net settlement reducing daily deposits and for weekend batches funding on Tuesday.

What this checkpoint does not settle

The processing rate is modeled, not contracted. The \$43,573 is built from illustrative interchange and an assumed 0.35% markup on an assumed card mix. The actual figure depends on a signed agreement and on cards Bellwether's guests have not yet carried through the door. A 0.25-point miss in either direction is \$4,359 a year, and the plan should say so rather than present a modeled number as a fact.

The integrations are promised, not proven. Every vendor says they integrate. Rung 4 and rung 3 (Figure 26.10) look identical in a sales deck and cost 227 hours a year apart.

The delivery-marketplace decision is open and belongs to Chapter 28. If Bellwether takes that channel, both the technology cost and the channel economics change materially.

Off-premise mix affects the processing rate. The model blends everything at a card-present rate. More off-premise means more card-not-present volume at roughly half a point more.

Open questions carried forward:

1. What does the signed processing agreement actually say, in interchange-plus terms, with all per-item and monthly fees disclosed? (before opening)
2. Does the plan take a third-party delivery marketplace, and what does that do to both this budget and the channel's margin? (Chapter 28)
3. Will the POS-to-accounting integration hold, or does the plan need to budget the bookkeeper hours in Figure 26.4? (Chapters 31, 33)
4. Should Bellwether surcharge, cash-discount, or neither — a hospitality question with a \$40,000 price tag attached, in a plan whose entire premise is a neighborhood restaurant people come back to? (Chapters 23, 27)
5. Is 4.73% right for this concept, and what would the first year of real statements say? (Chapter 31)

Conclusion

Two numbers leave this chapter.

The first is \$73,273 — 4.73% of sales — the all-in cost of running Bellwether's technology for a year, of which 59% is payment processing that never arrives as a bill and is never examined. It is the largest single occupant of the other-operating line, larger than utilities, larger than insurance, larger than marketing, and it consumes better than a quarter of the plan's operating profit. An operator who has not computed it is managing a cost the size of a full-time salary by not looking at it.

The second is \$1,743,750 — the card volume the fee is actually charged on, which is one and a quarter times Bellwether's card sales because it carries the sales tax and the tips as well. One dollar in five of the processing bill is charged on money that was never the restaurant's. Nothing can be done about that except knowing it, which is precisely why every operator's mental estimate of their processing cost is low.

But the money is the smaller half of this chapter. The larger half is that the POS is the system of record, and every number in this book is a query against it. Menu engineering, ideal-versus-actual food cost, sales per labor hour, ticket times, turn times, RevPASH, the audit trail, the weekly flash report — none of them exist independently of what a server enters on a terminal at 7:40 on a Saturday. The technology decision is not about software. It is about whether the management system in Parts III, IV, and VII is possible at all, and whether the data feeding it is honest. That is why a mandatory cover count is worth more than a nicer reporting screen, and why a KDS is justified by a timestamp rather than by the death of paper.

Part V closes here. Over five chapters the room has been given a sequence of service, a hospitality standard, a revenue model, a food-safety system, and now the instrumentation that measures all four. The dining room is, as much as it can be on paper, built.

Part VI turns outward. Everything so far has assumed the guest arrives at the door. Chapter 27 asks the harder question — how do they find out you exist, at a cost per cover a four-point-margin business can actually afford? — and Chapter 28 takes the channel this chapter deliberately handed forward, and prices delivery honestly.

Key Terms

Point of sale (POS) — the software and hardware through which orders are entered, routed, priced, tendered, and recorded. Properly understood as the restaurant's system of record: the authoritative account of what was sold, to how many guests, when, by whom, with what discounts, paid how. Every operating metric in Parts III, IV, and VII is a derivative of it. (Ch. 26)

Kitchen display system (KDS) — screens that replace printed kitchen tickets, routing items to the station that makes them and timestamping every step. Its decisive advantage over paper is not speed but record: without timestamps there is no ticket time, and without ticket time Chapter 14's 22-minute standard is a feeling rather than a measurement. (Ch. 26)

Inventory management software — software holding item, recipe, and vendor records, importing invoices, and computing usage, theoretical cost, and variance. Its real return is not the hours saved but that a shorter count actually gets done. It cannot count for you, and it will produce a confident wrong answer from a sloppy count faster than a spreadsheet would. (Ch. 26)

Scheduling software — software that builds shifts against a forecast, publishes to staff, tracks the time clock, and warns on overtime. Useful in proportion to whether it receives sales history from the POS; sales per labor hour requires sales and labor by hour in the same place. (Ch. 26)

Reservation platform — software managing bookings, waitlists, table assignments, pacing, and guest records. It is what makes a host stand's pacing caps enforceable under load, and what holds the guest memory that Chapter 23's recognition depends on. (Ch. 26)

Online ordering — guest-initiated ordering for off-premise, split into first-party (your site, your prices, your guest data, a platform fee plus processing) and marketplace (a third-party app's guests, priced by commission — Chapter 28). The structural difference is not the fee; it is who owns the second visit. (Ch. 26)

Integration and API — the automatic exchange of data between two software systems, usually by way of an application programming interface: a published set of rules by which one program requests data from another and receives it in a predictable form. "We integrate" describes five different rungs of reliability; ask which one. (Ch. 26)

Payment processing — the service that authorizes cards, settles transactions, and deposits funds. At a full-service restaurant it is typically the largest single line in the technology budget and the least examined, because it is netted out before the deposit arrives. (Ch. 26)

Interchange — the fee, set by the card networks and paid to the bank that issued the guest's card, that makes up the large majority of card-processing cost. Published, granular, revised periodically, varying by card type — and not discountable by your processor, who merely passes it through. (Ch. 26)

Effective rate — total processing fees for a period divided by total card volume for the period. The only honest measure of what processing costs, and it should always be computed a second way, over net sales, because that is the version that lands on the P&L. Bellwether's are 2.50% and 2.81%. (Ch. 26)

Downgrade — a transaction billed at a worse interchange category than it should have earned. Restaurant-specific causes include tip adjustments settled well above or long after authorization, and batches not closed within roughly 24 hours. Invisible on a summary statement; visible only in the interchange category detail. (Ch. 26)

Surcharging — adding a fee to credit-card transactions to pass processing cost to the guest. Constrained by card-network rules (a cap, advance notice, disclosure at entry and point of sale, a separate receipt line, and a flat prohibition on surcharging debit) and by state law, which varies and has been litigated. Structurally distinct from cash discounting, which posts the card price and discounts for cash. (Ch. 26)

Data ownership — the question of what transaction, guest, employee, and configuration data you can retrieve, in what format, and how quickly, if you leave a vendor. Answerable in a contract clause before signature and almost never after notice. (Ch. 26)

Technology cost as a percentage of sales — all-in annual technology spend, software plus infrastructure plus payment processing, divided by net sales. Bellwether's is 4.73%, of which 2.81 points is processing. It lives inside other operating expenses and has no line of its own on a standard restaurant P&L, which is a large part of why nobody manages it. (Ch. 26)

Spaced Review

1. Without looking back: what are the three parties paid on every card transaction, roughly what share does each receive at Bellwether, and which one can you actually negotiate with?
2. From Chapter 1: prime cost is COGS plus labor. Technology is in neither. Explain why a chapter about software nonetheless spends most of its length on measurement — and name three prime-cost numbers that do not exist without a POS.
3. From Chapter 13: state the usage formula. Now explain precisely what inventory software does to that formula, and what it does not do.
4. From Chapter 19: sales per labor hour requires two data streams. Name them, name the system each comes from, and describe what happens to the metric when those two systems do not talk.
5. A 110-seat restaurant does \$2,100,000 of net sales, 88% on card, with 7.5% sales tax and 19% average tips on card sales. Compute its card volume. At an effective rate of 2.65% on card volume, what does processing cost, and what is that as a percentage of net sales?
6. The recurring question: an operator is offered a POS at half price on the condition that they process payments through the same vendor at a rate 0.30 points above their current processor. Their card volume is \$1,600,000 and the full-price software is \$6,000 a year. Should they take it — and what is the second question you would ask before answering the first?