Technology in the restaurant industry, sorted by which vendors publish their math.

It is shorthand for the eight to twelve software categories a typical full-service operation buys: point-of-sale, kitchen display, online ordering, third-party delivery middleware, inventory and prep, scheduling and payroll, accounting, reservations, loyalty, review management, paid-marketing pixels, and AI phone answering. Quick-service operations run six to eight categories. Multi-location groups run twelve to twenty. The category list is well covered. The interesting question is which of those categories will tell you, in source-code detail, how their savings number is computed.

Because most savings claims in restaurant tech are sold without a formula. "Cut labor by 30 percent." "Recover 25 percent of lost revenue." "Pay for itself in three months." An operator who signs based on the headline never sees the constants, the rate assumptions, or the period the formula projects over. When the result misses, there is nothing to debug. PieLine's calculator on the homepage is the opposite of that: the formula is fourteen lines of TypeScript inside the RoiCalculator component in src/app/page.tsx, and the three constants that drive every dollar are missedRate equal to 0.35, daysPerMonth equal to 30, and pieLineMonthly equal to 350. You do not have to trust the marketing copy; you can read the function and decide for yourself whether the assumptions match your operation.

missedRate = 0.35 represents the share of inbound restaurant calls that go unanswered during peak hours, sourced from the homepage stats strip and from internal industry data. daysPerMonth = 30 is the period the calculator projects monthly loss across. pieLineMonthly = 350 is the entry-tier price in dollars, matching the public pricing section that quotes $350 per month for up to 1,000 calls. Two slider inputs feed the formula: calls per day (default 80, range 10 to 400) and average ticket size (default $35, range $10 to $120). Every dollar shown to the user is a function of those five numbers, no hidden multiplier.

Three lines. dailyMissedRevenue = calls × 0.35 × ticket. monthlyLoss = round(dailyMissedRevenue × 30). paybackDays = 350 / dailyMissedRevenue. firstYearNet = round(monthlyLoss × 12 − 350 × 12). The function returns paybackLabel as < 1 day, X.X days, or X.X months depending on which range the value lands in. There is no other arithmetic on the homepage page that contributes to a dollar figure.

Two reasons. The homepage stats strip cites 43 percent of restaurant calls going unanswered during peak hours, but a 24 hour rolling average is lower than peak. 35 percent is a deliberately conservative blend so the calculator does not overstate monthly loss. The same constant appears in a comment one line above the slider that says "Industry data: 35% of restaurant calls go unanswered during rush." An operator with a stricter view can mentally swap 0.35 for whatever rate matches their POS data; the formula is linear in that constant, so halving the rate halves the projected loss.

Almost none. POS vendors quote percentages of labor savings without exposing the model. Kitchen display vendors talk about ticket times without an open formula. Inventory tools cite food-cost recovery percentages with proprietary baselines. Online ordering vendors quote average-ticket lift with the calculation hidden inside an account dashboard. The pattern is consistent: the savings number is rendered server-side or sits behind a sales rep. Reading the formula in client TypeScript is unusual, and on the PieLine homepage that formula is in the same file as the rest of the page, not a separate widget that could be rebuilt at any time.

It sits on the phone layer. The carrier and the phone number stay the same; PieLine answers the inbound call, takes the order, and posts it directly to the existing point-of-sale through one of 50+ integrations (Toast, Square, Clover, NCR Aloha, Revel are the five live integrations called out on the homepage). The math model on the homepage projects savings only against the missed-call slice of phone revenue, not against staff cost, not against POS spend, not against marketing spend. It is intentionally narrow so the formula stays auditable.

Mylapore, an 11-location South Indian chain in the Bay Area, projects roughly $500 in additional revenue per location per day from eliminating the phone bottleneck. Run that through the calculator backwards and it implies recovering missed revenue on the order of $1,400 daily per location ($500 net at a $350 monthly cost is consistent with a calls-per-day count in the high-double-digits and a ticket of $35 to $50). Idly Express in Almaden runs 90%+ of its calls end-to-end through PieLine, which puts it well above the calculator's implicit miss-rate baseline. The customer numbers and the calculator's constants line up; one is the steady-state outcome, the other is the up-front projection.

Calls per day ranges 10 to 400 in steps of 5, defaulting to 80. Ticket size ranges $10 to $120 in steps of $1, defaulting to $35. Below 10 calls per day the math is uninteresting because total daily call volume is too low to matter. Above 400 calls per day the operator is firmly in multi-location territory and pricing is set together on a 15-minute demo call, not by the per-call defaults. The sliders are coarse enough that an operator can sweep the full range in 5 seconds; the formula recomputes synchronously on every change.

It signals that the vendor is willing to be wrong on paper. A formula is checkable. A constant is auditable. The sentence "PieLine pays for itself in 1.4 days at 80 calls per day and a $35 ticket" can be reproduced in a calculator app in fifteen seconds. A vendor who keeps the formula opaque never has that conversation, because the result is always whatever the marketing team set it to. The concrete bet PieLine is making by shipping the math is that the vast majority of small-to-mid-sized restaurants get a positive answer when they plug their own numbers in, and that operators who do the math themselves convert at a higher rate than operators who are told the math.