Olo

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

Nesting is documented: 'Custom Boxes' describes 'nested modifier groups', a 'first level nested modifier group' that 'can be either a multi-nested group such as the Burgers and Salads, or a single nested group', with 'required/optional tags' and Min/Max Modifier Quantity per group; 'Modifier Quantities' (115005204683) and Menu Training pt. 1 document per-group Single / Multiple / Unlimited / Set-a-limit min-max / Increments and Modifier Aggregate Quantity. Shortfall: no article states a depth of three or more levels, and the Consolidate-Modifiers-on-Quantity scaling applies 'for the first nested level only'. https://olosupport.zendesk.com/hc/en-us/articles/48021726126747-Custom-Boxes · retrieved 2026-09-03 adversarially verified

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

Menu Admin's modifier-choice config surface carries exactly one Price field per choice ('Price is only required for brands that are not integrated to a point of sale... POS Integrated clients can skip this step since pricing will pull directly from the POS' via a single POS Entity Type + POS Mapping ID per choice). The documented way to vary a group across parents is duplication: 'You have the option to reuse existing modifier groups or make copies and assign them to other products.' Sizes are themselves modifier choices each with its own flat price (the Is Base Product article's worked example: Small $6.99 / Medium $8.99 / Large $10.99). No parent-item or size price matrix exists anywhere in the documented Menu Admin surface - per-parent modifier pricing is achieved only by copying the group, which is exactly the mechanism the claim excludes. https://olosupport.zendesk.com/hc/en-us/articles/360025658332-Company-Menu-Admin-Menu-Training-pt-1 · retrieved 2026-08-04

Supports fractional/sectioned modifier placement (at minimum halves, ideally quarters) with independent pricing per section. differentiator

menu-pricing-fractional-placement

Company Menu Admin enumerates the whole modifier surface and it contains no portion, section or placement primitive. The group-level question is 'How many modifiers can the customer select from this group?' with exactly five answers - Single, Multiple, Unlimited, 'Set a limit: The customer can select a number of choices within a specified minimum and maximum range', and 'Increments: The customer can select a number of choices by increment value, for example, by 2, 5, 10, etc.' - all cardinality, none geometry. The modifier-choice field list is likewise flat, verbatim: '1. A Name is required, this is what the customer will see.' and '2. Price is only required for brands that are not integrated to a point of sale (POS), for example, brands exclusively using our Expo Standalone product.', then '5. Enter (optional) Base/Max Calories.' and '6. Default? can be selected if you want a choice preselected for the customer.' One Price per choice, no left/right/whole selector, no per-section price. The only compositional construct is nesting - 'Nesting modifier groups means placing one modifier group under a specific modifier choice' - a flow device, not a fraction. Corroborating second surface: the thirteen www.olo.com release pages (winter-2023 through 2026-spring) announce no halves/quarters/fractional-topping feature in three years of shipping notes. Consistent with this record's existing grade-B no on menu-pricing-half-and-half-rule. SHORTFALL: Olo is not a POS, so for POS-integrated pizza brands portion pricing is computed in the POS and Olo only maps to it; and the help centre is a FLOOR, not a census - the 231 public articles reference 383 distinct ids, 152 (40%) of which are gated (401/403, not 404). Checked on audit: none of the 113 recoverable gated titles names a portion, half, section or placement feature, and the gated set is dominated by per-POS Menu Mapping Instructions. The verdict therefore rests on the affirmative Menu Admin field enumeration plus the thirteen www.olo.com release pages, a surface that does close, not on Zendesk silence. https://olosupport.zendesk.com/hc/en-us/articles/360025658332-Company-Menu-Admin-Menu-Training-pt-1 · retrieved 2026-09-04

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

The documented Menu Admin surface has no portion primitive at all: products carry modifier groups whose choices have a selection type (Single/Multiple/Unlimited), min/max and aggregate quantities, and exactly one flat Price or POS Mapping ID each - nothing expresses half/whole placement, let alone a configurable pricing rule across halves. Help-centre searches for 'portion', 'half and half' and 'pizza builder' (2026-08-04) return no portions feature. This matches the record's settled grade-B findings that modifier pricing is strictly linear per choice and that no price matrix exists in the documented surface; a half-and-half rule (higher half / average / fractional toppings) has no object to attach to. For POS-integrated pizza brands any such rule lives in the POS, not in Olo. https://olosupport.zendesk.com/hc/en-us/articles/360025658332-Company-Menu-Admin-Menu-Training-pt-1 · retrieved 2026-08-04

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

Modifier Quantities is a documented first-class feature: per-choice quantity selection with Modifier Aggregate Quantity (min/max on the sum of the group), Min/Max Modifier Quantity per choice, a selectable Increment step, and a Consolidate Modifiers on Quantity product setting that multiplies modifier quantities by the parent quantity. Shortfall: pricing is strictly linear - quantity times the choice's single price - with no per-tier price multiplier, so light/regular/extra/double semantics (zero-charge light, discounted double) must be modeled as separate modifier choices each carrying its own explicit price or POS mapping. The tier-multiplier half of the claim does not exist. https://olosupport.zendesk.com/hc/en-us/articles/115005204683-Modifier-Quantities · retrieved 2026-08-04

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

Menu Admin's documented pricing model is one flat price per product or per modifier choice; sizes are themselves modifier choices each carrying a single price (the Is Base Product worked example: Small $6.99 / Medium $8.99 / Large $10.99), and varying a modifier group across parents is done only by duplicating the group. The record's modifier-price-by-parent-size cell already established at grade B that no parent-item or size price matrix exists anywhere in the documented Menu Admin surface; a two-axis size x crust/style grid with per-cell overrides is the same missing object. POS-integrated brands pull prices directly from the POS, where any such matrix would live. https://olosupport.zendesk.com/hc/en-us/articles/360025658332-Company-Menu-Admin-Menu-Training-pt-1 · retrieved 2026-08-04

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

Modifier Quantities enumerates the whole documented quantity/pricing surface: Modifier Aggregate Quantity (min/max on the sum of the group), Min/Max Modifier Quantity per choice, an Increment step, and Consolidate Modifiers on Quantity - and pricing is strictly linear, quantity times the choice's single price. There is no included-allowance field and no charge-only-for-overage behavior anywhere in the documented model (the settled topping-quantity-tiers cell already found no non-linear tier pricing exists). An 'N toppings included' rule can only be faked with $0 choices plus min/max limits, which is the workaround the claim excludes, not the capability. https://olosupport.zendesk.com/hc/en-us/articles/115005204683-Modifier-Quantities · retrieved 2026-08-04

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

Combos exist but as a POS-mapping exercise, not an Olo-native pricing engine: 'a QS brand can build and map Quick Combos on the Olo side' and at checkout 'validation will receive a response from POS that auto-applies the Quick Combo price' (Aloha FAQ); per-POS combo-mapping guides exist for Brink, Micros, Revel and SimphonyCloud (linked from Menu Mapping pt. 2), and the Aloha setup even recommends 'a marker item as a component in the Quick Combo... to avoid unwanted auto-application in-store.' Shortfall: the combo price is applied by the POS's validation response, behavior is integration-specific, and no doc describes Olo itself detecting eligible a-la-carte basket items and converting them into the combo. https://olosupport.zendesk.com/hc/en-us/articles/360001988831-Aloha-POS-FAQs · retrieved 2026-08-04

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

AI/ML Smart Cross-Sells and 'For You' categories across Olo digital channels, with a Menu Intelligence dashboard tracking item impact on ordering behavior. Digital channels only — no POS or kiosk prompts. https://www.olo.com/ordering · retrieved 2026-08-01

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

Availability changes propagate to Olo digital channels and out through Rails to marketplaces in 'near real-time.' No POS/KDS leg (Olo owns neither) and no published latency figure. https://www.olo.com/rails · retrieved 2026-08-01

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

Winter 2026 shipped automated menu-item scheduling with auto-return after 1-4 hours (the scheduled-restore half). No evidence of par/countdown decrement-on-sale triggering auto-86 at zero. https://www.olo.com/winter-release-2026 · retrieved 2026-08-01

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

Menu-item scheduling with timed auto-return is documented; per-location-timezone daypart price scheduling is not explicitly published. https://www.olo.com/winter-release-2026 · retrieved 2026-08-01

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

Rails' actual verbatim wording is only 'Adjust menu pricing to maintain margins'. That is one sentence supporting per-marketplace markup; it does not establish named price books, per-channel price sets, or assignment of price books to channels/locations. The Winter 2026 'tiered fees' cited as reinforcement are fees, not item prices. https://www.olo.com/rails · retrieved 2026-08-01 adversarially verified

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

Searched the public help centre (olosupport.zendesk.com search API, 2026-08-04) for 'dual pricing', 'cash discount', 'surcharge', 'service fee', 'convenience fee' and 'credit card fee': the only fee-configuration docs are Dispatch delivery-fee rules, and the discount hits are Olo Loyalty offer types and Aloha POS tender articles - no cash-discount or card-price-display feature anywhere. olo.com/pay (re-read 2026-08-04) mentions no dual pricing, cash discounting or surcharging. But item prices on Olo channels pull from the integrated POS, and no document enumerates the pricing-display options in a way that would positively rule a card-price-as-base mode out, so this stays unknown rather than no. || 327th: FIRST TIME THIS CELL HAS BEEN CHECKED INDIVIDUALLY (its note was empty; only the sibling payments-dual-pricing cell had been worked). Tested against the largest Olo corpus yet assembled, 4,132,744 chars: "dual pricing" 0, "cash discount" 0, "two prices" 0, "cash price" 0, "card price" 0, "credit price" 0, surcharging 0; 'surcharge' scores 2 on a substring grep and 0 tokenised — both are the plural "surcharges" inside the Olo Pay merchant agreement's PROHIBITION on the merchant, quoted below, so the only two hits in 4.1 MB argue against the capability rather than for it. The item-level conjuncts this cell adds over payments-dual-pricing — a card price shown as the base price, applied consistently across POS, kiosk and online ordering, and printed on the receipt — are unreachable from any public Olo surface for a structural reason worth recording: Olo does not own the menu. Its menu is received from the POS, its own guidance treats card-cost recovery as the POS's business (Aloha "Surcharges ... are combined with the tax amount ... We cannot see them separated"), and its merchant agreement runs the other way — "Merchant agrees: It shall not set any surcharges of its own for accepting any credit card transactions other than allowed by Scheme Rules or applicable law" (https://www.olo.com/olo-pay-terms-and-conditions). NEW SURFACE CHECKED AND REPORTED SO IT IS NOT RE-FOUND: mcp.olo.com, Olo's anonymous ordering MCP server, answers initialize and tools/list without credentials today (serverInfo ordering-mcp-server 1.0.0, 17 tools; it is now a UCP agentic-commerce surface requiring meta["ucp-agent"].profile). Its catalog tools state plainly that pricing is single-valued and menu-owned — get_product: "supply catalog.restaurant_id to resolve the product's title and price from the restaurant's menu (without it, only option groups are returned — Olo menus own pricing)" — one price per product id, with no cash/card pair, but a tool DESCRIPTION is not a field-level schema and cannot carry the no. CORPUS USED FOR THE CONTROLS: 4,132,744 chars assembled this pass from every Olo corpus on disk (script corpus build + ctl.mjs in .cache/q327/olo) — the 233-article olosupport.zendesk.com Help Center API census plus its 7 non-image attachments (Dispatch, Chargebacks, the three Serve guides), the 158-article getwisely.zendesk.com (Olo Engage) census plus its two PDFs and the Engage Warehouse Data Dictionary, the 55-article ologuesthelp.zendesk.com census, the 341-route partners.olo.com directory payloads, and all four www.olo.com legal documents. IT IS A FLOOR, NOT A CENSUS: the olosupport href fixpoint names 149 article ids that are 401-gated, so per the session rule no capability 'no' may rest on it. Retrieved 2026-09-18. || 328th: MERGE HOLD (proposed no/B, held unknown): The Serve census bounds only the online-ordering conjunct; the POS, kiosk and receipt conjuncts do not exist at Olo (no POS). No module at all = hold (326th rule); the agent flagged this row itself. PROPOSAL AS WRITTEN: 328th: NEW SURFACE AND THE CONJUNCT THIS CLAIM TURNS ON IS NOW CENSUSED. The claim requires the card price to be displayed as the base price 'applied consistently across POS, kiosk, and online ordering'. Olo's online-ordering channel is Olo Serve (serve-next.olo.com), and this pass took it to a complete census for the first time: buildId Qf-toB1-JcZW3iX3iMy_c, 25 routes from the app's own _buildManifest.js, 51 chunks fetched at 200, 2 rounds, 0 misses, 4,015,455 chars; nonsense control /_next/static/ZZZNONSENSE/_buildManifest.js = 404. The menu/cart renderer (pages/menu/[...params]-8d809c23a1def55a.js) shows one price per product and a cart whose money lines are taxes, fees[] and discounts - `y.fees.reduce(...)`, `y.taxes.reduce(...)`, `y.discounts.filter(...)`, with i18n keys cart.estimatedTaxesAndFees, cart.estimatedTax, cart.fees, cart.deliveryAdjustment - and nothing that pairs a cash price with a card price. Tokenised over all 51 files: "dual pricing" 0, "cash discount" 0, "cash price" 0, "card price" 0, "two prices" 0, surcharge 0, basePrice/cashPrice/cardPrice/displayPrice = 0. This corroborates the single-price product model already recorded from mcp.olo.com ('Olo menus own pricing', one price per product id) with the shipped code that renders it. Consistency across channels therefore fails at the online-ordering channel itself, which is the channel Olo owns. WEAKER THAN THE SIBLING payments-dual-pricing CELL, AND I SAY SO: this claim also reaches POS, kiosk and the printed receipt, and Olo ships no POS, so the POS conjunct is unbounded rather than measured. If the owner prefers the 'product lacks the module entirely' rule for the POS half, hold this at unknown and keep the move on payments-dual-pricing. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. "dual pricing"/"cash discount"/"cash price"/"card price" 1 hits in 1 pages; the Spring 2026 release's "applying surcharges for large catering orders" is a per-order delivery-fee adjustment in Switchboard, not a card price (homonym); the single 'cash discounts' hit is Olo's payments blog describing what "some restaurants" do (industry commentary, https://www.olo.com/blog/what-restaurants-should-know-about-credit-card-fees). Retrieved 2026-09-18. adversarially verified

Menu changes can be staged as an effective-dated version, previewed before publish, and rolled back to a prior version after publish. differentiator

menu-pricing-versioning-effective-dates

One leg is documented publicly, and it depends on the integration. Olo Release Notes - September 9, 2020 (retired help-centre article 360049394651, Wayback 2020-10-28): 'NCR Cloud: Added the ability to publish pricing based on a price record's effective date range'. Release Notes - March 17, 2020 (360041038211) show scheduled POS price pulls on one integration: 'Micros 9700: Users can now disable availability changes when performing scheduled price updates'. The effective date belongs to the POS price record, and Olo honours it on publish; Olo does not author it. Store Menu Admin (Menu Training pt. 3, live article 360026137891, read 2026-08-04): 'As you make changes, you can preview how the menu will appear to customers on the front-end site'. It links a 'Scheduled Menu Changes' article (6514298372507) that is login-gated with no Wayback capture. Olo's Q2 2022 results release names 'scheduled menu changes' among its Quarterly Release highlights (grade D). Shortfall: effective dating is shown only as NCR Cloud POS price records (and scheduled price pulls for MICROS 9700), not as a named Olo menu version. The preview is described while editing, and nothing says the changes are held unpublished. No rollback to a prior published version is documented anywhere. Date caveat: 2020 release notes; live Store Menu Admin read 2026-08-04. https://web.archive.org/web/20201028201646/https://olosupport.zendesk.com/hc/en-us/articles/360049394651 · retrieved 2026-09-13 adversarially verified

Supports a central corporate menu template pushed to locations with field-level governance controlling which attributes a location may override. differentiator

menu-pricing-franchise-hierarchy

Rails supports menu changes 'for a single location or in bulk' and Olo runs centralized menu management for enterprise brands. Field-level override governance is not documented. https://www.olo.com/rails · retrieved 2026-08-01

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

Winter 2026 added dietary tags (vegan, gluten-free) on items and modifiers with guest filtering; Summer 2026 added allergen menu tags meeting California SB 68. No recipe-derived nutrition (Olo has no recipe module). https://www.olo.com/product-release · retrieved 2026-08-01

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

The document says: “This new feature provides an intuitive interface that allows you to map ingredients and related quantities to products in your menu.” CORRECTED after the corpus grew: this cell was scored no on a corpus in which every recipe hit was a blog or partner page. The Spring 2024 quarterly release page, unreadable then and readable now, announces Catering+ Production Sheets and describes exactly the linkage half of this claim - an interface mapping ingredients and quantities to menu products. That is a bill of materials, so a flat no is not defensible. Named shortfall, which is why this is partial and not yes: the feature is scoped to Catering+ and its output is a printable back-of-house production sheet, described on the same page as prepping for large-volume orders and quantifying the ingredients and items needed to fulfil upcoming orders for a period. It is forward-looking prep quantification, not the two things the claim's second clause requires - a sale depleting theoretical inventory, and an item-level theoretical food cost. The feature is current, not historical: the live Olo Dashboard Overview (article 115000076446) lists Production Sheets among the Catering management tools under the Orders tab, www.olo.com/catering lists customizable production sheets for BOH prep, and the Winter 2026 and Spring 2026 release pages both announce a redesign of pack slips and production sheets. Olo holds no stock and sells theoretical food costing through integration partners in its directory (MarketMan, BevSpot, BarTrack, Foodini). Grade C because the carrying document is a vendor marketing release page; the live help-centre articles name Production Sheets but do not describe the ingredient mapping, and no Olo Ordering API reference is in this corpus. Controls re-run 2026-09-06 over the final 1,628-document corpus, all unchanged from the previous run: bill of materials 0 documents, depletion 0, deplete 0, theoretical 2 (both blog pages), recipe 7, recipes 9, production sheets 12. Figures are bounded to the 1,628 documents in .cache/q225/txt (index.tsv www row 657), not to the 608 HTML files in corpus/www; the four fetched-but-unconverted partner pages were grepped directly for recipe, bill of materials and depletion terms and contain none, and 58 /partners/ slugs remain unfetched against 392 partner URLs in the sitemap, so any bound over the partner directory here is a floor with a named remainder. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: bill of materials 0, depletion 0, deplete 0, theoretical 2, production sheets 12 ALL REPRODUCE. Two MOVED with the final tail: recipe 7 to 8 documents and recipes 9 to 10 documents, the added document in both cases being the Wisk partner page - an inventory and food-cost product, i.e. Olo continuing to sell theoretical food costing as somebody else's product, which reinforces the named shortfall. QUOTE RE-VERIFIED VERBATIM against www-www.olo.com_quarterly-release_spring-2024.txt line 80. THE STANDING RULING ON FIELD LISTS DOES NOT BITE HERE, because this verdict is a `partial` carried by an affirmative announcement, not a `no` bounded by a walkthrough: the linkage half is evidenced ("map ingredients and related quantities to products in your menu"), the depletion and theoretical-food-cost half is not evidenced in either direction, and that is the named shortfall. VALUE, GRADE, URL AND QUOTE UPHELD. https://www.olo.com/quarterly-release/spring-2024 · retrieved 2026-09-06

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

Verified verbatim on Rails: '15+ Marketplace Integrations', '99% Delivery market covered', 'Make near real-time menu changes for a single location or in bulk', 'Two-way data synchronization'. This is Olo's genuinely strongest documented cell and survives adversarial reading. https://www.olo.com/rails · retrieved 2026-08-01 adversarially verified

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

Olo ships a feature literally named Dynamic Pricing, but it is a channel markup, not a demand engine: 'Brands can dynamically update separate pricing for direct delivery orders based on specific menu items and/or locations using Olo’s ordering API for applications designed by a custom front-end developer as well as through Olo’s white-label ordering interface, Serve. Delivery prices can be managed in the POS system, or—if a brand uses a POS application that does not have such native functionality or simply wishes to manage delivery prices in Olo directly—can configure the delivery price markup in the Olo Dashboard.' That satisfies only the channel axis of the claim (direct-delivery price separate from in-store), scoped by item and location. SHORTFALLS: no time-of-day rule, no demand or surge input, no automatic variation of any kind - the markup is operator-configured and static until changed - and no floor/ceiling guardrail is documented anywhere. Grade C: a marketing release page, and the sentences quoted are its complete description of the feature. Consistent with this record's existing partial on menu-pricing-channel-price-books. CURRENCY CAVEAT ADDED ON AUDIT: the sole evidence is a Fall 2023 release announcement, now three years old, and no later surface (the 2024-2026 release pages, /pay, the ordering product pages) restates the feature. A release note is evidence that a feature shipped, not that it still ships; treat this capability as announced-2023 and unconfirmed-since. Grade stays C. https://www.olo.com/quarterly-release/fall-2023 · retrieved 2026-09-04

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

Scored yes on inference with partners.olo.com as the source. I fetched partners.olo.com: it names the Standard/Gold/Platinum tiers and references 'over 400 integrated partners' but the directory renders empty ('No relevant partners found') and no payment gateway or processor partner is identified. Olo Pay being a distinct SKU makes non-Olo-Pay operation plausible, but no source affirmatively documents supported alternative processors/gateways. https://partners.olo.com/ · retrieved 2026-08-01 adversarially verified

Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator

payments-published-rates

Affirmatively verified — the Pay page publishes no rate of any kind and olo.com has no pricing page. This is one of the rare cases where no is defensible over unknown, because the absence of a pricing page across the entire site is itself observable. https://www.olo.com/pay · retrieved 2026-08-01 adversarially verified

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

Checked 2026-08-04: olo.com/pay, the Olo Pay Terms and Conditions, the Spring 2025 / Spring 2026 / Summer 2026 release pages, and help-centre searches - no mention of dual pricing or cash discounting anywhere. Olo Pay spans digital card-not-present checkout and card-present payment terminals (kiosk and pay-at-table), but its merchant-facing configuration docs are login-gated, so a two-price cash/card display cannot be positively confirmed or excluded. || 325th: 325th: NEW SURFACE, no move. Across the 288-article two-help-centre census (see payments-surcharge-guardrails for the bound) "dual pricing", "cash discount" and "two prices" score 0, and the one article touching the mechanic describes it as the POS's: Aloha "Surcharges ... are combined with the tax amount ... We cannot see them separated." Olo's own price surface is the menu it receives from the POS, and the closest documented price-variant mechanic is Olo Loyalty's Price Adjustment offer (article 46337927260443), which temporarily discounts items for members and is explicitly a promotion, not a cash/card price pair: "The discount value is the difference between what the item would usually cost and the lower price it's being offered for during the promotion." No cash-and-card totals on a guest check are documented. Held unknown: the corpus is a floor (233 of 304) and the Menu category does not cover POS-side price configuration at all. Retrieved 2026-09-17. || 328th: MERGE HOLD (proposed no/B, held unknown): The claim is about a POS storing two prices and printing cash and card totals on the guest check and receipt. Olo ships no POS and no printed check; a guest-facing ordering app's line-item list is not the module the claim scores. No module at all = hold (326th rule). The Serve census is kept as the bound for the online conjunct. PROPOSAL AS WRITTEN: 328th: A COMPLETE CENSUS OF OLO'S OWN GUEST-FACING ORDERING APP, WHICH IS THE SURFACE THIS CLAIM RENDERS ON, AND IT CARRIES THE `no`. NEW SURFACE, never mined by any prior pass (q319-q327 fetched only the root HTML of serve-next.olo.com): Olo Serve (serve-next.olo.com), Next.js, production, buildId Qf-toB1-JcZW3iX3iMy_c. Censused from the publisher's own manifest to a fixpoint: /_next/static/<buildId>/_buildManifest.js enumerates 25 routes (/, /basket/products/[productId]/edit, /checkout/auth, /expired, /favorites, /group-order/{join,participant-confirmation,start}, /health/{live,ready,startup}, /locations, /locations/[regionCode], /login, /menu/[...params], /open-source-licenses, /order/arrival/[orderId], /orders/[orderId], /recent-orders, /rewards, /search, /thank-you/[orderId], /user/confirm-email, /user/upgrade, /_error); all 51 referenced chunks fetched at 200 in 2 rounds with 0 misses and 0 new loader entries in round 2 = 4,015,455 chars of Olo's own shipped production JS. SOFT-200 CONTROL PASSED: /_next/static/ZZZNONSENSE/_buildManifest.js returns 404 (5,069 B error page) while the real manifest is 1,561 B of `self.__BUILD_MANIFEST=`. EVIDENCE: the guest check renderer is in chunk 9660-47a2b5ee6a50e731.js and its line-item set is a CLOSED ENUMERATION read off the component's own memo-dependency list - subtotal, vendorDiscount, authBuffer, deliveryCharge, deliveryFeeAdjustmentAmount (with data-testid="delivery-fee-adjustment"), fees[] (rendered `y.fees.map(e => ... e.name ... e.description ... e.amount)` under data-testid="taxes-and-fees" / "fee"), tip, donationsTotal and vendorTax. There is no cash total, no card total, no second price of any kind, and no per-item price pair: tokenised, case-insensitive, word-boundary over all 51 files, "dual pricing" 0, "cash discount" 0, "cash price" 0, "card price" 0, "two prices" 0, surcharge 0, "service fee" 0, "convenience fee" 0, "credit card fee" 0, "non-cash adjustment" 0, and basePrice/cashPrice/cardPrice/priceType/displayPrice = 0 occurrences of any of those field names. That the one thing a dual-pricing product MUST do - print both totals on the guest check - is absent from the only check renderer Olo ships is what converts this cell. NOTES-ONLY LEAD RECORDED SO IT IS NOT MISREAD: the menu page chunk carries a feature-flag key `transparent-pricing-disclosure-olo-135375`; per standing policy a flag name is not a shipped feature, and 'transparent pricing disclosure' is fee DISCLOSURE, the opposite direction from a card-price-as-base mode. POISON PUBLISHED: a substring grep for `void` over this corpus scores 2,916 and every one is the JavaScript `void 0` idiom - a reader testing the sibling comps/voids cell against a JS census must tokenise and read. BOUND: this census covers Olo's guest digital-ordering app only; Olo's Dashboard admin and its 149 gated olosupport ids are not in it. It is nevertheless a census of the product surface the claim names (the guest check), which the gated KB is not. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. "dual pricing"/"cash discount"/"cash price"/"card price" 1 hits in 1 pages, including on https://www.olo.com/pay and the release pages describing Olo Pay card-present terminals; outside the Olo Pay T&C, 'surcharge' is only the Spring 2026 per-order delivery-fee adjustment in Switchboard (a homonym) and the blog below; the single 'cash discount' hit is that blog. Olo's own payments blog treats surcharging and cash discounts as something "some restaurants" do and pitches Olo Pay on processor-fee negotiation instead ("Restaurant brands, unfortunately, have to eat credit card fees; however, many don't realize most processor-level fees are negotiable", https://www.olo.com/blog/what-restaurants-should-know-about-credit-card-fees) - no Olo dual-pricing feature is offered there. Retrieved 2026-09-18. adversarially verified

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

Fee configuration exists (tiered %/flat fees, separated fee and tax line items) but no documented debit/prepaid BIN exclusion or network cap enforcement. || 325th: 325th: NEW SURFACE (325th), a full Zendesk Help Center API census of BOTH of Olo's help centres. (1) olosupport.zendesk.com/api/v2/help_center/en-us/articles.json: 233 articles, 14 categories, 56 sections, and — never mined before — 620 ARTICLE ATTACHMENTS, of which 7 are non-image (Olo_-_Dispatch__2___1_.pdf 606 KB, Olo Serve Web Style Guide.pdf 2.6 MB, Chargebacks_Overview.pdf 75 KB on article 115005491743, Olo_Serve_Global_Data_and_Events__1_.pdf 65 KB, Delivery_Cost_Calculator.xlsx, Inventory_Upload_Sample.csv). (2) ologuesthelp.zendesk.com, a SECOND help centre nothing in the record names, found by its own URL inside olosupport bodies: 55 articles, 5 categories, 9 sections (guest account, passwordless sign-in, Olo Loyalty member self-service). Combined corpus 1,286,782 chars; scripts oz.mjs / og.mjs / ctl.mjs in .cache/q325/olo. FLOOR, NOT A CENSUS: /hc/sitemap.xml lists 304 and 70 entries against the APIs' 233 and 55, so no 'no' may be published from it, and the 14 olosupport categories are General Information, Dashboard, Brand, Menu, Ordering, Serve, Olo Loyalty, Expo, Dispatch, Rails, Switchboard, Billing, POS Integrations and SSOS, Delivery — Sync, Host, GDP, Marketing, Sentiment and Olo Accounts have NO category at all. EVIDENCE: the only surcharge material in 288 articles says the surcharge is the POS's, not Olo's, and that Olo cannot even decompose it — the Aloha POS FAQs article (360001988831) reads "Surcharges are returned to Olo in the Validation response back to Olo, but they are combined with the tax amount. Therefore, if the tax=.50 and the surcharge=.05, then Aloha validates that tax as .55 to Olo. We cannot see them separated", with a later correction "we've recently found that this behavior has changed and we are receiving the surcharge back from the POS wrapped into the subtotal, not the tax". Separately, www.olo.com/olo-pay-terms-and-conditions (read in full today; a payment-facilitator agreement using Scheme Owner / Acquirer / Holdback wording) says the merchant "shall not set any surcharges of its own for accepting any credit card transactions other than allowed by Scheme Rules or applicable law" — i.e. Olo Pay defines no surcharge fee of its own and forbids the merchant adding one. Bounded controls over the 288 articles: "cash discount" 0, "dual pricing" 0, "convenience fee" 0, debit 0, BIN 0 as a bank identification number (66 substring hits, 2 word-boundary, both the English word 'bin'); and PREPAID IS A HOMONYM HERE - it scores 21 and every one means a PREPAID ORDER, paid online before pickup ("Orders are submitted as 'prepaid' to Olo", "one Tender to submit prepaid orders to Aloha (via a 'general' tender)"), never a prepaid card product code. HELD UNKNOWN on two rules, not on absence of evidence: the KB is a floor (233/304), and a terms clause allocating compliance duty is an applicability clause, which settles rights and not product behaviour. POISON PUBLISHED for anyone re-testing these cells: a substring grep of the two help centres scores RPO 95 times and RTO 6, and not one is a recovery objective — RPO resolves only to purpose(s), repurposed, corporate, incorporate(d) and purported, and RTO only to Puerto, Bertolone and Burtons; tokenised as standalone words both are 0. A substring grep for BIN scores 66 and the only 2 word-boundary hits are the English word 'bin' - the rest are combine(d/s), combination(s), binding, describing, subscribing, webinar and bing. Likewise my own word-boundary control UNDERCOUNTS plurals (surcharge 4 substring vs 2 bounded, webhook 41 vs 18, 'text message' 107 vs 82), so the bounded figures below are floors on the vendor's own vocabulary, not the substring counts. Retrieved 2026-09-17. || 328th: 328th: NEW SURFACE, no move, and it measures the fee ENGINE from the guest side for the first time. Olo Serve (serve-next.olo.com, Next.js buildId Qf-toB1-JcZW3iX3iMy_c) censused to a fixpoint from its own _buildManifest.js: 25 routes, 51 chunks, 2 rounds, 0 misses, 4,015,455 chars; nonsense control /_next/static/ZZZNONSENSE/_buildManifest.js = 404. Olo's guest-facing fee model is a flat untyped list: the order-summary component (chunk 9660-47a2b5ee6a50e731.js) renders `y.fees.map(e => ...e.name ... e.description ... e.amount)` - a fee carries a name, an optional description and an amount, and nothing else. There is no fee TYPE, no card-product or BIN condition, no cap field and no per-location toggle anywhere in the shipped guest code, and tokenised over all 51 files surcharge 0, "convenience fee" 0, "credit card fee" 0, debit 0, BIN 0. That is consistent with the recorded reading that surcharging on Olo orders is the POS's, not Olo's. Still unknown rather than `no`: a BIN/product-code exclusion would run SERVER-SIDE inside Olo Pay, which no guest bundle can see, and Olo Pay's merchant configuration remains gated. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. surcharge 5 hits in 3 pages: the two known Olo Pay T&C sentences, two in Olo's payments blog (surcharging as something "some restaurants" do, with state rules; industry commentary, no Olo feature, https://www.olo.com/blog/what-restaurants-should-know-about-credit-card-fees), and ONE NEW HOMONYM - the Spring 2026 release: "Delivery Fee Adjustments: Operators using Catering+ can now adjust delivery fees on a per-order basis in Switchboard, applying surcharges for large catering orders or discounts for guest recovery" (https://www.olo.com/2026-spring-release). That is a manual per-order DELIVERY-FEE adjustment, not a card surcharge, and states no BIN/debit/prepaid exclusion or cap. "dual pricing"/"cash discount"/"cash price"/"card price" 1 hits in 1 pages. Retrieved 2026-09-18. adversarially verified

All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.

payments-emv-nfc

Olo Pay handles card-present and card-not-present, supporting Apple Pay, Google Pay, contactless and mobile wallets. https://www.olo.com/pay · retrieved 2026-08-01

Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator

payments-softpos-tap-to-pay

Olo Pay card-present is documented exclusively as dedicated terminal hardware: 'Experience Olo Pay's POS-integrated payments on modern, reliable payment terminals' - EMV devices, USB-connected readers, with 'Pay-at-table and mobile payment available' running on those terminals. The kiosk variant is literally named 'Olo Pay Card-Present for Kiosk' (Summer 2026 terminal-management note), and the July 2023 launch described guests paying 'through an attached payment terminal.' No Olo material anywhere - release pages, help centre, olo.com/pay - offers phone-based readerless acceptance, and Olo ships no staff-facing payment app that could host Tap to Pay on iPhone or Android. https://www.olo.com/quarterly-release/spring-2025 · retrieved 2026-08-04

Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.

payments-pay-at-table

Olo sells a named Pay at Table product, but it is guest-phone, not staff-handheld: 'With splitting checks being a common headache for guests and servers alike, Olo’s Pay at Table solution allows guests to simply scan a QR code on the receipt and elect to split equally, split by items, or define specific amounts contributed by each guest. In addition to enhancing the guest experience by allowing guests to pay on their personal device—including support for mobile wallets—servers benefit from quicker table turns and higher tips on average.' The card-never-leaves-the-guest outcome is met and check splitting is met. SHORTFALL against the claim as written: Olo ships no handheld. The only Olo Pay hardware documented is fixed card-present terminals (Spring 2025: EMV-compatible, USB-connected devices, plus a kiosk variant), the Pay page lists no handheld SKU, and the word 'handheld' appears nowhere in the 35 www.olo.com pages or the 231 help-centre articles. No tip prompt on a staff device is documented, and 'pay at table' has zero hits across the entire help centre - the Spring 2025 terminal bullet 'Pay-at-table and mobile payment available' is a one-line marketing mention that adds no hardware detail. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. Specifically, 'pay at table' and 'handheld' returning zero hits is a floor result, not proof of absence. What actually carries the no-handheld shortfall is the affirmative www.olo.com surface - /pay and the thirteen release pages list no handheld SKU - and that sitemap-backed enumeration does close. https://www.olo.com/quarterly-release/winter-2023 · retrieved 2026-09-04

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

First limb verified verbatim: 'Olo’s Pay at Table solution allows guests to simply scan a QR code on the receipt and elect to split equally, split by items, or define specific amounts contributed by each guest', with guests paying 'on their personal device—including support for mobile wallets'. QR on the printed check, view-and-pay from the guest's own phone, is exactly the claim. SHORTFALL: the second limb - the payment closing the check in the POS automatically - is nowhere documented. Olo is not the POS; the release page says nothing about writing the tender back to the check, and no help-centre article covers Pay at Table at all ('pay at table' has zero hits across the 231). Also unstated: whether QR delivery extends beyond the printed receipt to a table tent. The only documented downstream hook is Sentiment: 'integrate with Pay at Table to trigger post-transaction surveys'. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. So 'no help-centre article covers Pay at Table' is a floor statement and cannot by itself establish that the POS check-close writeback is undocumented; the second limb is therefore UNESTABLISHED rather than shown absent, which is why this stays partial and not yes. https://www.olo.com/quarterly-release/winter-2023 · retrieved 2026-09-04

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

Olo is a digital-ordering platform, so the two POS flows map only partly. Tip prompt: the retired 'Suggested Tip' article (360001809872, Wayback 2020-10-28) documents a guest-facing prompt on the guest's own device: 'There's the option to configure default tip amounts of 15%, 20%, or 25% that will automatically appear in a customer's basket... a tip will automatically be selected at checkout'. The retired 'Applying tips to Switchboard orders' (360052983452, updated 2021-03-03) is a staff-entered tip on phone orders (15/20/25% presets or custom), not a guest prompt, and adds 'Olo doesn't support split-tipping'. Post-order change: 'Adjust a Sale Total (Partial Refunds)' (retired, updated 2021-02-19, Wayback 2021-06-24) lets a Dashboard user click 'Other Actions' and then 'Adjust Subtotal' or 'Refund Tip' 'depending on what changes you need to process, a subtotal adjustment or a tip adjustment'. It carries a window, 'There is a 90 Day Limit for refunds', and 'You can only adjust an order once'. Shortfall: tips are fixed and charged at online checkout, not pre-authorised and then adjusted. The only tip-specific post-order action is a downward refund of a captured charge, so the 90-day limit is a refund window, not a batch or tip-adjust window. No manager screen for unadjusted tips is documented. Date caveat: 2020-2021 archived articles; the live 2026 help centre has no guest tip-prompt article (its 'tip' hits are Dispatch driver-tip distribution and 'Tip:' callouts). https://web.archive.org/web/20210624183621/https://olosupport.zendesk.com/hc/en-us/articles/360055753912-Adjust-a-Sale-Total-Partial-Refunds- · retrieved 2026-09-13 adversarially verified

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

The document says: “TipHaus syncs directly with POS, automatically detecting all relevant sales and employee data. From steakhouses to coffee shops, managers can create as many tip sharing or tip pooling rules as needed.” CORRECTED. I first scored this no at grade B on a corpus in which tip pooling tokenised to zero. That zero was measuring a truncated crawl, not Olo: the partner directory was cut at a contiguous alphabetical tail, which is exactly where the tip vendors sit. Over the final 1,628-document corpus tip pooling is 4 occurrences in 2 documents, tip pool 2 in 1, tip sharing 2 in 1, all of them Olo partner pages. Why this is partial and not no: the connective tissue is Olo's own. Every one of these pages carries the notice that the integration is currently only supported through the Omnivore API, and Omnivore is an Olo product, not a third party's - the FY2024 10-K names our acquisitions of Wisely Inc. and Omnivore Technologies, Inc., with the acquisition dated 2022-03-04 (grade A). A brand on Olo can therefore reach configurable pooling through middleware Olo owns and sells, which is materially different from a vendor that has no path at all, and the payroll leg of the claim has a matching Olo-owned pipe: Proliant's page describes a two-way Omnivore integration sharing employee and pay information between payroll and point-of-sale systems. Why this is not yes, named precisely: no Olo surface computes, stores or displays a tip pool. Olo's own tip feature is the two-party Dispatch split (article 35828711816219), which states the POS keeps receiving one aggregate tip amount, so pooling of the restaurant's share happens outside Olo; the rules engine is a separately licensed third-party product (TipHaus, TipReports, Tip n Post), the integration is explicitly not through Olo Ordering or Dashboard but through the Omnivore POS API, and Olo employs no one on the restaurant's behalf so it holds no hours or role record of its own. On the claim's four named allocation bases, the corpus evidences two and only two, both on the TipReports page and neither on the document cited here: point-based and percentage-based tip share structures. Hours worked is evidenced by nothing - it tokenises to 0 documents across all 1,628. Sales is not evidenced as a basis either; the strongest statement is the one quoted here, that TipHaus detects sales and employee data from the POS, which is an input feed, not an allocation rule. A reviewer could defensibly hold this at no on the ground that nothing in the claim's mechanism is an Olo surface; what would settle it is an Omnivore API reference showing which labor and tip endpoints exist, and that document is not in this corpus (only raw/robots.developer.olo.com.txt was fetched). Grade C: the carrying document is a partner marketing page published on www.olo.com. Bounding: these figures are from the 1,628 documents in .cache/q225/txt (index.tsv www row 657), not the 608 HTML files in corpus/www - four fetched partner pages (tattle, td-merchant-solutions, techtris, thanx) were never converted and are invisible to the tokeniser, so I grepped them directly and found no tip term - and 58 /partners/ slugs are still unfetched (still-missing.txt) against 392 partner URLs in Olo's sitemap and a directory facet reading All 340. Every bound over the partner directory in this note is therefore a floor with a named remainder of 58, never a ceiling. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: tip pooling 4 occurrences in 2 documents, tip pool 2 in 1, tip sharing 2 in 1, hours worked 0 ALL REPRODUCE over the complete corpus. This cell is now the one that catches its sibling: the reporting analyst published tip pool is 0 over a truncated corpus for reporting-tip-tax-compliance and did not re-run it; this note's figures are the correct ones. VALUE, GRADE, URL AND QUOTE UPHELD at partial/C. THE AUDITOR TESTED THE OMNIVORE ARGUMENT FOR CONSISTENCY ACROSS THE BATCH, because it is a large lever: 106 of the 392 partner pages carry the Omivore service tag, so reachable through Olo-owned middleware cannot by itself convert every partner capability into an Olo `partial`. It does not, and the line the batch draws is principled: this claim and extensibility-payroll-export ask for a computation or an export that the partner demonstrably supplies over that middleware, whereas multi-location-central-labor-policy asks for enforcement AT THE TERMINAL, which no partner supplies over it either. The distinction is stated here so the three cells can be read together. The analyst's own caveat is endorsed and repeated: a reviewer could defensibly hold this at `no` on the ground that nothing in the claim's mechanism is an Olo surface. https://www.olo.com/partners/tiphaus · retrieved 2026-09-06

Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator

payments-offline-store-and-forward

Store-and-forward is shipped and named as such, in the Olo Pay card-present terminal bullet list: 'Offline capabilities (store and forward) ensure your restaurant won’t lose out if connection is lost', alongside 'EMV-compatabile devices shift fraud liability off brands', 'USB-connected devices ease setup', 'Support for gift card refunds and full and partial refunds' and 'Point-to-point encryption offers the highest level of protection of your guest data'. The Olo Pay product page repeats it as a bare bullet, 'Offline capabilities'. SHORTFALL, and it is the whole second limb of the claim: no configurable per-transaction floor limit, no cumulative offline ceiling, no offline duration cap and no post-reconnect failed-payment report is documented on any release page, on /pay, or in the 231 help-centre articles - the marketing bullet quoted here is the entire public description. Separately, the one help-centre 'Offline Mode' hit is the POS's offline mode, not Olo's, and it degrades rather than buffers. Consistent with this record's existing no on payments-offline-decline-liability. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. The missing-limits shortfall therefore rests on the closing www surface (the Spring 2025 release page and /pay, which together are the entire public description) rather than on the help centre. https://www.olo.com/quarterly-release/spring-2025 · retrieved 2026-09-04

Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator

payments-offline-decline-liability

Olo advertises the surface but not the liability. The Spring 2025 release page markets Olo Pay card-present with 'Offline capabilities (store and forward) ensure your restaurant won't lose out if connection is lost' - a claim pointing the opposite direction from a loss disclosure. The public Olo Pay Terms & Conditions (last updated 2024-06-27), the document that does allocate transaction risk (s.11: unauthorized, irregular or fraudulent charges 'shall remain the full responsibility of Merchant'; s.2.6 settlement only for funds received), contain no offline, store-and-forward or deferred-authorization provision at all. Help-centre searches for 'offline', 'store and forward' and 'declined payment' (2026-08-04) surface no offline-payments article and no post-reconnect failed-offline-payments report. Neither limb of the claim - published decline-loss allocation, post-reconnect failure report - is publicly documented. https://www.olo.com/olo-pay-terms-and-conditions · retrieved 2026-08-04

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

The document says: “Cash, credit card, and gift card payment” OUTSIDE THE 23, AND CORRECTED BY THE AUDITOR BECAUSE THIS SWEEP'S EVIDENCE FALSIFIES THE ROW AS IT STOOD. The standing row held `no` at grade B cited to https://www.olo.com/ with the reasoning that the home page shows a fully enumerated 16-SKU suite containing no stored-value product, and it extended that reasoning to validate the blanket no across the labor, inventory and kitchen sections. That is premise P1, and P1 is false: the FY2024 10-K states Our platform currently includes the following modules: Ordering, Dispatch, Rails, Switchboard, Network, Virtual Brands, Kiosk, Catering+, Sync, GDP, Marketing, Sentiment, Host, and Olo Pay - fourteen modules including Virtual Brands and Kiosk, which the nav omits, while the nav carries Serve, Olo Loyalty, Olo Accounts and Order with Google, which the filing omits, and the filing's own list is introduced by includes. Neither list is a product census, so the home page could not establish this proposition, and a marketing home page is grade C at best in any event. THE TWO CLAIMS THIS ROW HAD COLLAPSED, RULED ON SEPARATELY. (i) DOES OLO ACCEPT A GIFT CARD AS A TENDER? YES, and this is settled by the cited article, which is live, updated 2024-07-08, and unusually carries an explicit ceiling sentence - it enumerates the functionality available for the Dine-In handoff mode, the quoted line among it, and closes Any functionality not explicitly mentioned above is not supported at this time. Gift card tender is inside that ceiling, not outside it. It is corroborated across the corpus by the Terms of Use naming a Branded Company-specific gift card as an accepted Payment Provider, by the Aloha Stored Value integration, by Paytronix Comp Cards as a Serve payment method, by gift-card refunds on Olo Pay terminals, by the Summer 2026 Ecard integration processing gift cards across 150+ POS systems, and by twelve third-party gift processors carrying the directory's Gift Cards service tag. (ii) DOES OLO ISSUE OR HOLD A STORED-VALUE BALANCE? NO. Every gift instrument in the corpus belongs to the brand or to a third-party processor; the Ecard integration is described as working without disrupting the brand's existing program; Olo Loyalty's seven offer types contain no loadable balance and its money-shaped construct, Points Banking, is priced in points; its only liability export is unused points and rewards; and the tokenised controls gift balance, value card and e-gift are each 0 documents over the complete 1,628-document corpus, with the concept term stored value occurring 140 times in 127 documents of which the only live-KB carrier is the Aloha POS FAQ answering that Olo integrates to NCR's Aloha Stored Value. THE VALUE THEREFORE HOLDS AT `no`, because this claim as written asks for FIRST-PARTY gift cards with real-time balance tracking, and Olo issues none - but it held for the wrong reason on the wrong document, and the row is re-cited from a marketing home page to a live help-centre article that carries an explicit ceiling and makes the accept-versus-issue distinction visible. THE SENTENCE THAT MUST NOT SURVIVE is the old note's use of nav silence to validate absences in three other categories; that is the P1 fallacy propagating, and any cell resting on it should be re-opened. https://olosupport.zendesk.com/hc/en-us/articles/360050334652-How-to-Enable-Dine-In · retrieved 2026-09-06 adversarially verified

House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.

payments-house-accounts

Catering+ ships Preferred Accounts, invoicing, and tax-exempt certificate upload. Per-account credit limits and periodic statement generation are not documented. https://www.olo.com/product-release · retrieved 2026-08-01

A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.

payments-split-tender

Splitting exists and is enumerated: guests 'elect to split equally, split by items, or define specific amounts contributed by each guest' via the Pay at Table QR flow, each paying 'on their personal device', so one check does settle across multiple tenders. Three of the claim's four axes are met - even shares, by item, arbitrary amount. SHORTFALLS: no split-by-seat, and Olo holds no seat model at all (Company Menu Admin has categories, products and modifiers only); no published cap on the number of ways a check may be split, so the 'no hard cap below eight' condition is unverified rather than met; and this is a guest-facing digital flow, not a server tender screen - Olo ships no POS, so mixed cash/card or gift-card-plus-card settlement on the operator side belongs to the integrated POS. Grade C: a marketing release page, and the sentence quoted is its entire description; the help centre has zero hits for 'split check', 'split equally' or 'split by item'. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. The 'zero hits for split check / split equally / split by item' sentence is therefore a floor, not an enumeration, and the split-by-seat and split-cap shortfalls stand as unestablished rather than as measured absences. https://www.olo.com/quarterly-release/winter-2023 · retrieved 2026-09-04

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

Winter 2026 added dashboard void-before-capture; Dispatch supports refunds. Role-based authorization and an immutable approver audit log are not documented. https://www.olo.com/winter-release-2026 · retrieved 2026-08-01

In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator

payments-chargeback-tooling

The Olo Pay page publishes outcome statistics ('Saved in $11M in chargeback fees', '$240,000 won in response to fraudulent disputes') but describes no dispute-management tooling, evidence submission workflow, or deadline tracking. Outcome stats are not a capability. Spring 2026 in-store dispute tracking supports partial, not yes. https://www.olo.com/pay · retrieved 2026-08-01 adversarially verified

Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator

payments-card-on-file

Verified verbatim on the Olo Accounts page: guests 'securely save their contact, delivery, and payment information on file for faster checkouts' with one-time-code verification, and 'passwordless checkout at any restaurant in the Olo Accounts network'. Note the page states '25M+ guests on the network' and 'more than 500 restaurant brands', which conflicts with the dossier identity section's '108 million connected guests' — the researcher should reconcile which metric counts what. https://www.olo.com/olo-accounts · retrieved 2026-08-01 adversarially verified

Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator

payments-payout-timing

A deposit cadence is published for card-present: 'The gross settlement payout model for card-present payment processing through Olo Pay provides brands with daily payouts that contain their total accepted payments for a given day', the stated purpose being to 'match daily payouts with POS sales, reducing teams of daily reconciliation tasks and further simplifying reporting.' Supporting reporting exists (Summer 2023 shipped a payout report with a day-by-day breakdown of all deposits; Fall 2023 an Itemized Payout Report covering sales, refunds, chargebacks and fees). SHORTFALLS: 'daily payouts' names a cadence, not a settlement lag - no T+1/T+2 figure, no cutoff time, and no schedule at all for card-not-present is published anywhere; and no next-day, same-day or instant-funding option is offered in any Olo material. The binding Olo Pay Terms and Conditions publish no timing whatsoever and disclaim the obligation, settling only what the Acquirer has already remitted, with discretionary Rolling Reserve and Reserve Minimum holdbacks on top. Grade C, marketing release page; the legal document that would raise this to B is silent on timing. https://www.olo.com/quarterly-release/spring-2024 · retrieved 2026-09-04

A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator

payments-multi-entity-routing

Per-location banking is visible but the routing structure is not: the Summer 2026 release ships 'Bulk assigning banking account details in onboarding' for Olo Pay - bulk assignment only makes sense across many location/entity accounts - and the Olo Pay T&C settle funds 'to Merchant's designated bank account' per merchant agreement, consistent with each franchisee/legal entity holding its own account under the brand's unified Dashboard reporting (e.g. the Daily Credit Card Placed Orders by Store report). Shortfall: no public document describes the MID or split-settlement structure or per-legal-entity routing rules, so the mechanism is inferred from onboarding tooling rather than documented. https://www.olo.com/product-release · retrieved 2026-08-04

Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.

payments-p2pe-pci4

Olo Pay claims 'point-to-point encryption'; Olo's DPA requires compliance with 'PCI-DSS version 4.0 and any subsequent versions.' No AoC or P2PE listing published or offered on request in public materials. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).

delivery-driver-roster

Strengthened, not weakened. The Dispatch page's own framing is 'Forget about managing your own drivers', and its stated purpose is to 'eliminate the need to manage a courier fleet'. It does list 'Delivery providers and self-delivery options' as a setting, but there is no driver entity, clock-in/out, or run history. No is correct and now affirmatively supported rather than inferred. https://www.olo.com/dispatch · retrieved 2026-08-01 adversarially verified

Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).

delivery-dispatch-board

Single dashboard managing multiple provider integrations with delivery monitoring and performance analytics. Multi-order run batching to one driver is not documented (DSP-brokered model). https://www.olo.com/dispatch · retrieved 2026-08-01

Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator

delivery-route-map

The document says: “Send Olo updated delivery statuses and estimated time of arrival / delivery with courier location updates every 30 seconds after a courier has been assigned.” Delivery Guidelines is Olo's own start-to-finish split of responsibilities between the Dispatch customer and the delivery service provider, and it assigns every routing function to the DSP: the DSP accepts a quoted order within five minutes, passes order details to its own courier, and pushes courier location back to Olo every 30 seconds. Olo therefore receives a courier position it did not compute, and there is no multi-stop run for it to sequence, because each Dispatch order is bid on and awarded to a single DSP courier (Dispatch Store Settings, article 360026943032, enumerates the whole quote/tie-breaker/preferred-provider mechanism and contains no routing control). An operator-side map does exist and I am not denying it: the Expo Mode Comparison Chart (article 360043362692) carries a Dispatch driver-map row, and per trap 2 I confirmed it against the raw HTML body in .cache/q225/raw/zd-articles.json rather than the flattened text - the table's three header cells are Feature, Companion, Standalone (there is no Supported/Not-Supported pair), and the driver-map row's two data cells are both green check glyphs. But that chart's Dispatch block enumerates seven driver capabilities (re-request, driver status, driver map, driver name and phone, and cancel/delayed/early notifications) with no routing or sequencing row, and the archived Expo driver-map article (web.archive.org capture 2021-08-02 of article 4402543933211; a later revision exists and was not read for this proposition) says the map draws exactly three markers: restaurant location, delivery location, driver location. Bounding the absence: Delivery Guidelines is a ceiling rather than a floor because it purports to state the complete set of obligations for the delivery from start to finish and puts dispatching, pickup and dropoff routing on the DSP side of that line. Corroborating, and now stronger after the partner-directory tail was fetched, Olo's own directory sells the routing to its brands as somebody else's product: GetSwift (automates your dispatching, routing and tracking, utilizing your own fleet), Cartwheel (a Driver app and a Dispatch app) and Onfleet (a web-based dispatch dashboard that helps businesses route and dispatch efficiently). Controls re-run 2026-09-06 over the current corpus, all still zero and all unchanged across three corpus revisions: sequencing 0, multi-stop 0, turn-by-turn 0, geocoded 0, geocode 0, dispatcher 0, batched 0. Those zeros are bounded to the 1,628 documents actually present in .cache/q225/txt (index.tsv: www 605, wayback-kb 680, zd-public 231, zd-guest 55, sec 5), NOT to what was fetched: .cache/q225/corpus/www holds 608 HTML files, four of which (tattle, td-merchant-solutions, techtris, thanx) were never converted to text and are invisible to the tokeniser, so I grepped those four raw files directly for every control above and found no hit. A further 58 sitemap URLs, all /partners/ slugs, remain unfetched (.cache/q225/still-missing.txt), and Olo's sitemap publishes 392 partner URLs against the 340 in this corpus, so any bound over the partner directory is a floor with a named remainder, not a ceiling. Also not read: the 149 KB ids that return 401. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: sequencing 0, multi-stop 0, turn-by-turn 0, geocoded 0, geocode 0, dispatcher 0, batched 0 ALL REPRODUCE over the complete corpus including the previously-unread 52-page partner tail. CONTROL CAPABILITY TESTED AND PASSED: routing fires on 30 documents / 60 occurrences and route on 19, so these controls were capable of firing. THE STATED BOUNDING ENUMERATION IS FALSIFIED AND IS REPLACED. The note says Delivery Guidelines purports to state the complete set of obligations for the delivery from start to finish. The article's own opening says the opposite: The details below serve as a set of guidelines for Dispatch customers and delivery service providers (DSPs) to highlight the responsibilities associated with the delivery from start to finish. This article may be updated from time to time with new obligations. A document that highlights responsibilities and reserves the right to add obligations is a FLOOR. VALUE, GRADE, URL AND QUOTE UPHELD, on the support that actually carries them: (a) the quoted sentence, affirmative prose describing a different mechanism - the DSP computes the courier position and pushes it to Olo every 30 seconds, so Olo receives a route it did not compute; (b) the Expo Mode Comparison Chart (360043362692), which IS a genuine ceiling because it is a checkmark/cross matrix that records real absences (Ability to issue partial refunds/adjustments is crossed for both modes), whose Dispatch block carries seven driver rows and no routing or sequencing row; and (c) the mechanism - each Dispatch order is bid on and awarded to a single DSP courier, so no multi-stop run exists for Olo to sequence. https://olosupport.zendesk.com/hc/en-us/articles/360049420592-Delivery-Guidelines · retrieved 2026-09-06

Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator

delivery-driver-tracking

'Driver tracking and delivery monitoring' is not language on the cited Dispatch page. The page markets a branded direct-delivery guest experience and DSP orchestration. Guest-facing courier tracking is highly likely in a DSP-brokered model and is implied by 'consistent guest experience', but operator-side live driver tracking is not documented. Marketing-page inference presented as documented capability. https://www.olo.com/dispatch · retrieved 2026-08-01 adversarially verified

Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator

delivery-zones-polygon

Serviceable areas exist as a brand-controlled variable but are negotiated with the courier, not drawn by the operator. This article, Dispatch column: 'the restaurant brand controls the delivery variables including fees and serviceable areas in partnership with the DSP' and 'For serviceable areas, the brand primarily decides the areas they would like to service, but they must also work with a DSP willing to service that area as well.' For Rails it is the opposite: 'marketplaces generally control the delivery variables including fees and serviceable areas'. SHORTFALLS: no geometry is documented anywhere - polygon, radius, geofence and boundary return zero hits across all 231 help-centre articles and all 35 www.olo.com pages, and the phrase delivery area appears once, in Dispatch Store Settings, only as a consequence of blocklisting a DSP. The Dispatch Store Settings article enumerates every per-store Dashboard setting (Dispatch on/off, quote tie-breaker, min/max order amount, max delivery fee, max transit time, vehicle types, preferred and blocklisted providers, notification emails, pickup instructions, Quick Ticket, automated guest refunds, delivery taxable, advance orders, priority order value, fee tiers, tip distribution) plus the settings Olo manages internally, and contains no zone, map or boundary control at all; its only geographic levers are the max-transit-time rejection rule and allowed vehicle types. An operator therefore cannot self-serve a polygon or a drive-time isochrone; coverage is whatever a DSP will bid on. Not scored 'no' because the help-centre census is not closed - see the note on reporting-raw-warehouse-export. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. NAMED GATED ARTICLES ON THIS SUBJECT: 'Dispatch Coverage Report' (360008462551), 'manage Delivery Service Providers' (115001407966), 'Dispatch' (360001000911) and "Expo's Dispatch features" (360057267892) are all gated, and a coverage report is squarely zone-adjacent, so the 'polygon / radius / geofence / boundary return zero hits' sentence must be read as a floor. What survives is the affirmative Dispatch Store Settings setting-by-setting enumeration and the Rails-vs-Dispatch control split. https://olosupport.zendesk.com/hc/en-us/articles/13470115810203-What-is-the-difference-between-Rails-and-Dispatch · retrieved 2026-09-04 adversarially verified

Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.

delivery-zone-pricing

The source does not say 'customizable delivery zones and pricing controls'. It says 'Set fee limits and max transit times'. A fee cap is a real cost control, but the 'zone' half of the cell is not supported by the cited page at all. Partial on fee limits only. https://www.olo.com/dispatch · retrieved 2026-08-01 adversarially verified

Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.

delivery-address-validation

Out-of-zone rejection happens at order time, but as a by-product of courier quoting rather than as a documented address check. Dispatch Overview, order flow: upon selecting Delivery the customer enters their 'delivery address and receives the best-matched quote from available DSPs. They will then be able to view the delivery fee and estimated delivery time returned from the DSP' - the address is submitted and priced before the basket is accepted, and if no DSP bids the guest cannot continue on Delivery. The separate Dispatch Store Settings article adds two operator-set rejection rules on that same quote (Dispatch unavailable if the quoted DSP fee exceeds Max Dispatch Delivery Fee; quotes rejected if the quoted transit time exceeds Max Transit Time) and a brand-customisable customer-facing Dispatch error message. SHORTFALLS: the claim asks for validation/geocoding against a mapping service and nothing in the corpus documents that - geocode, autocomplete, undeliverable and address validation are zero-hit across all 231 articles and all 35 www pages - so a mistyped but in-zone address is not shown to be caught, and no equivalent check is documented for self-delivery or for Rails orders, where the marketplaces rather than the brand control fees and serviceable areas. Cited article edited 2022-04-04, the oldest surface used in this batch. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. DECIDING GATED ARTICLES: 'Failed Order at Checkout' (360042581071) and 'Failed Order (403 error)' (360044561392) are gated and are exactly where an address-rejection or geocode-failure behaviour would be documented, so 'geocode / autocomplete / undeliverable / address validation are zero-hit across all 231 articles' is a floor result. The partial rests on the affirmative Dispatch Overview quote-at-address-entry flow, not on that absence. https://olosupport.zendesk.com/hc/en-us/articles/115000835946-Dispatch-Overview · retrieved 2026-09-04 adversarially verified

Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator

delivery-driver-comp

The document says: “Our system will only ever transmit the driver's designated portion of the tip to the DSP and subsequently to the driver.” This article documents the only driver-compensation mechanism Olo has: a percentage of the guest tip, configurable per store and per DSP, which Olo transmits to the DSP, which in turn pays its own courier. The article is explicit that no POS change is needed because the POS keeps receiving one aggregate tip amount, and that the resulting split is viewable in a Dashboard Tip Splitting Report. That is an inter-company fee split, not a per-delivery compensation ledger: Dispatch couriers are the DSP's contractors, so Olo holds no driver record onto which mileage or a per-run flat reimbursement could be attached. Bounding the absence: Dispatch Store Settings (article 360026943032) is the vendor's own complete settings table for Dispatch - it lists every setting exposed in Dashboard and then names the further settings Olo manages internally - and its only driver-money control is Driver Tip Distribution; that makes it a ceiling for Dispatch configuration rather than a floor. Controls re-run 2026-09-06 over the final 1,628-document corpus: mileage still 1 document (the archived Aloha POS error-code list, in no compensation sense) and reimbursement still 10 occurrences in 3 documents (six DEFM14A, three S-1, one Dispatch article about requesting reimbursement from a DSP), both unchanged across three corpus revisions. Payroll MOVED and is corrected here: 62 occurrences in 8 documents, up from 57 in 6, because the newly fetched partner-directory tail added Paychex and Proliant. That matters and I record it rather than bury it: Proliant's page says its integration with Omnivore - Omnivore being an Olo-owned product, acquired 2022-03-04 per the FY2024 10-K - is a two-way link between payroll and point-of-sale systems sharing employee and pay information. So Olo does own a pipe that can carry pay data to payroll. It still does not carry the claim, because the inputs the claim names do not exist anywhere: mileage or distance per run is unrecorded, there is no per-delivery flat reimbursement field, and the pipe runs POS-to-payroll for the restaurant's own employees while a Dispatch courier is the DSP's contractor who never appears in either system. Figures are bounded to the 1,628 documents in .cache/q225/txt (index.tsv www row 657), not to the 608 HTML files in corpus/www; the four fetched-but-unconverted partner pages were grepped directly and contain none of these terms, and 58 /partners/ slugs remain unfetched (still-missing.txt) against 392 partner URLs in Olo's sitemap, so the directory bound is a floor with a named remainder. The public KB is separately a 26.8% floor (231 public bodies referencing 288 ids, 149 of the missing returning 401). AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: mileage 1 document, reimbursement 10 occurrences in 3 documents, payroll 62 occurrences in 8 documents ALL REPRODUCE exactly over the complete corpus; the analyst's own correction of payroll to 62/8 is confirmed and is the figure the reporting analyst failed to pick up. THE STATED CEILING IS OVER-READ AND IS NARROWED. Dispatch Store Settings is a fair ceiling for the settings EXPOSED IN DASHBOARD (The following Dispatch Settings will show up that you can manage for a single store), but the note also treats its internal tier as closed. That tier reads Additional settings are managed internally by Olo and are not available directly in the Dashboard. Please reach out Olo Support ... to update these settings: followed by exactly ONE named item, with no completeness assertion - a floor of one, not an enumeration. VALUE, GRADE, URL AND QUOTE UPHELD on the mechanism and the quoted sentence: Olo transmits a percentage of the guest tip to the DSP, the courier is the DSP's contractor, and no Olo surface holds a driver record onto which mileage or a per-run reimbursement could attach. CORROBORATION FOUND BY THE AUDITOR, archived and therefore never sole support: Reconcile Dispatch Tips (web.archive.org capture 2019-08-21, article stamped Updated May 16, 2019; a later revision exists and was not read for this proposition) instructs that the store should never pay the tip amount to the driver directly and that tip payment is handled between the delivery provider and the driver - which is the same absence of a per-driver settlement, stated affirmatively. https://olosupport.zendesk.com/hc/en-us/articles/35828711816219-Dispatch-Driver-Tip-Distribution · retrieved 2026-09-06

Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.

delivery-cash-reconcile

The document says: “Upon checkout, the guest pays for the contents of the basket and the delivery quote; payment for the delivery quote, either whole or subsidized, is added directly to the restaurant's merchant account.” Dispatch Payment Flow is Olo's end-to-end description of how money moves on a delivery order, and it describes a fully prepaid card flow with no cash leg and no driver leg: the guest pays basket plus delivery quote at checkout into the restaurant's merchant account, the store floats the Dispatch fees and tips, DSPs periodically invoice Olo, and Olo then invoices the restaurant monthly. There is no point at which a courier holds the restaurant's money, so there is nothing for a settle-up to reconcile, and Olo has no driver roster to compute a per-driver over/short against - the courier is the DSP's contractor, and Delivery Guidelines (article 360049420592) assigns the courier's conduct to the DSP and tells couriers never to ask for a tip. Bounding the absence: this article is a ceiling rather than a floor because it is written as the complete flow between consumers, merchants, DSPs and Olo, not as a list of examples. Caveat recorded honestly: Olo does support unpaid orders - the live Toast POS FAQ (article 360055538772) and NCR Cloud Aloha POS FAQ (article 360041745972) both answer yes to whether payment can be accepted in-store - but that is a check left open on the store's own POS for a guest who arrives, not cash handed to a driver. The Olo Pay product page lists its supported payment methods as credit cards, contactless payments and mobile wallets, and I treat that as a floor rather than a ceiling because the list is introduced by including; cash is not among them. Controls re-run 2026-09-06 over the final 1,628-document corpus, all unchanged across three corpus revisions: cash on delivery 0, cash tender 0, driver bank 0, settle up 0, over/short 0; pay in store 20 occurrences in 9 documents, all archived and all Switchboard or POS-configuration articles, none a Dispatch article. The newly fetched partner-directory tail added no cash-handling or driver-settlement partner. Figures are bounded to the 1,628 documents in .cache/q225/txt (index.tsv www row 657), not to the 608 HTML files in corpus/www; the four fetched-but-unconverted partner pages were grepped directly and contain none of these terms, and 58 /partners/ slugs remain unfetched against 392 partner URLs in the sitemap, so the directory bound is a floor with a named remainder. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: cash on delivery 0, cash tender 0, driver bank 0, settle up 0, over/short 0 and pay in store 20 occurrences in 9 documents ALL REPRODUCE over the complete corpus. CONTROL CAPABILITY TESTED AND PASSED: cash payment fires on 3 documents and cash drawer on 2, so the zero-hit controls were capable of firing. THE STATED CEILING IS FALSIFIED AND IS REPLACED. The note says Dispatch Payment Flow is a ceiling rather than a floor because it is written as the complete flow ... not as a list of examples. The article says of itself: Below is an example of a typical order placed via Dispatch and how the fees are passed between consumers, merchants, DSPs, and Olo, and its diagram footnote says This flow diagram is representative of Olo's subscription based pricing model. It calls itself an example and representative. VALUE, GRADE, URL AND QUOTE UPHELD on what does carry them: the article's general, non-example statement of the money path - Olo holds agreements with Delivery Service Providers (DSPs) directly, so there is never a need for a direct money transfer between restaurant brands and the DSPs, plus the quoted prepaid checkout - and the mechanism, that the courier is the DSP's contractor and never holds the restaurant's money. ONE FACT THIS NOTE UNDERSTATED: Olo does document a cash payment path - the live How to Enable Dine-In article lists cash among Dine-In functionality - but it is the guest paying in the store on the store's own POS for a dine-in handoff, not cash handed to a Dispatch courier, and no document in the corpus puts cash on a delivery order. https://olosupport.zendesk.com/hc/en-us/articles/360000412152-Dispatch-Payment-Flow · retrieved 2026-09-06

Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.

delivery-daas-dispatch

Verified verbatim on the Dispatch page: '27+ delivery service providers', '96% Of Olo brands covered by 2+ DSPs', '28 min Average delivery time', 'Automated delivery rescues'. This is the one delivery cell where the quoted numbers are actually on the page. https://www.olo.com/dispatch · retrieved 2026-08-01 adversarially verified

Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator

delivery-daas-fallback

Fallback rules for provider failures and 'automated delivery rescues' are documented, with 96% of locations covered by 2+ providers — but this is DSP-to-DSP overflow, not in-house-driver-to-DaaS overflow. https://www.olo.com/dispatch · retrieved 2026-08-01

Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator

delivery-3p-direct-integration

Olo Help Center, Supported Rails Marketplaces, enumerates the marketplaces 'we're currently live with' and names DoorDash, Grubhub and Uber Eats explicitly alongside Caviar, ezCater, delivery.com, 7NOW, Allset, DeliverLogic, EatStreet, Favor, Food Dudes, Kitchen United, Ritual and Zifty. The brand signs its own contract with each marketplace; Olo owns the integration. The Rails DoorDash self-service article documents a direct DoorDash OAuth login, store mapping and menu qualification driven from the Olo Dashboard, with no middleware vendor in the path. https://olosupport.zendesk.com/hc/en-us/articles/360032449272-Supported-Rails-Marketplaces · retrieved 2026-08-02 adversarially verified

Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.

delivery-3p-injection

Rails consolidates all digital orders regardless of origin 'without manual entry into the POS system.' https://www.olo.com/rails · retrieved 2026-08-01

Menu, pricing, modifiers, and photos publish from the POS master menu out to connected third-party marketplaces, including channel-specific price markups, without maintaining a separate menu in each portal.

delivery-menu-push

DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. All four menu flags are TRUE for `olo_rails`, inside an active collection: `MENU_PULL_SUPPORTED` ('Real-time menu syncing'), `MENU_CONTAINS_ITEM_IMAGE_URL` ('Integrated images'), `CHANNEL_BASED_MENU` ('Channel Based Menus') and `MENU_CONTAINS_ITEM_LEVEL_BASE_PRICE` ('Dual Pricing'). Those cover every element the claim names — menu, photos, and channel-specific price markups — and Olo is one of only five providers in the registry with `CHANNEL_BASED_MENU` built. This replaces a grade D marketing-page citation. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12

Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).

delivery-86-sync

DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. The flag `ITEM_LEVEL_86` is TRUE for `olo_rails`. DoorDash labels the flag 'Real-time item 86ing' and defines it on the programme page as 'Real-time item 86ing - updates item availability across systems when items are marked unavailable.' That answers the prior shortfall, which was that item-level 86 is not explicitly enumerated as a named capability. `partial` is retained because the claim also requires restore-on-availability, which no flag carries, and because this attests the DoorDash channel only. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12

Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.

delivery-store-pause

Rails Management lets managers 'give and remove access' to each marketplace per store, or 'for all stores and all marketplaces in bulk', from the Dashboard, and Enable/Disable Store (115000122283) switches off all online ordering with an audited reason. Shortfall, in Olo's own words: 'This feature should not be used as a means to temporarily deactivate a marketplace... Marketplaces do not quickly deactivate a store on their interface based on this feature. If orders are submitted after a marketplace has been deactivated, the orders will fail'; Olo recommends 'working directly with the marketplace' for temporary pauses. https://olosupport.zendesk.com/hc/en-us/articles/360045286812-Rails-Management-Access-Markup-Pricing-and-Roundup · retrieved 2026-09-03 adversarially verified

Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator

delivery-3p-reconciliation

Spring 2026 made marketplace discounts pass through to the POS, described by Olo as 'closing a long-standing reconciliation gap'; Rails gives near-real-time sales data by location and marketplace. Full payout-deposit matching with commission itemization and missing-order detection is not documented. https://www.olo.com/2026-spring-release · retrieved 2026-08-01

Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator

delivery-injection-error-visibility

Verified verbatim: 'Access near real-time sales and error data by location and marketplace.' Corroborated by public per-integration component health on status.olo.com. https://www.olo.com/rails · retrieved 2026-08-01 adversarially verified

Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.

delivery-tracking-page

The Dispatch page supports a branded direct-delivery experience and 'Skip the Line', but does not describe a branded order-tracking page with live status/ETA. Same over-read as the driver-tracking cell. https://www.olo.com/dispatch · retrieved 2026-08-01 adversarially verified

Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator

delivery-promise-time

Sourced to olo.com/ordering, which lists 'Order throttling' and 'Customizable capacity rules engine' but says nothing about dynamically computed quote times. Combining that with Dispatch's 'max transit times' to conclude dynamic promise-time calculation is researcher synthesis, not documentation. https://www.olo.com/ordering · retrieved 2026-08-01 adversarially verified

Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.

delivery-offline-behavior

Olo does not document explicit offline behavior for delivery. The Dispatch FAQ and Dispatch Payment Flow articles (both read 2026-08-04) walk through how Dispatch works - DSP selection, Dashboard features, setup, and the guest-pays-at-checkout money flow ('payment for the delivery quote... is added directly to the restaurant's merchant account') - with no outage/offline section, and help-centre searches for 'offline'/'outage' surface nothing for Dispatch. The claim's cash-delivery-order and driver-settlement scenarios do not exist in Dispatch's documented model at all: delivery is performed by third-party DSPs under Olo's agreements and paid digitally at checkout. https://olosupport.zendesk.com/hc/en-us/articles/360019209451-Dispatch-FAQ · retrieved 2026-08-04

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

Serve is Olo's hosted white-label storefront on the brand's own domain and branding, self-service designable without engineering, with commission-free direct ordering. https://www.olo.com/serve · retrieved 2026-08-01

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

'Centralized menu management for all digital channels' from a single dashboard, synced with the integrated POS. https://www.olo.com/ordering · retrieved 2026-08-01

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

Serve includes a branded mobile app; Summer 2026 shipped native push notifications to Serve mobile app users, and Fall 2025 added Apple ID login. Distinct from the separate Olo Network second-party app. https://www.olo.com/product-release · retrieved 2026-08-01

Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.

digital-account-saved-payment

Olo Accounts: passwordless one-time-code sign-in with saved contact, payment and delivery data, auto-filled on repeat purchase, recognized cross-brand across the Olo network. https://www.olo.com/olo-accounts · retrieved 2026-08-01

Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator

digital-upsell-engine

Olo Help Center, Sales and Orders Reports Overview, documents a 'Product Recommendation Source' report: 'Product-level sales data with attribution to where each item was added to the basket (e.g., Smart Cross Sells).' Its enumerated sources include 'Smart Cross Sell Product', 'Static Cross Sell Product', 'Cross Sell Product' and 'For You Product', filterable by Client Platform, Source and Vendor. This satisfies both limbs of the claim: rules-based (Static) and algorithmic (Smart) suggestions, plus per-item attach attribution reporting on those suggestions. Note the 10-K's Ordering-module capability list does not mention cross-sell at all - the help center is the load-bearing source here. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-08-02 adversarially verified

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Customizable capacity rules engine plus order throttling, applied to scheduled and immediate digital orders. https://www.olo.com/ordering · retrieved 2026-08-01

Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.

digital-fulfillment-modes

Pickup, delivery, curbside and 'other handoff modes' documented with mode-specific fees. Dine-in/QR table ordering is not documented as a handoff mode. https://www.olo.com/ordering · retrieved 2026-08-01

Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.

digital-qr-table

'How to Enable Dine-In' documents a Dine-In handoff mode on Serve web, the mobile app, API and Switchboard with 'Cash, credit card, and gift card payment', loyalty earn/redeem, and 'Custom fields triggered by Dine-in handoff mode selection (i.e. Table Number)' so staff know where to bring the food; Dine-In orders are exempt from throttling. Shortfall: no QR-code generation or table tent is documented, the order is prepaid rather than attached to an open POS check, and no split or tip-at-table flow is described. https://olosupport.zendesk.com/hc/en-us/articles/360050334652-How-to-Enable-Dine-In · retrieved 2026-09-03 adversarially verified

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

'Creating a Kiosk Experience': 'Through Olo's Ordering API, a restaurant can work with an agency to create a digital interface optimized for a physical device' (Shake Shack cited); interested brands 'reach out to your Customer Success Manager or Deployment Manager'. Olo Pay card-present terminals are marketed for kiosks. Shortfall: Olo ships no kiosk application of its own; the kiosk UI is agency-built on the API, and no accessibility or unattended-EMV documentation exists for it. https://olosupport.zendesk.com/hc/en-us/articles/115003300826-Creating-a-Kiosk-Experience · retrieved 2026-09-03 adversarially verified

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

Olo's retired help-centre article 'Group ordering overview' (updated 2017-08-29, Wayback 2019-07-21) documents the shareable-link flow: 'Group ordering is available to all Olo customers and gives you a way to easily aggregate individual orders. This can be helpful for events, office lunches or parties.' 'Customers will have to login to access group ordering'; then 'Begin a group order and you will be given a unique link to invite others to order with you. Set a deadline and invite your group', 'Check your email for a link to manage the order and view the basket containing your group's order', and 'When everyone is finished adding items to the order, use the link to place the order as usual.' Enablement is by support ticket ('submit a ticket on the Help Center'). A 2021 article, 'Order Search by Last 6 Digits of an Olo Order ID' (4408248700699, Wayback 2021-12-02), shows group orders still live: 'When we find a matching Order ID for a group order, we display each guest on a separate line item in the results table.' Payment: the organiser places the combined order 'as usual', i.e. one order with a single payment by inference, which the claim allows; split payment across participants is not documented. Shortfall: no per-person or total spend cap is documented, and the organiser must hold a logged-in account. Date caveat: 2017-2021 archived docs; article 115004451943 is absent from the 2026 Help Center API. Supersedes a prior fabricated olo.com/ordering citation. https://web.archive.org/web/20190721070140/https://olosupport.zendesk.com/hc/en-us/articles/115004451943-Group-ordering-overview · retrieved 2026-09-13 adversarially verified

Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator

digital-catering-portal

Catering+ is a distinct flow with guest-facing quotes, branded PDF proposals with embedded payment links, lead-time settings, invoicing, Preferred Accounts, tax-exempt certificate upload, and event/delivery calendar scheduling. https://www.olo.com/catering · retrieved 2026-08-01

Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator

digital-voice-ai-phone

Switchboard is explicitly a human-operated tool for 'staff or call center agents to quickly digitize and route phone orders' — not AI answering calls. No named certified voice-AI partner verified. https://www.olo.com/switchboard · retrieved 2026-08-01

Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.

digital-drivethru-ai

The document says: “Some restaurants have implemented voice AI technology at the drive-thru or for call-in orders using Olo’s Ordering API and partner ecosystem” Olo's own AI round-up names Voice AI as one of eleven AI capabilities and states affirmatively that restaurants have run voice AI at the drive-thru on Olo's Ordering API together with its partner ecosystem, so lane voice ordering is a real, first-party-acknowledged path into Olo rather than a bare directory listing. Named shortfall, which is why this is partial and not yes: the voice agent is never Olo's. It is a partner's product reaching Olo through the Ordering API - ConverseNow's page describes virtual assistants that automate drive-thru and phone orders, and the newly fetched directory tail adds SoundHound AI, tagged Voice, whose page names a Dynamic Drive-Thru product across more than 10,000 locations - and Olo's FY2024 10-K risk factors list voice ordering among the third-party categories it enters agreements with, not among its own modules. Olo is also not the POS, so the menu and modifier structure the agent orders against is Olo's Company Menu, which POS-integrated brands map to POS entity ids. The second half of the claim, escalation-to-human handoff, has no support anywhere in the corpus, and Switchboard does not close the gap: its live overview describes an operator-driven order management tool for call-in orders and line-busting, with no voice automation and no lane. Neither does anything in the release pages - the only lane-related release is Fall 2024, which lets brands toggle a drive-thru handoff mode and its hours in Dashboard, and Olo's newest AI post (May 2026) says the first agentic capability it is shipping is Hours Management. Controls re-run 2026-09-06 over the final 1,628-document corpus: handoff to a human 0 documents, live agent 0, human agent 0 (unchanged across three corpus revisions); escalate 5 occurrences in 4 documents and escalation 35 occurrences in 14 documents, none in a voice-ordering sense; lane 7 occurrences in 3 documents, none of them drive-thru. Two figures MOVED with the directory tail and are corrected here: voice AI is now 12 occurrences in 6 documents (was 9 in 5; the new document is the SoundHound AI partner page) and drive-thru is now 60 documents (was 56). Figures are bounded to the 1,628 documents in .cache/q225/txt (index.tsv www row 657), not to the 608 HTML files in corpus/www; the four fetched-but-unconverted partner pages were grepped directly and contain no voice or drive-thru term, and 58 /partners/ slugs remain unfetched against 392 partner URLs in the sitemap, so this is a floor with a named remainder - more voice partners may exist, which would reinforce the shortfall rather than remove it. This citation is a vendor marketing page, hence grade C. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: handoff to a human 0, live agent 0, human agent 0, escalate 5 occurrences in 4 documents, escalation 35 in 14, lane 7 in 3 ALL REPRODUCE. Two MOVED again with the final tail: voice AI is now 13 occurrences in 7 documents (was 12 in 6; the new document is the Voicify partner page) and drive-thru is now 65 documents (was 60). The partner directory now closes: 14 partners carry the Voice service tag against a facet reading 12, so the voice-partner set is larger than the directory renders, which reinforces the shortfall rather than removing it. RULING ON PREMISE P7, WHICH THIS ROW WAS SAID TO OVERTURN: P7 IS NOT OVERTURNED, IT IS CONFIRMED. The quoted sentence attributes the implementation to restaurants "using Olo's Ordering API and partner ecosystem" - that is a statement that third parties built lane voice ordering on top of a public API, which is precisely what a partner capability, not an Olo one means. What the sentence does defeat is a bare `no`: Olo affirmatively acknowledges that the lane path works on its platform and names Voice AI among its own eleven AI capabilities, so an absence verdict is not available. `partial` is therefore the right landing, but for the opposite reason to the one given. ON GRADE: a blog post is vendor marketing and grade C is the project's standing treatment; the auditor records that a reading of the grade table which puts a blog post at D would be defensible, and that at C or D this citation could not carry a `yes` in any case. The escalation-to-human conjunct remains unevidenced in BOTH directions and is a named shortfall, not a settled absence. VALUE, GRADE, URL AND QUOTE UPHELD. https://www.olo.com/blog/11-ways-olo-uses-ai-to-fuel-restaurant-growth · retrieved 2026-09-06

Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.

digital-sms-ordering

CLAIM: supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS. VERDICT: partial/B (was unknown). NEW SURFACE: mcp.olo.com, found via crt.sh (%.olo.com, 166 names), is an anonymous Model Context Protocol server. An unauthenticated JSON-RPC 'initialize' POST to https://mcp.olo.com/mcp returns serverInfo {"name":"ordering-mcp-server","version":"1.0.0"}, and 'tools/list' returns 17 tool schemas (31.9 KB; saved at .cache/q319/olo/mcp-tools.json). Only the tool list was read. No tool was called. EVIDENCE (verbatim tool descriptions): search_restaurants "Find nearby restaurants ... across ALL Olo App–enabled brands"; search_catalog "UCP: search the product catalog"; create_cart / update_checkout "fulfillment.handoff_mode sets pickup/curbside/dinein/drivethru"; get_checkout "Once the session has line items and a handoff mode it is validated against the restaurant POS: status ready_for_complete plus final tax/totals on success"; complete_checkout "PLACES A REAL ORDER and charges the payment credential"; notify_order_arrival "the curbside/pickup \"I'm here\" signal"; cancel_order "requests cancellation of a real order". So Olo runs a chat/agent ordering rail whose orders are validated against, and land in, the restaurant POS. WHY NOT yes: it is an MCP endpoint for AI agents (UCP = agent commerce protocol), not a documented operator-facing conversational SMS or text-to-order channel. No olo.com page (659-URL sitemap, controls agent|chatgpt|ucp|mcp = 0 URLs) or release page announces it, so operator availability is not documented. Switchboard's SMS payment link (the existing rationale) stays text-to-pay, not text-to-order. Retrieved 2026-09-16. https://mcp.olo.com/mcp · retrieved 2026-09-16 adversarially verified

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

Olo Help Center, Order with Google FAQ and Onboarding: the brand's Google Business Profile 'Food Ordering button' is toggled on and Google is enabled as a Rails partner on the Rails Management page, after which 'the location should appear on Google for ordering within the same day.' 'The Branded ordering option at the top of the OwG Ordering page is your official branded Olo-OwG integration - with images, menus, etc being syndicated from Olo.' Direct link is provisioned to the GBP and sits above 'Third Party Ordering'. Caveat on the 'Preferred by Business' limb: exclusivity is not automatic - to remove marketplace links 'the brand needs to email their marketplace contact.' Priced as a per-order 'Order with Google Fee' line item; the FY2024 10-K places it in the Network add-on module requiring Ordering and/or Rails. https://olosupport.zendesk.com/hc/en-us/articles/360050780871-Order-with-Google-FAQ · retrieved 2026-08-02 adversarially verified

Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.

digital-apple-business-connect

331st: MOVED unknown -> partial/B. CLAIM: supports Apple Business Connect ordering placement, an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow. NEW EVIDENCE (Olo's own help centre, olosupport.zendesk.com, grade B; body text plus the article's attached screenshots downloaded at full resolution and read as images; the prior notes had Olo Sync naming "no publisher" and 'Apple Maps' at 0 in the KB bodies, which is now falsified). (1) APPLE IS A NAMED SYNC NETWORK. "Sync Listings Health" (article 25924505237275, updated 2024-05-21): "One of the key use cases for Olo Sync is keeping your restaurant's locations–often referred to as Listings in local search ecosystems–discoverable and optimized across heavily trafficked platforms like Apple, Bing, Facebook, Google, and Yelp." Its attached screenshots "Olo Sync - Listings Health - Listings Health by Network.png" and "...Dashboard Overview.png" (OLO Sync Listings Management > Listings Health) show the table tableDataHealthByNetwork with exactly 5 networks: Google Business Profile, Facebook, Apple Maps, Yelp, Bing Places ("Showing 1-5 of 5 entries"). The "How Sync works" diagram in "Sync Overview" (6795952941339, image mceclip0.png) shows the Apple logo among the destination publishers ("Olo automatically pushes updates in near real time"). (2) SYNC PUSHES ORDERING LINKS. "Sync Overview": "Syncs store hours, ordering links, address details, menu information, and more" and "Capture order and conversion data via direct ordering links", "*available for brands using our Ordering product". MET: Olo publishes a first-party listing-management product that syndicates location data to the Apple Maps listing and syndicates direct ordering links to its publishers. SHORTFALL (why partial, not yes): no Olo surface states that the ordering link lands on the Apple Maps place card as an Apple Business Connect 'Order Food' action; the ordering-link sentence is generic across "50+ publishers", and the Listings Health by Field screenshot enumerates 19 monitored fields (Listings Name, Address, Phone, Opening Status, Service Areas, Website URL, Long/Short Description, Business Hours, Special Hours, Service Hours, Category, Email Address, Fax, Impressum, Latitude/Longitude, Payment Forms, Price Range, Social Network URLs) with no order-action/action-link field, so the Apple-side placement type is unconfirmed. The words "Apple Business Connect" and "Order Food" still score 0 on every Olo surface. Retrieved 2026-09-18. https://olosupport.zendesk.com/hc/en-us/articles/25924505237275-Sync-Listings-Health · retrieved 2026-09-18 adversarially verified

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

Olo Loyalty gives direct in-flow access: points balance and progress visible during checkout, real-time accrual and redemption, passwordless enrollment tied to the same Olo Accounts identity. https://www.olo.com/loyalty · retrieved 2026-08-01

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

328th: NEW SURFACE - THE GUEST-FACING SIDE IS NOW A CENSUS, WHICH IS WHAT THE THREE PRIOR PASSES LACKED. Every prior hold on this cell rested on Olo's ADMIN docs being gated; but a guest subscription (recurring billing for a delivery-fee waiver, a per-period entitlement, or a paid loyalty tier) must be enrolled in and redeemed by the GUEST, and the guest app is now fully in hand. Olo Serve (serve-next.olo.com, Next.js, buildId Qf-toB1-JcZW3iX3iMy_c): 25 routes from its own _buildManifest.js, all 51 chunks fetched at 200, 2 rounds, 0 misses, 4,015,455 chars; nonsense control 404. The 25-route table is itself the enumeration: /menu, /basket, /checkout/auth, /favorites, /group-order/*, /locations, /login, /order/arrival/[orderId], /orders/[orderId], /recent-orders, /rewards, /search, /thank-you/[orderId], /user/confirm-email, /user/upgrade - there is no subscription, membership, plan, pass or enrolment route, and no recurring-billing screen anywhere in the app. Tokenised, case-insensitive, word-boundary over all 51 files: recurring 0, renew 0, "per month" 0, "unlimited delivery" 0. POISON PUBLISHED, both traps live in this corpus: `subscription` scores 4 and ALL FOUR are Next.js router internals (`{initialProps, pageLoader, App, wrapApp, Component, err, subscription, isFallback, locale...}` in main.js and pages/_app.js), never a guest entitlement; `membership` scores 5 and none is a paid tier - three are Olo Loyalty reward references (`{membershipId: e.membershipId, reference: e.externalReference}` when applying or removing a reward from a basket) and two are the billing-method variant 'Membership', which the same file resolves to a GIFT CARD or BRANDED CARD (`if("Membership"===t.variant){ ...if(e?.isGiftCard) return "Gift Card"; if(e?.isBrandedCard) return "Branded Card" }`). So Olo's own guest app uses the word membership for stored-value and loyalty identity, not for a subscription. Combined with the 4.1 MB documentation corpus already on record (every 'membership'/'subscription' hit there is an Olo Loyalty member type, an email subscription, or the OPERATOR's own marketing-plan bill), no guest subscription construct exists on any Olo surface. BOUND: guest ordering app + published docs; the Dashboard admin and 149 gated olosupport ids remain out of reach. Retrieved 2026-09-18. https://serve-next.olo.com/_next/static/chunks/9660-47a2b5ee6a50e731.js · retrieved 2026-09-18 adversarially verified

Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.

digital-promo-parity

Coupon manager plus location-based promotional banners (Summer 2026) span Olo digital channels; POS and kiosk parity depends entirely on the integrated POS, which Olo does not control. https://www.olo.com/ordering · retrieved 2026-08-01

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

Olo markets 'full guest data ownership' and GDP 'without vendor lock-in,' but publishes no bulk export mechanism, format, or fee position. Its DPA designates Olo a joint Controller, which qualifies the ownership claim. https://www.olo.com/gdp · retrieved 2026-08-01

Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.

digital-checkout-pci-sca

Checkout is Olo-hosted so card data never touches the brand's page, and Olo's DPA mandates PCI DSS v4.0. Script-integrity monitoring (6.4.3/11.6.1) and 3DS support are not documented publicly. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator

digital-surcharge-transparency

Winter 2026 tiered fees (percentage or flat, varying by order size) and Summer 2026 transparent display of Fees and Estimated Taxes as separate guest-facing line items. Card-surcharge jurisdiction and brand-rule handling is not documented. https://www.olo.com/product-release · retrieved 2026-08-01

Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.

guest-loyalty-unified-profile

GDP unifies transactional, behavioral, demographic and offline data for known and unknown guests across POS, ordering, loyalty, payments, reservations, web and email/SMS. Olo Pay Card-Present pulls in-store card transactions into the same profile. Dedup/merge rules not published. https://www.olo.com/gdp · retrieved 2026-08-01

Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator

guest-loyalty-thirdparty-identity-attach

Marketplace orders cannot attach automatically: for Rails orders 'the marketplace... own[s] customer data. In most cases, customer data shared with Olo is limited to the customer's first name and last initial.' What exists is manual and partner-specific: the Loyalty Dashboard 'Link a Purchase' (46361210581403) attaches an unclaimed purchase to a member by phone number, members can claim receipts in the Member Portal, and the 'Storefront by DoorDash Integration' (46381567369883) credits points only to members who log in ('No support for accruing points on guest orders'). Shortfall: no automatic identity match on DoorDash/Uber Eats/Grubhub marketplace orders. https://olosupport.zendesk.com/hc/en-us/articles/13470115810203-What-is-the-difference-between-Rails-and-Dispatch · retrieved 2026-09-03 adversarially verified

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

Verified verbatim on the Loyalty page: 'Flexible reward structures (points, visits, spend-based)', alongside 'Gamification & tiering systems', 'Multi-concept loyalty programs' and 'Points balance & progress tracking at checkout'. Claim-level marketing, but the quotation is accurate and the capability is explicit. https://www.olo.com/loyalty · retrieved 2026-08-01 adversarially verified

Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator

guest-loyalty-tiers

'Gamification & tiering systems' are marketed. Automatic promotion/demotion on a rolling spend or visit window is not documented. https://www.olo.com/loyalty · retrieved 2026-08-01

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

Olo Loyalty's POS-integration docs state offline behavior explicitly: 'Olo Loyalty functionality is unavailable when the POS is in Offline Mode' - the documented answer is blocked, not queue-and-reconcile - and the same article documents the reconciliation edge case: if an order with an applied reward transitions to offline mode before completion, the reward remains in the member's balance despite being applied to the transaction, a stated duplicate-redemption risk. Behavior is documented per POS integration (Toast article read 2026-08-04; a parallel Revel integration article exists). https://olosupport.zendesk.com/hc/en-us/articles/46383252653979-Toast-Integration · retrieved 2026-08-04

Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator

guest-loyalty-offer-stacking-rules

The 'Offers' article has a section 'Olo Loyalty Offer Stacking Is Not Supported': 'Olo Loyalty does not allow multiple Olo Loyalty offers to be applied in a single transaction. A guest can only use one Olo Loyalty offer at a time'; rewards 'can't be stacked'; combining with non-Olo coupons 'is up to your system rules'. 'Offer Configuration Options' adds that Multiply Points multiples 'do not stack' and a Maximum Applications Per Purchase cap. Shortfall: the rule is fixed (exclusive only); there is no operator-configurable stackable/exclusive flag or precedence order. https://olosupport.zendesk.com/hc/en-us/articles/46336823229979-Offers · retrieved 2026-09-03 adversarially verified

Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator

guest-loyalty-targeted-offers

Olo Help Center, Create and Send to an Audience: in the campaign builder the operator selects an action to 'send an offer, email, or text message,' turns the audience 'Segment ON,' and defines filters matching 'any' or 'all' - the worked example being 'to target those who lapsed 90 days, enter Visits | is | 0 | with last (hours) | 2160.' Offers are therefore issuable to a dynamically defined audience, not broadcast-only. Campaign Types (Automations) adds item- and spend-triggered issuance: Purchase Items Campaign 'triggers when specific item(s) are purchased (by PLU or Item Name)', Purchase Total, Visit Threshold and Point Threshold campaigns. Rules over recency, frequency, spend and items purchased are all present. https://olosupport.zendesk.com/hc/en-us/articles/46359010493083-Create-and-Send-to-an-Audience · retrieved 2026-08-02 adversarially verified

Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator

guest-loyalty-rfm-segmentation

SHORTFALL: the segments are not precomputed - the operator builds every query. The claim requires lifecycle segments computed automatically 'without the operator building the queries.' Olo Help Center, Common Audience Filter Combinations, is a cookbook teaching operators to hand-assemble them: 'Lapsed Members' is 'Visits | is | 0 | with last (hours) | 2160'; 'New Registered Members' is a pair of Brand Join Date conditions with an hour value the operator computes as '24 hours (1 day) plus 10 hours, resulting in 34 hours.' The underlying filter dimensions are genuinely rich (Visits, Brand Join Date, Offer Expiry, Offer Not Used, opt-in state), so rules-based segmentation is real - but no shipped RFM or new/regular/at-risk/lapsed/VIP segment set exists. Help center search for 'recency' and 'cohort' returns zero articles. Downgraded from yes. https://olosupport.zendesk.com/hc/en-us/articles/46359153784731-Common-Audience-Filter-Combinations · retrieved 2026-08-02 adversarially verified

Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.

guest-loyalty-lifecycle-automation

Guided automation builder plus a library of prebuilt automations; Olo cites 75% open rates on automated welcome emails and 15% re-order rates from automated takeout reminders. https://www.olo.com/marketing · retrieved 2026-08-01

Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator

guest-loyalty-native-email-sms

SHORTFALL: email is not native - it is delivered by the third-party Infobip integration. Olo Help Center, Email Actions: 'Email campaigns are only supported with the Infobip integration'; 'For an Infobip email integration, you must use a Infobip Broadcast Email Template'; the operator authors the creative in Infobip's portal and pastes a Template ID into Olo; and 'Infobip emails triggered from the Olo Loyalty Dashboard do not support substitutions,' so per-guest personalization is unavailable on that path. Email Notifications additionally support Mailchimp. SMS is stronger - Text Message Actions composes body copy natively in the campaign builder - but the Infobip Integration article states Infobip is the channel for 'Email and SMS marketing messaging' and 'Contact your Customer Success Manager to enable Infobip.' Downgraded from yes; the record's cited marketing page claimed a single-dashboard native send. https://olosupport.zendesk.com/hc/en-us/articles/46339840523291-Email-Actions · retrieved 2026-08-02 adversarially verified

Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.

guest-loyalty-consent-management

Summer 2026 shipped an automatic TCPA litigator check protecting campaigns from problematic numbers. Per-channel consent capture with timestamp and source of consent, and revocation handling beyond STOP, is not documented. https://www.olo.com/product-release · retrieved 2026-08-01

Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.

guest-loyalty-10dlc-registration

CLAIM: handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform. VERDICT: partial/B (was unknown). NEW SURFACE: getwisely.zendesk.com, the Olo Engage (ex-Wisely) Zendesk help centre, production, articles updated to 2026-09-11. Its HTML /hc/ is not linked from the olo KB, but the anonymous Help Center API serves 158 articles (2 pages, /api/v2/help_center/en-us/articles.json; 7 categories: GDP, Marketing, Sentiment, Host, Technical Documentation, Release Notes, Contact Us) and attachments.json across all 158 yields 2 PDFs (Olo Engage Analytics Suite Overview, 11.4 MB; Olo Engage Marketing Automation Guide, 10.1 MB). NOT A CENSUS: the href fixpoint names 24 article ids absent from the listing; probed, 22 = 404 and 2 = 401 gated (5026107804187, 5026083627931), so no `no` may rest on it. EVIDENCE: "Text Message Notifications" (updated 2024-11-05, Olo Host App): "NOTE: To adhere with A2P 10DLC regulations, freeform messaging will not be supported in the Host App. Changes to messages must be completed by a member of the Support team. If you need to make a change to a text message, please contact support with the specific message you want updated". That is Olo explicitly naming A2P 10DLC and handling compliance itself (Olo controls sender content), consistent with the q319 bundle finding that Olo provisions a per-merchant Twilio SMS service ("createMerchantSMSService"). "Automated SMS Compliance Enhancements" (2025-10-23): Quiet Hours Enforcement (9 PM-8 AM recipient-local) and Reassigned Number Protection, "automatically enabled for all brands". SHORTFALL (why not yes): no article names BRAND or CAMPAIGN REGISTRATION (The Campaign Registry, EIN/brand vetting, who files it, or any fee); controls over 158 bodies + 2 PDFs, word-boundary, case-insensitive: 10DLC = 1 (the quote above), A2P = 1 (same), "campaign registry" = 0, TCR = 0, toll-free = 0. The 10DLC statement is scoped to Host App transactional texts; the Marketing SMS article ("SMS/MMS Overview") documents only double opt-in. Retrieved 2026-09-16. https://getwisely.zendesk.com/hc/en-us/articles/5026048752923-Text-Message-Notifications · retrieved 2026-09-16 adversarially verified

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Campaign performance reporting with order and sales lift measurement; Fall 2025 added Holdout Groups so marketers can measure incrementality against a control group. https://www.olo.com/quarterly-release/fall-2025 · retrieved 2026-08-01

Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator

guest-loyalty-data-export-portability

Data-ownership and no-lock-in claims are prominent, but no self-serve CSV/API export path for the full guest list and transaction history is documented. https://www.olo.com/gdp · retrieved 2026-08-01

Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator

guest-loyalty-cdp-event-api

GDP is itself a restaurant CDP ingesting from dozens of systems and distributing across the Engage suite, and status.olo.com lists a 'Webhooks' component — but the outbound event schema and subscription model are behind the login-gated developer portal. https://status.olo.com/ · retrieved 2026-08-01

Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator

guest-loyalty-review-capture-routing

Sentiment runs automated post-visit surveys, intercepts and routes negative feedback into service recovery, and steers satisfied guests toward Google, Facebook, Yelp, Grubhub, OpenTable and TripAdvisor. Summer 2026 added 24/7 automated AI review responses. https://www.olo.com/sentiment · retrieved 2026-08-01

Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.

guest-loyalty-referral-program

Olo Loyalty's 'Full List of Campaign Types' enumerates all ten automations - Date & Time, Recurring, Next Visit, Purchase Items, Purchase Total, Registration, Visit Threshold, Birthday, Point Threshold, Direct Trigger - and no referral mechanic is among them. The companion Offers article's offer-type list (Add Points, BOGO, Dollar Discount, Percentage Discount, Free Item, Multiply Points, Price Adjustment) likewise has no two-sided referral reward, and help-centre searches for 'referral' and 'refer a friend' (2026-08-04) return nothing on point. Per-guest referral codes/links, referred-first-order attribution and two-sided rewards do not exist in Olo Loyalty; the closest primitive is the Direct Trigger Campaign, which fires from an external API call and would require the brand to build referral tracking itself. https://olosupport.zendesk.com/hc/en-us/articles/46322497040923-Campaign-Types-Automations · retrieved 2026-08-04

Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator

guest-loyalty-wallet-pass

'Mobile Passes Integration': members 'pull out their iOS or Android Mobile Pass and scan it', shared via 'Add to Apple Wallet' / 'Add to Google Wallet' buttons; 'When there is a push update to all the passes, the old version will automatically be removed.' Shortfalls: it is 'an in-store feature add-on' enabled by the CSM; passes are generated by a third party (app.passcreator.com links); the pass identifies the member (phone or Olo Loyalty Id in a QR) and the points balance is 'retrieved and displayed on the integrated platform', not stated as shown on the pass itself; 'not supported on watchOS'; SMS cannot share the download link. https://olosupport.zendesk.com/hc/en-us/articles/46382083496987-Mobile-Passes-Integration · retrieved 2026-09-03 adversarially verified

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Deletion paths are documented, but guest-side and vendor-side rather than operator tooling. Olo Account holders self-serve: 'Click Delete Account' in Olo Account Settings, after which 'Olo will disassociate all of your personal information from your account'. Olo Loyalty members use a 'Delete My Accounts form' reviewed by 'A customer support representative' (46380474871579). Operators route requests through Olo Support: the intake form's User Access & Management category covers 'deactivate a guest' (44765456164635). Shortfall: no operator-facing admin tool to locate, export or delete a guest's data is documented, and no access/export request path is described. https://ologuesthelp.zendesk.com/hc/en-us/articles/6025270811035-How-can-I-delete-my-account · retrieved 2026-09-03 adversarially verified

Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.

guest-loyalty-redemption-fraud-controls

Three documented controls. 'Limit Purchase Claims Via Member Window' restricts receipt/purchase claims to a window, 'Up to 1 successful claim every 6 hours' by default, with max submissions and window hours set 'through your Customer Success Manager during onboarding'. 'Offer Configuration Options' documents Multiple-use Limits ('use 2 times in 7 days', 'use 1 time in 12 hours'), Maximum Offer Uses Per Member and Maximum Applications Per Purchase. 'Fraud Detection Export' flags members whose daily transaction count exceeds a chosen 'Minimum Txn/Day' over a 7-day window. Shortfall: no manager approval on redemption and no employee self-redemption flagging; the claim-window limit is CSM-configured, not self-serve. https://olosupport.zendesk.com/hc/en-us/articles/46370425355931-Limit-Purchase-Claims-Via-Member-Window · retrieved 2026-09-03 adversarially verified

Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator

guest-loyalty-ai-offer-recommendation

SHORTFALL: content drafting only, no audience or send-time recommendation, and no product documentation. The only A/B-grade AI evidence located is one line in the FY2024 10-K Marketing module capability list: 'Advanced tools such as our AI creative assistant that leverages generative AI to empower marketers to instantly craft new content.' That reaches the claim's 'offer content' limb and nothing else - no documented AI/ML recommendation of target audience or send timing. The Olo Help Center returns zero articles for the creative assistant, for 'AI', or for 'Guest Intelligence Signals', the Summer 2026 release-note item the record relied on; that basis is a marketing page with no documentation behind it. Downgraded from yes. https://www.sec.gov/Archives/edgar/data/1431695/000143169525000010/olo-20241231.htm · retrieved 2026-08-02 adversarially verified

Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.

guest-loyalty-stored-value-gift

The document says: “Olo Loyalty rewards also can’t be stacked (i.e., you can’t apply two $5 rewards together). But we do offer a Points Banking program that gives guests control over their redemptions through higher-denomination reward tiers.” P3 tested and upheld; re-tested twice as the corpus grew 1,391 to 1,461 to 1,628 documents (www 420 to 490 to 605) and it holds each time. Olo Loyalty hangs points and offers off the member profile, never a money balance. This article's Offer Type Options section is Olo Loyalty's own set of offer types — Add Points, BOGO, Dollar Discount ($), Percentage Discount (%), Free Item, Multiply Points, Price Adjustment — none a loadable stored-value or gift balance; e.g. “Add Points — An offer that allows you to give out fixed number of points.” It is a ceiling rather than a floor because the article introduces the list by telling the reader which automations may lack some of these types (“Some Automations may not have all the offer types.”), i.e. every automation draws from this set. The nearest money-shaped construct is Points Banking, priced in points and not funded with money: “$25 Reward = 500 points”. Corroborating enumerations, named without quotation because they are other documents: the Olo Loyalty Export Data catalogue (article 46322256871579) lists 18 dashboard exports whose only balance report is Loyalty Liability, defined as unused points and rewards; All Audience Filter Options (article 46360087459355) offers Points Balance as the sole balance-shaped filter; the Winter 2026 release page launches Olo Loyalty as Olo's first-ever loyalty program with no stored value in it. Every gift instrument Olo touches belongs to someone else: the Summer 2026 release (https://www.olo.com/product-release) announces an Ecard systems integration processing gift cards across 150+ POS systems without disrupting the brand's existing program; Summer 2025 added Paytronix Comp Cards as a Serve payment method; Spring 2025 added gift-card refunds on Olo Pay terminals; Olo's Terms of Use call the instrument a Branded Company-specific gift card. Olo processes gift value and issues none. Controls re-run over all 1,628 documents (movement across the three runs shown): 'stored-value' 1/1 doc (unchanged, the Aloha Stored Value partner page); 'gift balance' 0, 'value card' 0, 'e-gift' 0 (all unchanged); 'eGift' 1/1 (unchanged); 'cash card' 0 then 1 then 1, the single hit being the Terms of Use Branded Company-specific cash card, which strengthens this verdict; 'gift card' 49 then 54 then 77 documents (69/74/98 occurrences) and 'gift cards' 123 then 127 then 156 documents (149/155/196), all growth on newly readable partner and release pages, none on an Olo-issued balance. The live-KB count is still 4 articles. The partner directory's Gift Cards facet claims 10 partners; 7 are now visible in the corpus (Givex, Heartland, ItsOnMe, NCR VOYIX, Paytronix, Spoonity, Valutec) and all 7 are third-party gift processors; the 3 unseen lie in the 52-page t-to-z remainder named below. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). ONE CONTROL IN THIS NOTE WAS INCAPABLE OF FIRING AND IS CORRECTED. The note publishes 'stored-value' 1/1 doc as a measurement of the concept. The tokeniser does not treat a hyphen as whitespace: the unhyphenated stored value occurs 140 times in 127 documents. The auditor read them - the overwhelming majority are the partner-directory name Aloha Stored Value appearing in nav and Related Partners blocks, the only live-KB carrier is Aloha POS: FAQs answering Does Olo integrate to Aloha Stored Value gift cards? with Olo does have an integration to Aloha Stored Value (ASV), and there are ZERO hits in all five SEC filings. So the corrected figure strengthens the verdict rather than threatening it: every stored-value construct in the corpus is a third party's. gift balance 0, value card 0, e-gift 0, eGift 1/1 and cash card 1/1 all reproduce; gift card MOVED 77 to 87 documents and gift cards 156 to 169, all growth on the previously-unread partner tail. THE PARTNER-DIRECTORY BOUND IN THIS NOTE IS FALSIFIED AND IS REPLACED. It says the Gift Cards facet claims 10, that 7 are visible, and that the 3 unseen lie in the 52-page t-to-z remainder. All 392 published partner pages are now read and all 392 carry a parseable Services block: TWELVE carry the Gift Cards tag (Aloha Stored Value, Givex, Heartland, ItsOnMe, NCR, Paytronix, Spoonity, SVS, Valuelink, Valutec, VantivCore, Worldpay), which is MORE than the facet's 10, so the missing five were never in a crawl remainder - they were lost to the analyst's Services-block parser, which required a trailing "Socials" heading that these pages do not carry. All twelve are third-party gift processors. ONE CEILING NARROWED: the Offer Type Options list bounds OFFER TYPES, and a stored-value wallet would not be an offer type, so it is the wrong enumeration for this claim. What bounds it is the Olo Loyalty Export Data catalogue (18 exports, sole balance report Loyalty Liability, defined as unused points and rewards), All Audience Filter Options (Points Balance the sole balance-shaped filter), and the affirmative fact that every gift instrument in the corpus belongs to a third party or to the brand. VALUE, GRADE, URL AND QUOTE UPHELD; premise P3 is confirmed on better evidence than it was tested with. https://olosupport.zendesk.com/hc/en-us/articles/46336823229979-Offers · retrieved 2026-09-06

Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.

reporting-realtime-dashboard

Olo Dashboard shows near-real-time sales and error data by location and marketplace. A dedicated off-premise mobile reporting app is not documented. https://www.olo.com/rails · retrieved 2026-08-01

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

The document says: “Our new Itemized Payout Report provides a full snapshot of all activity impacting the deposit amount—including sales, refunds, chargebacks, and fees—ensuring accounting teams have all the details needed for reconciliation.” VERDICT CHANGED BY THE CORPUS GROWTH (was `no` at grade B on the report catalogue). This quarterly release page was one of the 70 www.olo.com URLs previously unreadable, and it announces a single-document deposit reconciliation that the Sales and Orders catalogue does not list. A `no` is no longer defensible. It is not a `yes` either: the source is a release/marketing page, which establishes a vendor CLAIM, not the report's contents, and no help-centre article for it exists in the corpus - re-run over the final 1,628-document corpus, payout is 6 occurrences in 4 documents (this page 2, the Summer 2023 release page 2, the Spring 2024 release page 1, and one archived Xpient/IRIS POS FAQ), with zero live KB articles; Itemized Payout Report is 1 occurrence in 1 document, this one. NAMED SHORTFALLS against a conjunctive claim: (1) it is an Olo Pay payout document, so it is scoped to Olo Pay customers and to card settlement, not to a store's whole day; (2) the four elements it is said to cover are sales, refunds, chargebacks and fees - the corpus shows no tax line, no tip line, no discount line and no cash-deposit line, and the claim asks for all of those in one document; (3) the daily cadence is not asserted on this page - it comes from sibling release pages (Summer 2023 announces payout reports with a day-by-day breakdown of all deposits; Spring 2024 announces daily payouts matched to POS sales), and Summer 2025 adds that Olo Pay reports differentiate card-present from card-not-present transaction data, which is the nearest thing to a tender-type breakdown; (4) the word including in the quoted sentence makes its element list a floor, so the report may carry more than four elements - that is a reason not to write `no`, not a reason to write `yes`. Re-run absence controls over 1,628 documents, all unchanged from the smaller corpus: closeout 0 occurrences, close-out 0, end of day 2 occurrences in 2 archived documents (an IVR-notification article and an Aloha restart article, neither a report). The archived Reconciliation Guidelines and Reports (web.archive.org capture 2019-08-21, article stamped Updated August 06, 2019; a later revision exists and was not read) shows the pre-Olo-Pay procedure was three reports subtracted by hand - it is history, not the current state, and it is cited here only to date the change. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: closeout 0, close-out 0, end of day 2 occ/2 docs, Itemized Payout Report 1/1 all reproduce. payout MOVED, 6 occ/4 docs to 7 occ/5 docs - the added document is the Voosh partner page, a third-party delivery-recovery product, not an Olo report. VERDICT UPHELD at partial/C on the same document and quote. PREMISE P5 (Olo publishes no single end-of-day document) IS FALSIFIED by this page and the note correctly says so. https://www.olo.com/quarterly-release/fall-2023 · retrieved 2026-09-06

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Fall 2025 Menu Intelligence dashboard tracks how menu items affect ordering behavior for digital channels. Modifier-level quantity and net sales, and revenue-center slicing, are not documented. https://www.olo.com/quarterly-release/fall-2025 · retrieved 2026-08-01

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

CLAIM: produces an audit report of comps, voids, discounts and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps. Verified adversarially against Olo's public help centre and its attachment layer; the proposed partial does not survive, because no conjunct of this claim is met by anything other than an adjacent report, and the corpus floor forbids a no. WHICH CONJUNCT IS MET AND WHY: none. The proposal rested the met conjunct on one row of the pre-configured report catalogue at https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview. I re-parsed that table from the raw bytes, comments stripped first, tr by tr: it is a clean two-column table of 19 report rows plus a header, each name in its own td and each description in the adjacent td, so the quotes are real and nothing was welded by a tag-stripping normaliser. The rows are 'Itemized Adjusted Orders' | 'List of adjustments, including both full refunds and sub-total adjustments'; 'Itemized Cancelled Orders' | 'List of canceled orders'; 'Coupon Redemptions' | 'List of coupons redeemed, broken out by restaurant and order'; 'Coupon Setup Information' | 'List of all active, archived, and expired coupon setups'. Those are per-order transaction lists. An audit report as this claim defines it is a list plus an actor plus a reason plus a time, and Olo publishes the list only. The proposal itself called the adjustments report Olo's 'analogue of comps and voids'; an analogue is not the thing, and that concession is what decides this cell. SHORTFALLS. (1) Comps and voids do not exist as Olo surfaces at all. Tokenised over the 233 stripped bodies, comp 13 occurrences in 5 documents and comps 5 in 5, and every one is a POS-vendor construct Olo is instructing the brand to configure elsewhere - Aloha 'Open Dollar Comp' and a 'Comp ID' sent down in the order, Toast 'Open Dollar Comps' mapped by Discount record GUID. The Aloha integration article states in its own words 'Olo does not do literal voids, but does clear checks when validating orders', and the Aloha 'Void Reason ID' it has the brand create for Olo is to be set 'For COM Use Only' and 'Do Not report'. (2) Price overrides do not exist: tokenised 'price override' = 0 occurrences in both layers; bare override is 27 and overrides 14 across 16 documents and every inspected sense is a configuration override - store hours, banner, item group - not a cashier repricing an item. (3) There is no manager approval anywhere: approver = 0 in both layers, approval = 2 occurrences in 1 document, approved = 7 in 6 and every one is a campaign, an ACH mandate, a Google listing or an app-store review. (4) There are no reason codes for adjustments. 'reason code' is 2 occurrences in 1 body plus 1 in the attachment layer, and all three are the card-network CHARGEBACK reason code in 'Chargebacks Overview' and its attached PDF - 'Each chargeback will include a reason code indicating the reason for the chargeback' - a HOMONYM of the POS override reason code this claim means. I found one occurrence the proposal missed: 'reason codes' plural also appears in the Dispatch rescue article, 'Expanding the scope of eligible cancellations with additional reason codes', which is a delivery-cancellation reason on a roadmap line, a second homonym and still not an override reason. (5) Actor attribution is optional, single-action and unreported. 'Cancel an Order' (https://olosupport.zendesk.com/hc/en-us/articles/115000123846-Cancel-an-Order) says, verbatim from the raw bytes inside one em element, 'Note: If you would like to waive the PIN requirement, you can disable "Require PIN" on this page. However, auditing of who took the action on Expo will not be available if this PIN requirement is waived.' That is the only actor attribution in the corpus; it is defeasible by a brand setting, it covers the Expo cancel action only and not refunds or sub-total adjustments, and no report in the catalogue is documented as carrying the acting user as a column. (6) The word audit occurs exactly once in all 233 bodies, in 'Olo Dashboard Overview' (https://olosupport.zendesk.com/hc/en-us/articles/115000076446-Olo-Dashboard-Overview) as the bare phrase 'and audit reports', with no report named, no contents and no link; 'audit trail' = 0. WHY UNKNOWN AND NOT NO: the public corpus is a floor, not a census. I reproduced the href fixpoint independently: 289 distinct /hc/articles/<id> ids are referenced inside the 233 held bodies, 156 are absent from the listing, and probing api/v2/help_center/en-us/articles/<id>.json returned 149x 401 and 7x 404 with zero unlisted 200s, so the public set is 233 of at least 382 articles, about 61 percent. The two articles that would settle actor attribution are in that gap by name: 'Issue a Full Refund' (115000123986) answers 401, present and withheld, and 'Adjust a Subtotal' (115000124126) answers 404. Two further holes no text census can see: 25 player.vimeo.com iframes in 12 articles and 1,234 img tags in 160 articles, most of them Dashboard screenshots whose on-screen column headings are unreadable to any text census and are the likeliest place a user column would be visible. No no is publishable here and none is recorded. CONTROLS AND POISON. Positive controls live on both layers: over the 233 stripped bodies tokenised Olo = 1,641 occurrences in 169 documents and order = 942 in 111 under my normaliser (the proposal read 1,678/171 under its own); the figures are reader artefacts of tag handling and only the invariance is published - the harness is live, so a zero means something. On the 6 extractable attachment text units (5 PDFs via pdftotext -layout plus a CSV; the xlsx is declared residue) Olo = 62 occurrences across 5 of 6 units. POISON, published in full. First, my own tokenised control carried the trap: a case-sensitive comps read 0 while the corpus holds 'Comps' capitalised, and a naive substring comp matches complete, completed, components, company, comprising and complex - the 13 is only a word count because it was tokenised case-insensitively. Second, pdftotext -layout inserts intra-word spaces into this corpus, so an attachment-layer word-boundary control can read a false zero: the Chargebacks PDF literally contains 'cancel t he order a nd v oid the t ransaction', which means the attachment-layer void is 1, not the 0 the proposal published - and its sense is a payment void on a CVV or AVS mismatch, which sharpens rather than rescues the shortfall. Every attachment zero here was therefore re-run through a whitespace-squashed substring probe, whose own poison is that it manufactures matches out of table-of-contents numbering: 'S3' scored 2 hits that are 'App Icons 3. Loading Screen' and 'characters 3. iOS App Icon', and comp scored 3 that are complications and completed. Third, the 'Olo Serve Global Data and Events' PDF publishes Olo's field-level Order and Basket models - status values 'Pending | New | FaxPending | Emailed | InProgress | Closed | Failed | Cancelled | Scheduled', money fields vendorDiscount, subTotal, tip, totalCost, and basket coupon { code, description } - and they carry no actor, approver or reason field of any kind, which corroborates the shortfall; but that is the browser-side Serve data layer, a declared 'subset', so its silence bounds the tag surface and not the Dashboard reports. Do not cite updated_at as currency: it is a bulk re-save, 87 articles sharing 2026-04-24 with 36 in the single minute 20:41 and 58 sharing 2026-06-14. Retrieved 2026-09-15. || 331st: 331st: NEW SURFACE, no move: the screenshots attached to "Cancel an Order" (115000123846, 12 images) and "Sales and Orders Reports Overview" (115000124306, 7 images), downloaded from the olosupport attachment layer and read as images. The cancel flow in Expo is attributed to a person: Actions > Cancel Order opens "PIN Required / Select your profile" then "Enter Your PIN" for a named profile, and Dashboard > Expo > Brand Settings has per-store permissions "Cancel Scheduled Orders Settings ... Granting this permission will allow store managers to grant the ability to cancel scheduled orders to Expo users" and "Refund Settings ... refund closed orders", each with a "Require PIN" toggle. No screenshot shows a cancel REASON picker, a manager-approval step, or any report surfacing who cancelled/refunded; the Reports screenshots show only the report list UI (Recent Reports: "Closed Orders by Store", "Daily Closed Orders"; reports auto-deleted after two weeks). So PIN attribution exists at the action, but the audit REPORT with actor + approver + reason is still not evidenced; held unknown. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. Two vendor release statements bear on the conjuncts and neither is the audit report. (1) Voids now exist for Olo Pay: "Cut refund costs with immediate voids. Olo Pay customers can now void transactions directly in the Olo Dashboard before they're captured" (https://www.olo.com/winter-release-2026) - a payment void, with no actor, approver or reason report described. (2) A Dashboard audit tool exists but audits SETTINGS, not comps/voids: "Olo Dashboard Self-Service Auditing Tool ... empowering corporate users to view details on any location-level changes made to operational information like store hours, fraud settings, quote time overrides, and other settings" (https://www.olo.com/quarterly-release/fall-2023). That is an adjacent change log and cannot carry a partial. Also noted: the 2026 release's "Redacting personal data in Olo Reports" is a report-permission toggle, not an audit report. POISON: 'comp' on the site is mostly "+4% comp" (comparable sales) and "Paytronix Comp Cards" (a payment method). Retrieved 2026-09-18. || 334th: 334th: NEW SURFACE, no move. The 149 olosupport articles that now answer 401 (titles in .cache/q326/olo/oz-gated-titles.txt) were never read; 129 of them have Wayback 200 captures, all 129 fetched (2019-2022 captures, .cache/q334/olo/a/wbg/). Two bear on this cell. (1) 'Issue a Full Refund' (115000123986, captured 2020-08-11): in Dashboard > Orders > Refund Order the user must "Enter your name, select a reason for the refund, and enter any details for the customer" before "Process Refund Request" - so a refund carries a self-entered actor name and a picked reason at the action. (2) 'Refunding in Expo' (360057455672, captured 2021-05-17): Expo refunds require the employee's PIN, behind a per-employee refund permission a store manager toggles ("Location Settings > Users > Permissions ... The store manager can toggle this on for employees who can perform refunds"). Still no move, for the reasons the standing verification gave: these are refunds, not comps/voids/discounts/price overrides; no manager APPROVAL step exists (the manager grants a permission in advance, nobody approves the refund); and no page shows a REPORT surfacing the actor name or reason (the 'Itemized Adjusted Orders' row lists adjustments only). Over the 129 recovered bodies, tokenised: 'reason code' 0; audit* 7, every one a MENU or webhook change log ('Menu Audit Log Overview' links, the Menu Training FAQ 'Is there a way to audit the changes that have been made on the company menu', webhook change emails 'an extra layer of security and auditing') - adjacent, not a comp/void report; void 2, both Aloha COM error codes (ErrCOM_InvalidVoidReason, 'Cannot void a offline giftcard activation'), i.e. the POS's construct; approv* 0; comp 5, all related-article links to 'Coupon Setup and Discounts for Online Ordering via a Comp' (the Aloha POS construct). Retrieved 2026-09-18. adversarially verified

Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.

reporting-cash-over-short

The document says: “If a guest paid in-store, the refund processed in Dashboard is for reporting purposes only and you are advised to refund the guest through the original form of payment.” VERDICT HELD AFTER RE-RUN. Affirmative prose describing a DIFFERENT mechanism carries it: Olo does not hold the in-store tender. The same live article (updated 2026-06-14) adds that "a refund may also need to be processed through your POS for reporting reconciliation purposes". A cash over/short report compares counted cash in a drawer against expected cash from tenders and paid-outs; Olo captures neither a drawer count nor a paid-out. Re-run over the final 1,628-document corpus: drawer unchanged at 14 occurrences in 4 documents, every one an archived (2020-2021) Aloha or Silver POS error or custom-tender article about the POS's own drawer, none live and none an Olo surface; cash over 0 occurrences; over/short 0. cash MOVED, from 799 occurrences in 40 documents to 803 in 43 - I re-read the change: the five SEC filings still hold 756 of the 803, and the four added occurrences are in newly-readable www marketing pages (the Thoma Bravo acquisition notice, a blog post and similar), none of them a product claim. The 70 newly-readable www pages include the Olo Pay product page and eleven quarterly release pages; I read them for tender handling and they push the other way - Olo Pay's payment methods are given as credit cards, contactless payments and mobile wallets, and the payout-report family announced in 2023-2024 reconciles card deposits, never cash. WHY THE ENUMERATION IS A CEILING: this article enumerates the whole Olo Dashboard left navigation - Favorites, Stores, Orders, Guests, Menu, Analytics, Payments, Onboarding, Integrations, Settings - stating "Below are details on what each is used for", its only caveat being per-account access rather than completeness; no cash-management or drawer surface is among them. Confirmed against the raw HTML body in .cache/q225/raw/zd-articles.json that the one table in this article is the three-column Stores management grid, so the navigation list is prose and lost nothing in the text conversion. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: drawer 14 occ/4 docs, cash over 0, over/short 0, cash 803 occ/43 docs, per employee 3/3 - all reproduce exactly, including the 803/43 figure. CONTROL CAPABILITY TESTED: cash drawer fires on 2 documents (both archived Aloha articles about the POS drawer) and overage/shortage fire on 5 and 10 documents, so the zero-hit controls above were capable of firing. TWO CORRECTIONS TO THE NOTE'S REASONING, NEITHER OF WHICH MOVES THE VALUE. (1) THE STATED BOUNDING ENUMERATION IS THE WRONG ONE: the Dashboard left-navigation axis is a documented ceiling for MODULES (The sections in this guide offer information for each of the navigation tabs), but a cash over/short REPORT would live under Analytics, whose contents this article does not enumerate, so the nav axis does not bound this claim. What does bound it is the quoted sentence - Olo does not hold the in-store tender - plus the absence of any drawer count or paid-out surface anywhere Olo installs. (2) OLO DOES HAVE A DOCUMENTED CASH PATH, which this note understates: the live How to Enable Dine-In article (zd-360050334652, updated 2024-07-08) lists cash, credit card and gift card payment among Dine-In functionality. That is the guest paying in the store on the store's own POS; it gives Olo no drawer count and no paid-outs, so the verdict holds, but cash is not among Olo's payment methods was too strong. VALUE, GRADE, URL AND QUOTE UPHELD. https://olosupport.zendesk.com/hc/en-us/articles/115000076446-Olo-Dashboard-Overview · retrieved 2026-09-06

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

The document says: “The Dashboard's left navigation has several tabs. Below are details on what each is used for.” VERDICT HELD AFTER RE-RUN. The claim requires sales per labor hour and labor cost as a percentage of sales, by hour, department and employee, from actual clocked hours in the POS time clock. Re-run over the final 1,628-document corpus: time clock 0 occurrences (unchanged); sales per labor hour 0 (unchanged); clock in 5 occurrences in 3 documents (unchanged - two archived Aloha POS error articles about the POS's employee and drawer assignment, one blog post); punch 5 occurrences in 3 documents (unchanged, none in a time-clock sense); by employee 0; per employee 3 occurrences in 3 documents, two SEC filings and the Olo For Good page, none a report. labor MOVED, from 147 occurrences in 57 documents to 153 in 63 - I read the additions and they reinforce the verdict rather than threaten it: they are partner-directory pages (Lineup.ai, Harri, Instant) alongside the existing www.olo.com/partners/7shifts, so labour remains an Olo PARTNER category rather than an Olo capability. Decisive new test enabled by the growth: I read all eleven quarterly release pages (Summer 2023 through Spring 2026), the Winter 2026 release page and the product-release hub - the pages where Olo announces new Dashboard reports - and not one announces a labour, time-clock, scheduling or employee-hours capability of any kind. This live article (updated 2026-06-14) enumerates the navigation - Favorites, Stores, Orders, Guests, Menu, Analytics, Payments, Onboarding, Integrations, Settings - and none is a labour or team surface. WHY THE NAVIGATION IS A CEILING RATHER THAN A FLOOR: the article's stated purpose is to describe every navigation tab and its only reservation is per-account access, not unlisted tabs. Its per-tab contents ARE floors (the Stores tab list is introduced "Management options include:"), so the tab axis plus the release-page sweep plus the zero time-clock vocabulary is what carries this, not help-centre silence. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: time clock 0, sales per labor hour 0, clock in 5 occ/3 docs, punch 5/3, by employee 0, per employee 3/3 all reproduce. labor MOVED, 153 occ/63 docs to 168 occ/76 docs - I read the additions and they are partner-directory pages and blog posts, the largest single block being the previously-unread t-to-z partner tail (Today, Unifocus and others), so labour remains a partner CATEGORY and not an Olo surface. CONTROL CAPABILITY TESTED: hours fires on 185 documents / 626 occurrences and scheduling on 53 documents while time clock, "timeclock", timekeeping, hours worked and punches are each 0 - the controls were capable of firing. VERDICT UPHELD at no/B. The nav-tab axis IS the right ceiling for this claim, because labour productivity requires a surface that INGESTS clocked hours, not merely a report, and this article enumerates every navigation tab by its own stated purpose. https://olosupport.zendesk.com/hc/en-us/articles/115000076446-Olo-Dashboard-Overview · retrieved 2026-09-06

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

VERDICT HELD AFTER RE-RUN, but its support has been rebuilt, because the corpus growth weakened the catalogue as a ceiling. The claim asks for per-server average check, items per check, attachment rate by named category, and tips as a percentage of sales. Re-run over the final 1,628-document corpus: server scorecard 0 occurrences; items per check 0; attach rate 0; attachment rate 0; staff performance 0; by employee 0; per employee 3 occurrences in 3 documents, none a report; average check 22 occurrences in 14 documents, of which the only product-surface use is the Spring 2026 release page, where average check size is a GUEST-SEGMENT filter in Olo Guest Intelligence (online versus in-store guests), not a per-server metric; server 230 occurrences in 126 documents (was 229 in 125) and they are machines - Aloha Interface Server, RPC server, firewall rules. All 19 report types in this live table (updated 2026-06-14) are dimensioned by day, store, credit card type, product, order source or hour - "Orders placed for a restaurant or group of restaurants by day, broken out by credit card type", "Products broken out by restaurant, based on the day of pickup or delivery", "Breakdown of when orders are picked up or delivered, in one hour increments, by restaurant" - and the nearest thing to attachment reporting, Product Recommendation Source, gives "Product-level sales data with attribution to where each item was added to the basket", i.e. attribution to an algorithm, not to a person. Confirmed against the raw HTML that this table is two columns (Report Type / Description), 20 rows including the header, so no column was lost in conversion. WHAT BOUNDS THE ABSENCE, AND WHAT NO LONGER DOES: this catalogue is NOT a census - premise P2 is false and the corpus growth made it worse, since the Itemized Payout Report, the Olo Pay detailed payout report, the IC+ interchange fee report, the Uber Eats reports now in the Dashboard, the fraud orders report and the Tip Splitting Report are all absent from it. So the `no` rests on (a) the mechanism: every Olo order is entered by the guest through a digital channel, so no server identity exists to score, and (b) a positive sweep of all eleven quarterly release pages plus the Winter 2026 page and the product-release hub, the enumerations in which Olo announces new reports, none of which announces an employee- or server-dimensioned metric in any quarter from Summer 2023 to Spring 2026. Residual risk still named: Switchboard is Olo's one agent-mediated channel and no corpus document describes agent-level metrics for it. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). RE-CITED BY THE AUDITOR: EVIDENCE REPLACED, VALUE HELD. The quote was changed. The analyst's original quote was this article's introductory sentence, "There are several pre-configured sales reports available" - a FLOOR sentence ("several", "sales reports") from a document that opens by calling itself "a high-level overview of the different reports". A floor sentence cannot be the carrying quote of a `no`, and the analyst's own note already conceded the catalogue is not a census. The replacement quote is the Product Recommendation Source row, which is the nearest thing in Olo's entire report catalogue to attachment reporting and which attributes each added item to a SOURCE (an algorithm or a list), never to a person - that is affirmative prose describing a different mechanism, which is what carries this absence. RULING ON CEILING WITHIN ITS OWN CATEGORY: IT IS A RESCUE, NOT A DISTINCTION. This article is a floor three times over - it self-describes as a high-level overview, its list is introduced by several, and it cannot bound even its own category, since the live Dashboard Tip Splitting Report is a sales-adjacent report named in a 2025 article and absent from this table. No `no` in this batch may rest on it as a ceiling and none now does. ONE ERROR IN THE ANALYST'S OWN LIST OF ABSENTEES CORRECTED: the fraud orders report IS in this table, as the row Blocked Fraud Orders; the Itemized Payout Report, the IC+ interchange report, the Uber Eats reports and the Tip Splitting Report are genuinely absent. FIGURES RE-DERIVED: server scorecard 0, items per check 0, attach rate 0, attachment rate 0, staff performance 0, by employee 0 all reproduce; average check MOVED 22 occ/14 docs to 24/16 and server MOVED 229/125 to 231/127, both on newly-read partner and blog pages, neither a per-server metric. WHAT CARRIES THE `no`: the mechanism (every Olo order is entered by the guest through a digital channel, so no server identity exists to score - corroborated by the live Dispatch Driver Tip Distribution article, which states Olo hands the POS a single aggregate tip and keeps no per-employee ledger), the non-human dimension of all 19 rows in this table, and the positive sweep of all eleven quarterly release pages plus the product-release hub. Residual risk restated: Switchboard is Olo's one agent-mediated channel and no corpus document describes agent-level metrics for it. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-09-06

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

Sales by location and marketplace, guest segmentation by channel (Fall 2025), Spring 2026 IC+ interchange and network fee breakdown, and marketplace discount pass-through to the POS. Full margin net of each marketplace's commission is not documented as a single report. https://www.olo.com/2026-spring-release · retrieved 2026-08-01

Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator

reporting-multiloc-drilldown

Olo Help Center, Sales and Orders Reports Overview: reports are generated by selecting 'Report Category, Report Date Range, and Store Locations,' giving a group rollup over a selected estate. Side-by-side location comparison is served by the by-store report types - 'Closed Orders by Store', 'Daily Credit Card Placed Orders by Store', 'Product Breakdown - products broken out by restaurant', 'Time of Day Breakdown... by restaurant', 'Failed Orders by Store'. Drill to the individual transaction is served by 'Itemized Orders - list of orders', 'Itemized Adjusted Orders' and 'Coupon Redemptions - broken out by restaurant and order'. Mechanism caveat: this is report generation with .xlsx/.csv download rather than click-through drill-through in a single view. Replaces the record's prior reasoning, which inferred the cell from Olo's customer size rather than from any report inventory. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-08-02 adversarially verified

Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator

reporting-custom-report-builder

The reporting docs enumerate the surface and a builder is not in it: 'There are several pre-configured sales reports available' - 19 named report categories (Daily Placed Orders through Third Party Coupon Redemptions), each parameterized only by report category, date range and store selection, downloadable as .xlsx/.csv - and the Insights product is fixed dashboards (Overview | Insights, read 2026-08-04) offering filters and CSV download of 'the visible report' only. Help-centre and release searches for a dimension/measure report builder (2026-08-04) return nothing; the Spring 2026 release's new IC+ fee report is itself another canned report. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-08-04

Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.

reporting-scheduled-delivery

Sentiment offers 'dynamic dashboards and schedulable reports.' Whether scheduling extends to all Olo reports is not documented. https://www.olo.com/sentiment · retrieved 2026-08-01

Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator

reporting-raw-warehouse-export

UPGRADE partial -> yes. This cell was held at partial because 'the only documented automated path off the platform is the webhook stream' and because SFTP/S3/Snowflake/BigQuery all read 0 over the 233 olosupport bodies. That corpus was bound to the wrong publisher: Olo documents a Snowflake data share in the ENGAGE help centre (getwisely.zendesk.com), which the olosupport corpus never covered. NEW EVIDENCE, first-party vendor documentation: 'Olo Engage Warehouse (Data Warehouse Connection)' https://getwisely.zendesk.com/hc/en-us/articles/5026134931099 - 'Olo has developed the Engage Warehouse to empower clients to leverage all of their Olo data with the flexibility of Snowflake. This guide outlines the necessary instructions in order to connect to your Engage warehouse data share. This data share is a live connection to our warehouse that provides real-time data updates that can be queried upon. The warehouse data share solution is provided by Snowflake. As a result, your data ingest method must be able to connect to a Snowflake database and run compatible SQL commands. Olo provisions a dedicated database, credentials, and server that is used exclusively by you.' It documents hostname/username/password credentials issued by an Olo Engage representative, optional IP whitelisting, connection by Snowflake web UI and by SnowSQL CLI ('USE SCHEMA wisely_share_v1; SHOW TABLES;'), a dedicated warehouse that sleeps after 15 minutes of inactivity with a 20-30 s cold start, and backwards-compatible schema versioning. The companion 'Olo Engage Data Warehouse Client Share Data Dictionary' https://getwisely.zendesk.com/hc/en-us/articles/5026146180507 (62,295 chars of body text) enumerates 49 views in schema wisely_share_v2 with column-level definitions and a per-view refresh cadence, and the data is TRANSACTION-LEVEL, which is the conjunct that was previously missing: 'Orders wisely_share_v2.orders Contains one row for each order created online or through Olo's order management. Updated: Every 4 Hours'; 'Olo Pay Transactions wisely_share_v2.olopay_transactions Contains a row for each Olo Pay Transaction that is sent through our Payments Data Enrichment process to tie transactions to guest records ... Updated: Updated Daily'; 'Processor Transactions wisely_share_v2.processor_transactions ... Each row contains an individual transaction with a reference to a payment source (which includes the tokenized credit card information)'; 'Tickets wisely_share_v2.tickets ... Each row contains check data that is ingested from the POS/order management integration'; plus guests, guest_visit_history, parties, feedback_form_responses, sentiment_reviews and the campaign/automation history views. CLAIM CONJUNCTS: automated (a live share on a stated refresh cadence, no manual step) YES; recurring YES; bulk transaction-level raw data (49 raw views at order/ticket/payment grain) YES; customer-controlled destination named in the claim itself ('Snowflake') YES, since the brand queries it from its own Snowflake account. LIMITS, stated: 'Snowflake Data Share eligibility requires the brand's Snowflake instance to align with Olo's Snowflake instance, which is hosted on AWS us-east-1. Olo may also provide Snowflake Reader access in this region upon request and in accordance with your contract deliverables' - region-bound and contract-gated, and a share is read-only. Grade B (vendor's own help centre, read anonymously through the Zendesk Help Center API, articles live and re-fetched this pass). Retrieved 2026-09-17. https://getwisely.zendesk.com/hc/en-us/articles/5026134931099-Olo-Engage-Warehouse-Data-Warehouse-Connection · retrieved 2026-09-17 adversarially verified

Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator

reporting-public-api

Verified verbatim: 'Credentials for production will only be granted after certification, which must be completed separately for each Olo API.' Combined with developer.olo.com serving only a login form, partner-gated/partial is the right call — this is one of the few cells where the researcher resisted the marketing read. https://www.olo.com/api-usage-terms · retrieved 2026-08-01 adversarially verified

Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator

reporting-webhooks

'Webhooks' is a monitored component on Olo's public status page, confirming the capability exists. Retry semantics and payload signing are undocumented publicly. https://status.olo.com/ · retrieved 2026-08-01

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

CLAIM: API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. VERDICT: no — this cell had an EMPTY note and had never been worked; it is settled from Olo's own SEC filing and its own website rather than from the help centre, so the gated-KB floor does not bind it. EVIDENCE. (1) API ACCESS IS EXPLICITLY MONETISED PER TRANSACTION. Olo's FY2024 Form 10-K, "Components of Results of Operations": "Our transaction revenue primarily includes revenue generated from our Olo Pay solution, as well as fees charged to aggregators, channel partners, and other service providers in our ecosystem on a per transaction basis FOR ACCESS TO our Rails and Dispatch modules. For the years ended December 31, 2024, 2023, and 2022, 45.5%, 44.7%, and 50.9% of our platform revenue was subscription revenue, respectively, and 54.5%, 55.3%, and 49.1% was transaction revenue" — i.e. the majority of platform revenue is per-transaction access fees, and the API-reachable modules are named. (2) THERE IS NO STANDARD SUBSCRIPTION TO BE INCLUDED IN. The same filing: "Our contracts typically have initial terms of three years or longer, with continuous one-to-two-year automatic renewal periods ... we generally enter into relationships at the brand's corporate level and strive to secure exclusivity across all locations", and "a portion of our customers purchase an allotment of monthly orders for a fixed monthly fee and pay us an additional fee for each excess order". Olo publishes no plan or price list at all: https://www.olo.com/pricing returns 404 and https://www.olo.com/developers returns 404, with a nonsense-path control (https://www.olo.com/zzz-nonsense-control) also 404 at a DIFFERENT body size (16,200 vs 14,693 and 16,380 bytes), so those are honest 404s and not a catch-all. (3) EVERY CAPABILITY, INCLUDING THE DATA ONE, IS A SEPARATELY BOUGHT MODULE. The 10-K's product section states the dependency chain in its own words — "Customers with the Ordering module are able to utilize Kiosk as an add-on module", "Customers with the Ordering and/or Rails modules may utilize Network as an add-on module", "Customers with the Ordering module may utilize Switchboard as an add-on module" — and the raw-data product is inside the Engage suite ("Olo has developed the Engage Warehouse to empower clients to leverage all of their Olo data with the flexibility of Snowflake", getwisely article 5026134931099), not in a base plan. (4) THE DEVELOPER SURFACE IS CONTRACT-GATED. https://developer.olo.com/docs 302s to /Account/Login?ReturnUrl=%2Fdocs (re-confirmed today with a browser UA), and the separately-sold POS middleware, the Omnivore API, is sold by negotiation: its product page https://www.olo.com/omnivoreapi carries no price and two "Talk to partnerships" calls to action. (5) The API Usage Terms themselves reserve a penalty fee and set no included allowance: "Olo reserves the right to, at its sole discretion, (1) charge you a penalty fee and/or (2) immediately suspend access to the API if you breach any terms" (https://www.olo.com/api-usage-terms). Every conjunct of the claim's negative is therefore met: per-transaction access fees, module add-ons, and multi-year enterprise-only contracting. Retrieved 2026-09-18. https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=OLO&type=10-K · retrieved 2026-09-18 adversarially verified

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

326th: MOVED unknown -> partial (the existing note, 'No published tiers.', is falsified: Olo documents feature-gated reporting in two places). SATISFIED PART: the Dashboard's pre-configured report set ships with Ordering itself and includes product-mix and multi-location comparison at no analytics SKU - 'Product Breakdown: Products broken out by restaurant', 'Closed Orders by Store', 'Time of Day Breakdown ... by restaurant' ('Sales and Orders Reports Overview'), reachable by any Dashboard user with the permission, with scheduling ('users can easily create and schedule Reports', Olo Dashboard Overview). SHORTFALL: reporting is gated two ways. (1) Inside Olo Loyalty, the Export Data catalogue flags reports PREMIUM - 'Expired Points PREMIUM' - and states 'Premium feature reports are only available to accounts with the feature enabled.' (2) Olo's analytics depth is a separately purchased module: the whole Engage Analytics Suite (a 37-report Tableau catalogue) belongs to Engage, and its integration reports are explicitly conditioned on purchase ('Once purchased, please contact our Support', Sparkfly Integration), while the Engage Warehouse Snowflake share is provisioned 'in accordance with your contract deliverables'. The claim's POS-side conjuncts (labor vs sales, comps/voids audit) have no Olo surface at all. Grade B: vendor help-centre articles. Retrieved 2026-09-18. https://olosupport.zendesk.com/hc/en-us/articles/46322256871579-Export-Data · retrieved 2026-09-18 adversarially verified

Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator

reporting-history-retention

326th: MOVED unknown -> no, and NOT on silence - on Olo's own stated caps, which are all far below 24 months. The 'Export Data' article (Olo Loyalty Dashboard, Insights > Export Data) enumerates every export and prints a per-report window: 'Member Transactions (up to 31 days)', 'Manually Uploaded Points and Offers (up to 31 days)', 'Campaign Send Counts by Favorite Store (up to 31 days)', 'Send Counts by Favorite Store (up to 31 days)', 'Send Counts per Dashboard User (up to 31 days)', 'Store Performance (up to 31 days)', 'Expired Points (up to 366 days)', 'Offers Events (up to 366 days)', 'Overview (up to 366 days)', plus 'The report will be available in the Export History for 14 days' and 'Exports will expire in 14 days and be automatically deleted.' The longest window Olo documents anywhere is 366 days. CONTROLS over the 2,161,373-char corpus: '24 months' 0, 'two years' 0, archive 0 as a retrieval offer. POISON PUBLISHED: 'retention window' scores 2 and NEITHER is data retention - both are the Email Campaign Performance report's methodology ('we use a Retention Window to compare order volume and sales from the same sample of customers, both before and after the campaign'), and 'Guest Retention' is the NAME of an Engage report, so any substring test for retention on Olo returns marketing language. The Engage Warehouse Snowflake share, the deepest data surface Olo publishes, states a refresh cadence for every one of its 49 views and never a depth. BOUND: olosupport's 233-article listing equals its sitemap exactly (the 324th/325th '233 of 304' floor was sitemap sections+categories, retired today); the 149 gated ids are titled in .cache/q326/olo/oz-gated-titles.txt and none is a retention or archival article. Retrieved 2026-09-18. https://olosupport.zendesk.com/hc/en-us/articles/46322256871579-Export-Data · retrieved 2026-09-18 adversarially verified

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

Guest Intelligence Signals surfaces monthly behavioral anomalies with recommendations; Sentiment flags emerging trends 'before they impact revenue'; Spring 2026 added real-time payment terminal health monitoring. Operator-configured metric thresholds are not documented. https://www.olo.com/product-release · retrieved 2026-08-01

Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.

reporting-nl-query

326th: MOVED unknown -> no, on the same retired-floor and gated-roster bound recorded on reporting-sales-forecast (olosupport sitemap 304 = 233 articles + 56 sections + 14 categories, API diff 0; 149 gated ids probed and titled from href slugs, none an analytics article). EVIDENCE - Olo ships exactly three AI features and each is enumerated and off-claim: 'Engage Marketing: AI Creative Assistant' generates campaign copy, 'Review Response Tools: AI Suggested Responses and Prompt Directives' drafts replies to guest reviews, and Sentiment uses NLP to classify review text. None accepts an ad-hoc question against the operator's own sales or labor data. CONTROLS over the 2,161,373-char corpus: 'natural language' 2 substring / 2 tokenised AND BOTH ARE THE SAME POISON - 'NLP Primary Categories wisely_share_v2.nlp_primary_categories Contains details on Natural Language Processing (NLP) categories used for sentiment review analysis', a data-share reference table, i.e. the only 'natural language' in Olo's documentation is sentiment classification, not query; 'ask a question' 0, 'AI assistant' 0, copilot 0; chatbot 2 and both are Google Tag Manager instructions for putting a THIRD-PARTY widget on a Serve site ('This custom script could be used to add pop-ups, chatbots, ad tracking'), i.e. guest-facing and not Olo's. The Dashboard reporting flow is a fixed picker: 'Click the New Report button ... Select the Report Category, Report Date Range, and Store Locations'. Retrieved 2026-09-18. https://getwisely.zendesk.com/hc/en-us/articles/17070584774043-Engage-Marketing-AI-Creative-Assistant · retrieved 2026-09-18 adversarially verified

Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator

reporting-guest-cohorts

SHORTFALL: no lifetime-spend cohort reporting, and the analysis window is capped. Olo Help Center, Overview Insights, does deliver two of the claim's three limbs against identifiable loyalty records: new-versus-returning ('Total Unique Members', 'New Members', and member-versus-non-member splits including 'Member Adoption Rate', 'Non-Member Sales'), and visit frequency ('Member Frequency - the ratio of unique members who made at least one visit to the total number of member visits'). The lifetime-spend cohort limb is absent: 'Member Sales' is period revenue, comparison is only to Prior Period or Prior Year, and 'End Date - select any date in the past, up to 31 days after the chosen Start Date' caps the window at 31 days, which forecloses cohort tracking. Help center search for 'cohort' returns zero articles. Downgraded from yes. https://olosupport.zendesk.com/hc/en-us/articles/46272000417947-Overview-Insights · retrieved 2026-08-02 adversarially verified

Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator

reporting-sales-forecast

326th: MOVED unknown -> no. THE 'FLOOR (233 of 304)' THAT HELD THIS CELL IN THE 324th AND 325th IS A MEASUREMENT ARTEFACT AND IS RETIRED: olosupport.zendesk.com/hc/sitemap.xml has 304 <loc> entries, but they decompose as 233 ARTICLES + 56 SECTIONS + 14 CATEGORIES + 1 root, which is EXACTLY the Help Center API's 233 articles / 56 sections / 14 categories. Sitemap-articles minus API-articles = 0. The real gap is different and I have now enumerated it: an href fixpoint over the 233 public bodies references 385 article ids, of which 152 are absent from the listing; probed one by one today, 3 are 404 and 149 return 401 (gated). I RECOVERED A TITLE ROSTER FOR ALL 149 GATED ARTICLES from the slugs inside the public hrefs (100 full slug titles, 49 anchor-text-only) - file .cache/q326/olo/oz-gated-titles.txt - and the gated set is POS menu-mapping (Aloha, Brink, Micros, Simphony, Toast, Revel, Xenial, Xpient, POSitouch, Focus, Northstar, OloCloud), Dispatch operations, marketplace-facilitator tax, Expo device auth, Rails onboarding and user administration. NOT ONE gated title is a reporting-catalogue, forecasting, analytics or assistant article. EVIDENCE: Olo's two report catalogues are both public and both closed. (1) 'Sales and Orders Reports Overview' enumerates the Dashboard's pre-configured report types in a definition table - Daily Placed Orders, Daily Credit Card Placed Orders (+ by Store), Daily Closed Orders, Closed Orders by Store, Product Recommendation Source, Product Breakdown, Itemized Adjusted Orders, Itemized Cancelled Orders, Time of Day Breakdown, Advanced Future Orders Distribution, Itemized Orders, Failed Orders by Store, Blocked Fraud Orders, Coupon Redemptions, POS Outages, Coupon Setup Information, Loyalty Reward Redemption, Third Party Coupon Redemptions - every one historical; 'Time of Day Breakdown' is orders already picked up 'in one hour increments' and 'Advanced Future Orders Distribution' is orders ALREADY PLACED for a future time, not a model. (2) 'Olo Engage Analytics Suite Overview.pdf' (11.4 MB, attachment on getwisely article 23376762901659, extracted 65,617 chars) is the vendor's own list of every Engage report by product and integration; its four sections are Marketing and Growth, Operations, Waitlist/Reservation and Sentiment, and the only forward-looking figures in all of Engage are GUEST-level model outputs (Predictive GLV, Churn Risk, six_month_churn_risk), never store sales. CONTROLS over a 2,161,373-char corpus (olosupport 233 + ologuesthelp 55 + getwisely 158 article bodies + both Engage PDFs + the 62,295-char Engage Data Warehouse Data Dictionary; script ctl.mjs): forecast 0/0, forecasting 0/0, 'predicted sales' 0/0, 'par level' 0/0, 'demand' 22 substring / 19 tokenised singular and not one is a demand forecast - they are 'customer demand for food delivery', 'Google Demand Gen campaigns', 'high demand patios', 'on-demand data', and release-event replays 'available on-demand'. Olo has no labor or scheduling module for a forecast to drive. Retrieved 2026-09-18. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-09-18 adversarially verified

Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.

reporting-tip-tax-compliance

The document says: “Your existing point of sale system will continue to receive a single tip amount that represents the total tip distributed among restaurant staff and delivery drivers.” VERDICT HELD AFTER RE-RUN, with the newly-readable evidence read and weighed. Affirmative prose describing a different mechanism, from a live article (created 2025-04-09, updated 2025-07-16): even in the one tip feature Olo owns - percentage splitting of catering tips between restaurant staff and DSP drivers - Olo hands the POS a single aggregate tip and keeps no per-employee ledger. The claim is conjunctive and fails on all three limbs. (i) Declared versus charged tips per employee: no evidence anywhere; declared tips is unchanged at 5 occurrences in 2 documents, both archived (2020) Aloha POS error articles about an illegal declared-tips amount returned BY Aloha, so the declaration is the POS's. (ii) Tip pool distribution detail: tip pool is 0 occurrences across all 1,628 documents (unchanged); the only named tip report is the one this article points to - "The distribution of tip amounts for staff and drivers is available in the Dashboard Tip Splitting Report." - a staff-share versus driver-share split per Dispatch catering order, not a distribution among named employees, and its own article is not in the corpus, so I did not assume its columns. THE NEWLY-READABLE EVIDENCE I HAD TO WEIGH: the Summer 2024 quarterly release page, previously unreadable, announces RAILS STAFF TIPS POS SYNC, saying Olo surfaces staff tips from its reconciliation data and passes them along to brands, streamlining reconciliation and tip allocation across team members. Read closely, that is the SAME mechanism as the quote above - Olo transmits a tip amount to the brand's POS, which performs the allocation - so it does not create a per-employee tip ledger in Olo, and it does not move the verdict. (iii) Tax liability summary by jurisdiction: tax report 0 occurrences and tax remittance 0 across the corpus (both unchanged); the only remittance material is the archived (capture 2020-10-28) Marketplace Facilitator Laws FAQ, about DSP marketplace sales tax rather than employer tip tax, and none of the eleven release pages announces any tax-liability report. payroll is unchanged at 57 occurrences in 6 documents - five SEC filings, about Olo's own payroll costs, and www.olo.com/partners/heartland, a payroll partner listing; no Olo product document uses the word. WHY THE BOUND HOLDS: not help-centre silence but this article's positive statement of what Olo sends the POS, plus the release-page sweep, plus the absence of any employee dimension in the Sales and Orders catalogue and the Dashboard navigation. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). A PUBLISHED ZERO IS FALSIFIED AND IS THE MOST SERIOUS DEFECT THE AUDITOR FOUND IN THIS BATCH. This note published tip pool is 0 occurrences across all 1,461 documents (unchanged). Over the complete 1,628-document corpus tip pool is 2 occurrences in 1 document (the Olo partner page for TipReports) and tip pooling is 4 occurrences in 2 documents (TipReports and TipHaus). The zero was measuring where the crawl stopped, not Olo: the partner directory had been truncated at a contiguous alphabetical tail and the tip vendors sit inside it - the same false-zero mechanism that produced the sweep's other six reversals. The delivery analyst caught this on its own cell (payments-tip-pooling) and this note was not re-run against the repaired corpus. LIMB (ii) OF THIS CLAIM IS THEREFORE NO LONGER SUPPORTED BY A ZERO. It is still not satisfied: tip-pool DISTRIBUTION DETAIL is produced by a separately licensed third-party rules engine reached over the Omnivore POS API, on the partner's surface, and no Olo report displays it - which is exactly the finding that put the sibling cell payments-tip-pooling at `partial`, and the two cells are consistent only when read that way. VALUE UPHELD AT `no` because the claim is conjunctive and limb (i) is carried affirmatively by the quote (Olo transmits one aggregate tip and holds no per-employee ledger) and limb (iii) has no support of any kind: tax report 0, tax remittance 0, both with capable positive controls. FIGURES OTHERWISE RE-DERIVED: declared tips 5 occ/2 docs, tax report 0, tax remittance 0 all reproduce; payroll MOVED from the 57 occ/6 docs published here to 62 occ/8 docs (Paychex and Proliant, both partner pages), which the delivery analyst had already corrected and this note had not. ARCHIVE DISCIPLINE: the Marketplace Facilitator Laws FAQ is named with its capture date but without the required statement that a later revision exists and was not read for this proposition - recorded here, and it is corroboration only, never sole support. https://olosupport.zendesk.com/hc/en-us/articles/35828711816219-Dispatch-Driver-Tip-Distribution · retrieved 2026-09-06

Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.

multi-location-org-hierarchy

Olo serves 800+ brands across ~90,000 locations with location grouping and multi-concept loyalty programs, but a named 3-level hierarchy object that reporting and permissions scope to is not documented. https://www.olo.com/about-us · retrieved 2026-08-01

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

Centralized menu management publishes 'for a single location or in bulk' in near real time. A publish/version history recording what was pushed, when and by whom is not documented. https://www.olo.com/rails · retrieved 2026-08-01

Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator

multi-location-local-override-policy

The corporate-master / store-override split is documented: 'The Store Menu Admin is where you can turn on and off items from the Company Menu, which serves as the master menu, and apply them to specific locations'; stores can add or remove modifier groups per store menu (dedicated article 115000090243), and for POS-integrated brands each store's prices 'pull directly from the POS' - so availability and effective price vary locally while item definitions live in the corporate Company Menu. Shortfall: no per-field lock rules are documented - nothing shows corporate locking name/image/description while exposing price, or that locked fields are non-editable at store level. https://olosupport.zendesk.com/hc/en-us/articles/360026137891-Store-Menu-Admin-Menu-Training-pt-3 · retrieved 2026-08-04

Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.

multi-location-price-zones

Per-channel and per-marketplace pricing adjustment is documented; per-location-group and per-daypart price tiers on a single item record are not. https://www.olo.com/rails · retrieved 2026-08-01

Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator

multi-location-scheduled-publish

Menu item scheduling with timed auto-return exists (Winter 2026). Future-dated publish interpreted per location timezone with post-activation rollback is not documented. https://www.olo.com/winter-release-2026 · retrieved 2026-08-01

A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator

multi-location-new-store-template

New stores inherit configuration from a corporate template in two places: the Company Menu 'is considered the master menu, which provides information to each of the Store Menus' (Menu Training pt. 1, 360025658332), and the Loyalty Dashboard 'Manage Stores' (46364209387931) adds stores singly or by CSV import against a downloadable template. Shortfall: launching a location is a support workflow ('Launch, Transfer, or Close a Location' is an intake-form category; 'Contact your Customer Success Manager to fully enable your store'), no configuration-clone action or time-to-open is published. https://olosupport.zendesk.com/hc/en-us/articles/360026284851-Menu-Training-Introduction · retrieved 2026-09-03 adversarially verified

The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator

multi-location-corp-vs-franchisee-roles

Two dashboards, both documented. Ordering: 'User Management Overview' (360051811792) gives the Brand Administrator role the power to 'Create Dashboard roles and manage the permissions that make up each role', 'Manage store assignments for users' and manage partner permissions; the Company Menu is 'the master menu, which provides information to each of the Store menus' with a per-product 'Restaurants can change base cost?' flag. Loyalty: 'Dashboard User Permissions' defines named Franchisee roles ('Insights', 'Insights & Support', 'Insights & Lite', 'Insights & Marketing'...) that 'can view their insights (excluding campaign data)' with store-scoped permissions, and 'SMS Send Limits for Franchise Users (LSM Accounts)' caps franchisee sends. Note: Ordering's User Management tool is enabled through the CSM. https://olosupport.zendesk.com/hc/en-us/articles/46365406425115-Dashboard-User-Permissions · retrieved 2026-09-03 adversarially verified

Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator

multi-location-royalty-calculation

The document says: “New Store Opening forms, Franchise Activation forms, Olo Pay forms, and a store onboarding tracker.” VERDICT HELD AFTER RE-RUN, and this is the cell the corpus growth touched least. Every vocabulary control re-run over the final 1,628-document corpus is unchanged from the 1,391-document run, despite 70 added www.olo.com pages: royalties 0 occurrences; ad fund 0; marketing fee 0; revenue share 0; royalty 16 occurrences in 3 documents, all SEC (7 in the FY2024 10-K, 7 in FY2023, 2 in the S-1), and all of them either relief-from-royalty purchase-price valuation - pre-tax royalty rates of 20.0% and 1.0% as measurement inputs for the Omnivore developed technology and trademark - or IP-indemnity risk language about royalty-bearing licensing agreements. Premise P6 stands, and per rule 3 the filings' product silence is no evidence either way. THE NEW FRANCHISE MATERIAL I READ: the product-release hub announces redacting personal data in Olo Reports, giving franchisees access to reporting data while keeping guest personal information visible only to the right people through a single permission toggle - that is a franchisee VIEW permission, the same kind of thing as the Olo Loyalty franchisee roles in Dashboard User Permissions (Insights, Insights and Support, Insights and Lite, Insights and Marketing), not a fee engine. The other franchise-adjacent money surface remains Olo billing the location, enumerated line by line in Olo Invoice Reconciliation (Service Edition Fee, Order Package Fee, Order Transaction Fee, Order with Google Fee, Dispatch Program Fee, Technology Monthly Fee, Technology Transaction Fee) - Olo's invoice to the location, never a franchisor's royalty. This live article (updated 2026-06-14) enumerates the whole Dashboard navigation - Favorites, Stores, Orders, Guests, Menu, Analytics, Payments, Onboarding, Integrations, Settings - and the single franchise-named item in it is the quoted set of Onboarding forms. WHY THE ENUMERATION IS A CEILING: its stated job is to describe each navigation tab, its only caveat being per-account access rather than completeness; per-tab contents are floors (the Onboarding list quoted above is introduced by including:), so the bound is the tab axis, reinforced by vocabulary controls that now span 657 www.olo.com pages including all eleven quarterly release pages and all five SEC filings - not a help-centre-silence argument. Residual risk: 149 referenced KB ids return 401. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: royalties 0, ad fund 0, marketing fee 0, revenue share 0, franchise fee 0, franchise fees 0, advertising fund 0 and royalty 16 occurrences in 3 documents (all SEC) ALL REPRODUCE EXACTLY over the final corpus, which is the strongest control block in this batch. CONTROL CAPABILITY TESTED AND PASSED: franchise fires on 24 documents, franchisee on 39 and royalty rate on 2, so the zero-hit controls above were capable of firing; premise P6 stands. PREMISE P1 CORRECTED IN PASSING, THOUGH IT DOES NOT BEAR ON THIS ROW: the FY2024 10-K states Our platform currently includes the following modules: Ordering, Dispatch, Rails, Switchboard, Network, Virtual Brands, Kiosk, Catering+, Sync, GDP, Marketing, Sentiment, Host, and Olo Pay - a fourteen-module list that omits Serve, Olo Loyalty, Olo Accounts and Order with Google while the site nav omits Virtual Brands and Kiosk, and which is itself introduced by "includes", a floor word. Neither list is a product census and this verdict does not use one. VALUE, GRADE, URL AND QUOTE UPHELD; the nav-tab axis is the right ceiling here because a royalty engine would be a module, not a report. https://olosupport.zendesk.com/hc/en-us/articles/115000076446-Olo-Dashboard-Overview · retrieved 2026-09-06

Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.

multi-location-royalty-collection

The document says: “Franchisee users with marketing permissions can securely subscribe and manage their payment information enabling text message campaigns in their account.” Re-checked at 1,461 and again at 1,628 documents; not one figure below moved across either growth. The only automated franchisee-directed money movement documented anywhere in the corpus is the one this article describes, and it runs the wrong way and for the wrong thing: Olo debits a franchisee's own card or ACH through a third party (“All payment information is hosted by a 3rd-party application, Chargebee, which allows for a secure way to manage your payment and plan information.”) for that franchisee's own Local Store Marketing SMS plan, with a franchisee-visible invoice. Money flows franchisee to Olo for Olo's service; nothing is calculated from sales and nothing reaches a franchisor. That affirmative different-mechanism prose is the basis for the absence, not help-centre silence. P6 TESTED AND CONFIRMED, and now pinned to its acquisition: 'royalty' is 16 occurrences in 3 documents, all SEC, unchanged across all three corpus sizes, with 7 in the FY2024 10-K — 2 IP risk-factor (royalty-bearing licensing agreements; indemnity settlement costs including royalty payments) and 5 relief-from-royalty purchase-price-allocation valuation at a pre-tax royalty rate of 20.0% on developed technology and 1.0% on the trademark. I traced that PPA to its subject: it is the OMNIVORE acquisition (the note states the valuation of assets acquired for the acquisition of Omnivore was finalized during the year ended December 31, 2023, allocating Developed technology $4,410k, Trademark $150k, Goodwill $44,919k). So all 7 hits are accounting, exactly as P6 says, and none concerns franchise royalties. Controls re-run over all 1,628 documents, all UNCHANGED: 'royalties' 0, 'franchise fee' 0, 'franchise fees' 0, advertising fund 0, 'ad fund' 0, 'sweep' 0, 'ACH' 4 documents and 12 occurrences (this article; Billing | Manage Your Payment Method(s); Provide Olo's ACH ID to your Bank, which is Olo debiting the operator for Olo's own fees; and the archived Dispatch Billing in Canada). The newly readable back-office partners do not change it: Restaurant365, the one restaurant accounting and back-office platform in the directory, is tagged Data Analytics only and its page describes no fee collection. The five release pages add user-based billing, franchisee report access with guest-data redaction, bulk EIN and bank assignment in Olo Pay onboarding, and order-size-tiered fees — Olo's own pricing, not a franchisor's. Bound: 52 published partner pages (tattle through zonal) remain unread; a franchise back-office partner could hide there, and that would still not make royalty collection an Olo capability. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: royalties 0, franchise fee 0, franchise fees 0, advertising fund 0, ad fund 0, sweep 0, ACH 12 occurrences in 4 documents, royalty 16 occurrences in 3 documents all SEC - ALL REPRODUCE EXACTLY over the final corpus, unchanged across four corpus revisions. CONTROL CAPABILITY TESTED AND PASSED: franchise fires on 24 documents, franchisee on 39, "franchisor" on 1 and royalty rate on 2, so the zero-hit controls were capable of firing. Premise P6 is confirmed and the Omnivore purchase-price-allocation tracing is sound. THE ONE BOUND THAT IS WITHDRAWN IS THE ONE THE NOTE ITSELF FLAGGED: 52 published partner pages (tattle through zonal) remain unread; a franchise back-office partner could hide there - all 52 are now read, no partner page in the complete directory describes fee collection from a franchisee, and the directory's 37-label service vocabulary contains no accounting, billing or royalty category at all. The named remainder is satisfied and the bound is now closed rather than open. VALUE, GRADE, URL AND QUOTE UPHELD. https://olosupport.zendesk.com/hc/en-us/articles/46371030607515-Billing-a-Single-User · retrieved 2026-09-06

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

Above-store aggregation across sales, marketplaces and guest segments is Olo's default reporting posture for enterprise brands, with by-location and by-marketplace slicing. https://www.olo.com/rails · retrieved 2026-08-01

Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator

multi-location-normalized-item-rollup

Cross-location item rollup exists: the 'Product Breakdown' report gives 'Products broken out by restaurant' across whatever store set is selected, and store menus are instances of the corporate Company Menu ('the master menu'), so reporting keys to shared corporate products rather than per-store item lists. Shortfall: the docs never address the claim's hard case - whether rollup survives a store renaming or locally diverging an item - and store menus can carry store-specific deviations whose normalization is undocumented. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-08-04

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

The document says: “You must provide Olo with a valid credit card (Visa, MasterCard, American Express, Discover, or any other issuers accepted by us), charge card, Branded Company-specific gift card or Branded Company-specific cash card (“ Payment Provider ”).” The Terms of Use is a current, platform-wide vendor legal document (grade B) and it settles whose card it is: the guest tenders a Branded Company-specific gift card, the restaurant brand's instrument, which Olo accepts as a Payment Provider. Olo issues nothing. That is affirmative prose describing a different mechanism, which carries the absence — not help-centre silence, which cannot bound anything here (the public KB is a 26.8% floor: 231 public articles, 288 href-referenced ids, 149 of the missing returning 401). Conjunct by conjunct. (a) Cross-location redemption: served, but never by an Olo card — the Aloha POS FAQs (article 360001988831, live, updated 2026-06-14) state Olo has an integration to Aloha Stored Value configured above store for a whole brand, and the Summer 2026 release page (https://www.olo.com/product-release) announces an Ecard systems integration processing gift cards across 150+ POS systems including Toast, Square, Revel and Clover, explicitly without disrupting the brand's existing program. Processing, not issuing; the program stays the brand's. No phrasing of the kind Olo cannot handle gift cards across locations is permissible. (b) Reported outstanding liability: absent. The only liability report Olo publishes is the Olo Loyalty points liability export; 'liability' is 17 documents and 296 occurrences over all 1,628 documents (unchanged from the 1,461 run), and the sole live-KB carrier is still that points export. (c) Inter-store settlement between owners: absent. 'inter-store' is 0 occurrences across all 1,628 documents; Olo Pay's terms settle proceeds to the merchant's own bank account, and the Summer 2026 banking feature assigns a brand's EIN and bank details to its own locations in bulk rather than settling value between separately owned stores. ON THE BOUNDING ENUMERATION, now reconciled: Olo's sitemap publishes 392 /partners/<slug> URLs; the corpus now holds exactly 340 of them, which is exactly the All count in the directory's own facet widget, so the directory's 340 is its indexed set and the 52 sitemap extras (a contiguous t-to-z tail, tattle through zonal) are pages the directory itself does not count. The facet taxonomy is therefore a ceiling for the categories Olo recognises — tested directly: across the 263 partner pages carrying a Services block, every service label found is inside the 37-facet vocabulary — while any per-category count remains a floor with that named 52-page remainder. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: inter-store 0 occurrences and liability 296 occurrences in 17 documents both reproduce exactly. THE PARTNER-DIRECTORY RECONCILIATION IN THIS NOTE IS FALSIFIED AND IS REPLACED, AND THE AUDITOR RULES ON THE 340-VERSUS-392 QUESTION HERE BECAUSE THIS IS WHERE IT WAS ANSWERED WRONGLY. The note says the corpus holds exactly 340 partner pages, that this equals the directory's own All 340 facet, and that the 52 sitemap extras are pages the directory does not count. Measured over the complete corpus: the sitemap publishes 392 /partners/<slug> URLs, the index holds 392, and ALL 392 carry a parseable Services block - the 340 was an artefact of a parser that required a trailing Socials heading, and it matches the facet only by coincidence. The facet's own numbers are lower than the corpus in 25 of its 37 categories and higher in none, so All 340 understates Olo's 392 published partner pages by 52 and every per-category facet count is a FLOOR. RULING ON WHETHER THE FACET TAXONOMY IS A CEILING: IT IS, BUT ONLY ON THE VOCABULARY AXIS, AND THAT AXIS IS NOW CLOSED RATHER THAN SAMPLED. Across all 392 pages the Services blocks yield exactly 37 distinct labels and every one of them is inside the directory's 37-facet vocabulary, with zero labels outside it and zero facets unused - an exhaustive test with no remainder, which is a materially stronger result than the 263-page sample the note reports. Per-category MEMBERSHIP remains a floor. VALUE, GRADE, URL AND QUOTE UPHELD at no/B: the Terms of Use is a live vendor legal document and it settles whose instrument it is, and the three limbs fail as the note describes - Olo accepts a Branded Company-specific gift card, issues none, publishes no outstanding gift liability (its only liability export is Olo Loyalty points), and documents no inter-store settlement. THE CHECKER'S FOURTH NOWHERE STRING IS CONFIRMED, NOT ASSUMED: the phrase Olo cannot handle gift cards tokenises to 0 documents in the corpus, which is exactly why the note quotes it - to say the evidence forbids it. https://www.olo.com/terms-of-use · retrieved 2026-09-06

A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.

multi-location-cross-location-loyalty

Olo Loyalty supports multi-concept programs on a brand-wide guest profile; Olo Accounts recognizes a guest across the entire Olo network, not just one location. https://www.olo.com/loyalty · retrieved 2026-08-01

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

The Ordering product explicitly supports virtual brands, and Loyalty supports multi-concept programs. The 'same hardware and drawer' half of the requirement is POS-side and outside Olo's control. https://www.olo.com/ordering · retrieved 2026-08-01

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

Per-location tax handling with marketplace tax-exempt order support (Fall 2025), catering tax-exempt certificate upload (Summer 2026), and estimated taxes shown as a separate guest line item. Authoritative tax calculation generally originates in the integrated POS. https://www.olo.com/product-release · retrieved 2026-08-01

Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.

multi-location-multi-currency-locale

Cross-border stores in one account are supported; per-location currency and language are not. Manage Stores documents the store import file field by field, and the country field reads 'country the store is located. Values supported are “United States” and “Canada”.' - two countries and two currency areas, in one Olo Loyalty account where, as the article puts it, 'If you maintain a single or multiple stores for your account, you can manage them all from within your Settings.' SHORTFALLS: the enumerated store record carries no currency, locale, language or reporting-currency attribute at all - its fields are store_name, import_store, store_status, street_address_line1 and line2, city, state, zip, country, phone_number, the weekday and weekend opening/closing hours, and the POS keys toast_location_guid, qu_location_id, brink_location_token and revel_store_id. 'Currency' is zero-hit across the whole 231-article help centre. The Olo Pay terms and conditions separately disclaim any commitment to non-USD settlement, stating that the payment facilitator makes no guarantee it will provide the option to use currencies other than U.S. dollars and that available currencies may change at any time without notice. Nothing therefore establishes FX-converted consolidated reporting or a per-location language, and the documented country ceiling is two. The only locale dimension documented anywhere is time zone: the separate Live Insights article attributes data to the local time zone of the store where the purchase occurred. CENSUS CORRECTION, re-measured 2026-09-06 (the earlier figures in this note - 383 referenced, 152 absent, 40% - did not reproduce and must not be cited again): the Olo help centre is a FLOOR, not a census. The 231 public bodies reference 288 distinct article ids, of which 156 are absent; probed individually, 149 return 401 and 7 return 404, while nine fabricated ids at the same digit lengths all return 404. The Wayback CDX index then names 763 ids that once served 200, 549 of which the href fixpoint never saw, and 483 of those 549 still return 401 today - so the live help centre holds at least 231 + 632 = 863 articles and the public API shows 26.8% of it. Any zero-hit statement above is a floor over 231 of at least 863, not an enumeration. Re-derive with node .cache/q225/kb-census.mjs. So "'Currency' is zero-hit across the whole 231-article help centre" is a floor result, and 'the documented country ceiling is two' is a ceiling on one document, not on the platform. SCOPE: 'Manage Stores' (46364209387931) is the OLO LOYALTY store-import specification, not the ordering platform's store model, so the two-country field list bounds Loyalty store import only. What survives is the affirmative cross-border fact (US and Canada stores in one account) plus the published Olo Pay terms' non-USD disclaimer, which sits on the legal set and does close. https://olosupport.zendesk.com/hc/en-us/articles/46364209387931-Manage-Stores · retrieved 2026-09-04

Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator

multi-location-config-audit-log

The Menu Audit Log records 'a full history of menu updates, who is making them, how often, and the specific change details': edit date/time in local time, company vs vendor (store) menu, the action performed, 'Manager that performed the action', stores affected, and the place on the menu where the change was made - with search, filtering, .csv export, and review 'up to 30 days at a time.' Shortfall: it covers menu changes only - permissions, discounts/coupon setup, tax and other configuration objects have no documented audit trail - no immutability or retention statement exists, and the live article now sits behind customer SSO (the live URL 302s to olo.com/zendesksso; the cited 2022-01-29 Wayback capture is the page actually read). http://web.archive.org/web/20220129041947/https://olosupport.zendesk.com/hc/en-us/articles/360019752171-Menu-Audit-Log-Overview · retrieved 2026-08-04

Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator

multi-location-enterprise-sso

'Dashboard Login & Account Creation': 'if your company uses Single Sign On (SSO), then you must log in to Dashboard using your company's "Identity Provider" (rather than using the Olo Dashboard login page)', and private help-centre articles require login 'via SSO' when the brand uses 'a Third Party Identity Provider'. Shortfall: the protocol (SAML vs OIDC) is not named, no IdP setup guide is public, and SCIM provisioning/deprovisioning is not documented. https://olosupport.zendesk.com/hc/en-us/articles/4422086507035-Dashboard-Login-Account-Creation · retrieved 2026-09-03 adversarially verified

Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator

multi-location-enterprise-api

Withdrawing the old citation: developer.olo.com now 302s to /Account/Login (5,710-byte form, re-probed 2026-08-09), so no public endpoint contract is readable. What is readable is the public help centre. Reports are built by selecting 'the Report Category, Report Date Range, and Store Locations', and the catalogue includes 'Orders placed for a restaurant or group of restaurants by day', 'Closed Orders by Store', 'Itemized Orders' and 'Product Breakdown - Products broken out by restaurant', downloadable as .xlsx or .csv - transaction-level data across an arbitrary set of locations from one authenticated Dashboard session, no per-location credentials. Webhooks Overview (article 115005291346) adds a brand-wide push channel: webhooks 'provide order, menu, user, and vendor data as it changes', enabled per brand in the Dashboard. Shortfall: the multi-location export is an interactive Dashboard report, not a documented programmatic endpoint - for the webhook and API contract that same article says 'reference the Developer Portal documentation' and 'Olo can provide access to the Developer Portal', which is customer-gated. So the cross-estate data exists and is retrievable, but no publicly documented single-call API contract does. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-08-09 adversarially verified

Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.

multi-location-central-labor-policy

The document says: “Sales data will flow seamlessly from your POS System into Harri for easy, at-a-glance reporting and for sales forecasting, empowering businesses to control labor costs by leveraging activity-based labor scheduling.” The claim asks for labor rules configurable per location or location group and enforced AT THE TERMINAL. Olo operates no terminal and keeps no employee record; this page states the direction of travel — sales data leaves the POS through Olo's Omnivore middleware and lands in a third-party labor system, which is where scheduling and compliance live. The page carries “*This integration is currently only supported through the Omnivore API*”. With the partner directory now essentially complete I can census the category rather than sample it: 17 partners carry the Labor Management service tag (the facet claims 18; the one unseen is in the 52-page t-to-z remainder), and they are 7shifts, Axial Shift, Backbar Solutions, CheddrSuite, EmployeeMetrics, Fourth, Harri, Instant, Lineup.ai, Paychex, PourMyBeer, Proliant, ShiftForce, Tip n Post, TipHaus, TipReports and Tipzyy. CORRECTION to my earlier note, which over-generalised: 16 of the 17 carry the Omnivore-only notice and ShiftForce does NOT — it is tagged Data Analytics and Labor Management with no Omnivore integration described at all. Either way the labor rule lives in the partner's product, on the partner's surface. Nothing here is Olo enforcing an overtime, break or predictive-scheduling rule at a terminal it does not operate. Controls re-run over all 1,628 documents, all UNCHANGED at zero: 'overtime' 0, predictive scheduling 0, 'fair workweek' 0, 'meal break' 0, 'time clock' 0, 'timeclock' 0, 'timekeeping' 0, 'hours worked' 0, 'punches' 0. Two near-miss controls checked by sense rather than count: 'clock in' 5 occurrences in 3 documents, two archived Aloha POS error-code articles about a POS employee login and one blog headline; 'punch' 5 occurrences in 3 documents, every one a loyalty punch card. 'labor hours' 4 occurrences in 3 documents — Olo's own R&D labor hours in the 10-Q, and two customer testimonials about staff time saved. Grade C because a partner page is vendor marketing. Note that data/vendors/olo/product.yaml excludes the labor category from scoring; this claim sits in multi-location and is scored. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: overtime 0, predictive scheduling 0, fair workweek 0, meal break 0, time clock 0, timeclock 0, timekeeping 0, hours worked 0, punches 0, and the two near-miss controls clock in 5 occurrences in 3 documents and punch 5 in 3 - ALL NINE ZEROS AND BOTH NEAR-MISSES REPRODUCE EXACTLY over the complete corpus. CONTROL CAPABILITY TESTED AND PASSED, and this was worth testing because these are the batch's most load-bearing zeros: scheduling fires on 53 documents / 76 occurrences, employee scheduling on 2, labor compliant on 1, compliance features on 1 and "hours" on 185 documents / 626 occurrences, so a predictive-scheduling or break-enforcement description would have been found. THE LABOR CENSUS IS CORRECTED AND IS NOW CLOSED. With all 392 partner pages read, 18 carry the Labor Management service tag - the analyst's predicted eighteenth is Today - and 18 is exactly the directory facet's own count, so this is one of the twelve categories in which the facet and the corpus agree and the category is a genuine census rather than a floor. The full set is 7shifts, Axial Shift, Backbar Solutions, CheddrSuite, EmployeeMetrics, Fourth, Harri, Instant, Lineup.ai, Paychex, PourMyBeer, Proliant, ShiftForce, Tip n Post, TipHaus, TipReports, Tipzyy and Today. The analyst's correction stands with one more partner: SEVENTEEN of the eighteen carry the Omnivore-only notice and ShiftForce does not. VALUE, GRADE, URL AND QUOTE UPHELD at no/C. WHY THIS IS A `no` WHILE ITS TWO OMNIVORE SIBLINGS ARE `partial`: this claim requires enforcement AT THE TERMINAL, and no partner supplies that over the Omnivore API either - the rule lives in the partner's own product - whereas payments-tip-pooling and extensibility-payroll-export ask for a computation and an export that the partner demonstrably does supply over it. https://www.olo.com/partners/harri-sales-connector · retrieved 2026-09-06

Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.

extensibility-public-api-docs

Re-evidenced 2026-08-09 - the old citation (developer.olo.com) is now only a login form and a gate is not by itself proof of absence, so the cell now rests on Olo's own published API Terms of Use, which state the position affirmatively. Section 3: "'Confidential Information' means the Olo APIs, all information provided by Olo about the Olo APIs, performance and any other specifications for the Olo APIs, including any Olo-provided specifications used by you to build your own API(s) for integration with Olo... You shall not disclose Confidential Information to any third party." Section 1(e): "Olo will make credentials available to you through the Olo developer portal... Credentials for production will only be granted after certification, which must be completed separately for each Olo API." Corroborated by Olo's own public SDK README, which links developer.olo.com/docs/load/olopay and annotates it "(Note: requires an Olo Developer account)", and by the live probe: developer.olo.com and every path under it 302 to /Account/Login (5,710 bytes; /robots.txt and /sitemap.xml return the portal's own NotFound page). Omnivore's docs sit behind panel.omnivore.io/login (403 to anonymous fetch). One narrow carve-out, which does not change the value: the Olo Pay client SDK class reference is public at ololabs.github.io, and signature-auth code samples are public at github.com/ololabs/dev-support-code-samples - but those are client-side helpers, and the Ordering, Rails, POS and webhook API references they point at are the confidential, credentialed material. https://www.olo.com/api-usage-terms · retrieved 2026-08-09 adversarially verified

API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator

extensibility-api-access-cost

Olo's binding APIs Terms of Use contain no access, per-location or tier fee of any kind. The only money in the whole instrument is a breach remedy - Olo reserves the right to, at its sole discretion, 'charge you a penalty fee and/or (2) immediately suspend access to the API if you breach any terms of these Terms of Use' - which is a penalty, not an access charge, and must not be read as one. Corroborated on a second surface by Olo's own enumeration of what an operator is actually billed, the help-centre article Olo Invoice Reconciliation (37069343928219), which lists Service Edition / OFP-Contracted Platform Fee, Order Package Fee, Order Transaction Fee, Order with Google Fee, Dispatch Program Fee, Technology Monthly Fee, Payment Gateway Fee and Technology Transaction Fee - and no API, developer-portal, integration or webhook line item. Shortfalls that keep this off 'yes': (1) access is gated, not free-at-will - 'Credentials for production will only be granted after certification, which must be completed separately for each Olo API', so each additional API is a separate approval; (2) the Terms expressly subordinate themselves to the unpublished contract - 'If any of the terms of the Agreement differ from a term in this Terms of Use, the terms in the Agreement will control' - and there is no published MSA, SLA or price list anywhere on www.olo.com (the 657-loc sitemap has no /pricing page), so a negotiated API or integration fee cannot be excluded; (3) that invoice list is explicitly conditional on the brand's billing structure, not an exhaustive rate card. https://www.olo.com/api-usage-terms · retrieved 2026-09-04

The vendor publishes its partner/marketplace commercial terms (referral fee, revenue share percentage, or per-location partner fee) in public documentation.

extensibility-partner-revshare

Olo does publish some channel-partner commercial terms in public, unauthenticated vendor documentation. Olo Invoice Reconciliation states 'There are various line items that can appear on your invoice depending on the billing structure determined by your brand' and then names, among others, an Order with Google Fee at '5% charged on the subtotal of all orders processed via Google enhanced redirect', a Technology Transaction Fee described as a 'Transaction fee, applicable to each order processed by Licensed Applications', a Service Edition Fee / OFP-Contracted Platform Fee being a 'Monthly fee, per active location for using the Olo platform', plus Dispatch Program Fee, DSP Fee and DSP Tips. So a marketplace-channel revenue-share percentage and a per-active-location platform fee are both published. Shortfalls: the amounts for every other line are deferred to the unpublished MSA, which the same article tells the reader to consult for all order-package pricing details per location; nothing is published for the Olo Connect partner directory itself - the two /partners/*-pricing pages on disk (juicer-pricing, sauce-pricing) are partner product names, not fee schedules, and disclose no referral fee, rev-share or per-location partner fee, and the 393-loc /partners/ tree is unmined; and for Rails, Olo disclaims knowledge rather than disclosing, the Rails FAQ (115005665043) saying Olo is oftentimes not privy to the fee/commission structures between the store and the marketplace. The prior verified verdict of unknown rested on the partner directory's silence, which still holds for the directory; it missed this affirmative first-party fee disclosure, so this is an upgrade on new evidence rather than a contradiction. https://olosupport.zendesk.com/hc/en-us/articles/37069343928219-Olo-Invoice-Reconciliation · retrieved 2026-09-04 adversarially verified

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

A test environment exists: 'What is OloCloud?' says 'Once we've tested the integration in our test environment, we'll connect you with a developer who will approve the integration for testing in our production environment'; the Loyalty 'Olo Ordering Integration' article refers to 'the Olo Sandbox account', 'Sandbox API and oAuth credentials' and an 'Olo Test Lab'. Shortfall: the sandbox is provisioned by Olo for contracted brands and certifying partners ('If Olo Sandbox account is available'); it is not free, self-serve, or documented with seeded data. https://olosupport.zendesk.com/hc/en-us/articles/115005674526-What-is-OloCloud · retrieved 2026-09-03 adversarially verified

Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).

extensibility-oauth-partner-apps

'Olo Ordering Integration' (Loyalty): 'the Olo integration team sends the Olo Loyalty Sandbox API and oAuth credentials', 'Olo sets up the oAuth and the API Integration', and to disable, 'Olo disables the oAuth and API integrations'. So the Loyalty API authenticates integrations with OAuth credentials that Olo issues and revokes per integration. Shortfalls: credentials are issued by Olo's integration team, not granted by the operator; scopes are not documented; the Ordering platform API's own auth model remains behind the login-gated developer portal. https://olosupport.zendesk.com/hc/en-us/articles/46381686489883-Olo-Ordering-Integration · retrieved 2026-09-03 adversarially verified

The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.

extensibility-webhooks-push

'Webhooks' is a first-class monitored component on Olo's status page, confirming push exists; the event catalog and lifecycle coverage are not publicly readable. https://status.olo.com/ · retrieved 2026-08-01

Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator

extensibility-webhook-reliability

Signing is documented: in the Olo Ordering Integration the 'Brand configures the Webhooks and share the generate Secret with Olo integration team', who configure 'the secret in Olo Loyalty' to verify the order-event webhooks; the OloCloud POS interface likewise lists 'Signature validation' as a requirement (115005674526). Shortfall: no public page documents retry with backoff, redelivery, or replay; the Webhooks Overview (115005291346) defers those to the login-gated Developer Portal. https://olosupport.zendesk.com/hc/en-us/articles/46381686489883-Olo-Ordering-Integration · retrieved 2026-09-03 adversarially verified

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

Order injection is Olo's central function — Rails marketplaces, Order with Google, Switchboard, the Olo Network app and partner front-ends all inject through Olo's Ordering API into the brand's POS as normal tickets. https://www.olo.com/rails · retrieved 2026-08-01

Menu items, modifiers, and prices can be written and updated via API, not just read. differentiator

extensibility-menu-write-api

A programmatic menu-write path into Olo exists and is named in vendor documentation: the Rails Filters article's FAQ asks 'My brand uses MIS/Menu Sync (aka Store Sync) to send Olo menus. Can I use this feature?', i.e. brands push their menus into Olo through Menu Import Service / Menu Sync rather than only typing them into Menu Admin. Prices are also written into Olo programmatically from the POS - Menu Mapping, Menu Training pt. 2 (360026137851), documents that for POS-integrated stores Olo automatically updates prices twice daily plus a manual update and a brand-wide Price Sync Tool - so item prices are machine-updated, not read-only. Shortfalls, which are why this is not 'yes': no endpoint reference, verb set or schema is public (developer.olo.com is login-gated and its /robots.txt 302s, so under RFC 9309 the host is blocked, and the API Terms make the specifications Confidential Information), so it cannot be established that MIS is an HTTP API rather than a file/feed service; the public help centre contains no MIS or Menu Sync article at all - but that is a FLOOR, not a census: the Zendesk API and the sitemap agree at 231 only because both are generated from the same table filtered to the same public visibility, and the 231 public bodies reference 383 distinct article ids, so 152 (40%) are gated (401/403, not 404). The gated set is dominated by exactly the articles that would carry this - roughly fifteen per-POS 'Menu Mapping Instructions' (Toast Basic and Advanced, Aloha, Simphony, SimphonyCloud STS GEN2, Micros M3700, Brink, Revel, Focus, Xpient, Xenial, POSitouch, CBS Northstar, Treatware, OloCloud), 'Fixing Menu Mismatches' (360025180392) and 'Menu Training FAQ' (360026412751). So the absence of an MIS article is not evidence about MIS; the mechanism is established affirmatively, by being named in the Rails Filters FAQ; MIS/Menu Sync brands are second-class, since 'Rails filters can only be configured using the Menu Admin interface within the Dashboard and cannot be configured using Menu/Store Sync or Menu Import Service'; and the price write is POS-to-Olo on Olo's schedule, not an operator-driven write. https://olosupport.zendesk.com/hc/en-us/articles/360028092432-Control-Marketplace-Menu-Visibility-with-Rails-Filters · retrieved 2026-09-04

Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator

extensibility-data-symmetry

NEW SURFACES, STILL unknown. (1) docs.wisely.io (Olo Engage API, anonymous Postman collection, 48 requests). Orders are write-only there: "PUT pos/orders Create Order" and "POST orders/batch" exist, with no order GET, and "order.source_type ... Currently, only accepted values are \"toast\" or \"olo\"". Guests are read+write (guest/search, external/guest/create, guest/create upsert). Reservations and waitlist have GET/POST/PATCH/DELETE. There are no menu, employee or inventory objects. (2) mcp.olo.com anonymous ordering MCP server tools/list (17 tools). Restaurants and catalog are read-only (search_restaurants, get_restaurant, search_catalog, get_product, lookup_catalog). Carts/checkouts/orders are create/read/cancel. Neither surface is the core Ordering API reference (developer.olo.com is still a login shell), so read/write parity across the claim's five objects cannot be scored. Retrieved 2026-09-16. || 323rd: NEW SURFACE, still unknown, and it adds a third asymmetric object set. Beyond the Engage Postman collection (orders write-only) and the mcp.olo.com tool list (catalog read-only), Olo documents a Snowflake data share - 'Olo Engage Warehouse (Data Warehouse Connection)' https://getwisely.zendesk.com/hc/en-us/articles/5026134931099 - whose Client Share Data Dictionary (https://getwisely.zendesk.com/hc/en-us/articles/5026146180507) enumerates 49 views in schema wisely_share_v2 covering orders, tickets, olopay_transactions, processor_transactions, guests, guest_visit_history, parties, feedback_form_responses, sentiment_reviews and the campaign and automation history. A Snowflake share is read-only by construction and the article offers no write path for any of those 49 objects, so the three documented Olo surfaces are each one-directional in a DIFFERENT direction: orders writable but not readable (Engage API), catalog readable but not writable (MCP), 49 warehouse objects readable but not writable (Engage Warehouse). That is the shape the claim calls asymmetric, but it still cannot carry a no, because Olo's main Ordering API is documented only behind the developer.olo.com login (an ASP.NET login shell on every path including /docs and /llms.txt) and one partner portal is not a census of a vendor's APIs. Retrieved 2026-09-17. || 325th: 325th: TWO NEW SURFACES, neither measures symmetry. (1) CORRECTION TO THE BRIEF'S PREMISE: developer.olo.com is NOT open. Its root serves only two links (/project and www.olo.com/api-usage-terms), /docs and /project both 302 to /Account/Login?ReturnUrl=, and /robots.txt, /sitemap.xml, /llms.txt and /openapi.json all land on /Error/NotFound?aspxerrorpath=. The Ordering API reference cannot be read anonymously, so no object-by-object read/write matrix can be built. (2) api.omnivore.io (Olo's POS-integration API, marketed at www.olo.com/omnivoreapi) DOES serve an anonymous HAL index at /1.0/: _links activate, auth, billing_onboarding, connect, data, oauth2, referral_code, support, test. Walking it anonymously yields /1.0/data/pos_types/ — a live POS-type census (aloha "NCR Aloha" v12.3+, brink "Par" all, cloudconnect "NCR CloudConnect" Real Time v3, doshii beta 3+, each with a versions collection and a gateway boolean) — and /1.0/connect/pos/. Every location, ticket, menu, employee and tender resource sits behind /1.0/oauth2/, so the methods per object are unobservable without credentials; /1.0/locations/ and /1.0/docs/ return honest {"errors":[{"error":"not_found"}]}. (3) status.olo.com/api/v2/components.json enumerates 39 production components and names the API surfaces separately — Ordering API, Point of Sale API, Dispatch API, Coupon API, Menu Services, Menu Exports, Webhooks, Sandbox Environment, Eighty Sixing, Reporting, Scheduler, Developer Portal — which shows menu EXPORTS as its own component but is a health-check list, not an object model, so notes only. Held unknown. Retrieved 2026-09-17. || 326th: 326th: NEW SURFACE, no move, and it is a documented one-directional surface. Olo's bulk data product is the Engage Warehouse: 'Olo has developed the Engage Warehouse to empower clients to leverage all of their Olo data with the flexibility of Snowflake ... This data share is a live connection to our warehouse that provides real-time data updates that can be queried upon', with SnowSQL instructions that go no further than 'SHOW SCHEMAS; USE SCHEMA wisely_share_v1; SHOW TABLES'. Its companion 'Olo Engage Data Warehouse Client Share Data Dictionary' (149,475 bytes of HTML, 62,295 chars of text) defines every view of wisely_share_v2 column by column with a refresh cadence, and tokenised over that dictionary 'write' 0 and 'read-only' 0 - the verb is absent in both directions, but nothing in it or in the connection guide describes any path for a client to write a row back. Ingest, where it exists, runs the other way through Olo-operated integrations ('a brand's Sparkfly Loyalty data is ingested on an ongoing basis via Engage API endpoints'). The Ordering API object model still cannot be read: developer.olo.com/docs 302s to /Account/Login (re-confirmed today), and the one gated olosupport article that would bear on the write side is titled 'Self Service Webhooks' (id 360061153692, 401). Held unknown: a warehouse share is not the API the claim is about, and Olo's API reference remains unreadable anonymously. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. read-and-write / bi-directional / write-back 1 hits in 1 pages, and it is a PARTNER's claim ("Sparkfly ... with bi-directional connection to the POS and Olo"), not an Olo API object matrix. Nothing on www.olo.com enumerates API objects or methods. Retrieved 2026-09-18. adversarially verified

API rate limits are published as specific numeric quotas with documented throttling behavior and headers.

extensibility-published-rate-limits

CLAIM: API rate limits are published as specific numeric quotas with documented throttling behavior and headers. VERDICT: partial/B (the published value is no/B, cited to the olo.com API Usage Terms, and it is now FALSIFIED for part of the platform). NEW SURFACE: docs.wisely.io, found via crt.sh on wisely.io (Olo acquired Wisely; it is now Olo Engage, and the dashboard at app.getwisely.com is titled "Olo | Engage Dashboard"). It is an anonymous Postman Documenter collection "Wisely API (Public)" (collection JSON https://docs.wisely.io/api/collections/26531044/2s9Y5Tz5NW?segregateAuth=true&versionTag=latest, 5.0 MB, 48 requests, "public":true). No prior olo pass cited it. EVIDENCE (verbatim): Create Order, Get Guest Profile, Create Reviews, Create Review Response and Update Review Response say "Rate Limit: Soft limit of 30 requests per second per store."; Create Order Bulk says "Soft limit of 25 requests per second per store."; the collection description says "429: Rate limited - Use the response headers to decide when to submit the next request". WHY partial: numeric quotas are published for only 6 of 48 requests. The throttling response (429) is documented, but no header is named (controls x-ratelimit / ratelimit / retry-after = 0 in the collection). The limits cover only the Engage (Wisely) API. The Ordering/Dispatch/POS APIs are still governed by the API Usage Terms' "reasonable request volume, as set by Olo from time to time". Retrieved 2026-09-16. https://docs.wisely.io/ · retrieved 2026-09-16 adversarially verified

The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator

extensibility-doordash-preferred

DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `olo_rails`, rendered as 'Olo', with qualityStatus CERTIFIED and 7 of the 8 high-quality features built. CERTIFIED and AT_RISK are the program's other two tiers, so this is positive evidence of non-membership rather than a failure to find the vendor: it is present in the registry and carries a status that is not PREFERRED. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

Olo Help Center, Set Up the Rails DoorDash Integration (Self-Service): brands 'log in with their DoorDash account, using DoorDash's secure login (oAuth), then select the Olo and DoorDash stores they want to map,' then Activate Integration to reach 'Live on Marketplace'. The article explicitly covers migrating off competing middleware - 'You can move your store integration from another provider to Olo through the screen... once you integrate the store through Olo orders will start to be directed to Olo.' Uber Eats and Grubhub are named on Supported Rails Marketplaces. No Otter/Chowly/Deliverect/Checkmate layer is involved; Rails is Olo's own module, though the docs note 'Rails billing will need to be setup for the Olo store.' https://olosupport.zendesk.com/hc/en-us/articles/27060912955035-Set-Up-the-Rails-DoorDash-Integration-Self-Service · retrieved 2026-08-02 adversarially verified

The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).

extensibility-middleware-compatibility

Olo's partner directory lists Chowly and Cuboh, each stamped 'This integration is currently only supported through the Omnivore API', i.e. they inject into the POS through Olo's Omnivore middleware arm rather than treating Olo Ordering as an endpoint. The olo.com sitemap (661 URLs) has no Deliverect, Otter or Checkmate partner page. Shortfall: two aggregators, both via Omnivore only; Olo itself is not documented as a middleware endpoint. https://www.olo.com/partners/chowly · retrieved 2026-09-03 adversarially verified

Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.

extensibility-accounting-connectors

Restaurant365 is a listed Olo Connect partner ('restaurant-specific accounting and back-office software platform'), but the page names no data flow, journal mapping or ownership of the connector. The 661-URL olo.com sitemap contains no QuickBooks Online, Xero or Sage partner page. Shortfall: no QuickBooks Online connector, and the R365 listing does not establish a vendor-maintained journal-entry integration. https://www.olo.com/partners/restaurant365 · retrieved 2026-09-03 adversarially verified

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

The document says: “Our integration with Omnivore saves you time and money by eliminating inaccuracies and data duplications with a seamless, user-friendly 2-way integration between your payroll and point-of-sale systems. Proliant and Omnivore work together by sharing important employee and pay information between systems automatically in real-time.” MOVED `unknown` to `partial` once the partner-directory tail was fetched; my earlier `no` and then `unknown` both rested on controls that were measuring where the crawl stopped. THE TWO PROVIDERS ARE REAL: Paychex (https://www.olo.com/partners/paychex, self-described as cloud-based payroll, HR, and benefits solutions, and named in this claim's own rubric) and Proliant (this page, a leader in the HR and payroll industry) both carry the service tags Labor Management and Omivore and both carry “*This integration is currently only supported through the Omnivore API*”. THE PIPE IS OLO'S OWN, not a marketplace listing: Omnivore is Olo-owned, and the FY2024 10-K carries its purchase price allocation — Developed technology $4,410k, Trademark $150k, Goodwill $44,919k — which is grade-A confirmation that this middleware is an Olo product. Direction is right for the claim: Proliant describes a 2-way integration between payroll and point-of-sale systems, so POS-to-payroll movement is covered, and it is explicitly automatic and real-time, which answers the claim's without-manual-re-keying test. THE NAMED SHORTFALLS, four of them, are why this is `partial` and not `yes`. (1) NOBODY SAYS HOURS. The claim asks for LABOR HOURS. This page says employee and pay information — materially closer than the Harri page's sales data, but not the same thing as clocked hours, and I will not read it as such. Across all 1,628 documents 'time clock', 'timeclock', 'timekeeping', 'hours worked', 'punches' and 'overtime' are each 0 occurrences, and the 5 hits for 'punch' are every one a loyalty punch card. No document in the corpus says a punch or an hour moves. (2) ONLY ONE OF THE TWO DOCUMENTS ITS PAYLOAD. Paychex's page describes what Paychex sells and says nothing about what data crosses the integration, so the claim's two-provider threshold is met on provider identity but only singly on evidenced data flow. (3) IT IS OMNIVORE, NOT THE OLO PLATFORM. The capability sits in Olo's POS-middleware product, not in the ordering, Serve, Pay or Loyalty surfaces the rest of this record scores, and Olo's own site files Omnivore API under Partners rather than in its product nav. (4) OLO HOLDS NO CLOCK. Any hours originate in the customer's POS; Olo relays rather than produces them, so 'natively' is true of the pipe and not of the record. Grade C: both pages are vendor marketing, and the claim is table-stakes weight so no grade floor bars a non-`yes` verdict at C. What would settle it upward to `yes` is an Omnivore API reference enumerating an employee, shift or labor endpoint; that is not in this corpus. Bound: 52 of Olo's 392 published partner pages (tattle through zonal) remain unfetched, so the payroll-partner set is a floor — though no payroll or HCM vendor name appears among those 52 slugs, and 'ADP', 'Paylocity' and the payroll vendor Gusto have no /partners/ slug in the sitemap at all, at alphabetical positions the crawl did cover. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: time clock 0, timeclock 0, timekeeping 0, hours worked 0, punches 0, overtime 0 all reproduce, as do the 5 hits for punch (3 documents, every one a loyalty punch card). THE PAYROLL-PARTNER BOUND IS NOW CLOSED RATHER THAN A FLOOR. The note ends 52 of Olo's 392 published partner pages (tattle through zonal) remain unfetched, so the payroll-partner set is a floor. All 392 are now read. The auditor searched every one of them: exactly three mention payroll - Paychex, Proliant and Heartland, the last of which is tagged Gift Cards and Payment Processor and whose page describes payments, not a payroll integration. So the two-provider set is Paychex and Proliant and it is now a census, not a floor; the analyst's prediction that no payroll or HCM vendor was hiding in the tail is confirmed. The Labor Management facet is likewise closed at 18 partners, matching the directory's own count exactly. VALUE, GRADE, URL AND QUOTE UPHELD at partial/C. THE AUDITOR RECORDS THIS AS THE CLOSEST CALL IN THE BATCH: the claim's subject is LABOR HOURS and no document in the corpus says an hour or a punch moves, which is a strong argument that the honest verdict is `unknown`. It is upheld at `partial` because the claim's operative test - a native export to at least two NAMED payroll providers without manual re-keying - is affirmatively evidenced by the quoted sentence (two-way, automatic, real-time, employee and pay information) over middleware Olo owns, and shortfall (1) names the gap precisely. A reviewer moving this to `unknown` would be defensible; a reviewer moving it to `no` would not. https://www.olo.com/partners/proliant · retrieved 2026-09-06

Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator

extensibility-bi-data-warehouse

Transaction-level data does leave Olo to a customer-controlled destination, but as an event stream, not a scheduled bulk export. Webhooks Overview: third parties subscribe to Olo events by 'providing an HTTPS endpoint that Olo will deliver event details via HTTP POST', and webhooks provide 'order, menu, user, and vendor data as it changes, allowing you to power your brand's custom productivity integrations with Olo data', with the article naming 'collect order data as it happens for revenue reports' among the use cases. So Olo's reporting UI is not the ceiling on analysis. Shortfalls: no scheduled file delivery to any customer-controlled store is documented - Snowflake, warehouse, SFTP and S3 return zero hits across the 13 quarterly and seasonal release pages 2023-2026 and all 35 www.olo.com pages, surfaces that do close, and across the public help centre - but the help centre is a FLOOR, not a census: the 231 public bodies reference 383 distinct article ids and 152 (40%) are gated (401/403, not 404), among them 'Webhook self-service page' (360061153692), which is precisely where self-served or scheduled delivery configuration would be documented; the operator-facing exports that do exist are manual UI downloads (Sales and Orders Reports Overview, 115000124306, tells the operator to download the .xlsx or .csv file from Recent Reports; Loyalty's Export Data, 46322256871579, is Dashboard-initiated and its files are deleted automatically after 14 days); and the webhook event catalogue is deferred to the gated Developer Portal, so completeness of the stream cannot be verified. Consistent with the already-scored extensibility-webhooks-push = partial. https://olosupport.zendesk.com/hc/en-us/articles/115005291346-Webhooks-Overview · retrieved 2026-09-04

The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.

extensibility-app-marketplace

A public, filterable Partner Directory of 400+ integrated partners is browsable without login. Operator self-install (vs. a partnership inquiry / sales-assisted enablement) is not documented. https://partners.olo.com/ · retrieved 2026-08-01

Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.

extensibility-custom-fields-scripting

Custom fields exist on the ordering flow: 'Custom fields can be leveraged to capture the customer's table number, number of guests, etc.', appearing when the guest selects a handoff mode, with an operator-chosen label (max 128 characters) and required flag. Shortfall: fields are provisioned by Olo Support from a request, not defined self-serve, and there is no vendor-hosted scripting or custom logic against platform objects. https://olosupport.zendesk.com/hc/en-us/articles/360050334652-How-to-Enable-Dine-In · retrieved 2026-09-03 adversarially verified

The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.

extensibility-headless-embedded

Cited to olo.com/serve, which does not mention headless use, API-driven front-ends, or Serve being optional. It markets Serve as 'Your digital no-cost front-end' with '$0 setup'. Supporting evidence exists elsewhere (Ordering API exists; API Usage Terms contemplate per-platform credentials for 'iOS, Android, Web, Kiosk'), but production credentials require per-API certification, so a brand cannot build headless against Olo without a signed, certified relationship. Partner-gated headless, not open headless. https://www.olo.com/serve · retrieved 2026-08-01 adversarially verified

The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.

extensibility-api-versioning-deprecation

Olo does publish a breaking-change notice policy, in the binding API Terms of Use, section 1(d): when a change 'is reasonably expected to render your integration incompatible with the Olo APIs, Olo will use commercially reasonable efforts to notify you in advance of such change and you will be required to update your integration into the applicable Olo APIs no later than six (6) months after such notice', with a tighter window for security fixes - 'your integration must be updated within one (1) month of any change to the Olo APIs or Olo API specifications intended to address a security vulnerability' - and revocation of access if the partner does not comply. That is a stated deprecation and migration window, which is half of what this claim asks for. Shortfalls, all serious: there is no public changelog - the developer portal that would carry one is login-gated and RFC 9309-blocked, and the quarterly release pages are product marketing with no API version notes; the commitment is 'commercially reasonable efforts', not a guarantee, and the same document pulls the other way, saying Olo 'may change, suspend, or discontinue any aspect of the Olo APIs at any time' and 'You acknowledge that Olo may modify the Olo APIs from time to time, and that Olo is not obligated to notify you of any such modification'; no version identifiers, sunset schedule or supported-version list are published. The only deprecation Olo announces publicly is an integration retirement, not an API version - NCR Cloud - Aloha POS: FAQs (360041745972) notes that the NCR Cloud Connect APIs are deprecated and will not be available for new brands. https://www.olo.com/api-usage-terms · retrieved 2026-09-04

A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator

extensibility-data-portability-exit

Self-serve machine-readable order export exists on demand while the contract is live: the Dashboard's Analytics > Reports tool produces reports the operator runs for chosen date ranges and locations, including Itemized Orders ('List of orders'), Product Breakdown, Itemized Adjusted Orders and Itemized Cancelled Orders, and the article tells the operator to 'check out the "Recent Reports" section of the Reports tab' to 'download the .xlsx or .csv file and open it in Microsoft Excel or another spreadsheet tool for further analysis'. Olo Loyalty adds a parallel export set for guest and member data (Export Data, 46322256871579). Shortfalls that block 'yes': no menu export and no payments-metadata export is documented for the operator; report runs are bounded by a UI-chosen date range, not a documented complete historical dump; Loyalty exports expire and are deleted after 14 days; and nothing published addresses contract end at all - there is no MSA, no exit or off-boarding clause and no data-return obligation on www.olo.com (the legal set is terms-of-use, api-usage-terms, olo-pay-terms-and-conditions and the privacy notices; /legal/ and /terms-of-service/ both 404 byte-identically to a fabricated control path), and the API Terms' only termination-time data obligation runs the other way, requiring the partner to promptly return all Confidential Information to Olo. Whether a full historical export is contractually available at exit is contract substance and remains unpublished. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-09-04

Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.

reliability-offline-order-entry

Olo is a cloud platform with no on-premise terminal. Its Summer 2026 'POS offline fallback mode' keeps Olo accepting digital orders when the POS backend is unreachable — the opposite direction from terminal-side offline. https://www.olo.com/product-release · retrieved 2026-08-01

Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator

reliability-offline-card-auth

The document says: “Offline capabilities (store and forward) ensure your restaurant won’t lose out if connection is lost” OVERTURNS THE PRIOR BARE `no` AND MY OWN INTERIM `unknown`. SUBJECT TEST: situation (a) — Olo ships the thing the claim is about. Olo Pay Card-Present puts first-party payment hardware in the store, and this Spring 2025 release page enumerates that hardware's capabilities under the heading 'Experience Olo Pay’s POS-integrated payments on modern, reliable payment terminals:' — seven bullets, of which the quoted one names the exact mechanism this claim asks for, store-and-forward, and states its purpose in outage terms. The live Olo Pay product page (https://www.olo.com/pay) corroborates independently: its operations bullet list carries the bare entry 'Offline capabilities' alongside modern EMV-compatible payment terminals and point-to-point encryption. So card payments are claimed to be accepted while the connection is lost, and this is not cash-only fallback. WHY `partial` AND NOT `yes`: this is weight `differentiator`, and both supporting documents are vendor marketing pages (grade C) — the grade floor forbids a `yes` below grade B, and vendor marketing establishes a claim, not a fact. SHORTFALLS, NAMED: (1) The capability is scoped to the card-present terminal fleet, which is not generally available — 10-K FY2024 (grade A) states that card-present functionality is currently available only through integrations with select ordering-kiosk and POS partnerships and through Olo's payment gateway partner, and the current release page scopes its terminal-fleet monitoring to Olo Pay Card-Present for Kiosk. An Olo customer on Ordering alone does not get this. (2) No limits are published anywhere: no floor limit, no per-transaction or cumulative offline cap, no time window, no post-reconnect decline liability. I read the public Olo Pay Terms & Conditions in full (321 lines): it contains no offline, deferred-authorisation or store-and-forward clause at all — its two uses of the word offline are about bank transfers and about taking the Payment Interface down for maintenance. This matches the settled sibling cell reliability-offline-decline-liability. (3) Nothing in the operator help centre documents the behaviour: tokenised across all 1,628 documents, 'store and forward' occurs once, in this one release page, and zero times in the 231 public and 680 archived KB articles. DO NOT CONFLATE WITH THE OTHER OFFLINE FEATURE: the current release page's POS offline fallback mode, which it describes as keeping locations online and accepting orders even when the POS goes down, runs the other direction — Olo's cloud continuing to accept digital orders while the store's POS backend is unreachable — and says nothing about a card terminal authorising a card while its own link is down. Only the store-and-forward bullet supports this cell. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). THE CONTROL THAT MATTERS HERE WAS RE-DERIVED OVER THE COMPLETE CORPUS AND HOLDS: "store and forward" is 1 occurrence in 1 document, this release page, and zero in the 231 public and 680 archived KB articles. That control had previously been published over a corpus in which the page containing the phrase was on disk as HTML with no text file written - a control that could not have fired - and it now fires correctly and returns the same answer. CONTROL CAPABILITY TESTED AND PASSED: "offline" fires on 81 documents / 202 occurrences across the same document set, so a store-and-forward description in the help centre would have been found. VALUE, GRADE, URL AND QUOTE UPHELD at partial/C, and the row is consistent with the standing record cell payments-offline-store-and-forward (partial/C, same release page, same quote) and with reliability-offline-decline-liability. The grade floor is correctly applied: this is a differentiator-weight claim and both supporting documents are vendor marketing, so `yes` is barred. https://www.olo.com/quarterly-release/spring-2025 · retrieved 2026-09-06

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

Olo Pay card-present advertises store-and-forward - the Spring 2025 release's exact words are 'Offline capabilities (store and forward) ensure your restaurant won't lose out if connection is lost' - so the liability question is live, and the public Olo Pay Terms & Conditions are where Olo allocates transaction risk: unauthorized, irregular or fraudulent charges 'shall remain the full responsibility of Merchant', chargebacks and settlement suspension are specified, yet no offline, store-and-forward or deferred-authorization clause appears and no per-transaction or cumulative offline cap is stated anywhere public. The vendor does not publicly document who bears a post-reconnect decline. (Mirrors the settled payments-offline-decline-liability cell in this record.) https://www.olo.com/olo-pay-terms-and-conditions · retrieved 2026-08-04

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

The document says: “Expo now has two ways to access the application - through a browser shortcut on the home screen of your device (as a Progressive Web App) or by downloading the Olo Expo app on the Apple App Store or Google Play Store.” SUBJECT TEST: mixed (b) then (a). Olo ships no POS terminal that holds a check, so there is no check/table state for terminals to share; but Olo does put multiple in-store devices in one location — the Expo Mode Comparison Chart's General section carries a Multiple Devices in a Single Location row ticked for both Companion and Standalone (row confirmed against the raw HTML `body` field in .cache/q225/raw/zd-articles.json, article 360043362692, where the header row is Feature / Companion / Standalone) — so the degraded-LAN question has a real subject and gets a real `no`. THE MECHANISM OLO DESCRIBES IS THE OPPOSITE ONE: this article is Olo's complete statement of what an Expo device needs, and every dependency it names is a remote host. Expo is a PWA or app-store app running in Chrome or Safari; the article's closed list under 'URLS that need to be safelisted:' is api.olo.com, ops.api.olo.com, static.olocdn.net, expo.olo.com, events.launchdarkly.com, app.launchdarkly.com, clientstream.launchdarkly.com, api.raygun.io, api-js.mixpanel.com, maps.googleapis.com, maps.gstatic.com, fonts.googleapis.com and fonts.gstatic.com — thirteen internet endpoints and no local server, no peer device, no on-LAN service. The hardware section is 'Suggested Devices (not mandatory):' — operator-supplied consumer tablets, not a terminal fleet with shared state. WHY THIS ENUMERATION IS A CEILING, NOT A FLOOR: a safelist is written to be exhaustive — its purpose is that a store firewall configured to it lets Expo work — so a LAN peer or local server that Expo depended on would have to appear in it, and none does. Corroboration from the same corpus: Olo's live Aloha installation guide (115000632923) puts a Windows service on the back-of-house server whose configuration tester connects outbound to Olo's servers on port 443 to fetch cloud configuration, and the archived Expo Standalone Offline Issues article (capture 2021-09-19, article updated 2021-02-12; a later revision exists and was not read for this proposition) states that navigating away or losing the connection leads to being considered offline and stopping the acceptance of digital orders. RE-MEASURED over the final 1,628-document corpus: 'LAN' 1 doc / 1 occurrence (a 2019 error-message article), 'local network' 2 docs / 3 occurrences (both archived, both about reaching a cloud POS) — unchanged. The 70 newly-readable www pages, including all eleven quarterly-release pages, contain no Expo LAN, peer-sync or local-server feature; Expo appears on exactly one of them (Summer 2023, announcing native iOS/Android apps for MDM deployment). AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: LAN 1 document / 1 occurrence and local network 2 documents / 3 occurrences both reproduce. CONTROL CAPABILITY TESTED AND PASSED: peer fires on 6 documents and printer on 48, so a LAN-peer description would have been found. THE STATED CEILING IS FALSIFIED AND IS WITHDRAWN. The note argues that a safelist is written to be exhaustive - its purpose is that a store firewall configured to it lets Expo work - so a LAN peer or local server that Expo depended on would have to appear in it. That is an assumption about how the vendor writes safelists, and THE SAME ARTICLE REFUTES IT: its heading is URLS that need to be safelisted, and an on-LAN dependency is not a URL that traverses an egress firewall, which is why this very article documents two local dependencies that the safelist omits - an AirPrint or CloudPRNT printer for iOS, and an Android ESC/POS print service on the store network configured by IP address and port number. The safelist is a ceiling for Expo's INTERNET dependencies and is silent by construction on its LAN ones. VALUE, GRADE, URL AND QUOTE UPHELD on grounds that survive: Expo is a browser PWA or app-store app whose orders arrive only over api.olo.com and expo.olo.com; Olo's own Aloha installation guide shows what Olo actually installs in a store, a single Windows service beside somebody else's POS, so the check and the table state are the POS vendor's and there is no Olo check for terminals to share; and the Expo Mode Comparison Chart, a checkmark/cross matrix that records real absences, has a General section carrying Multiple Devices in a Single Location with no shared-state, peer-sync or local-server row. ONE OVER-REACH TRIMMED: Olo ships no POS terminal is slightly too broad - the FY2024 10-K enumerates a Kiosk module that puts an Olo ordering interface on a physical in-store device - but a kiosk is equally cloud-served and holds no shared check, so the verdict is unaffected. https://olosupport.zendesk.com/hc/en-us/articles/360029271212-Expo-Device-Browser-and-Software-Requirements · retrieved 2026-09-06

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

Olo documents no edge server or on-premise engine; the ordering path is entirely cloud request/response, which is why 'POS offline fallback' had to be built as a cloud-side queue. https://www.olo.com/product-release · retrieved 2026-08-01

Kitchen display and/or kitchen printer routing continues to function while offline.

reliability-offline-kds-printing

The document says: “If you want these to print in the kitchen or appear on a KDS screen, this must be routed like other items.” SUBJECT TEST: situation (b) for the routing half and (a) for the printing half. Olo ships no KDS and performs no kitchen routing: this live installation guide (updated 2026-06-14) is Olo's own account of what it puts in an Aloha store, and it is a Windows service plus configuration records inside somebody else's POS — 'Once prepared, the Olo services are required to be installed on the Aloha BOH machine, and tested.' Kitchen production routing is explicitly the POS's function, not Olo's: of the Olo order mode the guide says 'Routing rules in Aloha will determine where items are sent for production.', and of the Olo Memo Item that carries the guest name and phone it says the quoted sentence above — i.e. the KDS screen is Aloha's and Olo reaches it only by being routed like any other Aloha item. It follows that when the store is offline there is no Olo-side kitchen routing to keep working; whatever the kitchen still gets is the POS vendor's offline behaviour, scored on that vendor's record, not here. THE ONE PRINT SURFACE OLO DOES OWN FAILS THE CLAIM TOO: Expo's printing is enumerated in the Expo Mode Comparison Chart's Printing section as chit layout print, letter layout print and group/batch printing — three rows, no offline or spooled row (confirmed against the raw HTML `body` field in .cache/q225/raw/zd-articles.json, article 360043362692, because the .txt conversion loses the Companion/Standalone columns) — and the Expo requirements article makes the path cloud-bound and printer-network-bound: iOS needs an AirPrint or CloudPRNT printer, Android prints through a third-party ESC/POS print-service plugin, and Expo itself only reaches orders through api.olo.com / expo.olo.com. WHY THAT IS A CEILING: the mode chart is Olo's own feature-by-feature comparison, written to show an operator everything each mode can do, and the requirements article's safelist is exhaustive by construction. Corroborating archived material, never the sole support: the Expo Audio and Visual Notification Guide (capture 2022-01-25; later revisions exist and were not read for this proposition) says that when the store's POS loses its connection to Olo, online orders will not be received. Live corroboration from a different integration: the live Toast Integration article (46383252653979) states under its Offline Mode heading that Olo Loyalty functionality is unavailable when the POS is in Offline Mode. TESTED AGAINST THE NEWLY-READABLE RELEASE PAGES, WHICH STRENGTHEN THE VERDICT RATHER THAN OVERTURNING IT: the current release page (https://www.olo.com/product-release) ships a POS offline fallback mode, described there as keeping locations online and accepting orders even when the POS goes down — Olo's cloud keeps ACCEPTING orders during a POS outage, which is the order-intake direction and is precisely a case where the POS's kitchen routing is NOT running; it promises nothing about printers or KDS screens, and it needs Olo's cloud to be reachable, so it cannot apply when the store itself is offline. Fall 2025's OrderReady AI for Aloha POS and KDS is a cloud order-ready-time prediction fed to Aloha's KDS, not Olo-side routing, and equally cloud-dependent. Re-measured over 1,628 documents: kitchen printer 0 docs / 0 occurrences; 'KDS' 19 docs / 27 occurrences, every one of them naming a POS vendor's KDS (Aloha, Brink, MICROS, POSitouch, Focus) or a partner's, never an Olo one. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: kitchen printer 0 documents and KDS 27 occurrences in 19 documents both reproduce; every KDS hit names a POS vendor's or a partner's KDS. CONTROL CAPABILITY TESTED AND PASSED: printer fires on 48 documents / 89 occurrences and printers on 7 while kitchen printer is 0, so that control was capable of firing - and the partner directory independently carries a Kitchen Display System service tag on 3 partners, none of them Olo. ONE OF THE TWO STATED CEILINGS IS FALSIFIED AND IS WITHDRAWN: the requirements article's safelist is NOT exhaustive by construction, because it enumerates URLs to be safelisted on an egress firewall and is silent by construction on on-LAN dependencies - the same article documents an AirPrint/CloudPRNT printer and an Android ESC/POS print service reached by IP address and port, neither of which is in the safelist. The other stated ceiling survives: the Expo Mode Comparison Chart is a checkmark/cross matrix that records real absences (partial refunds are crossed for both modes), confirmed by the auditor against the raw HTML body in .cache/q225/raw/zd-articles.json where the header row is Feature / Companion / Standalone, and its Printing section is exactly three rows with no offline or spooled row. VALUE, GRADE, URL AND QUOTE UPHELD on the affirmative half: this live installation guide is Olo's own account of what it puts in an Aloha store and it assigns kitchen production routing to the POS - Routing rules in Aloha will determine where items are sent for production. - so there is no Olo-side kitchen routing that could continue during an outage. RESIDUAL NAMED HONESTLY, which the original note did not: Expo's own print path is a local-network printer, and no document in the corpus states whether an order Expo already holds can still be printed while the WAN is down. That is a gap in the printing half; it does not reach the routing half, which is what the claim is chiefly about and which is affirmatively settled. https://olosupport.zendesk.com/hc/en-us/articles/115000632923-Aloha-POS-Prerequisites-and-Olo-Service-Installation · retrieved 2026-09-06

The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.

reliability-printer-fallback

Olo's only native printing surface is the Expo tablet, and it is a single-printer, largely manual affair: iOS requires an AirPrint or CloudPRNT printer ('A CloudPRNT compatible printer is required for Auto-Printing'), Android prints through a third-party ESC/POS print-service plugin configured as the OS default printer, with the operator opening the order PDF and printing from the viewer. The Expo FAQ states 'Auto printing from Expo is not currently supported, but action-based printing and bulk printing is available', and the Expo Mode Comparison Chart's Printing section enumerates the entire printing feature set as chit layout, letter layout and group/batch printing. No backup-printer designation, no failover on an unreachable printer, no print-failure alert exists; for POS-integrated brands kitchen-ticket printing is performed by the POS, outside Olo. https://olosupport.zendesk.com/hc/en-us/articles/360029271212-Expo-Device-Browser-and-Software-Requirements · retrieved 2026-08-04

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

STILL unknown. NEW SURFACE: getwisely.zendesk.com, the Olo Engage (ex-Wisely) Zendesk help centre, production, articles updated to 2026-09-11. Its HTML /hc/ is not linked from the olo KB, but the anonymous Help Center API serves 158 articles (2 pages, /api/v2/help_center/en-us/articles.json; 7 categories: GDP, Marketing, Sentiment, Host, Technical Documentation, Release Notes, Contact Us) and attachments.json across all 158 yields 2 PDFs (Olo Engage Analytics Suite Overview, 11.4 MB; Olo Engage Marketing Automation Guide, 10.1 MB). NOT A CENSUS: the href fixpoint names 24 article ids absent from the listing; probed, 22 = 404 and 2 = 401 gated (5026107804187, 5026083627931), so no `no` may rest on it. The only multi-device doc is for the Olo Host iPad app: "Information added to your iPads should sync across to the other iPads in your location. If the syncing is interrupted, there are several items to consider" followed by connectivity troubleshooting only; no reconciliation rule. "conflict" = 2 hits, both "Scheduling Conflicts" in Reservation Availability (inventory override prompt, not device partition): POISON. offline = 2, both Sparkfly "offline campaigns like direct mail": POISON. Retrieved 2026-09-16. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. The one new continuity feature is POS-side, not device-partition: "POS offline fallback mode: Keep your locations online and accepting orders even when your POS goes down" (https://www.olo.com/product-release). It states no reconciliation rule for orders taken during the outage (no last-write-wins, merge or prompt). conflict/offline 24 hits in 19 pages, the rest being governing-law "conflict of law", the Olo Pay 'offline' maintenance clause, store-and-forward terminals and blog prose - POISON. Retrieved 2026-09-18. adversarially verified

The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).

reliability-offline-feature-matrix

Olo documents one specific degraded-mode behavior (POS offline fallback mode, Summer 2026) but publishes no comprehensive matrix of what is unavailable during an outage. https://www.olo.com/product-release · retrieved 2026-08-01

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

Verified independently: status.olo.com is fully public with no login, ~40 monitored components including Ordering API, Dispatch API, Point of Sale API and Webhooks, with subscription options. No uptime percentages published, as stated. Note the researcher missed that olo.com/ordering separately advertises '99.99% uptime' — a marketing figure, not a contractual SLA, so reliability-contractual-uptime-sla correctly stays unknown. https://status.olo.com/ · retrieved 2026-08-01 adversarially verified

A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator

reliability-contractual-uptime-sla

Olo's published Security Policy (an exhibit to the MSA, last updated 2020-09-08) states that a security-driven suspension 'shall not be considered Downtime as defined under the Digital Ordering Terms & Conditions Addendum, if applicable to Customer's use of the Services'. So a contractual Downtime definition exists in an addendum. Shortfall: the addendum is not published, so neither the uptime percentage nor any service-credit remedy can be read. https://www.olo.com/security-policy · retrieved 2026-09-03 adversarially verified

The vendor publishes written post-incident reports or root-cause summaries for major outages.

reliability-incident-postmortems

status.olo.com publishes a full incident history (Atlassian Statuspage; the Atom feed read 2026-09-03 carries 25 incidents such as 'Ordering Disruption', 'Menu Eighty Sixing Processing Delays', 'Some reporting data is delayed'). Each entry is a timeline of Investigating / Identified / Monitoring / Resolved updates with one-line causes ('Our image provider has notified us that they are aware of the issue'). Shortfall: no entry carries a written postmortem or root-cause report; the feed contains no 'postmortem' or 'root cause' text at all. https://status.olo.com/history.atom · retrieved 2026-09-03 adversarially verified

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Olo runs a Zendesk support portal (olosupport.zendesk.com) with a ticket-submission path; the portal returned 403 to automated fetch and 24/7 phone support is not publicly stated. || 325th: 325th: NEW SURFACE, no move, and it is the closest thing to a negative I found. Across the 288-article census of BOTH Olo help centres (olosupport 233 + ologuesthelp 55; see payments-surcharge-guardrails for the bound) "24/7" scores 0, "24 hours a day" 0, "around the clock" 0, and the word telephone occurs 6 times, all six inside "TCPA (Telephone Consumer Protection Act)" in SMS-marketing articles - no support phone number appears anywhere in either help centre. www.olo.com/support does not describe a support offering at all — it 301s straight to olosupport.zendesk.com/hc/en-us. The one article that defines how a customer reaches Olo is 44765456164635 "Contact Olo Support: Using the Intake Form", and it is a WEB FORM with a closed product picker (Ordering, Olo Pay, Olo Loyalty, Engage, Omnivore API) and a closed category matrix (Something is Broken or Not Working / Manage Settings & Features / User Access & Management / Launch, Transfer, or Close a Location / billing), stating "This form is for restaurant brands and partners who work directly with Olo's platform" — no phone channel and no stated hours. The API Terms (www.olo.com/api-usage-terms, read in full today) go further for the API specifically: "Olo may elect to provide you with support or modifications for the Olo APIs ... in its sole discretion, and may terminate such Support at any time without notice to you." Held unknown rather than 'no' because the KB is a floor (233 of 304 sitemap entries) and support hours are normally a contractual term in the MSA, which the KB itself defers to ("the terms of your Master Services Agreement (MSA) ... will take precedence") and which is not public. Retrieved 2026-09-17. || 326th: 326th: THE BOUND CHANGED, THE VERDICT DID NOT. The 325th held this cell on 'the KB is a floor (233 of 304 sitemap entries)'. That floor is an artefact and is retired: the 304 sitemap <loc> entries are 233 articles + 56 sections + 14 categories + 1 root, and sitemap-articles minus API-articles = 0. What the corpus really lacks is 149 GATED articles (href fixpoint over the 233 public bodies -> 385 referenced ids, 152 absent, probed today: 3 x 404, 149 x 401), whose titles I recovered from the href slugs (.cache/q326/olo/oz-gated-titles.txt): they are POS menu mapping, Dispatch ops, tax, Expo, Rails and user administration, with no support-hours or support-plan article among them. Over a 2,161,373-char corpus that now also includes the complete Olo Engage help centre (getwisely, 158 articles; its own sitemap lists the same 158, and of 24 referenced-but-absent ids 22 are 404 and only 2 are gated) '24/7' 0, 'around the clock' 0, 'phone support' 0. Engage's own documented support channel is a ticket portal too ('Contacting Support: View past requests within the Engage Help Center'). NEW COUNTER-EVIDENCE AGAINST READING A MARKETING '24/7' AS SUPPORT: Olo's 10-K says the round-the-clock rotation is ENGINEERING, not customer support - 'alerts configured to automatically notify our 24/7 on-call rotation in the event of a problem' - so a future pass finding '24/7' on an Olo page must check which rotation it means. Still unknown: support hours are an MSA term ('the terms of your Master Services Agreement (MSA) ... will take precedence') and the MSA is not public. Retrieved 2026-09-18. || 331st: 331st: TWO NEW READS, no move. (1) Olo FY2024 Form 10-K (SEC EDGAR, text on disk .cache/q325/olo/10k-2024.txt, 484,307 chars), grepped for this cell for the first time: "Platform revenue primarily consists of fees that provide customers access to one or more of our modules and standard customer support" (support is bundled, but its hours/channel are not stated), and the only "24/7" in the filing is engineering on-call, not customer support: "alerts configured to automatically notify our 24/7 on-call rotation in the event of a problem". "24 hours" 0, "around the clock" 0, phone 0 in a support sense. (2) The intake-form screenshot attached to "Contact Olo Support: Using the Intake Form" (Screenshot_2025-12-24_102633.png, read as an image) shows the closed "What type of support do you need?" picker (Something is Broken or Not Working / User Access & Management / Manage Settings & Features / How-To & Guidance / Launch, Transfer, or Close a Location / Developer Tools, API Access, & Integrations / Billing, Invoices, or Banking / Suggest a New Feature or Share Feedback) with no phone or hours option. Still no stated support hours; the MSA holds them. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. Olo's own customer-contact page (https://www.olo.com/contact/current-customers, 'Contact Olo | Customer Support') says only "Please visit our Help Center for resources on our ordering platform and ways to contact Support" - no phone number and no hours. Every '24/7' on the site is POISON for this cell (17 hits in 14 pages): the Waffle House case study ("the 24/7 diner", "open 24/7"), Cold Stone ("a website that now handles orders 24/7"), partner pages describing the PARTNER's own service (Resy "24/7/365 customer service", Pivot Up Technologies "24/7 Support: Round-the-clock assistance", ezCater "24/7 service", Reachify "24/7 responses to phone calls", VOICEplug "24x7"), a blog line about reviews posted 24/7, and the Sync release ("AI agents ... 24 hours a day"). None is an Olo support commitment. Retrieved 2026-09-18. || 334th: MERGE HOLD (proposed no/B, held unknown): The Omnivore API SLA (panel.omnivore.io, business-hours support) bounds only Olo's POS-middleware arm; the record's core product is the ordering platform, whose support hours rest on job ads (grade D) and whose live 2026 posting states no hours. A sibling product's SLA does not bound the core product's support tier; Olo's MSA is not public. PROPOSAL AS WRITTEN: 334th: MOVED unknown -> no/B. CLAIM: 24/7/365 live human phone support included in the base subscription. NEW SURFACE, never read by any pass: Olo's own published support SLA for its Omnivore API product, https://panel.omnivore.io/legal/service-level-agreement ('Omnivore API Customer Support and System Availability Service Levels', 'Last Modified: June 25, 2025', written in Olo's name as successor to Omnivore; live, 200, anonymous GET). It states a bounded support window and a scheduled-only phone channel: "Support Business Hours: Monday-Friday, 9am to 6pm US/Eastern, excluding any day that Olo's corporate office is closed"; "Customer support is available for all Severity Levels via the Olo Community Portal during Support Business Hours"; "Customer support is available for all Severity Levels via email during Support Business Hours"; "Phone Support: Customers may request phone support for Severity 3 and Severity 4 cases if unable to resolve via email. Olo will schedule a time during Support Business Hours for support to be provided via phone." It also prices support separately: "Support Fees: The fees paid by Customer to Olo specifically for support. Does not include Service Fees." THE 24/7 LINE WAS REMOVED: the 2021-09-20 Wayback capture of the same URL (Omnivore Technologies era) read "Phone Outage Line: For Severity 1 and Severity 2 cases, a telephone Outage Line is available 24 hours a day, 7 days a week" (voicemail, callback within the Request Response Time, up to $100 billed per non-outage call); the June 2025 Olo revision has no Outage Line at all (tokenised 'Outage Line' 0, '24 hours' 0, '24/7' 0 in the live text; the only continuous commitment is Severity 1 work - "Olo will take and continue to take the actions which will most expeditiously resolve the request" - reached through the business-hours portal/email channels). The stale 2020 Acceptable Use Policy on the same host still mentions "Omnivore's 24/7 Outage Line" but predates, and is contradicted by, the 2025 SLA that defines the channels. CORROBORATION FOR OLO'S ORDERING-PLATFORM SUPPORT (second surface, Olo's own job postings via the Lever API and 222 Wayback-captured jobs.lever.co/olo postings): Customer Support Specialist postings captured 2020-07-22 and 2021-01-21 state "Olo's Support platform is available 7 days a week 9:00am-12:00am EST" and that the team handles "online customer support requests and phone calls" (https://web.archive.org/web/20210121052752/https://jobs.lever.co/olo/c0708fab-b8f8-4be6-9447-625ac0c5d8ed); the live 2026 Senior Customer Support Specialist posting (https://jobs.lever.co/olo/48011b46-0a12-4d96-9453-381deab31730) says "Our Support team is available to our customers 7 days a week. Including evening, weekends, and holidays" - evenings, not overnight. Every Olo support-hours statement found names a bounded window; none is 24/7. POISON: '24/7' in 13 of the 222 postings is ENGINEERING on-call ('Participate in a sustainable 24/7 on-call rotation', DBRE/Security/Cloud Ops), the same rotation the 10-K names - not customer support. CAVEAT for the merge: the SLA is the Omnivore API product's; the ordering platform's hours rest on job postings (grade D) and the MSA is not public. Retrieved 2026-09-18. adversarially verified

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

Olo's own store-installation guide is explicitly a self-install runbook for the brand's technical team, not a description of an Olo field visit. It states that the 'Olo services are required to be installed on the Aloha BOH machine, and tested' and that the guide 'assumes the end user has a working knowledge of configuring and supporting the Aloha POS software and its operating environment'; the operator generates a store password in Dashboard, downloads the OloAloha agent from Brand > POS Downloads, and is told 'Keep this page open as you move to the store computer for installation', then runs the installer and the POS configuration tester himself, at an estimated 7-10 minutes. Where store-level expertise is missing Olo refers the operator outward rather than dispatching anyone: 'contact your NCR Aloha dealer to provide these parameters'. Every Olo role named across the corpus is remote - Customer Success Manager, Deployment Manager, TAM, Front End Specialist - and the Dashboard Onboarding tab is a set of forms and trackers. Corroboration: Olo ships no terminals or POS hardware and sells no field service; 'on-site' occurs exactly once in the PUBLIC help centre and there it describes Qu's product, not Olo's - and that is a FLOOR, not a census: the 231 public bodies reference 383 distinct article ids and 152 (40%) are gated (401/403, not 404). The recoverable gated titles that touch installation - 'Download the Installer' (115005526103), 'Olo Firewall Requirements' (115002248886), 'automatic updater' (115000632506), 'Quick Glance: Best Practices & Requirements' (115005528466) - all point the same way, toward operator self-install; no installation, professional-services or field-deployment offering appears on any of the 35 www pages or the 13 release pages, and the 657-loc sitemap carries no such page. Shortfall: this is a published-offering finding - an enterprise brand could negotiate on-site launch support in an MSA Olo does not publish. Subject note: the cutover-night risk this cell is aimed at belongs to the brand's POS vendor, since Olo installs only a Windows service beside an existing POS. https://olosupport.zendesk.com/hc/en-us/articles/115000632923-Aloha-POS-Prerequisites-and-Olo-Service-Installation · retrieved 2026-09-04

The vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. differentiator

reliability-menu-build-service

Olo's 2024 Summer Release blog (Wayback 2024-07-18) names 'POS menu builder for brands using Toast': 'A time-saving service that enables brands on Toast POS to import menu items- rather than build each by hand ... The POS menu builder can use the data already configured in your POS to build and map your initial menu, kickstarting your deployment', replacing what 'used to take brands weeks of manual work'. Shortfall: the build is an automated import, available only on Toast, and the brand refines it afterwards ('You can now spend time refining your menu'), rather than Olo staff building the menu. Olo's retired 'NCR Cloud - Aloha : Implementation Order of Operations' (updated 2021-10-27, Wayback 2022-01-25) lists the step 'Olo menu build and Lab Testing' with owner 'Client step', and the live Menu Training series trains brand staff to build the company menu. Marketing blog = grade C. Date caveat: 2024 release blog. https://web.archive.org/web/20240718071150/https://www.olo.com/blog/2024-summer-release-19-features-to-mark-19-years-of-innovation · retrieved 2026-09-13 adversarially verified

A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.

reliability-hardware-replacement-sla

Checked 2026-08-04: Olo fields real payment hardware - 'modern, reliable payment terminals' (Spring 2025 release) whose fleet status the Dashboard's terminal-management portal now monitors (Summer 2026) - while Expo runs in a browser on operator-chosen tablets (requirements article lists 'Suggested Devices (not mandatory)'). No public page says who supplies the terminals or documents any replacement/advance-exchange program or turnaround time, and Olo Pay merchant onboarding docs are gated, so the claim is unresolved. || 327th: FIRST TIME THIS CELL HAS BEEN CHECKED (its note was empty), and the finding is that the claim has nothing to attach to. Olo supplies no hardware to operators under any documented programme: the only device guidance on any Olo surface tells the BRAND which of its own iPads will work — "iPad Compatibility" enumerates iPad Pro (all generations), iPad Air (all generations), iPad 5th generation or newer and iPad Mini 2nd generation or newer, with a closed accessory list of "iPad Countertop Stand, iPad Case & Holder, Keyboard" — and the network guides tell the brand which Wi-Fi access points to buy ("What Aruba hardware do you support? This integration has been tested on: Hardware model: AP-303"). CONTROLS over the 4,132,744-char corpus described below: "hardware replacement" 0, "advance exchange" 0, "advance replacement" 0, replacement 0 (zero occurrences of the word in any form), turnaround 0, swap 0, "next business day" 0, "purchase hardware" 0, "kiosk hardware" 0; 'warranty' scores 12 tokenised and every one is a disclaimer of warranty in the Terms of Service or API Terms ("THE OLO APIS ARE PROVIDED 'AS IS' WITH NO WARRANTY"), never a hardware programme. POISON PUBLISHED, and it is severe on exactly the two acronyms this cell turns on: 'RMA' scores 1,438 on a substring grep and 0 tokenised — every hit is inside information / performance / format — and 'SLA' scores 48 on a substring grep and 0 tokenised, inside translation / translate / slack / Tesla. Anyone re-testing this cell with a substring grep will read 1,438 RMA hits and 48 SLA hits as evidence. Held unknown rather than no, per merge policy: a vendor that ships no hardware at all is a product the claim does not apply to, and the corpus is a floor (149 gated olosupport ids). CORPUS USED FOR THE CONTROLS: 4,132,744 chars assembled this pass from every Olo corpus on disk (script corpus build + ctl.mjs in .cache/q327/olo) — the 233-article olosupport.zendesk.com Help Center API census plus its 7 non-image attachments (Dispatch, Chargebacks, the three Serve guides), the 158-article getwisely.zendesk.com (Olo Engage) census plus its two PDFs and the Engage Warehouse Data Dictionary, the 55-article ologuesthelp.zendesk.com census, the 341-route partners.olo.com directory payloads, and all four www.olo.com legal documents. IT IS A FLOOR, NOT A CENSUS: the olosupport href fixpoint names 149 article ids that are 401-gated, so per the session rule no capability 'no' may rest on it. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. "advance exchange"/"hardware replacement"/replacement/RMA/"next business day" 2 hits in 2 pages, both prose ("SMS isn't a replacement for email", "not a replacement" for first-party ordering) - POISON. The Olo Pay terminals are described only as "modern, reliable payment terminals ... USB-connected devices ease setup" (spring-2025 release); no supply, warranty or swap programme is stated anywhere reached. Retrieved 2026-09-18. adversarially verified

Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.

reliability-backup-restore

STILL unknown. NEW SURFACE: getwisely.zendesk.com, the Olo Engage (ex-Wisely) Zendesk help centre, production, articles updated to 2026-09-11. Its HTML /hc/ is not linked from the olo KB, but the anonymous Help Center API serves 158 articles (2 pages, /api/v2/help_center/en-us/articles.json; 7 categories: GDP, Marketing, Sentiment, Host, Technical Documentation, Release Notes, Contact Us) and attachments.json across all 158 yields 2 PDFs (Olo Engage Analytics Suite Overview, 11.4 MB; Olo Engage Marketing Automation Guide, 10.1 MB). NOT A CENSUS: the href fixpoint names 24 article ids absent from the listing; probed, 22 = 404 and 2 = 401 gated (5026107804187, 5026083627931), so no `no` may rest on it. Nearest: "Olo Engage Warehouse" gives brands a live Snowflake data share ("a live connection to our warehouse that provides real-time data updates that can be queried upon"), which is data export, not operator backup/restore, and no RPO/RTO. backup = 0; restore* = 3, all "restored_at" (party returned to waitlist): POISON. Security & Privacy states breach notice "within 24 hours", not recovery objectives. Retrieved 2026-09-16. || 323rd: NEW SURFACE, still unknown. The Engage Warehouse Snowflake share (https://getwisely.zendesk.com/hc/en-us/articles/5026134931099) is the closest thing Olo publishes to operator-retrievable data - the brand gets its own credentials and a dedicated database and can pull all 49 wisely_share_v2 views by SQL - but it is a live read-only analytics replica, not a backup/restore: the article covers connection, server sizing, sleep and cold start, and schema versioning, and says nothing about restoring configuration or transactional state. Tokenised across the two Engage PDFs (65,617 + 37,038 chars) and the 158 Engage article bodies (549,208 chars): rpo 0, rto 0. POISON PUBLISHED: 'rto' squashes to 24 hits in the Analytics Suite PDF text and 8 in the Marketing guide with 0 tokenised, all artefacts of pdftotext -layout inserting intra-word spaces, so a squashed-substring control on rpo/rto is worthless on this corpus. No RPO/RTO figure on any Olo surface reached to date. Retrieved 2026-09-17. || 328th: 328th: NEW SURFACE, no move, and new poison for this cell. Olo Serve (serve-next.olo.com) censused completely (buildId Qf-toB1-JcZW3iX3iMy_c, 25 routes, 51 chunks, 0 misses, 4,015,455 chars, nonsense control 404): backup 0 over the whole app. POISON PUBLISHED: `restore` scores 9 and every one is rrweb session-replay plumbing in pages/_app (`restoreHandlers`, `this.restoreHandlers.push(...)`), plus one basket string ('basket discount was removed to apply a reward and could not be restored'); `offline` scores 3 and all three are the browser `window.addEventListener("offline")` online/offline event and the OIDC `scope=openid+profile+email+phone+offline_access` parameter - never an operator offline mode or a recovery objective. Separately re-read Olo's 2024 10-K on disk: its only continuity language is the risk factor that customers 'may be entitled to significant compensation from us in the form of service level credits', which per standing merge policy is a risk factor, not a commitment. No RPO/RTO on any Olo surface. Retrieved 2026-09-18. || 331st: 331st: NEW SURFACE, unreadable today. trust.olo.com is a SafeBase portal (CNAME olo.portals.safebase.io) whose page state (a 2026-09-15 copy at .cache/q310-olo/raw/trust.olo.com_, 191,652 bytes, __NEXT_DATA__ 49,046 chars) lists a "BC/DR" control category with 13 item ids and an "Infrastructure" category with 20, but the item texts are loaded client-side from app.safebase.io, and today every trust.olo.com, olo.portals.safebase.io and app.safebase.io path answers 403 "Just a moment..." (Cloudflare managed challenge, cf-mitigated: challenge) to curl with browser headers; Wayback is offline. The only BC/DR prose in the copy is a hidden SafeBase TEMPLATE placeholder ("We are happy to provide details about our risk mitigation practices and recovery objectives upon request", "hidden":true), which is not tenant-authored and is not evidence. The FY2024 10-K has backup 0, "disaster recovery" 0, RPO/RTO 0 (only "fault-tolerant cloud-based servers"). Next pass: read the 13 BC/DR items from a browser. Retrieved 2026-09-18. || 332nd: 332nd: TWO NEW READS, no move. (1) THE trust.olo.com LEAD IS CLOSED, and not by the Cloudflare challenge: in the portal's own page state (the 2026-09-15 __NEXT_DATA__ copy, .cache/q331/olo/a/trust-nextdata.json) the tenant configuration props.pageProps.orgInfo.sp.products.default.raw.spData.cards marks the "BC/DR" card (business_continuity) "hidden":true, and likewise infrastructure, risk_profile, policies, reports and 12 more - 21 of 30 cards are hidden; only overview, certifications, application_security, data_privacy, documents, legal, trusted_by, subprocessors and customer_data are shown, and the portal KB is empty ("kb":{"entries":[],"hasPrivate":false}). So the 13 BC/DR item ids are not published by Olo on the public portal at all; reading them from a browser would show nothing more. The only tenant-authored continuity text there is the SOC 1/SOC 2 Type II bridge letters (Linford&Co, period ending 2025-09-30), which name no RPO/RTO. trust.olo.com / olo.portals.safebase.io still 403 (Cloudflare managed challenge) to curl with full Sec-Fetch/sec-ch-ua headers and to Windows' own TLS stack (PowerShell Invoke-WebRequest); Wayback CDX holds 0 captures of either host. (2) Olo's Security Policy (https://www.olo.com/security-policy, on disk since the 325th but never quoted for this cell) and its Data Processing Addendum say only "Olo's information security program includes the following safeguards: (a) secure business facilities, data centers, servers, and back-up systems and disaster recovery" - backups exist as a safeguard, but no operator-triggered backup/restore and no RPO/RTO figure; RPO/RTO/"recovery time"/"recovery point" 0 in it. NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. Over that floor: backup/DR 6 hits in 4 pages, all the same Security Policy / DPA safeguard sentence plus a partner's "cellular backup" (Pivot Up Technologies) and one release-page 'backup' meaning a guest's backup plan; RPO/RTO 0. Retrieved 2026-09-18. || 334th: 334th: NEW SURFACE, no move. Olo's published Omnivore API SLA (https://panel.omnivore.io/legal/service-level-agreement, Last Modified June 25, 2025) and Omnivore Terms of Service (https://panel.omnivore.io/legal/terms-of-service, Last Modified January 22, 2026), both live and never read before, were searched for this cell: data loss is only a severity class ("Severity 1 - Full Outage ... includes ... loss, corruption, or breach of Customer data"), availability is a 99.99% uptime target with credits, and post-mortems are promised for Major Incidents within 5 business days. backup 0, restore 0 (other than 'restored' in status updates), RPO/RTO 0, 'recovery point'/'recovery time' 0 in both documents. status.olo.com and status.omnivore.io incident JSON (50 incidents each, latest 2026-03-20) also read: every 'restore' is service restoration, never a data restore or a recovery objective. The 129 Wayback-recovered gated olosupport articles score backup 1, and it is an instruction to back up the Aloha.ini file on the store's own POS server before editing it - not an Olo data backup. Still no operator backup/restore and no RPO/RTO figure. Retrieved 2026-09-18. adversarially verified

The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.

reliability-pci-dss-4-attestation

Olo's Data Protection Addendum requires compliance with 'PCI-DSS version 4.0 and any subsequent versions' for Card Present Services and obliges customer subcontractors to the same standard. No AoC or P2PE listing is published or offered on request in public materials. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.

reliability-mfa-role-based-access

Summer 2026 shipped SMS 2FA for Dashboard login; Fall 2025 shipped 'enhanced dashboard security.' SMS is the weakest MFA factor and no role-based permission model is documented publicly. https://www.olo.com/product-release · retrieved 2026-08-01

A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.

reliability-self-serve-training

A public training library exists: the four-part Menu Training Series (Introduction, Company Menu Admin, Menu Mapping, Store Menu Admin) with stated learning objectives, the 'Expo User Guide (Videos)' (360042794592) and the Loyalty Insights and Campaign guides are all readable without login. Shortfalls: 'For security purposes, you will need to log in to Dashboard to access most Olo Help Center content' (4422086507035), and there is no terminal practice/training mode because Olo ships no terminal software beyond the browser-based Expo. https://olosupport.zendesk.com/hc/en-us/articles/360026284851-Menu-Training-Introduction · retrieved 2026-09-03 adversarially verified

Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator

reliability-failover-terminal-role

The document says: “In Configuration Center, the Interface Server, Interface Terminal, and Interface Employee must be set up at the store level.” SUBJECT TEST: situation (b), and the note says so plainly — Olo operates no order-terminal fleet with a master/server role, so there is no role for a peer to assume. This live guide (updated 2026-06-14) is the document that establishes what Olo actually puts in the store, and it is one Windows service beside an existing POS: 'Once prepared, the Olo services are required to be installed on the Aloha BOH machine, and tested.', started as OloAlohaService and OloUpdateService. The only object in Olo's footprint that carries the word terminal is a LOGICAL Aloha record, not a device: the quoted configuration line, plus the guide's record table which asks the operator to create an Interface terminal ID (example 98, 'Olo Terminal') and set its Interface Host to the Olo interface server. That is Aloha's Aloha Connect external-interface licensing model — the guide notes Aloha Connect with at least one External Interface Terminal license must be enabled on the Aloha Security Key — so both the 'terminal' and the 'master' in this claim belong to NCR: the corpus's Aloha error articles carry Aloha's own master election language (error 86, no order number assigned by master), which is the POS vendor's mechanism and is scored on the POS vendor's record. Olo's own resilience story is cloud-side, not terminal-side: the same guide has the store agent connect outbound to Olo on port 443 for cloud configuration, and Olo's Dashboard merely REPORTS the resulting up/down state (Offline Stores tab, POS Outages Report). THE PHYSICAL TERMINAL FLEET OLO NOW OPERATES DOES NOT CHANGE THIS. The newly-readable release pages confirm Olo fields real hardware — Olo Pay Card-Present payment terminals, EMV-compatible, USB-connected, with a Dashboard terminal-management portal showing live status for every terminal — but these are payment peripherals hanging off a kiosk or POS host, not order terminals holding checks, and a monitoring portal is the opposite of automatic role assumption: it tells a human which terminal is down. No document in the corpus gives any terminal a master, primary, standby or election role. WHY THIS IS A CEILING AND NOT A FLOOR: the Aloha guide is Olo's own complete installation runbook for its largest on-premise integration — it enumerates every prerequisite, every service and every store-level record Olo requires — and it describes a single-instance agent with no second instance, no election, no standby. RE-MEASURED over the final 1,628-document corpus: 'failover' still 0 docs / 0 occurrences; 'redundant' 7 docs / 8 occurrences, none about store-side POS or terminal redundancy. The absence is bounded to what Olo installs, not to help-centre silence: the public KB is only a 26.8% floor (231 public bodies reference 288 ids; 149 of the 156 absent ones return 401, present and withheld), which is why the verdict rests on affirmative prose describing a different architecture rather than on a zero-hit. AUDIT (single adversarial auditor, 2026-09-06, over the FINAL and COMPLETE 1,628-document corpus: zd-public 231, zd-guest 55, www 657, wayback-kb 680, sec 5; all 657 sitemap URLs fetched, all 392 published /partners/<slug> pages present, remainder ZERO, so .cache/q225/still-missing.txt is stale and every floor with a named remainder of 52/58 bound in this note is withdrawn as satisfied). FIGURES RE-DERIVED: failover 0 documents and redundant 8 occurrences in 7 documents both reproduce. CONTROL CAPABILITY TESTED AND PASSED: redundant fires on 7 documents and peer on 6 while failover is 0, so the control was capable of firing. VALUE, GRADE, URL AND QUOTE UPHELD at no/B - this is the best-founded `no` in the batch, because its bounding document is Olo's own complete installation runbook for its largest on-premise integration and the absence is bounded to WHAT OLO INSTALLS rather than to help-centre silence, exactly as the note says. The KB floor figure in this note is corrected from ~30% to the measured 26.8% (kb-census.mjs: 231 public against a live floor of 863, of which 149 are ids referenced by public bodies that answer 401 and 483 are archive-only ids that answer 401). https://olosupport.zendesk.com/hc/en-us/articles/115000632923-Aloha-POS-Prerequisites-and-Olo-Service-Installation · retrieved 2026-09-06

Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.

reliability-cellular-backup

Migrated from the 2026-08-01 research pass; no source URL was recorded. || 326th: 326th: NEW SURFACE, no move. Olo's only documented store-level device fleet is the Olo Host iPad app, and the Engage help centre now bounds it: 'iPad Compatibility' enumerates the supported devices (iPad Pro all generations, iPad Air all generations, iPad 5th generation or newer, iPad Mini 2nd generation or newer), the iOS policy ('runs on the last two versions') and a CLOSED accessory list - 'Compatible Accessories: iPad Countertop Stand, iPad Case & Holder, Keyboard' - with no modem, router or cellular accessory. The connectivity documentation assumes wired/Wi-Fi only: 'Make sure the iPads are connected to your internal network ... We recommend having a connection of 12Mbps or higher', and the four network build guides are all Wi-Fi controllers (Ubiquiti, Meraki, Aruba, Aerohive). CONTROLS over 2,161,373 chars: cellular 0, failover 0, hotspot 8 tokenised and ALL EIGHT are the UniFi guest-portal 'Hotspot' authentication setting, not a data uplink. POISON PUBLISHED, and it is severe: LTE scores 721 on a substring grep and 1 tokenised - the 720 are inside alternate/filtered/Deloitte-style words - and the single tokenised hit is not a product statement at all but the privacy policy's tracking list, 'radio/network information (e.g., Wi-Fi, LTE, 5G)', which is also the only tokenised '5G'. Held unknown: Olo's payment terminals (Olo Pay) have no public hardware documentation, so terminal-level failover cannot be bounded from the Host iPad app alone. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. Olo's only first-party statement about its payment TERMINALS' connectivity describes store-and-forward, not a cellular path: "Experience Olo Pay's POS-integrated payments on modern, reliable payment terminals: EMV-compatabile devices ... USB-connected devices ease setup; Offline capabilities (store and forward) ensure your restaurant won't lose out if connection is lost" (https://www.olo.com/quarterly-release/spring-2025, marketing, grade C). LTE/cellular/4G/5G/failover 5 hits in 4 pages, all POISON: the privacy-policy tracking lists ("radio/network information (e.g., WiFi, LTE, 3G)") and two PARTNERS' products (Pivot Up Technologies "network infrastructure with cellular backup"; Beachy "a 5G cellular-supported mobile POS"). Notes only: marketing silence cannot carry a no, and the terminal model is still unnamed. Retrieved 2026-09-18. adversarially verified

Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator

commercial-month-to-month-contract

Olo Inc. Form 10-K for FY2024 (filed 2025-02-28). sec.gov refuses our client ('Undeclared Automated Tool'), so the filing was read from the unmodified Wayback id_ capture web.archive.org/web/20250228125908id_/ of this URL (HTTP 200, 2,255,983 bytes). It states Olo's standard contract term five times: 'Our contracts typically have initial terms of three years or longer, with continuous one-to-two-year automatic renewal periods'. Three of the five match that exact string. The other two differ only in hyphenation ('one-to-two year', 'one -to- two -year'). It adds: 'We recognize revenue from subscription agreements monthly over the terms of these agreements, which is typically three years or longer.' This is a published statement in a regulatory filing that the standard commercial offer is a multi-year initial term that renews automatically. That is the same shape as the peer no's (arryved MSA 8.1, cake-pos 10.1, par-brink SSA 12.a, xenial 4.1.2), each of which also allows a different negotiated term. Controls over the whole filing, tag-stripped with comments removed: 'month-to-month' / 'month to month' 0, 'for convenience' 0, 'no long-term' 0, 'shorter term' 0. 'early termination' 2, both about an office lease and a 10b5-1 trading plan, not customer contracts. Traps: 'We generally bill monthly in arrears' is how often Olo invoices, not a month-to-month term. 'a portion of our customers purchase an allotment of monthly orders for a fixed monthly fee' is a pricing unit inside the term contract. Scope: Olo sells no core POS tier, so the subject is its Order/Pay/Engage platform subscription. Limit: 'typically' is not a closed list, so a shorter term negotiated privately with some brand cannot be ruled out. Nothing public offers one, and a private negotiation is not a public offer, which is what the claim asks about. https://www.sec.gov/Archives/edgar/data/1431695/000143169525000010/olo-20241231.htm · retrieved 2026-09-15 adversarially verified

Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator

commercial-no-early-termination-fee

The claim's subject is explicitly PUBLICATION - 'Vendor's published terms of service or MSA state no early termination fee' - and no published Olo instrument states it. Measured today: /legal/ and /terms-of-service/ both 404 at 92,521 bytes, byte-identical to a fabricated control path, so no MSA or SLA is published; www.olo.com/terms-of-use is consumer website terms. The one published commercial contract, the Olo Pay T&C, expressly defers both term and money to the unpublished agreement - '12.1 Term The term shall be set forth in the Merchant Agreement.' and clause 13.2 sets the liability cap itself as whatever is 'set forth in the applicable Merchant Agreement' - and its section 12 lists only Olo's own termination rights, with no merchant exit right except the change-with-exit clause at 15.5 ('If the change has a material adverse impact on Merchant and Merchant does not agree to the change, Merchant may terminate the Merchant Agreement by giving at least one month written notice'). Shortfalls: this is a no on the published-statement limb only. It is NOT a finding that an ETF exists - the published set is silent either way, and liquidated damages, if any, live in the unpublished Merchant Agreement / MSA and order forms. https://www.olo.com/olo-pay-terms-and-conditions · retrieved 2026-09-04

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

olo.com/terms-of-use is consumer/website terms last updated April 27, 2020 and explicitly not a service agreement; no auto-renewal term or cancellation notice window is published anywhere. https://www.olo.com/terms-of-use · retrieved 2026-08-01

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Olo Help Center, Order with Google Onboarding: 'All of the Olo-supported credit card processors can be used except for the deprecated Worldpay platform,' and payments run on 'the merchant account ID (MID) set up in the store' with 'the brand is the merchant of record.' Olo therefore supports a plurality of third-party processors on the brand's own MID. Corroborated by the FY2024 10-K: Olo Pay is a separately-sold module ('Olo Pay is currently available to brands and locations utilizing Olo's Ordering module' - Pay is optional on Order, not the reverse) and GPV of ~$2.8B against GMV of ~$29B means roughly 90% of platform order volume settled on processing Olo did not provide. https://olosupport.zendesk.com/hc/en-us/articles/360050177472-Order-with-Google-Onboarding · retrieved 2026-08-02 adversarially verified

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

No rate is published. Spring 2026 added an IC+ interchange and network fee breakdown report, indicating an interchange-plus model exists commercially — but the bps + per-transaction markup is not disclosed. https://www.olo.com/2026-spring-release · retrieved 2026-08-01

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

The public Olo Pay T&C give change-with-exit protection: 'Payment Facilitator may revise these Terms and Conditions from time to time on 30 days written notice to the Merchant', and 'If the change has a material adverse impact on Merchant and Merchant does not agree to the change, Merchant may terminate the Merchant Agreement by giving at least one month written notice' (that notice due within 30 days of the change notice) - a penalty-free exit on adverse changes, with shorter notice only for changes imposed by law or the schemes. Shortfall: the exit right triggers only on 'material adverse impact', not on any increase, and the actual processing rates sit in the unpublished Merchant Agreement, so no published cap on vendor-initiated rate increases can be verified. https://www.olo.com/olo-pay-terms-and-conditions · retrieved 2026-08-04

Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).

commercial-pricing-published

olo.com has no pricing page. Every product page terminates in Request a Demo. No per-location or per-terminal figure exists publicly. https://www.olo.com/ · retrieved 2026-08-01

Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator

commercial-module-unbundling

Olo sells 16 discretely named SKUs (Ordering, Serve, Dispatch, Rails, Catering+, Loyalty, Order with Google, Switchboard, Olo Network, Pay, Host, Sync, Marketing, GDP, Sentiment, Accounts) that are clearly separately purchasable, but independent cancellation without repricing is not documented. https://www.olo.com/ · retrieved 2026-08-01

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

Fails on the published-price limb, which is a publication question and measurable. Olo Pay Card-Present does put vendor hardware in the store - the Pay page lists 'Modern, EMV-compatible payment terminals that are easy to set up' alongside 'Online and in-store payment processing' - but the same page names no price and terminates in 'Request a Demo', and no price, purchase, rental or lease term for those terminals appears on any Olo surface: the 657-loc www sitemap has no /pricing page, and the public help centre has zero terminal-procurement content (no reader model, no order form, no hardware SKU; the only EMV mention is a kiosk provider bringing its own card reader via Rails) - though that is a FLOOR, not a census: the 231 public bodies reference 383 distinct article ids and 152 (40%) are gated (401/403, not 404), so the help-centre limb is NOT load-bearing and the verdict rests on the 657-loc www sitemap, which does close. Everything else Olo runs on the operator's existing equipment rather than Olo hardware, which narrows but does not satisfy the claim: the Dispatch FAQ (article 360019209451) states delivery orders reach the restaurant with no additional hardware needed, Expo runs on the customer's own modern devices and browsers with an AirPrint or CloudPRNT printer (article 360029271212), Host runs on a standard iPad, and printer and KDS routing for integrated orders is owned by the restaurant's POS rather than Olo (MICROS RES 3700 FAQ, article 360002043331). Shortfalls: Olo sells no POS terminals and no KDS screens at all, so that half of the claim is out of scope and belongs to the operator's POS vendor; and whether Olo Pay terminals are sold outright or leased is contract substance no public surface establishes - this no rests on the absence of a published price, not on a proven lease. https://www.olo.com/pay · retrieved 2026-09-04

Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator

commercial-hardware-not-locked

Host runs on a standard iPad and Serve is browser-based, so most of Olo requires no vendor hardware at all. Olo Pay Card-Present terminal openness is undocumented. https://www.olo.com/host · retrieved 2026-08-01

One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.

commercial-implementation-fee-published

No implementation, menu-build, onboarding or training fee is published, nor stated as $0. https://www.olo.com/ · retrieved 2026-08-01

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

Self-serve exports exist per report: Dashboard Reports are built from 'the Report Category, Report Date Range, and Store Locations' with transaction-level types (Itemized Orders, Closed Orders by Store, Product Breakdown) exported to xlsx/csv, and the Loyalty Dashboard 'Export Data' section (46322256871579) offers eleven CSV exports (Store Performance, Offer Events, Loyalty Liability, Fraud Detection...). Shortfall: exports are report-by-report over a chosen date range, no single full-history export or documented bulk API is public, and payment-level detail is not among the listed report types. https://olosupport.zendesk.com/hc/en-us/articles/115000124306-Sales-and-Orders-Reports-Overview · retrieved 2026-09-03 adversarially verified

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

Olo markets restaurant ownership of first-party guest data and GDP 'without vendor lock-in,' but publishes no export format, mechanism, or fee position for guest records and loyalty ledgers. https://www.olo.com/gdp · retrieved 2026-08-01

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

CLAIM: contract or documentation specifies a post-termination data retrieval window - a defined number of days during which the operator can still export their data - rather than immediate cutoff. Partial upheld on adversarial review; grade B, first-party vendor legal page. This is a RIGHTS claim, not a feature claim, so a published addendum is the correct instrument for it rather than an applicability error. CITATION CONFIRMED, AND THE NEAR-MISS PAGE IDENTIFIED. I re-fetched both pages this session. https://www.olo.com/data-processing-addendum, 'Olo Data Processing Addendum', Last Updated February 14, 2023, is the operator-facing one: 'entered into between the company accessing or using Olo's products or services ("Company") and Olo Inc. ("Processor")'. Tokenised on its stripped text, termination 4, terminate 1, retention 2, retain 3, return 2, ninety 1, destroy 1, Personal Data 34. https://www.olo.com/data-protection-addendum is a DIFFERENT CONTRACT FOR A DIFFERENT PRODUCT, not merely a thinner page: 'Olo Data Protection Addendum', Last Updated June 26, 2024, 'entered into between the entity accessing or using Olo Pay ("Customer")'. On it termination, terminate, retention, retain, return, ninety, 90 and destroy are all 0. The processing DPA expressly disclaims that product - 'this DPA does not apply to any Personal Data processed by Processor in connection with Borderless Olo Pay'. So the citation must be the data-PROCESSING addendum, and the two are not versions of one another. WHICH CONJUNCTS ARE MET AND WHY. Three, literally. (i) A contract specifies it, and it survives the agreement's end: 'This DPA will survive termination of the Agreement.' (ii) A defined number of days: Schedule 1 section 8, 'Period of Data Retention by Processor' - 'Processor will retain the Personal Data until the date that is ninety (90) days following termination of the Agreement, unless otherwise agreed to by the parties.' (iii) The operator can still get its data during that period, by enforceable right rather than by self-service. Body section 8, 'Return or Destruction of Personal Data' - 'Upon Company's request, or immediately upon termination of the Agreement, Processor will cease all Processing of Personal Data and, at Company's direction, either (a) return such data to Company or (b) destroy such data and certify such destruction to Company in writing. Processor is permitted to retain Personal Data where it has a legal requirement to do so.' And a clause the proposal did not cite, which is the strongest support in the document and which I add here: section 2(f), Olo agrees to 'at Company's request, update, correct, delete, supplement, transfer, and provide Company with access to Personal Data in Processor's possession or control'. Because the DPA survives termination and the data is held for 90 days, that access-and-transfer right is live across the window. Together that is not an immediate cutoff of the data, so the claim's contrast is satisfied in substance. Every quote was read from the raw fetched HTML with comments stripped first and each sits in its own p element; nothing was welded. SHORTFALLS, numbered. (1) It is a vendor-side RETENTION ceiling plus a return-on-direction obligation, not a documented self-service export window: nothing states that the brand keeps Dashboard, Reports or API access during those 90 days, and the same sentence says Olo will 'cease all Processing of Personal Data' immediately on termination, while Schedule 1 section 4 says 'The Processing will begin after the Effective Date and will end upon expiration or termination of the Agreement.' Retrieval is therefore mediated by Olo on request, and the operator cannot be shown to be able to log in and pull a report. (2) Scope is Personal Data as the DPA defines it. Schedule 1 section 6, 'Types of Personal Data', is 'Contact information; location information; and transaction information', and section 5 covers 'processing and fulfilling online order and delivery transactions; verifying customer information; processing payments; creating and maintaining guest profiles; providing software to enable Company to manage consumer marketing campaigns; and conducting analytics'. Transaction information is squarely inside scope, which is why the cell is a partial and not an unknown, but the brand's menu, configuration and reporting estate is not shown to be covered. (3) The commercial contract itself is not public. 'Order Package Overview' (https://olosupport.zendesk.com/hc/en-us/articles/360044223752-Order-Package-Overview) says twice that terms live in a private document - 'If you're unsure about the current pricing model details can be found in your MSA' and 'Review your MSA for all pricing details' - so the MSA may set a different or better window that cannot be read. (4) Drafting defect worth recording so no future reader double-counts: Schedule 1 numbers TWO consecutive sections '9. Period of Data Retention by Processor', and the second one's body is in fact the technical and organisational security measures. There is one retention clause, not two. CONTROLS AND POISON. Tokenised word-boundary over the 233 stripped help-centre bodies, termination = 0 and terminate = 0, and retention = 1 occurrence which is the marketing homonym 'higher customer retention rates' in a Stores Insights article - which is why this cell is sourced to www.olo.com and not to the KB at all. Positive controls live in the same runs: Olo = 1,641 occurrences in 169 of 233 bodies and order = 942 in 111 under my normaliser (the proposal read 1,678/171 under its own; only the invariance is published, the figure is a reader artefact), and on the 6 extractable attachment text units Olo = 62 across 5 of 6, where termination, retention and export are 0. POISON: pdftotext -layout inserts intra-word spaces in this corpus - the Chargebacks PDF literally reads 'cancel t he order a nd v oid the t ransaction' - so attachment-layer word-boundary zeros are unreliable alone; re-run through a whitespace-squashed substring probe over 23,820 squashed characters, termination, retention and export remain 0, and that probe's own poison is that it manufactures 'S3' out of 'App Icons 3.' and RTO out of 'processor to'. I deliberately did NOT score this cell from https://www.olo.com/api-usage-terms, whose clause 'Upon the expiration or any termination of these Terms of Use... you, at your expense, will promptly return all Confidential Information in your possession to Olo' binds a third-party integrator returning OLO's information - the mirror image of the operator retrieving its own - and reading it as an immediate-cutoff no would have been an applicability error. https://www.olo.com/terms-of-use governs website use only. CORPUS BOUND: the published legal set enumerated by Olo's own sitemap at https://www.olo.com/sitemap.xml, 660 URLs, whose complete legal and policy subset is olo-privacy-notices, privacy-notice, terms-of-use, api-usage-terms, security-policy, data-processing-addendum, data-protection-addendum, olo-pay-terms-and-conditions, olo-pay-privacy-policy, olo-pay-illinois-biometric-data-policy and ca-applicant-privacy-notice; the MSA is not in it. The help-centre corpus this record's other cells rest on is a floor of 233 public articles of at least 382 (289 referenced ids, 156 absent, 149x 401 gated and 7x 404, reproduced independently this session), so no no is publishable from it either. Retrieved 2026-09-15. https://www.olo.com/data-processing-addendum · retrieved 2026-09-15 adversarially verified

Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator

commercial-data-ownership-clause

Marketing asserts full guest data ownership, but the only published contractual document — the Data Protection Addendum — states 'Customer is a Controller and Olo is a Controller,' i.e. Olo claims joint controllership of guest data rather than processor status. No published clause constrains Olo's own use of that data. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).

commercial-source-available-selfhost

Verified verbatim in the API Usage Terms: licensees may not 'substantially replicate products or services offered by Olo' or 'use the Olo API specifications in a product or service that competes with products or services offered by Olo.' Proprietary SaaS, affirmatively documented. https://www.olo.com/api-usage-terms · retrieved 2026-08-01 adversarially verified

Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.

commercial-pci-p2pe-tokenization

Olo Pay claims point-to-point encryption and Olo Accounts implies tokenized card-on-file, but no SAQ type (A / P2PE-HW) is named and no validated P2PE listing is cited. https://www.olo.com/pay · retrieved 2026-08-01

Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.

commercial-pci-dss-4-controls

The DPA mandates PCI DSS v4.0, and Summer 2026 shipped SMS 2FA on Dashboard login (partially addressing the MFA requirement). Payment-page script-integrity monitoring per Req 6.4.3/11.6.1 is not documented despite Olo hosting the checkout page. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.

commercial-soc2-attestation

trust.olo.com (SafeBase, read 2026-09-03) lists 'SOC 2 Type 2' and 'SOC 1 Type 2' reports and a 'PCI DSS v4.0.1' AoC under Compliance, with the report downloads behind an access request. The help-centre article 'Olo PCI Compliance Overview' (360043119711) sends customers to trust.olo.com for the AoC, the PCI responsibility matrix and the ASV scan attestations, and states Olo is a Level 1 PCI-DSS service provider on Visa's listing. https://trust.olo.com/ · retrieved 2026-09-03 adversarially verified

Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.

commercial-privacy-dsar-tooling

Olo publishes an executable Data Protection Addendum and a CCPA notice of right to opt out of sale/sharing. In-app tooling for the operator to locate, export and delete an individual guest's records is not documented, and the DPA specifies no DSAR procedure. https://www.olo.com/data-protection-addendum · retrieved 2026-08-01

Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator

commercial-wcag-kiosk-accessibility

Olo's accessibility statement references WCAG 2.1 but names no conformance level (A/AA/AAA), publishes no VPAT or ACR, identifies no specific surfaces, and directs enquiries to esg-team@olo.com. There is also no kiosk product. https://www.olo.com/accessibility-statement · retrieved 2026-08-01

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

Olo supports configurable service fees (tiered %/flat) with guest-facing fee/tax line-item disclosure, but card-network-compliant surcharging with debit/prepaid exclusion is not documented. || 325th: 325th: NEW SURFACE, no move. www.olo.com/olo-pay-terms-and-conditions, the Olo Pay merchant agreement, read in full today (30,669 bytes HTML / 51,608 chars stripped; found in the www.olo.com sitemap alongside api-usage-terms, security-policy, terms-of-use and olo-pay-privacy-policy). It is a payment-facilitator agreement in Scheme Owner / Acquirer / Holdback / Payment Facilitator terms, and its only fee-pass-through provision runs the OTHER way: "Merchant agrees: It shall not set any surcharges of its own for accepting any credit card transactions other than allowed by Scheme Rules or applicable law." There is no dual-pricing or cash-discount programme defined, no debit/prepaid exclusion mechanism and no receipt or menu-board disclosure requirement anywhere in the agreement; "dual pricing", "cash discount" and "convenience fee" score 0 across it and across the 288-article help-centre census described on the payments-surcharge-guardrails cell. Held unknown: an agreement clause allocating compliance duty to the merchant is not an enumeration of what the platform can do, and the KB behind it is a floor (233 of 304 sitemap entries). Retrieved 2026-09-17. || 328th: 328th: NEW SURFACE, no move. Olo Serve (serve-next.olo.com), Olo's guest ordering app, censused completely for the first time (buildId Qf-toB1-JcZW3iX3iMy_c, 25 routes from its own _buildManifest.js, 51 chunks, 0 misses, 4,015,455 chars, nonsense control 404). The claim's receipt/menu-board DISCLOSURE half is the only part this corpus touches and it is present in a different form: the cart and order summary itemise every fee with a name and a description (i18n keys cart.fees, cart.estimatedTaxesAndFees, cart.estimatedTax, and data-testid="taxes-and-fees"/"fee"), and the menu chunk carries a feature-flag key `transparent-pricing-disclosure-olo-135375` - NOTES ONLY, since a flag name is not a shipped feature. But the surcharge/dual-pricing engine the claim is actually about is absent from the guest app entirely (surcharge 0, "dual pricing" 0, "cash discount" 0, debit 0, BIN 0 over all 51 files), and fee disclosure is an adjacent feature, not a part of this claim, so it cannot carry a partial. Held unknown. Retrieved 2026-09-18. || 332nd: 332nd: NEW SURFACE (332nd): www.olo.com is a HubSpot CMS site whose anonymous site-search endpoint (/_hcms/search?term=<t>&limit=100&offset=N) was swept with 37 cell-vocabulary terms (support, 24/7, backup, disaster recovery, surcharge, dual pricing, cash discount, LTE, cellular, terminal, hardware, replacement, offline, conflict, void, comp, audit, refund, API, webhook, Olo Pay, card present, ...), returning 670 distinct www.olo.com URLs (blog, case studies, 300+ partner pages, the quarterly/seasonal release pages and the legal documents); 646 of 670 fetched at 200 (24 partner/product pages stayed 429 after slow retries), stripped of script/style/comments. NOT A CENSUS: www.olo.com/sitemap.xml itself 429'd, so the search union is a floor and carries no 'no'. Positive control: olo 9414 hits in 646 pages. "dual pricing"/"cash discount"/"cash price"/"card price"/"non-cash adjustment" 1 hits in 1 pages; surcharge 5 hits in 3 pages, two of them the Olo Pay T&C, two the payments blog below, and one a POISON homonym in the Spring 2026 release ("Delivery Fee Adjustments ... in Switchboard, applying surcharges for large catering orders"), a per-order delivery-fee adjustment. The one 'cash discounts' hit is Olo's payments blog describing what "some restaurants" do and noting state rules ("Some states, like Connecticut, ban surcharging outright; others, like Minnesota, require specific disclosure at the point of sale", https://www.olo.com/blog/what-restaurants-should-know-about-credit-card-fees) before pitching Olo Pay on fee negotiation; it offers no Olo compliance mechanism. No compliant card-surcharge or dual-pricing programme is described on any page reached. Retrieved 2026-09-18. adversarially verified