Vendors / Pizza & delivery-led
Slice / Slice Register
Slice (Slice Register POS, Slice Ordering, Slice App)
dossier live
- Claims in scope
- 291
- Scored
- 291
- Assessed
- 290
- Unknown
- 1
- Not applicable
- 23
- Values challenged
- 154
Identity
- Owner
- Slice Solutions, Inc.
- Founded
- 2010, by Ilir Sela, originally under the name MyPizza. Slice publishes no founding year, founder name or HQ on any page reachable from slice.com — https://slice.com/why-slice carries the mission statement and nothing biographical — so the founding facts are third-party (grade E, https://en.wikipedia.org/wiki/Slice_(app), retrieved 2026-08-02, and that article itself carries editorial flags about reliance on routine press coverage). The headquarters below, by contrast, is first-party.
- Scale
- '15,000 independent pizzerias choose Slice' — vendor claim, https://slice.com/why-slice, retrieved 2026-08-02. TechCrunch reported the same 15,000 figure at the Slice Register launch in March 2021, so the network has not visibly grown on Slice's own telling in five years. Register install base is not broken out anywhere: Slice never says how many of the 15,000 run Slice Register versus only the $39 Online membership. ARR, GPV and order volume: unknown — Slice is private and files nothing.
- Who it is for
- Single-location independent neighbourhood pizzerias in the US. The product shape is the evidence: counter/phone/delivery order entry with no table or check object, no KDS, no inventory, no multi-location governance, one shop per Owner's App, and a two-bundle price card ($399/mo Family with hardware, $39/mo Online without) with no volume or location tiering. Slice's own positioning: 'We believe local restaurants deserve all the advantages of big chains without compromising their independence' (https://slice.com/why-slice, retrieved 2026-08-02).
- Site
- https://slice.com/
Lineage
- 2010 — founded: Founded by Ilir Sela as MyPizza, an online ordering platform for independent pizzerias; later renamed Slice.
- 2020 — acquired: Slice acquired the point-of-sale company Instore, which became the basis of Slice Register — the POS launched on 2021-03-30, described at launch as available 'at no initial charge for the hardware or software', with payment processing as the only fee.
Pricing
transparency: published · unit: mixed · processor lock-in: yes
- Software
- Two published bundles, exact dollars, no sales call. FAMILY MEMBERSHIP: '$399/month' + '$2.00/order' + a '$1,000 implementation fee'; includes Point of Sale, Website, Online Ordering, Slice App, Phone Ordering, Google Listing Management, Loyalty Rewards, Automated Marketing, Flex Delivery, Supplies, Integrations, 24/7 Customer Service, Owner's Portal, Account Manager and Owner Community. ONLINE MEMBERSHIP: '$39/month' + '$3.00/order', no implementation fee, no hardware, no POS, no phone ordering, no Flex Delivery, no account manager. Re-retrieved 2026-08-02, unchanged from the 2026-08-01 pass. The per-order fee replaces a percentage commission — Slice App orders are marketed as commission-free.
- Card processing
- '2.90% + $0.30' published on both plan columns (https://slice.com/pricing, retrieved 2026-08-02); the POS product page independently states '2.9% plus $0.30 per transaction'. Flat blended only — no interchange-plus option is published or offered.
- Contract
- 'Month-to-Month' is a PRICING-PAGE assertion and the published agreement does not match it. The claim that no merchant agreement exists was stale and was corrected 2026-08-10: the Online Restaurant Agreement IS public at https://slice.com/online-restaurant-agreement/. Its General Terms set an 'initial Order Form Service Term' that 'will automatically renew for consecutive periods of the same duration as the initial Order Form Service Term' absent notice from either party — i.e. a fixed renewing term, not month-to-month. The pricing page says 'Zero locked-in contracts'; the contract says otherwise, and the contract is readable.
- Early termination
- THERE IS ONE, AND IT IS PUBLISHED. The previous sentence — 'None advertised ... those merchant terms are not public, so the absence of an ETF is a marketing statement' — was stale and read in the vendor's favour; corrected 2026-08-10. The Online Restaurant Agreement's General Terms carry a clause headed 'Early Termination Fee': if the Restaurant terminates a Service before the end of the initial or renewal Order Form Service Term other than for Slice's material breach, it must immediately pay amounts due, including the Annex 4 hardware return fees. That is why commercial-no-early-termination-fee is `no` at grade A. The $1,000 implementation fee and bundled hardware feed the same clawback.
- Hardware
- Included at no separate charge on Family: 'Register and Stand, Payment Terminal, Cash Drawer, Receipt Printer, Kitchen Printer, Network Kit', plus a delivery card reader. Treat '$0 hardware' as partial rather than settled: the pricing page also offers 'Additional configurations available' with no prices, and three cost-bearing items are unpriced anywhere — the second iPad (Order Manager Kit), the NYC1 mobile card reader, and the per-delivery courier fee on Flex Delivery. Ownership versus loan on cancellation is not stated.
API posture
public API: none
- Cost to integrate
- unknown — no partner programme, revenue share, certification path or integration cost is published. The one public bounty on Slice's site is $1,500 per referred pizzeria location, which is an operator referral programme, not partner commercial terms.
- Webhooks
- none documented
- Data export on exit
- Partial and undated. Self-serve CSV download exists in the Owner's App Financials section for Order Activity, Orders, Tax, Sales Mix and the Sales Summary, with PDF for statements and date ranges up to a custom range (https://slice.com/knowledge-hub/owners-app-web-financials/, retrieved 2026-08-02). Customers can be IMPORTED but no customer-list export is documented; no loyalty ledger export; no history retention window. A POST-TERMINATION WINDOW IS PUBLISHED, and the sentence denying one was stale (corrected 2026-08-10): the Online Restaurant Agreement's General Terms, 'Portability and Deletion of Restaurant Data' — 'Upon request by Restaurant made within thirty (30) days after the effective date of termination or expiration of this Agreement, Slice will make Restaurant Data available to Restaurant for export or download. After that thirty (30) day period, Slice will have no obligation to maintain Restaurant Data, and may thereafter delete or destroy all copies'. It is request-and-return, not self-serve. The claim that only diner-facing Terms exist was the same stale premise: the merchant agreement is public and is what these thirty days come from. What it still does NOT contain is a merchant data-OWNERSHIP clause.
- Notes
- Slice is the most closed vendor in this peer group. There is no public REST or GraphQL API, no sandbox, no OAuth app model, no webhooks, no published rate limits and no app marketplace; developers.slicelife.com serves marketing content with no API links. 'Integrations' is a checkbox on the pricing page, and the POS page claims Slice Register 'integrates with 30+ delivery apps including DoorDash, Grubhub, and Uber Eats' (https://slice.com/products/point-of-sale-for-pizza-shops/, retrieved 2026-08-02), but Slice never says whether those are first-party certified integrations or resold middleware, and Slice is not in DoorDash's 2026 Preferred Integration Partner cohort (Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, UrbanPiper). The decisive limitation is stated by Slice itself and re-confirmed on 2026-08-02: 'Slice receives the Third-Party orders but does not have a way to communicate back to those providers' (https://slice.com/knowledge-hub/register-third-party-orders/). One integration did appear since the previous pass: Homebase, as a Time Clock app on the Register iPad — a partner product, enabled by contacting Slice Support, with scheduling and payroll run separately in Homebase's own tools.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Docs define dine-in as counter-service: orders 'placed in-store and consumed in-store' that 'do not require customer information'. No table, section, or floor-plan object appears anywhere in the Register docs. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-01
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
The Order Entry article enumerates the whole line-item surface. Adding an item is 'Select the Dining Option / Select a Category / Choose an Item / Select the Item Type / Add Modifiers / Add the Item' - no seat field. After adding, the documented per-line actions are Modify, Item Notes, Line Item Discount, Remove an Item and Adjust Quantity; none assigns a seat. Splitting is payment-side only: 'The Split Payment option lets you accept more than one form of payment for a single order. You can divide the payment evenly, assign custom amounts, or apply a full payment to part of the order', with the three on-screen choices 'Split payment evenly', 'Pay custom amount', 'Pay total owed'. No seat-based split exists. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
No coursing, hold, or fire action in Register order entry or order management docs. Counter/delivery product. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-01
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
The Register order-entry article (updated February 6, 2026) lists 'Split - Allows splitting checks' among the 'More Order Actions', separately from the 'Splitting a Payment' section that divides a tender. So check splitting exists as a named order action. Shortfalls: the article never states the split granularity (no by-item, by-seat or N-way modes are described), Register has no seat or table model to split by - the dining options are exhaustively 'Dine In, Pickup, Delivery, To Go' - and no merge, combine or recombine action appears anywhere in the Register order-entry, order-management or employee-permission documentation, including the permission list that gates every other order action down to 'Line item clear before send'. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
The Register order-entry article enumerates its payment surface exhaustively - 'There are three ways to pay for an order: Card, Cash, and Other' - and the card flow is only 'Use Card' (customer present) or 'Hand Entry' (over the phone), with the tip taken on the reader at the time of sale. No authorization-and-capture, incremental auth or open-tab flow exists. The dining options are likewise closed - 'Dine In, Pickup, Delivery, To Go' - and the complete 'More Order Actions' list (Add Note, Copy, Split, Discounts, Extra Charge, Hold, Clear Order, Taxes) has no open-tab action; the nearest is 'Hold', which saves an unpaid order to Order Management with no card held against it. End-of-day handling is a cash drawer close-out, not a stale-tab sweep. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
CLAIM: an open check can be transferred between servers, tables and devices, and the transfer is recorded in an audit log naming both employees. VERDICT: no (moved from unknown; the cell carried no note at all). EVIDENCE: 'transfer', 'transferred', 'transfers' and 'reassign' score 0, 0, 0 and 1 word-boundary hits in the 116-document Knowledge Hub census, and the single 'reassign' is a delivery batch, not a check. (The site and contract score 18 and 12 for 'transfer' and they are all legal assignment-of-rights and 'migration or transfer of data' - poison for this control.) Slice Register has no server assignment and no table entity (this record's floor-plan and seat-level cells are already no), and each iPad is an independent client: Register > Settings, 'Download changes from Slice: Sync updates made in the Slice Owner's App (web) to this iPad. If you use multiple Register iPads, you must download changes on each device.' The nearest thing to the claim's audit log is real but is about overrides, not transfers: the Owner's App (web) Register article documents an approval log whose Action column holds entries like 'Turn off tax at order level' and 'Line item clear before send', with Status and Date, and says 'This log provides a clear audit trail for tracking sensitive activities performed and approved within your system.' Slice itself rules out the shift dimension: Employee Permissions states 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register.' BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-09-18 adversarially verified
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Hardware list has no handheld. The mobile device shipped is the NYC1 Mobile Card Reader for door/delivery payment, plus a second iPad (Order Manager Kit) for back of house. https://slice.com/knowledge-hub/order-manager-kit/ · retrieved 2026-08-01
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Moved off unknown on a document earlier passes never read: Slice's own Terms and Conditions (Slice POS Terms, 'Telecommunications > Offline Transactions'). Slice contractually permits offline operation of the POS - 'Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline' - and states the payment half of the behaviour: offline transactions are queued and submitted for authorization on reconnect, capped at $100 per transaction unless an Order Form says otherwise. SHORTFALL: the only offline scope Slice publishes anywhere is this contractual sentence. Nothing states whether order creation, modifier application, kitchen-printer routing or cash tender continue during an outage, and no supported/unsupported offline table exists in the 45 Knowledge Hub articles, 30 release notes or 26 FAQs. The claim's second limb - 'the vendor publishes what does and does not work offline' - is therefore met only for card capture. Note also the vocabulary trap that misled earlier passes: 'offline orders' in Slice's REPORTING means in-person Register orders, not disconnected ones; this T&C section is the one place the word means disconnected. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-05 adversarially verified
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
Slice documents QR codes in exactly one role, and it is not at-table ordering: the online-ordering product page answers 'Can customers order through social media or via QR codes?' with 'you can place ordering links on social pages or QR codes on menus, pizza boxes, or signs' - a link to the shop's Slice online menu. The string 'QR' does not occur once in the 45 Knowledge Hub articles, 30 release notes or 26 FAQs. Orders placed that way arrive as ordinary Slice Online orders: the Register Order Management article shows each landing as a new order requiring confirmation with its own ETA, listed alongside Register orders, never appended to one. There is also no open check to append to - Register's dining options are Dine In, Pickup, Delivery and To Go, with no table or seat model. https://slice.com/knowledge-hub/register-order-management/ · retrieved 2026-08-08
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
Kiosk appears in neither the 12-product catalog nor the included-hardware list. https://slice.com/pricing · retrieved 2026-08-01
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
Asked directly whether it handles a shop's order volume, Slice equates 'all order types' with phone, online and walk-in, and repeats the same triple twice more on the page under the heading 'One system for every order' - there is no lane, window or car-side mode, so no order-point/pay-window separation and no lane sequencing to score. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-09-06 adversarially verified
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
The vendor equates its full set of order types with phone, online and walk-in, so there is no drive-thru service segment for order, total or window timers to measure, and Slice's documented reporting surface contains no speed-of-service metric of any kind. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-09-06 adversarially verified
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
Slice Phone is explicitly human agents: 'our trained support team handles order taking', and support is 'No AI, robots, or chat bots — fully human support'. No voice-AI partner API published. https://slice.com/products/phone-ordering/ · retrieved 2026-08-01
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
Only manual levers: editable prep-time ETAs in 1- or 5-minute increments and a timed Pause. No automatic capacity limits per slot or load-driven quote extension. https://slice.com/knowledge-hub/register-shop-status/ · retrieved 2026-08-01
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
Confirmed: 'Scheduled: Orders set for a future time or date' is a first-class status alongside In Progress and Complete. https://slice.com/knowledge-hub/register-order-management/ · retrieved 2026-08-01 adversarially verified
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
'Catering order support' is claimed on the online-ordering product page. No quote, deposit, balance-due, or event-schedule workflow is documented. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
Slice states outright: 'Slice receives the Third-Party orders but does not have a way to communicate back to those providers.' https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-08-01
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
Discounts carry reason codes and permissioned actions require a manager four-digit PIN approval. No exception report and no void documentation; the Employee Permissions Log 'only tracks assigned permissions', not instances. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-08-01
Menu, modifiers & pricing engine
Payments & money movement
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
2.90% + $0.30 Slice processing is the single published rate on both memberships; the payment terminal ships in the Family bundle. No supported third-party processor or gateway list exists. https://slice.com/pricing · retrieved 2026-08-01
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
A single blended headline rate is published on the pricing page - '2.90% + $0.30 card processing' on both the Family ($399/month + $2.00/order) and Online ($39/month + $3.00/order) columns - but that is a first-party sales page, not documentation. Named shortfalls: no interchange-plus schedule, no card-type, AmEx or keyed/manual-entry differential, and no monthly, PCI, gateway or statement fee disclosed. Slice's own Owner's Portal Help defines Card Present and Card Not Present processing fees as 'any percentage and swipe fees outlined in your agreement for card processing' (https://sites.google.com/slicelife.com/owners-portal-help/home/statement-definitions/slice-payments, retrieved 2026-08-06), i.e. the rate that actually applies is set in the non-public merchant agreement; the Slice Register site quotes no percentage at all and offers a Cash Discount alternative. Searched: slice.com/pricing, slice.com/knowledge-hub help centre (no pricing, fee or billing article exists - it directs financial questions to a phone number), slice.com/terms-of-service, sliceregister.com, and the sites.google.com/slicelife.com Register product help site, whose pages redirect to a Google account login. https://slice.com/pricing/ · retrieved 2026-08-06
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
Moved up from unknown: cash discounting is evidenced downstream even though no setting is documented. The Financials article lists 'Cash Discounts' as an Orders Report column and, in the Sales Summary, as 'Total discounts applied when customers paid with cash', and the Sales Summary's Service Fees section includes 'Credit Card Surcharges'. Shortfall: Register Settings documents no cash-discount or surcharge configuration at all, nothing states that two prices are stored per item, and neither the guest check nor the receipt is documented as printing both cash and card totals. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-02 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
Surcharging itself is real and reported: the Register Sales Summary Report has a 'Credit Card Surcharge' line under Payments and the Owner's App (web) Sales Summary CSV carries 'Credit Card Surcharges - Total surcharges applied to credit card transactions' and '# of Credit Card Surcharges Collected'. The guardrails the claim asks about are absent, and one is contradicted: Slice's own definition is 'Credit Card Surcharge - A fee charged when a customer pays with a credit OR DEBIT card', which is the opposite of BIN-based debit exclusion. No prepaid exclusion, no network percentage cap, and no per-location enable/disable control appear in the Owner's App (web) Settings page, the Register Settings page or the Register configuration article - and surcharge configuration is not self-service anywhere in the documentation. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-08
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Moved up from unknown on evidence no earlier pass cited. The Slice Driver App article documents chip and contactless acceptance in Slice's own words: 'Ask the customer to insert, tap, or swipe their card on the reader', on a reader paired over Bluetooth ('Double-tap the button on the reader's side to confirm the connection'). Shortfall: this covers only the mobile reader used at the door. The countertop Payment Terminal shipped in the Family bundle is never named or described in any Slice document, PIN debit is not mentioned, and Apple Pay / Google Pay acceptance appears only at online checkout, never at a physical reader. https://slice.com/knowledge-hub/register-slice-driver-app/ · retrieved 2026-08-02 adversarially verified
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
Mobile acceptance requires the separate NYC1 Mobile Card Reader, which is the documented alternative to phone-native tap. https://slice.com/knowledge-hub/order-manager-kit/ · retrieved 2026-08-01
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
Slice's only mobile reader is a Driver App accessory: it pairs over Bluetooth to the driver's own phone (Settings > Card Readers > Pair Reader), requires that 'the driver has an assigned order', and the payment procedure is headed 'here's how to accept a card payment at the door' - tap 'Pay with card reader', customer is prompted to add a tip, then insert/tap/swipe. There is no server handheld: the Register kit is 'iPad, printer, card reader, and cash drawer', and Order Entry states 'Credit card payments and tipping are still completed through the shop's credit card reader' at the counter, with the iPad flipped toward the customer as the customer-facing display. https://slice.com/knowledge-hub/register-slice-driver-app/ · retrieved 2026-08-08
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
VERDICT moved to no, and the ambiguity the prior note left open is now closed from the print side. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) carries the complete printed-document designer, `register.printerTemplates.*`, and it is closed at exactly two documents - `register.printerTemplates.tabs.customerReceipt` = 'Customer receipt' and `.tabs.kitchenTicket` = 'Kitchen ticket'. There is no bill/check template and no table tent. The customer receipt DOES print a QR code, and the app says what it is for: the JSX renders `<img alt={t('register.printerTemplates.preview.qrCodeAlt')} className={styles.qrCode}>` immediately after the line `register.printerTemplates.preview.orderDirectlyFrom` = 'Order directly from [pizzeria name] on the Slice app.' - a re-order/app-download QR, not a pay-this-check QR - and the same preview already stamps `register.printerTemplates.preview.paidBadge` = 'PAID' with a tip line and change due, i.e. the receipt is produced after settlement. The receipt's configurable options are likewise a closed three: upload logo, `showEta` ('Show ETA') and `showTipAmounts` ('Show suggested tip amounts on receipts'). BOUND/CONTROLS over the 7.33 MB corpus: `qrCode` occurs exactly 7 times - the i18n key definition, its two CSS-module class entries, the two JSX references to that same receipt image, and two inside the vendored Adyen Drop-in (`voucher, qrCode, await, bankTransfer, sdk` and the separator label `qrCodeOrApp`) (`voucher`, `qrCode`, `await`, `bankTransfer`, `sdk`) where the first is an Adyen payment-method TYPE, not a Slice feature; that Adyen hit is the trap a bare `QR` grep would have scored as a yes. Bound: the printed-document designer, which is where a scan-to-pay QR on a check would have to be configured. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 adversarially verified
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
On-device tip prompt is documented ('the customer will be prompted to add a tip'); order management shows tip-present/absent icons. No pre-auth-then-adjust flow, batch window, or unadjusted-tips manager screen documented. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-01
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
No labor module and no time clock exist, so there is no hours or role basis for pooling. Not present in any documentation. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-08-01
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
Moved off unknown. Slice's Terms and Conditions ('Offline Transactions') document store-and-forward explicitly: transactions initiated while disconnected are queued and submitted for authorization when connectivity is restored. A per-transaction limit is published and it is $100 ('Unless otherwise specified in an Order Form, offline transactions may not exceed $100 per transaction'). SHORTFALL, which is why this is partial and not yes: neither limit is operator-configurable. The per-transaction cap is varied only by negotiating an Order Form with Slice, and the cumulative limit is not published at all - Slice merely reserves the right to set one ('Slice reserves the right to limit the number of offline transactions that may be queued'), with no stated ceiling and no operator-visible setting. No Register Settings screen in the Knowledge Hub exposes an offline limit. The claim asks for configurable per-transaction AND cumulative limits; Slice ships fixed, vendor-set ones. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-05 adversarially verified
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
Moved off unknown. The claim's first limb is now squarely met: Slice publicly and unambiguously allocates the loss to the merchant in its Terms and Conditions - 'Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register and/or Slice Standalone Payments is offline.' That sits directly beneath the sentence establishing that offline transactions are queued and authorized later, so it is squarely about a stored transaction that fails on reconnect. SHORTFALL: the second limb is not met. No post-reconnect report of failed offline payments is documented. The Owner's App (web) Financials report set (Order Activity, Orders, Tax, Sales Mix, Sales Summary) contains no failed-offline-payment view, and the only order-level failure signal published is the Register Order Management colour icon - 'a red dollar icon means payment failed, the order was canceled, or it was refunded' - which conflates three causes and is per-order, not a reconciliation report. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-05 adversarially verified
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 Register order-entry article closes its tender set - 'There are three ways to pay for an order: Card, Cash, and Other' - and then tells the operator what to do about gift instruments under the third: 'Other - Used for anything that is not cash or card, e.g., check, PAPER GIFT CERTIFICATE, running your own invoices, etc.' That is Slice documenting the manual workaround in place of the feature: the amount is recorded as an Other tender with no balance held by Slice. Consistent with that, the string 'gift card' occurs zero times across all 45 Knowledge Hub articles, 30 release notes and 26 FAQs, and zero times on the Slice Register marketing page; the Owner's App (web) Financials report columns track Credit Card, Cash, Other, Slice Online payments and discounts (promo codes, loyalty rewards, Slice Credit) with no gift-card liability or balance line anywhere. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
Slice documents the workaround instead of the feature. The Register order-entry article closes the tender set at 'Card, Cash, and Other' and defines Other as 'anything that is not cash or card, e.g., check, paper gift certificate, RUNNING YOUR OWN INVOICES, etc.' - the shop keeps the account, Slice records a tender. The one occurrence of the phrase in the corpus confirms the same shape: the Delivery Management Report's driver settlement line reads 'Other: Any payments that do not fall under cash or card (such as house account or Slice Pay)', i.e. house account is a label for an Other-tender payment, not an object Slice maintains. There is no account entity anywhere - no credit limit, no running balance, and no invoice or statement generator for customers; the enumerated Statements/Payouts surface in Owner's App (web) Financials is Slice paying the shop, not the shop billing a customer. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
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
Split payments exist — refunds can target 'specific payments' when a payment was split, and checks divide evenly or by custom portions. No documented split cap, no split-by-item or by-seat. https://slice.com/knowledge-hub/register-order-management/ · retrieved 2026-08-01
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
Refunds and discounts are permission-gated with manager four-digit PIN approval. But the Employee Permissions Log 'only tracks assigned permissions' and is explicitly not an activity log — no immutable approver-attributed audit trail is documented. https://slice.com/knowledge-hub/register-employee-permissions/ · 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
Statement Summary carries a Chargebacks line: 'Refunds due to customer disputes through their bank or credit card issuer, including reversed chargebacks.' No dispute dashboard or evidence-submission workflow documented. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
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
'Saved payment accounts for repeat customers' on first-party digital ordering. Tokenization, cross-channel reuse at the Register, and no-PAN-stored assurance are not documented. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Both halves are published. Schedule: the FAQ 'When and how will I receive my payout?' states 'Payouts are sent via Direct Deposit to your bank account based on your preferred schedule - daily, weekly, bi-weekly, or monthly', changed by calling Slice. Accelerated funding: the Owner's App (web) Financials Payouts table documents a payout 'Method: Indicates the payout method (e.g., INSTANT)', the Statement Summary's bottom line is 'Total: The expected funds paid by Slice to your Debit Card TODAY', and the Owner's App (web) Settings article documents how to switch it on - 'Payout management: This is where you can add a debit card to receive your Slice payouts faster. Adding a debit card is optional, but it is required to receive the fastest possible payouts.' Caveat for the reader: Slice publishes the cadence and the instant option but not a cut-off time or a guaranteed settlement window. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-08
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
CLAIM: a single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. VERDICT: no (moved from unknown). EVIDENCE: the standard Pizzeria Agreement, Annex 3 (Slice POS Terms), makes the deposit account singular and change-controlled: 'In connection with the Slice POS, Restaurant must maintain a deposit account (“Merchant Deposit Account”) to enable Slice or its vendors or partners to deposit proceeds of sales transactions Restaurant processes through Slice POS', and 'Restaurant will not change the Merchant Deposit Account without obtaining prior written consent from Slice.' Settlement runs through one third-party processor to one designated account: 'Slice or the Processor will act as Restaurant's agent to collect and hold all monies received from Consumer on Restaurant's behalf and to remit the funds that may be owed to Restaurant's designated account, except for cash transactions', with the processors named as Adyen N.V., Stripe, Inc. and Wells Fargo Bank, N.A. (Payment Facilitator and ISO), and 'If approved, Restaurant shall receive all settlement directly from Processor.' The owner-facing FAQ matches: 'Payouts are sent via Direct Deposit to your bank account based on your preferred schedule - daily, weekly, bi-weekly, or monthly.' CONTROLS: 'split settlement' 0, 'merchant ID' 0, 'legal entity' 0 in all three corpora; 'MID' 1 hit in the KB and it is 'X report (mid-shift cash report)'. The only multi-shop affordance documented anywhere is a login-time picker: 'If you have multiple shops, select the location you are in.' BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-18 adversarially verified
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
CLAIM: vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request. VERDICT: no (moved from unknown). EVIDENCE OF ABSENCE: across all three corpora the word-boundary counts are PCI 0/0/0, 'Payment Card Industry' 0, P2PE 0, 'SOC 2' 0, SOC2 0, 'ISO 27001' 0, token 0, tokenization 0, AOC 0, 'Attestation of Compliance' 0, SAQ 0, attestation 0. That includes the entire 177,854-character Pizzeria Agreement of 2026-03-05 - whose Annex 7 is titled 'Scheme Rules' and incorporates the Adyen / Wells Fargo Acquiring Addendum, and whose Annex 8 defines 'Security Incident' and imposes data-security duties on the RESTAURANT ('Restaurant shall implement and maintain reasonable and appropriate physical, technical and organizational safeguards ... notify Slice in writing within 48 hours'), never on Slice - and the whole 74-page slice.com page index, which contains no /security, /trust, /compliance or trust-centre page. The only security statement Slice publishes is the consumer-grade FAQ 'How secure are payments?': 'Slice partners with industry-leading payment processors to ensure all transactions are secure and encrypted. Your payment information is protected and used only for processing orders - it is never shared or stored beyond what's necessary to complete the transaction.' That sentence is the ONLY occurrence of encrypt* in any corpus, it names no standard, no version, no SAQ type and no report, and it attributes the security to the processors rather than to Slice. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/ · retrieved 2026-09-18 adversarially verified
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
Verified and slightly stronger than described — routing targets are named ('kitchen, pizza, bar, etc.') and bulk edit can reassign printers across many items. Still printer-only routing with no KDS, so partial is the right ceiling. https://slice.com/knowledge-hub/owners-app-web-menu/ · retrieved 2026-08-01 adversarially verified
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
Corrected 2026-08-08: the previous note's 'No KDS product exists' is withdrawn as stated, because https://slice.com/family-membership/ advertises 'Discounted kitchen displays & kiosks (coming soon)'. An expo screen still cannot exist, because no display device ships: the Slice Register product page answers 'What hardware is included with Slice Register?' with 'an iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader', and /pricing's Hardware list adds only a Network Kit and Stand. Kitchen output is print - register-order-management says 'Moving the order will trigger printing from both the customer receipt printer and the kitchen printer' - and printed tickets have no bump state to consolidate across stations. 'expo', 'bump' and 'kitchen display' occur zero times in the 45 Knowledge Hub articles, 30 release notes and 26 FAQs retrieved from the WP REST API on 2026-08-08. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-08 adversarially verified
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
Re-evidenced 2026-08-08; the earlier "no coursing anywhere in the documentation" rationale is withdrawn as absence-of-mention. Register > Order Entry (updated February 6, 2026) walks the whole order lifecycle and enumerates the complete item-level action set once an item is on the check - "Modify", "Item Notes", "Line Item Discount", "Remove an Item", "Adjust Quantity" - with no course or seat assignment, and the complete order-level set under More: "Add Note", "Copy", "Split", "Discounts", "Extra Charge", "Hold", "Clear Order", "Taxes". The one hold Slice ships is whole-order and releases on tender, not on demand per course: "Hold - Saves the order in Order Management In Progress. The order will not print to the kitchen until it is paid for or sent." Firing time is likewise whole-order and binary - Owner's App (web) > Register > Printer Settings offers exactly two Print Modes, "Incremental: Prints as items are ordered" and "After Payments: Prints only after full payment has been accepted". There is no expo screen to fire from: Slice ships no KDS ("Discounted kitchen displays & kiosks (coming soon)"). "course", "coursing" and "fire" occur zero times across all 101 first-party articles - 45 Knowledge Hub, 30 release notes, 26 FAQs - re-pulled from slice.com/wp-json/wp/v2/ on 2026-08-08. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08 adversarially verified
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
Re-evidenced 2026-08-08 on a field enumeration rather than on silence. Owner's App (web) > Menu (updated April 9, 2026) enumerates every field on the New Item page - Item type ("Build your own pizza" / "Regular menu item"), Item details (Name, Display name, Kitchen name, Category, Description, Photo), modifier groups, "Sizes and pricing", Options (Loyalty reward, Item available online, Item available on Slice Register, house favorite, Contains alcohol, Discount ineligible) and "Register printing" (Customer receipt / Kitchen) - and there is no cook-time or prep-time field anywhere on it. The only prep timing Slice exposes is order-level and manual: Owner's Portal > Time Management > ETA sets shop-wide defaults where "Delivery and pickup ETAs are set separately" and "Manually adjusting the ETA for a specific order in the Register will override the default ETA only for that order", and Register > Settings > Order Settings offers "Custom ETAs for Online Orders: Allows your shop to adjust prep times in one- or five-minute increments when confirming Slice Online Orders. Pickup ETAs must stay between 10 and 90 minutes, and delivery ETAs must stay between 20 and 120 minutes." There is also no display to stagger onto - Slice ships no KDS ("Discounted kitchen displays & kiosks (coming soon)") and kitchen output is a thermal ticket that prints once, in Incremental or After Payments mode. "cook time", "prep time", "stagger" and "pacing" occur zero times across the 101 first-party articles re-pulled from slice.com/wp-json/wp/v2/ on 2026-08-08. https://slice.com/knowledge-hub/owners-app-web-menu/ · retrieved 2026-08-08 adversarially verified
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
Only manual Pause with a timer and manual ETA editing. No load-triggered automatic pacing. https://slice.com/knowledge-hub/register-shop-status/ · retrieved 2026-08-01
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
Explicit: 'Pausing or closing orders affects Slice online orders and Slice Phone orders—third-party orders will not be impacted.' https://slice.com/knowledge-hub/register-shop-status/ · retrieved 2026-08-01
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
Slice 'does not have a way to communicate back to those providers'. No order-ready event reaches DoorDash/Uber Eats. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-08-01
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Corrected 2026-08-08: the old rationale 'No KDS, therefore no bump bar' rested on a premise that is refuted as stated - Slice does advertise kitchen displays, but as unavailable: the Family Membership benefits list reads 'Discounted kitchen displays & kiosks (coming soon)'. That is a stated limitation, not silence, and it is what carries the no. Consistent with it, the Slice Register product page's included-hardware answer names 'an iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader' - no display and no keypad - and 'bump' occurs zero times across the 45 Knowledge Hub articles, 30 release notes and 26 FAQs pulled from the WP REST API on 2026-08-08, so no supported bump-bar models are documented anywhere. Re-check when the 'coming soon' displays ship. https://slice.com/family-membership/ · retrieved 2026-08-08 adversarially verified
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Re-evidenced 2026-08-08. The claim is about an all-day view on the station, and no station display ships: Family Membership lists "Discounted kitchen displays & kiosks (coming soon)" and the Slice Register included-hardware answer is a closed list - "iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader" - with no display. Station output is a printed ticket per order. On the Register itself, Order Management is enumerated as the "central hub for handling all incoming and active orders" with exactly three status tabs - "Scheduled", "In Progress", "Complete" - and bottom filters "To Go, Delivery, Pickup, Dine In"; every view is order-by-order, none aggregates outstanding quantities per item or per modifier. "all day" and "all-day" occur zero times across the 45 Knowledge Hub articles retrieved from the WP REST API on 2026-08-08. https://slice.com/knowledge-hub/register-order-management/ · retrieved 2026-08-08 adversarially verified
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
Re-evidenced 2026-08-08. The entire per-station configuration surface is enumerated in Owner's App (web) > Register > Printer Settings - "Create New Setting: Add a new printer setting to direct menu items to specific prep stations", with fields "Name", "Print Modes" (Incremental / After Payments) and "Print Quantity" - and it holds no target time, no colour escalation and no audible alert. The station-display alternative is closed by Slice's own wording: Family Membership lists "Discounted kitchen displays & kiosks (coming soon)", i.e. not available, and the Register included-hardware answer names no display. "cook time" occurs zero times across the 45 Knowledge Hub articles pulled from the WP REST API on 2026-08-08. The only alerting Slice documents is on intake (scheduled-order banners at two hours and one hour, New Order Alert Sound in Register Settings), which is not per-station cook-time escalation. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08 adversarially verified
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Re-evidenced 2026-08-08. Register Settings > Receipt Settings enumerates the whole printer surface - "Receipt Printers: Discover, install, rename, delete, and test receipt printers" - and Owner's App (web) > Register > Printer Settings offers only "Create New Setting" with "Name", "Print Modes" and "Print Quantity". No device is designated as a backup and no automatic re-route exists; the documented remedy for a printer that does not produce a ticket is manual - check paper, re-select the Epson TM-m30III, print a test page - plus Order Management's manual reprint of an In Progress order. The screen half of the claim is closed by Slice's own statement that displays are not available: Family Membership lists "Discounted kitchen displays & kiosks (coming soon)", and the Register included-hardware answer names no display. "backup printer", "failover" and "fail over" occur zero times across the 45 Knowledge Hub articles retrieved from the WP REST API on 2026-08-08. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-08-08 adversarially verified
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
Re-evidenced 2026-08-08. The prior `unknown` rested on treating KDS existence as unsettled; it is settled in the other direction. Slice's own Family Membership benefits list reads "Discounted kitchen displays & kiosks (coming soon)" - a vendor statement that the surface is not available yet - and the Slice Register product page answers "What hardware is included with Slice Register?" with a closed list: "iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader". No display device ships, so no KDS can continue to receive and display tickets during an outage. Corroborating: "kitchen display" and "KDS" occur zero times across the 45 Knowledge Hub articles pulled from the WP REST API (epkb_post_type_1) on 2026-08-08, and the only documented kitchen output is print ("Moving the order will trigger printing from both the customer receipt printer and the kitchen printer"). This is a `no` about the claim's subject, not about outage behaviour, which remains undocumented separately. Re-check when the "coming soon" displays ship. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-08 adversarially verified
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
Kitchen tickets are customizable (font, item order, additional information) and items carry a distinct 'kitchen name'. Ticket-level detail only; no build/assembly screens. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-08-01
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
Slice Register kitchen tickets set half-placed toppings apart as their own lettered lines. The Owner’s Portal kitchen-ticket template preview (thermal and impact) prints each pizza topping as its own list: "R" Onions, "W" Pepperoni, "L" Capers. A setting in the same form, "Display whole (W) modifier", turns the W marker on or off. Shortfall: the only placements are LEFT_HALF and RIGHT_HALF plus whole, so there are no quarters or sections. The marker is a letter prefix, not a pie or column graphic. The evidence is the Portal’s built-in mock ticket, not the Register’s print code or a captured ticket. No KDS surface is shown. https://owners.slicelife.com/_next/static/chunks/2uwqhg6bmkr3v.js · retrieved 2026-09-15 adversarially verified
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Order Management (updated April 30, 2026) documents a manual whole-ticket reprint: 'Print : Print a receipt or kitchen ticket for an In Progress order if your Register app is connected to a printer', and 'Moving the order will trigger printing from both the customer receipt printer and the kitchen printer.' Shortfall, restated 2026-08-08 without the earlier 'no KDS' framing: the action is order-level and is offered only while the order is In Progress ('Orders stay In Progress until they are manually moved to Complete'), there is no recall of a ticket already sent and no way to refire a single item - 'reprint', 'refire' and 'bump' occur zero times across the 45 Knowledge Hub articles, 30 release notes and 26 FAQs retrieved from the WP REST API on 2026-08-08. Reprinting the whole ticket is the documented substitute for both. https://slice.com/knowledge-hub/register-order-management/ · retrieved 2026-08-08 adversarially verified
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
Re-evidenced 2026-08-08. Kitchen output at Slice is paper only: the Family Membership benefits list reads "Discounted kitchen displays & kiosks (coming soon)" and the Slice Register included-hardware answer is a closed list - "iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader" - with no display, so there is no live ticket to flag. The full print-routing surface is enumerated in Owner's App (web) > Register > Printer Settings: "Create New Setting", "Name", "Print Modes: Incremental / After Payments", "Print Quantity", plus edit/delete. Nothing sends a change notice, and "reprint" and "refire" occur zero times across the 45 Knowledge Hub articles retrieved from the WP REST API on 2026-08-08. An incremental-mode printer prints newly added items as separate lines, which is not a visual flag of added/changed/removed items on a live ticket. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08 adversarially verified
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
Re-quoted 2026-08-08 - the page was rewritten (modified 2026-06-15) and the old citation's wording no longer appears. It now reads: 'Do my customers get order tracking? Yes. Customers get an order confirmation by text and via the Slice app, and can track their order's progress in real time in the app.' Included, no separate purchase, so partial. Shortfall, restated without the earlier 'no KDS bump event' framing: this is a Slice-channel notification tied to order placement and in-app status, and nothing ties it to the shop marking food ready. Register has no ready state to trigger it - Order Management's statuses are Scheduled, In Progress and Complete, 'Orders stay In Progress until they are manually moved to Complete' - and the word 'ready' occurs zero times in the 30 release notes and 26 FAQs pulled from the WP REST API on 2026-08-08. Counter and phone orders entered on the Register are outside the Slice-app channel this describes. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-08 adversarially verified
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Slice's stock feature is availability, not inventory: an item or a single size is flagged in or out of stock for 12 or 24 hours or indefinitely, so there is no quantity on hand for a waste entry to deplete, no reason-code capture, and no Slice kitchen-display product to log at since kitchen displays are marked '(coming soon)'. https://slice.com/knowledge-hub/owners-app-web-menu/ · retrieved 2026-09-06 adversarially verified
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
VERDICT moved to no. The prior note's blocker was that the documented reporting surface was open-ended by construction ('various financial and sales reports', 'including:', 'such as:'). The shipped app is not open-ended. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) enumerates the report product exactly: `reports.tabs.*` = Orders, Order activity, Sales mix reports, Sales summary, Tax reports, Credit card payments, and each has a `createModal` whose entire input set is a date range, a time range (All day or Shift hours), a sales channel (All / Online / Register) and an order type - there is no station, no daypart and no percentile input, and no timing report exists. `analytics.tabs.*` is closed at Orders and Customers, whose tiles are Sales by day, Top selling, Least selling, Your customers and Delivery & pickup. The nearest timing objects in the whole app are operator-entered ETAs (`eta.*`) and the auto-complete timer (`register.automations.autoComplete.description` = 'Automatically move paid orders to Complete after a set time'), neither of which measures or reports actual elapsed ticket time. BOUND/CONTROLS over the 7.33 MB corpus, tokenised word-boundary: `speed of service` 0, `ticket time` 0, `prep time` 0, `cook time` 0, `daypart` 0, `percentile` 0, `station` 0 (`stations` 4, all `register.printerTemplates.kitchenForm.displayOtherStations` = 'Display other stations', a print-routing label, not a timing dimension). Bound: the Owner's Portal reporting product; Slice's public API is not covered by this corpus. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 adversarially verified
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
CLAIM: generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list. VERDICT: no (moved from unknown). EVIDENCE: forecast 0, forecasting 0, 'prep list' 0, 'par level' 0, predicted 0, projection 0, daypart 0 word-boundary hits in the 116-document census. 'prep' occurs only as 'prep time' / 'estimated prep times' (the ETA shown to the customer) and in the scheduled-order alert ('You will receive an alert 1 hour before the prep time'). The kitchen-facing output Slice documents is a printed per-order Kitchen Ticket ('Kitchen Tickets only display items and relevant kitchen details by default'), never a daily prep sheet. The Owner's App (web) report set is enumerated closed in the Financials article - Order Activity, Orders, Tax, Sales Mix, Sales Summary - and every one is backward-looking. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/owners-app-web-analytics/ · retrieved 2026-09-18 adversarially verified
Delivery, dispatch & third-party channels
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
Downgraded from yes on independent retrieval of the Driver App article, which no earlier pass cited. Drivers are app logins, not first-class entities the operator administers: 'contact Slice Support at (888) 974-9928 to add your driver's login to your account. Each driver needs a unique email address.' Assignment state is one binary toggle — 'Tap the Available toggle to receive batch assignments... Drivers must be logged in and marked Available to be assigned' — not in-store / on-run / returning. Shortfall: no operator-managed roster, no driver clock-in/out or shift concept anywhere in the Driver App article, and per-driver history exists only as the Delivery Management Report's batch settlement. https://slice.com/knowledge-hub/register-slice-driver-app/ · retrieved 2026-08-02 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
Upheld on my own retrieval. The four sections are as described — Unassigned, Awaiting, In progress, Delivered — driver selection is real ('tap the arrow to open the list of active drivers and select the driver for the batch'), and sequencing is explicit ('The order in which you select the deliveries sets the delivery route'). The in-progress view shows which orders were delivered, the time each was delivered, and the driver's location. A genuine native dispatch surface, not marketing. https://slice.com/knowledge-hub/register-delivery-management/ · retrieved 2026-08-02 adversarially verified
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
Live map with geocoded stops and an editable delivery sequence, but the sequence is operator-set ('Change the sequence') — no system-generated route optimization is documented. https://slice.com/knowledge-hub/register-delivery-management/ · retrieved 2026-08-01
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
Downgraded from yes; a differentiator held to the highest bar. The dispatch article surfaces 'The driver's current location on the map' with no refresh cadence, and the Driver App article documents GPS only in the driver's own direction — 'Tap Start Navigation to use GPS directions to the customer' — never as position reported back to the shop. The only feature Slice describes as real-time tracking belongs to its outsourced couriers: the release note Track Slice Delivery Drivers in Real Time covers 'your Slice Delivery driver's progress... real-time updates like driver name, status, and estimated timing'. Shortfall: continuous in-house driver GPS with a stated update interval is not documented. https://slice.com/knowledge-hub/register-slice-driver-app/ · retrieved 2026-08-02 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
The zone FAQ states the geometry directly: 'Your delivery zone is the distance where you will fulfill delivery orders. To guarantee accuracy, we work with you to DRAW a virtual delivery zone around your neighborhood or city. You can have multiple delivery zones with multiple different delivery fees/minimums.' A drawn zone around a neighborhood is not a radius and not a postcode list, and multiple zones are supported. Named shortfalls: it is not operator-configurable at all - 'Call (888) 974-9928 to add or edit delivery zones' - so there is no map editor in the Owner's App (web) or the Register; the FAQ never says the shape is an arbitrary polygon rather than a bounded neighbourhood selection; and drive-time isochrones are not offered in any form. https://slice.com/?echo_kb_faq=what-is-my-delivery-zone-and-how-do-i-edit-it · retrieved 2026-08-08
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
Two of the three per-zone attributes are documented, and automatic application from the address is documented separately. The zone FAQ: 'You can have multiple delivery zones with multiple different delivery fees/minimums.' Order Entry, on taking a delivery order: 'If you have delivery fees configured for Slice Online Ordering, they will be automatically applied based on the address' - with a per-order override by 'tapping the pencil icon next to the fee amount'. Named shortfalls: there is no per-zone promise time - ETAs are shop-wide, set in Owner's App (web) or adjusted per order on the Register within global bounds ('Pickup ETAs must stay between 10 and 90 minutes, and delivery ETAs must stay between 20 and 120 minutes'), never per zone; and neither fee nor minimum is operator-editable, since both the zone FAQ and the fee FAQ route the change to Slice ('We can update these for you - contact (888) 974-9928 for support'). https://slice.com/?echo_kb_faq=what-is-my-delivery-zone-and-how-do-i-edit-it · retrieved 2026-08-08
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
The Register order-entry article documents the whole flow for a delivery order. Geocoding at order time: 'Address Line 1 uses GOOGLE MAPS to suggest nearby addresses for accuracy' and 'The system will auto-fill city, state, and ZIP code.' Zone evaluation before the order is accepted: 'If you have delivery fees configured for Slice Online Ordering, they will be automatically applied based on the address' and 'If the address is OUTSIDE YOUR SLICE ONLINE DELIVERY ZONE, YOU WILL BE NOTIFIED but allowed to proceed.' That satisfies the claim as worded, which asks for rejection OR flagging - Slice flags, on the customer screen, before the items are entered and the order submitted. Reader caveat: the flag is advisory rather than blocking, and it is deliberately so, since a shop may choose to deliver outside its online zone on a phone order. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
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 Delivery Management Report captures cash collected, credit-card payments, tips and cash settlement per driver. Shortfall: no per-delivery or mileage-based driver pay is computed, no reimbursement rate is configurable, and the Driver App article documents no mileage capture, so nothing feeds a payroll figure. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-02
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
Upheld on my own retrieval of the Cash Management article. The Delivery Management Report settles each driver: 'Total amount', 'Cash collected', 'Credit card' with a nested tips line, 'Delivery fees', and 'Cash due to driver' — computed by comparing cash collected against card tips, so the shop pays the difference when tips exceed cash and the driver returns the surplus when cash exceeds tips. That is a settle-up flow, not merely a report of takings. Caveat: no explicit over/short variance figure per driver. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-02 adversarially verified
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
Upheld; I re-retrieved the page and the sentence is intact: 'If you are using Flex Delivery, you can also choose to assign a delivery to your selected Slice Delivery provider, Uber or DoorDash.' The same page adds 'Simply select that option, tap Reassign Delivery, and we will send an outsourced driver', and Register Settings carries the toggle 'Outsource delivery orders: Toggle this setting on to have our partners deliver your Slice orders'. Caveat retained: the per-delivery courier cost is published nowhere, and the handoff covers Slice-channel orders, not marketplace orders. https://slice.com/knowledge-hub/register-delivery-management/ · retrieved 2026-08-02 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
Register Settings has a Flex Delivery toggle to 'switch between using your in-house drivers and our delivery partners' and dispatch allows per-order assignment to Uber/DoorDash. Automatic rules (no driver available / out of zone / wait threshold) are not documented. https://slice.com/knowledge-hub/register-settings/ · 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
'Integrates with 30+ delivery apps including DoorDash, Grubhub, and Uber Eats' with no separate tablet. Slice never states whether these are first-party certified or middleware-brokered, and Slice is absent from DoorDash's 2026 Preferred Integration Partner list. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-01
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
Upheld on my own retrieval. Marketplace orders 'appear in their own column on the New Orders page', are confirmed with a tap or automatically — 'enable Auto-Confirm Orders so they go straight to the kitchen as soon as they arrive' — and Register Settings confirms auto-confirm 'allows Slice and third-party orders to be automatically confirmed', with automatic kitchen-ticket printing for online and third-party orders. No tablet farm, no re-keying. Inbound injection is the one direction of this integration that works. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-08-02 adversarially verified
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
Item availability cannot reach the marketplaces: Slice 'does not have a way to communicate back to those providers'. Stock toggles affect Register and Slice online only. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-08-01
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
Upheld; positive evidence of absence re-retrieved verbatim: 'Pausing or closing orders affects Slice online orders and Slice Phone orders—third-party orders will not be impacted.' Pause 'temporarily stops receiving pickup, delivery, or both for a set time' and Close stops orders for the remainder of the day, but neither reaches the marketplaces — the operator must still pause each one in its own portal. https://slice.com/knowledge-hub/register-shop-status/ · retrieved 2026-08-02 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
Slice separates third-party sales but never reconciles them to a marketplace payout. The Register Sales Summary Report's Third-Party section is enumerated in full and holds three lines: 'Total Order Sales', 'Total Tips' and 'Average Order Value', prefaced by 'All Third-Party Orders are prepaid.' The Owner's App (web) statement and report set is likewise enumerated column by column - Statement Summary, Transactions CSV, Order Activity, Orders, Tax, Sales Mix, Sales Summary - and every fee line in it is a SLICE fee (Card Processing Fees, Slice Partnership Fees, Slice Delivery Fees, Phone Order Fees, Register Subscriptions, Chargebacks). No marketplace commission, marketing fee, marketplace payout deposit, or missing/unpaid-order line appears anywhere, and none could: Slice states the integration is one-way - 'Slice receives the Third-Party orders but does not have a way to communicate back to those providers' - so it never sees DoorDash or Uber Eats remittance data. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-08
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
CLAIM: vendor exposes integration health to the operator - failed/rejected order injections, connection status per channel, and alerts on failure - rather than failing silently. VERDICT: no (moved from unknown). EVIDENCE: Slice's own third-party article documents the opposite of a health surface. It warns 'Do not edit third-party menus directly - this will break the integration and cause service interruptions', and it closes the loop-back direction: 'Slice receives the Third-Party orders but does not have a way to communicate back to those providers.' Two adjacent surfaces exist and neither is the claim: Register > Settings offers 'Slice Support: View your Connection Status to confirm your Register is online and connected' - the iPad's own link to Slice, one boolean, not per-channel integration health - and Owner's App (web) > Settings has 'Point of sale integrations. This is where you connect or manage your point of sale integrations with Slice. Available integrations include Square, Clover, and Facebook. This section is used only to manage those connections.' CONTROLS: 'integration health' 0, 'failed order' 0, injection 0, retry 0, webhook 0, 'error log' 0 in all three corpora; all 10 'alert' hits are the New Order Alert sound/pop-up or the scheduled-order banner, and the only 'reject' is the OPERATOR rejecting an order with a reason. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-09-18 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
'Real-time order tracking via text and app' for Slice-channel orders. Whether the tracking page sits on the restaurant's own domain, and whether it reflects live driver state for in-house drivers, is not documented. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01
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
Promise times are manually set prep-time ETAs editable in 1- or 5-minute increments, with 15-minute slot laddering. No dynamic adjustment from kitchen load or driver availability is documented. https://slice.com/knowledge-hub/register-shop-status/ · retrieved 2026-08-01
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
CLAIM: vendor documents explicit offline behavior for delivery - whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage. VERDICT: no (moved from unknown). EVIDENCE: Slice documents offline behaviour for exactly one thing, and delivery is not it. Annex 3 (Slice POS Terms), 'Offline Transactions': 'Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline. Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored ... offline transactions may not exceed $100 per transaction. Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register and/or Slice Standalone Payments is offline.' The strings 'Slice Delivery' and 'Driver' score 0 hits in that entire 177,854-character agreement, so the contract's offline provision cannot be read onto dispatch. The Driver App article documents a wholly connected flow - batches assigned to the driver, 'tap Start Navigation to use GPS directions', a Bluetooth card reader that must be 'updated to the latest version' before use, 'Confirm Delivery' - and states nothing about connectivity loss; Slice Delivery and Delivery Management say nothing either. 'outage' scores 0 in all three corpora. The nearest Slice gets is the FAQ 'How do I reconnect to Wi-Fi if I'm having internet issues?', a manual recovery procedure. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-18 adversarially verified
Digital ordering & guest-facing channels
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
Downgraded from yes: the evidence was the pricing page, and the 'own branding/domain' half of the claim is undocumented. The Website Tools article describes a Slice-hosted, Slice-controlled site — the operator picks 'font and background color that best represent your shop' and edits the tagline and 'Our story', but designs are set by Slice's team and a different one must be requested from support — plus Smart Buttons, Smart Popups and 'a direct URL to your shop's menu for seamless online ordering' to paste into a site the operator runs elsewhere. Shortfall: connecting a custom domain is documented nowhere, the template is not operator-controlled, and ordering carries a per-order charge ($2.00/order Family, $3.00/order Online, waived under $10) in place of a percentage commission. https://slice.com/knowledge-hub/owners-app-web-website-tools/ · retrieved 2026-08-02 adversarially verified
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
Verified verbatim and stronger than cited: 'This means you get the benefits of having an app, without the cost or work of building your own.' Slice explicitly positions the shared marketplace app as the substitute for a branded app. https://slice.com/products/slice-app/ · retrieved 2026-08-01 adversarially verified
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
Downgraded from yes: the cited source does not support the payment half of the claim. The Register customer article documents editing 'their name, phone number, or address', that 'All Slice Online Customers are already in the system', search by phone as 'the most unique identifier', and order history with a 'Reorder button in the top right to place the same order' — and says nothing about stored cards. Saved payment survives only as a marketing bullet on the online-ordering page ('Saved payment accounts for repeat customers'), the same grade-D evidence on which this record already scores payments-card-on-file partial. Shortfall: no documented tokenization and no documented card reuse at the Register. https://slice.com/knowledge-hub/register-customer-management/ · retrieved 2026-08-02 adversarially verified
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
'Built-in upsells' claimed. No configuration model and no attach-rate reporting documented.
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
Scheduled orders supported with 15-minute slot laddering off the configured prep time. No per-slot capacity limits or automatic slot closure when saturated. https://slice.com/knowledge-hub/register-shop-status/ · 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
Marketing-page-only evidence, and it conflicts with product documentation: the Register docs define dine-in as counter-service orders that 'do not require customer information', with no table or check object. Pickup and delivery are documented; curbside and QR dine-in are claim-level with no supporting Knowledge Hub article. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01 adversarially verified
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
The only QR statement on the retrieved page is 'you can place ordering links on social pages or QR codes on menus, pizza boxes, or signs' - a marketing-grade deep link into the shop's Slice online-ordering page, which a guest could scan at a table. The named shortfall: it opens a new online order, never an existing check. Order Entry enumerates the Register payment surface as closed - 'There are three ways to pay for an order: Card, Cash, and Other' - all cashier-initiated, with tipping taken on the shop's card reader and the three split modes ('Split payment evenly', 'Pay custom amount', 'Pay total owed') driven from the iPad. No guest-facing scan-to-pay, split or tip against an open check. Earlier notes citing 'curbside and dine-in QR' from this page are withdrawn: neither phrase appears on it. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-08
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
Slice marks kiosks '(coming soon)' on its own top-tier Family Membership benefit table - the vendor's statement that a kiosk is not yet available even to its highest tier - so there is no shipping self-order kiosk running the POS menu, let alone documented ADA UI or unattended EMV. https://slice.com/family-membership/ · retrieved 2026-09-06 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
325th: THE SURFACE THE 324th NOTE ASKED FOR IS NOW CENSUSED, and it closes the cell. CLAIM: 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. VERDICT: no. EVIDENCE/BOUND: the Slice CONSUMER ordering SPA at slicelife.com was taken to a webpack chunk-graph fixpoint. The entry bundle app-8ec7206a-bundle.js carries the loader table `__webpack_require__.u` with 33 chunk NAMES and 148 chunk HASHES; 40 bundles are preloaded in the document. Crawled in 2 rounds: 152 JS files, 4,207,259 bytes, 0 fetch failures, 0 outstanding references - every one of the 150 `r.e(<id>)` chunk ids in the whole corpus resolves to a file I hold except ids 472, 3306 and 4065, which have no JS hash and are the three CSS-only chunks named in the document's stylesheet list. The route/component enumeration is the whole consumer app: pages-HomePage, MenuPage, CheckoutPage, OrderConfirmationPage, SearchResultsPageV0, SignInSignUpPage, UserAccount(+Edit/NewAddress/PaymentEdit), RestaurantPromoCodePage, StripeRedirectPage, NotFoundPage, UnderMaintenancePage, plus containers/components ProductModal, OtherShopCartModal, ShoppingCart-DeliveryMethodModal, ShoppingCart-DeliveryPreferenceModal, Checkout-OrderDetailsSummary-ContactDetailsModal, SignInSignUpModal, ThreeDSecureModal, FeeModal, DealsModal, LoyaltyModal, AppDownloadQRModal, DebrandedShopDetailsModal, SupportModal, ShopHeader-ShopHoursModal, ShopHeader-ShopPhoneCtaModal. TOKENISED, word-boundary, case-insensitive controls over the 4.2 MB: `group order` 0, `groupOrder` 0, `group_order` 0, `shareable` 0, `share link` 0, `shareLink` 0, `participant` 0, `invite` 0 (stem `invit\w*` 0 across the whole corpus), `spend cap` 0, `spendLimit` 0, `cart link` 0, `split the bill` 0, `splitBill` 0. POSITIVE controls prove the corpus holds the checkout vocabulary rather than being the wrong corpus: `subtotal` 46, `tip` 53, `promo` 11, `giftCard` 190, `loyalty` 117, `Rewards` 38, `pizza points` 3, `apple pay` 8, `googlePay` 15, `cutlery` 4, `utensils` 1 - and the bundle ships the checkout copy inline as an English string dictionary, e.g. noPlasticTitle: 'Don’t send plastic cutlery' / noPlastic: 'We’ll let the restaurant know not to include plastic cutlery.' The ONLY sharing primitive in the app is a shop-page link copy, not a cart: `misc.shareButton.label` with `misc.shareButton.linkCopiedToast` calling navigator.share({title:document.title,url}) else navigator.clipboard.writeText, instrumented as trackClickedShareButton -> clicked_share_button {page_name, click_location}. POISON FOUND AND NAMED: `group` alone has 86 hits and is never group ordering (groupedProducts = menu categories' product groups, groupBy, console.group/groupEnd/groupCollapsed, CSS group__input/group__label); `split` has 218 hits, all String.prototype.split; `share`-stem hits are shared/sharedNodes/SharedArrayBuffer/isShared; and `participantes`/`participants`/`participante` (5 hits) are ADYEN'S SPANISH, FRENCH AND PORTUGUESE LOCALE TABLE for a click-to-pay cookie checkbox ('en las tiendas participantes'), the same class of trap as the Andorran-peseta `ADP` - an untokenised English search on 'participant' would have looked like a hit. Taken with the 324th's operator-side fixpoint of owners.slicelife.com (21 chunks, 7.33 MB, 3,974 i18n keys, `group order` 0) and the 45-article Knowledge Hub whose two checkout walkthroughs describe one cart and one payer, both sides of the product are now bounded and neither holds a multi-participant cart. Retrieved 2026-09-17. https://slicelife.com/sf2/public/app-8ec7206a-bundle.js · retrieved 2026-09-17 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 order support' claimed. No separate catering menu, lead-time rules, quotes, deposits, or invoice/ACH terms documented. https://slice.com/products/online-pizza-ordering-system/ · 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
Slice Phone uses live human agents by design — 'No AI, robots, or chat bots — fully human support'. No AI voice partner is named. https://slice.com/support/24-7-365-customer-support/ · 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
Slice's voice-ordering product is a staffed human call centre rather than an automated agent, and the same page equates its order types with phone, online and walk-in, so there is no lane for an AI voice agent to sit in and no escalation handoff to document. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-09-06 adversarially verified
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
Text-a-link branch only, read from served code rather than a documented feature. Slice's storefront bundle (368,420 B, sha256 22e9a6a42c5d075b..., re-fetched 2026-09-15) reads utm_campaign from the landing URL, and at byte 350779 has: const t="sms_quick_reorder_prompt"===s?"teleflow_sms_quick_reorder_prompt":"";e.setItem("attribution_source",t). A stored attribution is overridden unless it is already the teleflow value (@350654). The web order payload at @250089 carries it: {placed_via:"web",...,attribution_source:P(),...}. The campaign constant is exported at @132620. That campaign is not in the direct list [partner_websites, order_now_button, direct_websites], so such orders are tagged 'marketplace'. The SMS itself is inferred from the campaign name. The bundle does not show the message text, who sends it, or any operator control. No text-to-order: 'text to order' and 'reply' have 0 hits in the bundle, and the storefront dictionary has none either. The bundle's other SMS strings are order-update opt-in (@135456) and marketing consent (@141753). Owner's Portal 'reply' strings are review replies only. That the order reaches the Register rests on the record's online-ordering flow, not on this bundle. https://slicelife.com/sf2/public/app-da4cd548-bundle.js · retrieved 2026-09-15 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
Downgraded from yes under the differentiator grade floor. The only source is a vendor feature page written to sell, with no configuration steps and no Knowledge Hub counterpart: 'It's the Order Online button on your GBP listing. We make sure it links to a direct ordering channel — not a third-party app', and Slice 'manages your Google Food Ordering (GFO) so Google orders go directly to your own ordering link, not third-party marketplaces that take a cut'. Shortfall: the 'Preferred by Business' designation the claim names appears nowhere on the page, the provisioning mechanism is undocumented, and the operator holds no configuration surface — Slice claims and manages the listing on their behalf. https://slice.com/products/google-business-profile/ · 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
Listings claimed across 'Google, Apple, Bing, OneBite, and TripAdvisor'. Whether an Apple Maps 'Order Food' custom action is provisioned is not stated. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01
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
The loyalty program is Slice's marketplace-wide diner program, not the operator's. The Slice App page gives the shop no configuration surface and never states who funds the free pizza, whether points are portable to the shop's own channels, or whether the operator can see or adjust a balance. A vendor-run diner loyalty scheme the operator cannot configure is not a 'yes' on native loyalty attach. https://slice.com/products/slice-app/ · retrieved 2026-08-01 adversarially verified
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
VERDICT moved to no. The prior pass resolved the vocabulary (every merchant-side 'subscription') but had no enumeration of the guest-facing programme; the shipped app supplies one. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) enumerates the operator's entire guest-offer toolset as two closed namespaces - `loyaltyRewards.*` (Pizza Points: points per $1, expiry in months, milestone rewards, nothing else) and `specialOffers.*` whose tab/tile set is Campaigns, Deals, Promo codes, Automatic online discount and Register discounts. No recurring charge, no paid tier, no delivery-fee waiver and no per-period entitlement exists in either. BOUND/CONTROLS over the 7.33 MB corpus, tokenised: `membership` 0, `recurring` 0, `billing cycle` 0, `paid tier` 0. POISON NAMED: `subscription`/`subscriptions` score 8 and not one is a guest programme - they are the GraphQL operation-type regex `/^\s*(query|mutation|subscription)\b/i` in the Datadog RUM plugin and React Aria's internal `this.subscriptions = new Set`; `renewal` scores 3 and is Datadog RUM's `SESSION_RENEWAL` constant. Bound: the Owner's Portal, i.e. what the operator can configure; Slice's consumer app screens are not in this corpus. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 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
Promo codes support fixed or percentage discounts, order minimums, usage limits, date ranges and channel selection; an Online Discount applies to all online orders. Identical honoring at the Register is not documented. https://slice.com/knowledge-hub/owners-app-web-marketing/ · 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
The Profiles page holds 'a detailed database of your customers' with 'name, address, email, phone number, creation date, and the date of the most recent order', and its Import and Export section documents both directions: 'Import: Add your customer database from another system, with a maximum of 10,000 customers per import. The file must be a CSV...' and 'Export: Download your Slice customer database for further analysis or record-keeping.' No fee, ticket or approval is mentioned. Shortfall: no consented marketing status field exists in the documented profile or export (Slice sends the email and push campaigns itself per knowledge-hub/owners-app-getting-started/), the export's column set and format are not stated, order history is only available as a separate order-level CSV under Financials > Reports, and no merchant terms page addresses ownership - the published consumer ToS still grants Slice a 'world-wide, perpetual, irrevocable, royalty-free' content license. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-08-08
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
Slice hosts the entire digital checkout: knowledge-hub/online-ordering-slice-app/ states 'All payments are processed through the Slice App checkout', and the shop website is built and published by Slice itself (knowledge-hub/owners-app-web-website-tools/), so card entry never occurs on a page the restaurant controls. The security FAQ says Slice 'partners with industry-leading payment processors to ensure all transactions are secure and encrypted' and that payment information is 'never shared or stored beyond what's necessary to complete the transaction'. Shortfall: nowhere on slice.com does Slice publish a PCI DSS 4.0 compliance statement or AOC, say anything about the client-side script-integrity requirements effective March 2025, or mention 3DS / SCA; the FAQ names no processor and no standard. https://slice.com/?echo_kb_faq=how-secure-are-payments · retrieved 2026-08-08
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
The Sales Summary and Order Activity field lists document the fees as live objects: 'Credit Card Surcharge - A fee charged when a customer pays with a credit or debit card', 'Service Fees - Fees collected from customers for Register and Online orders', 'Cash Discounts - Discounts applied to orders paid in cash', and 'non-cash adjustment fees' folded into Dining Option and Gross Sales; the Order Activity report counts them separately ('Credit Card Surcharges: Total surcharges applied to credit card transactions', '# of Credit Card Surcharges Collected'). Service fees are explicitly reported for both channels. Shortfall: the surcharge is reported but never configured in any documented screen - it appears in no Owner's App (web) settings article, the Register Settings and Owner's App (web) Register articles expose only tips, discounts, printers and profiles, and Slice publishes nothing on the guest-facing surcharge disclosure, on states where surcharging is prohibited, or on debit-card and card-brand exclusions. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-08
Guest data, loyalty & marketing
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
'All Slice Online Customers are already in the system'; Register staff search by phone ('the most unique identifier') and can attach a profile to a dine-in order. Dedup/merge behavior is not documented. https://slice.com/knowledge-hub/register-customer-management/ · 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
The Customers dropdown 'provides detailed customer information for your Slice online and Register orders'. Its filter options are the whole configurable surface and exclude marketplaces: Analytics lets you 'filter by Register customers, Online customers, or both', and Segments shows 'all online and register customers who ordered in the last 30 days' with a filter of 'All Customers or Online + Register'. Profiles is described the same way. Meanwhile knowledge-hub/register-third-party-orders/ says third-party orders arrive in their own column and 'Slice receives the Third-Party orders but does not have a way to communicate back to those providers.' DoorDash, Uber Eats and Grubhub orders therefore do not attach to a Slice guest profile - they are not part of the customer database at all. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-08-08
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
One model only: points per order toward free pizza. Visit/punch and spend-tier accrual are not documented, and the program is Slice-wide rather than shop-configured. https://slice.com/products/online-pizza-ordering-system/ · retrieved 2026-08-01
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Customers > Analytics defines an automatic three-band classification on a rolling window: 'New Customers: First-time buyers. Repeat Customers: Customers who ordered less than three times in the last three months. Loyal Customers: Customers who ordered more than three times in the last three months.' Membership recomputes as the window moves, so guests are promoted and demoted without operator action, and the label is carried on the Top 10 Customers list, the Segments table and the end-of-day report. Shortfall: the bands are fixed and not configurable (no threshold, spend basis or additional tier can be set), they are analytics segments only - no entitlement, discount or benefit attaches to a tier, and the status is never shown to the guest in the Slice App or on the shop website. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-08-08
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
CLAIM: documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). VERDICT: no (moved from unknown). EVIDENCE: the only offline behaviour Slice documents anywhere is the card-transaction queue in Annex 3 ('Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored'), scoped to 'point of sale activities' and to authorization. Loyalty scores 10 word-boundary hits in the whole 116-document census and every one is either the Menu item flag 'Loyalty reward - Makes the item eligible for loyalty rewards' or the Slice App line 'Coupons and loyalty points, which update automatically when you add offers in the Owner's App' - i.e. loyalty is a cloud-maintained marketplace construct. No article, release note or FAQ states whether lookup, accrual or redemption is blocked or queued during an outage. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-18 adversarially verified
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
The Register Discounts page lists each discount's Discount Details as 'Code', 'Amount', 'Combinable: Indicates whether the discount can be used with other discounts' and 'Start and End Dates' - an explicit exclusive-vs-combinable setting exposed as configuration. Item-level eligibility is separately configurable via the menu item option 'Discount ineligible: Prevents the item from being discounted' (knowledge-hub/owners-app-web-menu/). Shortfall: the Combinable flag exists only on Register discounts; the Owner's App (web) Marketing screens that create the Online Discount, Promo Codes and Deals enumerate their fields (name, type, order minimum, usage limit of none/one-time/once per customer, start and end dates, channels) with no combinability option, and no article anywhere states the order in which discounts, promo codes, loyalty rewards and Slice credit are applied to a check. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08
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
'Push personalized discounts and deals straight to your customers' mobile device' plus 'Abandoned order alerts to recover missed sales'. No operator-facing audience rule builder is documented — Slice's marketing team operates it. https://slice.com/products/marketing-for-pizza-shops/ · retrieved 2026-08-01
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
Moved up from unknown on the Analytics article. Slice precomputes two guest views with no query-building by the operator: 'Most Valuable Customers' on spending and order frequency, and recently-ordered customers with an engagement level — recency, frequency and monetary in substance. Shortfall: no named lifecycle segments (new, regular, at-risk, lapsed, VIP), no segment membership counts, and no documented path from a view to a campaign audience — Slice's own marketing staff, not the operator, build the sends. https://slice.com/knowledge-hub/owners-app-web-analytics/ · 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
Managed-service automations exist (holiday/big-day emails, timed texts, abandoned-order alerts) but as 'Our marketing experts handle all emails, texts, and app messages — you don't lift a finger', not as operator-configurable always-on campaigns. https://slice.com/products/marketing-for-pizza-shops/ · 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
Sourced only to a marketing page, and the same page frames it as a done-for-you service ('Our marketing experts handle all emails, texts, and app messages — you don't lift a finger'). No operator-facing composer, audience builder, send scheduler, or consent surface appears in the Knowledge Hub. Native sending by the vendor on the operator's behalf is a managed service, not an operator messaging capability. https://slice.com/products/marketing-for-pizza-shops/ · retrieved 2026-08-01 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
Slice operates the guest messaging itself and publishes real revocation machinery that is NOT keyword-only: the privacy policy honors opt-out 'by following the unsubscribe instructions provided in those communications or by contacting us', the Slice SMS Terms (https://slice.com/slice-sms-terms/, updated 2026-02-25) accept any of STOP, CANCEL, END, UNSUBSCRIBE, REVOKE, OPT-OUT or QUIT and add 'You may also call the Slice support team at 888-974-9928', the rewards programme can be exited 'by reaching out to [support], through chat on the Slice app, or through SMS', and the policy honors browser Opt-Out Preference Signals including GPC. The SMS Terms also enumerate the SOURCE of consent (a form on slice.com or slicelife.com, texting short code 69362, or sign-up via an account manager or marketing event) and separate marketing from transactional consent ('you are not required to consent to receive Slice Alerts with marketing as a condition of purchasing'). SHORTFALLS, three: (1) no consent TIMESTAMP or stored source-of-consent record is documented anywhere; (2) revocation is expressly scoped to one channel rather than all - 'Your opt-out of Slice Alerts will apply to the channel through which you opted-in' - and the SMS Terms govern SMS only, with email opt-out handled separately by unsubscribe link; (3) SUBJECT: this is Slice-the-marketplace's consent record for messages Slice sends to diners, not an operator-controlled surface - knowledge-hub/owners-app-web-customers/ shows the pizzeria's customer profile carrying only name, address, email, phone, creation date and most recent order with no opt-in flag, and for operator-sent messages the merchant contract makes the Restaurant 'solely responsible for ... obtaining and retaining records of any required consent to communications and honoring opt-out requests', with no tooling described. https://slicelife.com/pages/privacy · retrieved 2026-09-05 adversarially verified
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: no (moved from unknown). EVIDENCE: Slice does ship operator-triggered SMS - the release notes 'Let Phone Customers Pay by Text' and 'Send Slice Phone Order Confirmations by Text', and slice.com/slice-sms-terms/ is a published page in the 74-page index - yet the word-boundary counts for '10DLC', 'A2P', 'brand registration', 'campaign registration', 'TCR' and 'The Campaign Registry' are 0 in all three corpora, including the 177,854-character contract. Slice sends the messages from its own numbers and never tells the operator that registration exists, that Slice handles it, or that it is the operator's duty. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/ · retrieved 2026-09-18 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
'Check your marketing results anytime in your Owner's App. Real-time reports show exactly which campaigns are bringing in sales.' No offer-to-check-total redemption tie-out is documented. https://slice.com/products/marketing-for-pizza-shops/ · 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
Customers > Profiles is 'a detailed database of your customers, including their contact information and order history' holding 'name, address, email, phone number, creation date, and the date of the most recent order', and its Import and Export section documents a one-click 'Export: Download your Slice customer database for further analysis or record-keeping' beside the 10,000-row CSV import - the operator performs both, with no fee, approval or support ticket mentioned. Transaction-level history is separately self-serve: knowledge-hub/owners-app-web-financials/ documents Reports > Order Activity, Orders, Tax, Sales Mix and Sales Summary, each generated by 'Create New Report' and downloaded as CSV, plus a per-statement 'Transaction CSV or PDF for a full breakdown of each transaction'. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-08-08
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
Slice's Knowledge Hub states that even its closest order integration is inbound-only - it ingests third-party orders and edits must be phoned through to the provider - and no developer-facing documentation for any subscribable guest or order event stream is obtainable on any host Slice controls, so there is nothing a CDP could subscribe to. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-09-06 adversarially verified
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
No feedback-request or review-routing feature is documented. An Owner's Portal reviewer had to ask whether owners can even see customer reviews. https://itunes.apple.com/us/rss/customerreviews/id=1402632571/sortBy=mostRecent/json · retrieved 2026-08-01 · not refetchable · site policy
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
VERDICT moved to no. New evidence: the shipped loyalty product is now fully enumerated, and it is points-only. The owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) carries the complete `loyaltyRewards.*` namespace (61 keys) describing Pizza Points end to end - `loyaltyRewards.howItWorksList.earnPoints` = 'Customers earn <bold>{points} points</bold> for every <bold>$1 spent</bold>', `.expire` = 'Points expire <bold>{months} months</bold> after they are earned', `.redeem` = 'Points can be redeemed for a free reward', with configuration limited to point milestones and the items attached to each. There is no guest referral code, no referred-first-order attribution and no two-sided reward anywhere in it. CONTROL AND ITS POISON: `referral` scores 9 in the 7.33 MB bundle and every single hit is either the MERCHANT bounty - `dashboard.callout.referral.text` = 'Get a major bonus when a shop you refer switches to Slice' with the button linking to slice.com/referrals/?utm_source=ownersportal, and `shared.shopReferral.description` = 'Know a pizzeria that could use better tools? Send them our way.' - or the literal string `utm_medium=referral` inside the Order-Now button URL builder. That confirms the prior pass's reading of pages__referrals_termsandconditions from the other direction: the only referral mechanic Slice ships is restaurant acquisition. Bound: the operator-facing loyalty and marketing product; the consumer app's own screens are not in this corpus. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 adversarially verified
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
Slice's guest loyalty (Pizza Points) lives in the Slice consumer app, and that app issues no wallet pass. Two sources back this. (1) The vendor names the app as where the balance lives: slicelife.com/pages/slice-rewards, re-read live 2026-09-15, says 'You can find your Pizza Points balance in the Rewards tab of the Slice app', and the page mentions no wallet, pass, email card or SMS card. (2) The Android app ships no pass code. I took com.slicelife.storefront 7.13.0 from the APKCombo mirror (66,888,357 bytes, sha256 444d31899de802bb2f1c7df6fd62bf6abdf43adfdbe63c3a96e6743b3654c74a) and searched every string in its ten dex files and resources.arsc (770,197 strings) plus its 13,082 com.slicelife classes. The loyalty feature is a first-party module (com/slicelife/feature/loyalty/, 703 classes). Its 'loyaltycard' classes (LoyaltyCardUIState, LoyaltyCardVisibilityUseCase, loyalty_card_description_with_shop_name) are an in-app Compose card, not a wallet object. No Slice class contains 'wallet' or 'pass'. Controls, tokenised and case-insensitive: 'add/save to google wallet' 0, 'apple wallet' 0, 'pkpass' 0, 'passkit' 0, 'passbook' 0, 'gp/v/save' 0. Poison: every 'wallet' hit in the dex and arsc dumps, including 'CreateWalletObjectsRequest', 'LoyaltyWalletObject', maskedWalletDetails*, wallet_*_holo_* and 'Nunua ukitumia Google Wallet', comes from Google's bundled play-services-wallet SDK (com/google/android/gms/wallet/), which the app uses for Google Pay (SliceGooglePayManager). None of those strings contains 'slicelife'. The web clients add nothing: the Owner's Portal and storefront dictionaries (.cache/q306-slice owners-dict.json, sf2-dict.json) have one wallet hit between them, 'issuerList.wallet.placeholder', a payment issuer picker. slice.com and slicelife.com (~465 + 9 files) have zero wallet tokens. LIMITS: the iOS app was not examined, so the Apple Wallet half rests on the Android build, the web census and the vendor naming the in-app Rewards tab. A string census cannot rule out a pass sent by email from the server, but no Slice page mentions one. https://apkcombo.com/slice-local-pizza-delivery/com.slicelife.storefront/download/phone-7.13.0-apk · retrieved 2026-09-15 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
Slice operates a consumer data-rights portal at privacy.slicelife.com. This is Slice-run and diner-facing — no operator-side admin tooling to locate, export or delete an individual guest's records is documented. https://privacy.slicelife.com · retrieved 2026-08-01
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
Employee Permissions gate the redemption-adjacent actions and produce an audit trail: per knowledge-hub/register-employee-permissions/, 'certain actions - like applying discounts, issuing refunds... require additional permissions' and 'if an employee tries to perform an action outside their assigned permissions, the system will block them until a user with approval grants or denies the request.' The Permissions Log in the Owner's App (web) 'records sensitive actions performed by employees and the details of who approved them' with columns Actioned By, Authorized By, Action, Status and Date, described as 'a clear audit trail for tracking sensitive activities performed and approved within your system' and as a tool to 'address potential shrinkage'; release-notes-2/control-who-manages-the-cash-drawer/ (2025-10-09) extends the same pattern to the cash drawer. Shortfall: none of this is loyalty-specific - there is no redemption velocity limit, no manual point-adjustment surface to approve (loyalty points are issued by the Slice Rewards Program, not the shop), and no flagging of an employee redeeming against their own guest profile. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08
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
VERDICT moved to no. The prior pass had the contract's generic 'AI Features' definition and no enumeration of the marketing product; the shipped marketing product is now enumerated. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) carries all of Special offers (`specialOffers.*`, 175 keys) and the campaign sender. Targeting is a closed, RULE-DEFINED segment list, not a model: `specialOffers.campaigns.sendCampaignModal.segments.*` = Loyal Customers / New Customers / Repeat Customers (plus All in the results table), and the rules are printed in the app - `dashboard.customersTile.segments.loyal` = '3+ orders in 3 months', `.repeat` = '2+ orders in 3 months', `.new` = 'First-time'. Send timing is fixed, not optimised: `specialOffers.campaigns.sendCampaignModal.description` = 'Campaigns are valid for 7 days after creation and apply to customers who placed an order in the last 30 days. One use per customer with a $10 minimum'. The one 'optimize' surface is a static three-item tip list with hard-coded copy - `campaignManager.optimizeModal.addDiscount.subtitle` = 'Discounts tend to perform 20% better', `.addMenuPhotos.subtitle` = 'Menus with 10+ photos perform better', `.lowerDeliveryFee.subtitle` = 'Delivery fees less than $4 perform better'. BOUND/CONTROLS over the 7.33 MB corpus: `recommendation` 0, `recommendations` 0, `send time` 0, `predicted` 0, `machine learning` 0, `model` in a targeting sense 0. POISON NAMED: `AI` is present 7 times and every one is Image Studio menu photography ('Draft with AI', 'our AI will automatically generate gorgeous, professional photos'); `audience` scores 104 and is entirely the Auth0 `AUTH0_AUDIENCE` constant and its error strings. Bound: the operator-facing marketing product in the Owner's Portal. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 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 Register tender surface is enumerated exhaustively: 'There are three ways to pay for an order: Card, Cash, and Other', where Other is 'used for anything that is not cash or card, e.g., check, paper gift certificate, running your own invoices' - a paper certificate is keyed as an untracked miscellaneous tender, with no balance looked up or decremented. The payment-type breakdown in knowledge-hub/owners-app-web-financials/ matches with no stored-value line: Credit Card Collected, Other Payment Collected, Cash Collected and Slice Online Payment, and the only balance-bearing instrument named anywhere is 'Slice credit', which the same article treats as a Slice-issued discount on online orders, not a shop-sold card. The customer profile schema in knowledge-hub/owners-app-web-customers/ (name, address, email, phone, creation date, most recent order) carries no balance field. Slice therefore sells no native gift card or stored-value account tied to the guest profile. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
Value upheld on retrieval, with one misattributed quote corrected: the employee-permissions article does not say the Register is not a time clock, it says 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions—it does not function as a time clock or track when employees log in or out.' The Time Clock itself is real — 'Time Clock is powered by Homebase, a Slice Partner', added to the Register iPad, punched by PIN on the iPad or on employees' own phones. Shortfall: it is the partner's product. The operator must already hold a Homebase account from joinhomebase.com, must 'reach out to Slice Support for help getting started', timecards live in Homebase, and Slice discloses no price for the Homebase side. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-08-02 adversarially verified
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
CLAIM: captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. VERDICT: no (moved from unknown). EVIDENCE: the documented punch is a four-digit PIN on the partner Time Clock app's keypad, and the whole clock-in and clock-out procedure is enumerated step by step (PIN; name prompt; Clock In; confirmation; on the way out, PIN, Clock Out, and optionally 'Rate your shift and leave a note for your manager') with no camera step anywhere. 'photo' scores 2 hits in the census and both are menu-item images ('take a new photo', 'Items with No Photos'); 'facial', 'biometric' and 'selfie' score 0. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-18 adversarially verified
Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.
labor-geofenced-mobile-punch
CLAIM: supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal. VERDICT: no (moved from unknown). EVIDENCE: mobile punching is mentioned - 'Your team can clock in using the Register iPad or their own phones - whichever works best for your shop' - but it is the partner's app and Slice documents no restriction on it whatsoever: geofence 0, geo-fence 0, 'location validation' 0, radius 1 (a delivery-zone radius), and 'GPS' 2 hits, both Driver App turn-by-turn navigation ('tap Start Navigation to use GPS directions to the customer'). No site check, no boundary, no location captured with a punch. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-18 adversarially verified
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
CLAIM: records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. VERDICT: no (moved from unknown). EVIDENCE: the claim's documentation conjunct fails outright. The only offline behaviour Slice publishes is Annex 3's card-transaction queue ('Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored'), which is scoped to point-of-sale activities and authorization and never mentions a punch; and the punch does not happen in Slice's software at all, so Slice publishes no reconciliation behaviour to document. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-18 adversarially verified
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Per-employee, per-action permissions assigned in the Owner's App — 'applying discounts, issuing refunds, or accessing reports' are named. The full grantable action list is not published and there is no per-location scoping (single-shop product). https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-08-01
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
Overrides require an approving user's four-digit PIN to grant or deny. But the Employee Permissions Log 'only tracks assigned permissions' — no immutable, queryable record of who approved which override. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-08-01
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Positive evidence of absence, and stronger than the previous inference: Slice's own article states "You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll." Scheduling is deliberately outside the platform that now holds the punch data. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
CLAIM: generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. VERDICT: no (moved from unknown). EVIDENCE: Slice holds no schedule to recommend into - scheduling is explicitly assigned to the partner ('You'll use the Homebase website or mobile app separately to set up schedules') - and every analytic it ships is backward-looking: the closed Owner's App (web) report set is Order Activity, Orders, Tax, Sales Mix and Sales Summary, plus an Hours Analytics page that reports 'Last 30 Days' shop availability and a 'Shop Status History' of pauses and closures. This is consistent with the record's existing labor-native-scheduling = no and labor-realtime-labor-percent = no. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-18 adversarially verified
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
The Owner's App report set is enumerated in the Financials article — Order Activity, Orders, Tax, Sales Mix, Sales Summary — and the Register adds only the Cash Drawer and Delivery Management reports. Not one carries a labour cost or hours dimension, and clocked hours are held by partner Homebase, so no live labour-percent view exists on any Slice surface. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-02
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
CLAIM: warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. VERDICT: no (moved from unknown). EVIDENCE: 'overtime' scores zero word-boundary hits in the 116-document census, the 74-page site index AND the 177,854-character contract, and there is no clock-in inside Slice software at which to warn. The only blocking Slice documents at the Register is the permission gate - 'If an employee tries to perform an action they do not have permission for - such as applying a discount, issuing a refund, or viewing reports - the system will block them ... The approving user enters their four-digit PIN to approve or deny the request' - which is an authorisation prompt, not an hours threshold. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-09-18 adversarially verified
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
CLAIM: configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. VERDICT: no (moved from unknown). EVIDENCE: 'break' scores 2 word-boundary hits in the whole census and both are the same sentence in the third-party article, 'this will break the integration' - a clean homonym trap. 'meal break' 0, 'rest break' 0, attestation 0, 'premium pay' 0, waiver 0 in the KB. Slice's only state-by-state jurisdictional machinery is sales tax (the Marketplace Facilitator article's MPF-state table), not labour law. SCOPE AND SHARED EVIDENCE: Slice ships NO labor module of its own and says so in its own words. Employee Permissions: 'Permissions do not track when an employee starts or ends their shift - they only define what they can do on the Register', and 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out.' The one time clock is a separate third-party app: 'The Time Clock app is added to your Register iPad ... Time Clock is powered by Homebase, a Slice Partner ... You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', and the documented punch procedure requires LEAVING Slice: 'Tap the iPad's home button to exit the Slice Register app. Tap the Time Clock app on the home screen. Enter your PIN on the keypad.' The 'Time Management' article in the Owner's App (web) is a HOMONYM, not a labour screen - it is shop operating hours, Shop Status, Weekly Hours, Scheduled Closings and delivery/pickup ETAs, with no employee in it at all. Word-boundary counts across the 116-document census: punch 0, timecard 0, 'time card' 0, overtime 0, labor 0, labour 0, 'meal break' 0, 'rest break' 0, geofence 0, geofencing 0, biometric 0, facial 0, attestation 0, 'premium pay' 0, staffing 0, forecast 0; payroll 2 and both are the Homebase sentence. NOTE ON SCOPE: this corpus bounds SLICE. What Homebase's own product can do is outside it and is not evidence about Slice either way. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-09-18 adversarially verified
Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.
labor-fair-workweek-support
Predictive-scheduling support requires a schedule inside the platform. Slice states scheduling happens 'separately' in Homebase's own website or app, so Slice tracks no advance-notice deadline and calculates no predictability pay. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
The claim requires enforcement at both scheduling and clock-in. Slice has no scheduling at all — 'You'll use the Homebase website or mobile app separately to set up schedules' — and documents no age-based hour or time-window restriction at punch. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
The Delivery Management Report computes a per-driver, per-batch tip settlement automatically: each driver gets a summary of total amount, cash collected, credit card, tips, other, delivery fees and 'Cash due to driver: Amount the shop owes the driver - or the driver owes the shop - based on tip handling', with the rule stated explicitly - 'If the cash collected is more than the driver's credit card tips, the driver keeps the value of their credit card tips and returns the rest to the shop. This shows as Cash Due to Drawer. If the credit card tips are more than the cash collected, the driver keeps the cash they collected and is paid additional cash by the shop to cover the full tip amount.' Shortfall: this is a single hard-coded cash-versus-card reconciliation for delivery drivers only. There is no pool: no percentage-of-sales, hours-worked, points or role-weighted allocation is configurable anywhere, no tip-out from one role to another exists, cashiers and kitchen staff are not covered, and hours now live in partner Homebase with no documented link to Slice tips. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-08
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
Card and cash tips are reported in the Sales Summary and per-driver in the Delivery Management Report. No per-shift contributed/distributed pool record exists because there is no pooling engine. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-01
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
Slice runs no payroll and emits no payroll export. Its labour-partner article positively assigns scheduling, employee management and payroll to Homebase, used separately from Slice; Slice's own reporting surfaces are enumerated closed and contain no payroll or W-2 artefact (Owner's App (web) Reports = Order Activity, Orders, Tax, Sales Mix, Sales Summary; Register Reporting tab = Sales Summary Report and Delivery Management Report). Tips are broken out only by channel and tender (Register Tips / Online Tips / Total Online Prepaid Tips) and per delivery driver, never by employee with an occupation code. No W-2, Box 12, code TP, Box 14b or tipped-occupation string occurs anywhere in the 500-document corpus. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-05 adversarially verified
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Explicit: "You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll." Payroll is the partner's product; Slice files no taxes and runs no direct deposit. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
Hours punched on the Register reach exactly one payroll destination — Homebase, which 'helps you manage schedules, hours, and team communication' and where the operator runs payroll. Shortfall: one provider, not the two the claim requires; no Gusto, ADP, Paychex or QuickBooks path is named; no file format or field list is published; and Slice itself exports no timecard file — the data is captured in the partner's app rather than exported from Slice. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-08-02
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
Shift swaps and open-shift claiming presuppose a schedule. Slice holds none; scheduling is done separately in Homebase, and Slice documents no request or manager-approval workflow of its own. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.
labor-digital-onboarding-i9
Slice's article places employee management outside its platform — 'manage employees' happens in Homebase — and Slice ships no new-hire onboarding, W-4 or I-9 collection, or E-Verify submission anywhere in the Owner's App. https://slice.com/knowledge-hub/homebase/ · retrieved 2026-08-02
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
The order-level export's columns are enumerated closed ("each column"): Ordered At, Customer, Order Type, Effective Subtotal, Tip, Tax, Discounts, Cash Discounts, Refunds, Delivery Fee, Order Total, Status - there is no employee, server or cashier column, so no per-employee average check, attachment rate or void/comp rate can be derived. Every other documented report is enumerated the same way and is dimensioned by channel, tender, dining option, tax or item, never by user. The only per-person report scores delivery drivers (total amount, cash collected, credit card, tips, other, delivery fees, cash due to driver). The one employee-keyed surface is explicitly not an activity record: register-employee-permissions states the Employee Permissions Log "only tracks assigned permissions" and "does not function as a time clock or track when employees log in or out". https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-09-05 adversarially verified
Reporting, BI & data access
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
Value upheld but the earlier basis was wrong: the record reasoned from the Financials article that only five fixed CSV reports exist, when the Owner's App also ships an Analytics section nobody had cited. It carries visual dashboards — Delivery & Pickup split, Sales by Day, Top and Least Selling Menu Items, Your Customers, Most Valuable Customers — with a period filter and an 'Online Only or Register' source toggle, on web and in the Owner's App. Shortfall that keeps this partial: no refresh interval or latency is stated anywhere, and no Slice document uses the words live or real-time for sales figures. https://slice.com/knowledge-hub/owners-app-web-analytics/ · retrieved 2026-08-02 adversarially verified
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
Sales Summary Report covers 'Total sales, payment methods, taxes, and tips for Register, Online, and Third-Party orders' with net/gross sales, service fees, discounts and average order value, paired with drawer close and cash reconciliation. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-01
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
Sales Mix Report tracks 'the quantity and sales performance of individual menu items'. Modifier-level PMIX and revenue-center slicing are not documented; date and order-type filters exist. https://slice.com/knowledge-hub/owners-app-web-financials/ · 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
Discounts carry reason codes and appear in the Sales Summary, but there is no report attributing comps/voids/overrides to the applying employee and approving manager — the permission log explicitly is not an activity log. https://slice.com/knowledge-hub/register-employee-permissions/ · retrieved 2026-08-01
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
Drawer open/close with opening and closing balances, No Sale / Pay Out / Pay In, and 'reconcile cash discrepancies'. Per-employee over/short attribution is not explicitly documented. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-01
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
Value upheld but on a wider base than the record used. The earlier note treated the Financials article as the whole report catalogue; it is not — the Owner's App also ships an Analytics section. I read it: Orders (Delivery & Pickup, Sales by Day, Top and Least Selling Menu Items) and Customers (Your Customers, Most Valuable Customers). Not one dimension is labour hours, labour cost or sales per labour hour, and clocked hours sit in partner Homebase rather than on any Slice surface. Positive evidence of absence across both report surfaces. https://slice.com/knowledge-hub/owners-app-web-analytics/ · retrieved 2026-08-02 adversarially verified
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
The item-mix report's columns are enumerated closed - Category, Item, Discontinued Item, Quantity Sold, Gross Sales, Item Discounts, Average Price - with no server dimension, so category attachment rate per server is not producible. Average Order Value exists only shop-wide and per channel (Sales Summary, End of day report), tips only at channel level (Register Tips, Online Tips), and the Orders Report's closed column list carries no employee id, so tips as a percentage of an individual's sales cannot be formed. Register-side reporting is likewise closed: the Reporting tab offers exactly the Sales Summary Report and the Delivery Management Report, filtered by Date & Time, Order Type and Dining Type. No scorecard screen exists in Analytics or on the mobile Report page. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-09-05 adversarially verified
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
Upheld with the shortfall sharpened on my own retrieval. Net Sales splits only 'Register Sales' and 'Online Sales'; Payments splits Credit Card Collected, Cash Collected, Slice Online Payment and Other Payment; Dining Option splits Delivery, Pickup, To Go, Dine In and the Slice online variants. Third-party appears in a single aggregate block at the end — 'All Third-Party Orders are prepaid', with total order sales, total tips and average order value. Shortfall: marketplaces are not broken out individually, and the Service Fees line covers Register delivery fees, credit-card surcharges and Slice online delivery fees only — no marketplace commission is netted anywhere. https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-02 adversarially verified
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
Multi-shop operators are handled by switching context, not by consolidation: knowledge-hub/owners-app-getting-started/ says 'If you have multiple shop locations, select the appropriate location to proceed' at login, and knowledge-hub/slice-register-getting-started/ repeats it for the Register ('If you have multiple shops, select the location you are in'). The Financials article then enumerates the entire reporting surface - 'Order Activity Report, Orders Report, Tax Reports, Sales Mix Report, Sales Summary' - and lists the complete field set of each ('The Sales Summary Report consists of:', 'Here's a breakdown for each row'); not one field is a location, shop or store dimension, and no group-total, side-by-side comparison or roll-up view appears in the Analytics, Report or Customers articles either. Drill-down to an individual transaction does exist, but only within the single shop context you logged into. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-08
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
Five fixed report types with date/order-type/dining-type filters. No dimension-and-measure builder or saved custom reports. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
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
The article closes its Sales Summary section with: 'You can get automated daily sales summaries by calling your Account Manager at (888) 974-9928 to set up daily Sales Summary Report (SSR) emails. These reports provide a breakdown of the day's sales and can be sent to multiple recipients, including managers and accountants.' So recurring email delivery to a recipient list is real. Shortfall: it covers exactly one report of the five documented (Order Activity, Orders, Tax, Sales Mix, Sales Summary) - the rest are 'Create New Report' then download the CSV on demand; the cadence is fixed at daily with no other option offered; and there is no self-serve scheduler - setup requires a phone call to a Slice Account Manager, so the operator cannot define or change the schedule or recipients from the Owner's App (web). https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-08
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
Manual CSV download only. No S3/SFTP/Snowflake/BigQuery destination and no scheduled bulk export. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
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
The conventional developer subdomain answers HTTP 200 with the consumer pizza-ordering homepage rather than a developer portal, no REST or GraphQL reference for orders, payments, menu or labor is obtainable on any Slice-controlled host, and there is no self-service credential path. https://developers.slicelife.com/ · retrieved 2026-09-06 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
Slice documents that it cannot send order updates back even to Uber Eats and DoorDash, its own integrated delivery partners, and publishes no callback documentation anywhere, so there is no outbound lifecycle webhook to a customer-supplied endpoint and no retry or signing behaviour to read. https://slice.com/knowledge-hub/online-ordering-third-party-orders/ · retrieved 2026-09-06 adversarially verified
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
Half the claim holds and half is void: raw-data self-service export - the customer database plus CSV order-activity, orders, tax, sales-mix and sales-summary reports - lives in the Owner's Portal, which slice.com/pricing/ lists as Included on both memberships, so raw data carries no data-access line item or per-location surcharge; but Slice publishes no API, so the programmatic half cannot be said to be bundled. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-09-06 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
Owner's Portal reporting is included on both memberships, but every Register-derived report (Sales Summary, drawer/cash, Delivery Management) requires the $399/mo Family tier since the POS itself is Family-only. https://slice.com/pricing · retrieved 2026-08-01
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
Shortfall: Slice publishes no retention policy. The only evidence is the Owner's Portal client, which sets fixed earliest-selectable dates for reports. It does not document how long data is kept, and nothing says whether a support-assisted archive exists or carries a fee. What the served chunk shows (re-fetched live 2026-09-15, 200, character offsets): the orders-report form declares eg1=new yh(2021,1,1),eg2=new yh(2023,1,1) (@3935585) and picks g="online"===f?eg2:eg1 (@3936063). It shows the merchant the copy "{orderType, select, online {Online} other {Register}} order data is available from {date}." (@1466744), and rejects earlier dates with "Please select a start date of {date} or later." (@1465474). The time-of-day report repeats the same floors (egQ/egJ @3930701). yh is @internationalized/date CalendarDate with 1-based months, so Register history is selectable from 2021-01-01 (about 68 months) and online history from 2023-01-01 (about 32 months). Both exceed 24 months. Each orders report is capped at 31 days (!(e.end.compare(e.start)>30), "Please select a maximum of 31 days." @1465322). Two other report forms cap at 365 days instead (>364, "Please select a maximum of 365 days." @3964613/@3967642), so a multi-year span still takes several queries. Treat the floors as UI lower bounds, most likely launch or migration dates, not a promise that the data is retained or complete. The 2024 Help Center (Wayback 20241107012749) described a 30-day self-serve window, with older orders only through a Partner Success Manager. That is the retired portal's behaviour and is superseded by these floors, but it shows the window has changed without notice. Zero-hit controls in the chunk: retention, months ago. "Exports available for 30 days." (@1266692) is about download expiry, not data retention. https://owners.slicelife.com/_next/static/chunks/2uwqhg6bmkr3v.js · retrieved 2026-09-15 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
The Insights page 'provides recommendations and sales trends': 'Sales Insights: Highlights weekly sales performance compared to previous periods. Notifications indicate whether your sales have increased or decreased and by how much', with 'Unread Insights: New insights are marked with a colored dot.' That is a deviation-from-historical-pattern notification the operator does not have to run a report to see, and the Owner's App home also shows today's sales, orders and voids against the same day last week. Shortfall: nothing is operator-configured - there is no metric picker, no threshold, and no rule builder; the surface is limited to weekly sales movement (voids, discount rate and forecast variance are not alertable); and delivery is an in-app Insights feed with an unread dot, not a push notification or email to a recipient list. The only push notifications Slice documents are guest-facing marketing sends. https://slice.com/knowledge-hub/owners-app-report/ · retrieved 2026-08-08
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
CLAIM: natural-language/AI query over the operator's own sales and labor data returning a figure or chart. VERDICT: no. NEW SURFACE that supplies the closed enumeration the prior pass said was missing: the Owner's Portal is a Next.js/Turbopack SPA at owners.slicelife.com whose chunk graph I crawled to a fixpoint (4 rounds, 21 chunks, 7.33 MB, 0 outstanding references; no source maps - every <chunk>.js.map and the nonsense control /zzz-nope-324.js.map return the identical 9.5 KB SPA shell). The bundle ships the app's whole English message catalogue, 3,974 dotted i18n keys. EVIDENCE: the catalogue enumerates the portal's own page list in `shared.navigation.*` (56 entries: Home, Orders, Menu, Items, Categories, Modifiers, Analytics, Reports, Statements, Financials, Payouts, Customers, Segments, Special offers, Loyalty rewards, Digital ads report, Pizzeria score, Hours overview, ETA, Delivery/Delivery rules/Delivery zones/Delivery Settings, Register, Printer settings, Printer templates, Profiles, System profiles, Automations, Tip settings, Employee permissions, Time Management, Phone, Image Studio, Branding studio, Asset/Website tools, Smart buttons, Smart popups, Classic buttons, Custom website, Google Business Profile, Goods, Operations, Resources, Settings, Feedback, User guide, Knowledge Hub ...), and the two analytic surfaces are themselves closed lists: `reports.tabs.*` = Orders / Order activity / Sales mix reports / Sales summary / Tax reports / Credit card payments (six, each with a `createModal` whose only inputs are date range, time range or shift hours, sales channel and order type), and `analytics.tabs.*` = Orders / Customers. BOUND/CONTROLS over the 7.33 MB fixpoint corpus, tokenised, case-insensitive, word-boundary: `natural language` 0, `assistant` 0, `chatbot` 0, `copilot` 0, `ask a question` 0, `recommendation` 0, `recommendations` 0. POISON NAMED: `query` scores 71 and every occurrence is TanStack/Apollo `useQuery`/GraphQL plumbing; `insights` scores 59 and is the Digital-ads `campaignManager.insights.*` canned-sentence set ('Google has been outperforming Facebook, Instagram, and Bing'), not a query surface; `AI` appears only in `imageStudio.*` ('Draft with AI', 'Manage your AI-generated photography'), which is menu photography, not data query. The bound is the Owner's Portal web app only; Slice's public API is not covered. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 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
Moved up from unknown. The Owner's App Analytics article — a report surface no previous pass cited, and one that refutes this record's repeated assertion that the Financials article enumerates the whole report catalogue — carries a Customers section with 'Your Customers' (recently ordered customers and engagement level) and 'Most Valuable Customers' ranked on spending, order frequency and loyalty, filterable by period and by 'Online Only or Register'. Shortfall: no new-versus-returning counts, no lifetime-spend cohort bands, and no export of the guest list behind the view. https://slice.com/knowledge-hub/owners-app-web-analytics/ · 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
CLAIM: forward sales forecast at daypart/hourly granularity from the location's own history, exposed in reporting and consumable by scheduling or ordering. VERDICT: no, on the closed enumeration the prior pass lacked. EVIDENCE: the owners.slicelife.com Turbopack bundle (chunk graph taken to a fixpoint, 21 chunks / 7.33 MB, 3,974 i18n keys - see reporting-nl-query for the retrieval and the soft-200 .map control) enumerates the whole reporting product: `reports.tabs` = Orders, Order activity, Sales mix reports, Sales summary, Tax reports, Credit card payments; `analytics.tabs` = Orders, Customers. Every tile in them is explicitly retrospective and the app says so in its own words: `analytics.orders.salesByDay.footer` = 'The <b>actual</b> sales represent earnings for the current week. The <b>average</b> sales represent earnings average for the last 4 weeks.', `hoursAnalytics.last30Days.title` = 'Last 30 days', `campaignManager.execution.results.description` = 'Last 90 days'. The one forward-looking object in the app is operator-entered, not modelled: `eta.deliveryPickup.subHeader` = 'Set your estimated delivery and pickup times' with `eta.adjustedTimeSection.subHeader` = 'Add additional time or subtract minutes from your average times during busy hours or slow days'. BOUND/CONTROLS over the 7.33 MB corpus, tokenised word-boundary: `forecast` 0, `forecasting` 0, `predicted` 0, `prediction` 0, `projected` 0, `daypart` 0, `percentile` 0. POISON NAMED: `projection` scores 17 and is entirely the charting library's map/scale projection code, and `recommended` is only `register.automations.editAutoCompleteModal.description` ('Recommended: {n} minutes') and photo-size guidance. Bound: the Owner's Portal web app; the public API is not covered. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 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
Card and cash tips are reported, and Tax Reports show gross sales, total tax collected and 'Total Withheld: The portion of sales tax withheld by Slice for remittance to tax authorities, where applicable'. Declared-vs-charged tips per employee and pool distribution detail are absent. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
Multi-location, franchise & enterprise governance
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
Multi-shop accounts do exist and locations are a real object: at login, 'If you have multiple shop locations, select the appropriate location to proceed', and on the dashboard 'the location selector lets you switch between multiple shop locations using a dropdown menu. If you manage more than one shop, tap the selector to choose the location you want to view.' Slice Register repeats it: 'If you have multiple shops, select the location you are in.' Shortfall: this is exactly one flat level. No enterprise/region/group object is named anywhere in the 45 Knowledge Hub articles, and every reporting and permission surface documented is scoped to the single selected shop rather than to a group. https://slice.com/knowledge-hub/owners-app-getting-started/ · retrieved 2026-08-08
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 item authoring surface is enumerated closed. The New Item page is documented field by field - Item type (build-your-own pizza / regular), Item details (Name, Display name, Kitchen name, Category, Description, Photo), modifier groups, Sizes and pricing, an Options section of six named toggles (loyalty reward, item available online, item available on Slice Register, house favorite, contains alcohol, discount ineligible) and Register printing - and editing is identical ("All of the fields will be the same as the New Item screen"). The Menu Matrix view repeats the same shape (Item name, Price, Category, Availability, Print Routing, Stock). No field is lockable, ownable by a parent, or marked corporate-versus-local, and the words corporate, parent and locked field appear nowhere in the Knowledge Hub or the release notes. A per-field override rule would have to be an item attribute, and the item attributes are a closed list. https://slice.com/knowledge-hub/owners-app-web-menu/ · retrieved 2026-09-05 adversarially verified
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
The Menu Item Matrix enumerates the item record - 'Item name', 'Price: The item's current price', 'Category', 'Availability', 'Print Routing', 'Stock dropdown' - a single price value per item. The per-item Options list controls channel by availability only ('Item available online', 'Item available on Slice Register'), never by price, and category availability can be set to specific days of the week while price cannot. The only price dimension Slice documents is per size (and per-size modifier pricing). There is no location group to price against - locations are a flat selector - so no price tier by location group, order channel or daypart exists. https://slice.com/knowledge-hub/owners-app-web-menu/ · retrieved 2026-08-08
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
Future-dated activation exists, but only for promotions and trading hours and only within one shop. Register Discounts take a Start Date for when the discount becomes active and an optional End Date; online promos in owners-app-web-marketing likewise 'Define a start date for the promo, and optionally add an end date'; Hours offers Schedule Closing with View All Scheduled Changes. Shortfall: menu and price changes cannot be scheduled at all - the fully enumerated owners-app-web-menu surface has no scheduling field, and the documented activation event for a menu change is a manual per-device download ('Changes made on this page will not take effect until each iPad downloads the updated menu'). Nothing targets a set of locations, no document describes interpreting an activation time in each location's own timezone, and no rollback of an activated change is described anywhere. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-09-05 adversarially verified
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
CLAIM: 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. VERDICT: no (moved from unknown). EVIDENCE: the documented opening path is a manual, per-device build with no clone step: 'After the Onboarding Call, install your hardware, including your iPad, printer, card reader, and cash drawer. Follow the Slice Register Install Guide for step-by-step instructions', then 'Configuring Printers, Payment Terminals, and Cash Drawers' one at a time on that iPad. Configuration does not propagate even between iPads of the SAME shop: 'If you use multiple Register iPads, you must download changes on each device.' CONTROLS: clone 0, duplicate 0, 'copy settings' 0 in all three corpora; 'template' scores 1 hit in the census and it is the customer-import 'CSV Template'; 'provision' scores 41 on the site and 29 in the contract and every one is the legal sense ('the provisions of this Agreement') - poison for this control. No time-to-open figure is published on any of the 74 pages; the pricing page publishes a $1,000 implementation fee, which is a price and not a date. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/slice-register-getting-started/ · retrieved 2026-09-18 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
The permission model - which is exactly the instrument this claim names - is enumerated exhaustively and is entirely single-shop. Register Permission groups are built by checking boxes under five categories, and every individual permission is listed: Orders (12 named actions), Shop Operations (Update Shop ETA), Cash Management (10 named actions including each viewable report), Menu Availability (update item availability) and Shop Availability (3 actions). Users are shop staff assigned a group and a four-digit PIN. There is no tenant, franchisor, corporate or cross-location role anywhere in it, and no permission that grants visibility into another shop. The only multi-shop construct Slice publishes is a viewer: one owner login selects a location from a dashboard dropdown 'to view'. Slice's merchant agreement reinforces this by treating a franchise agreement as an obligation of the Restaurant to a third party that Slice merely warrants against conflicting with; it defines no franchisor party and no multi-entity account. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-09-05 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 financial surface is enumerated closed and contains no royalty object. owners-app-web-financials documents every report Slice produces (Order Activity, Orders, Tax, Sales Mix, Sales Summary) and then every field of each, plus the Statement Summary line by line - Sales Subtotal, Tax Collected, Delivery Fees, Tips, Sales Tax Withholding, Refunds, Chargebacks, Slice Delivery Fees, Card Processing Fees, Slice Partnership Fees, Register Subscriptions, Phone Order Fees, Supplies, Past Due Amount, Other Adjustments - and the Order Activity Report's fee breakdown. Every fee construct is a Slice-to-restaurant fee. There is no royalty, ad-fund or marketing-fee amount, no royalty basis, no schedule, and no gross-versus-net-of-discounts configuration anywhere in the reporting or statement schema. In the merchant agreement 'royalt' occurs only in IP-licence boilerplate (royalty-free licences) and a third-party-rights warranty. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-09-05 adversarially verified
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 only automated debit authority Slice takes in its merchant contract is for Fees owed to Slice itself, swept from the Merchant Deposit Account or Sales Proceeds; the hardware clauses are the same, letting Slice obtain payment from the Restaurant's credit card or bank account for restocking and failure-to-return fees. Nothing authorises a debit directed by, or remitted to, a franchisor. The reporting side closes independently: owners-app-web-financials enumerates the Statement Summary line by line and the Payouts table field by field (Payout ID, Date Created, Date Paid, Amount, Method, Status), and every line is a Slice-to-shop payout or a Slice fee - there is no franchisee-visible statement of amounts charged on a third party's behalf, because there is no calculated royalty to charge. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-05 adversarially verified
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
Slice's three back-office reporting surfaces are each enumerated and each is scoped to one shop. Owner's App Report lists its entire contents - 'In this Article: Orders report, Scheduled Orders report, Statements, End of day report, Sales Report, Insights' - all described as 'your shop's performance'. Owner's App (web) Analytics enumerates Filters/Orders/Sales by Day/Top and Least Selling Menu Items/Customers, and Owner's App (web) Financials enumerates Online Orders, Register Orders and Statements. Viewing is explicitly one location at a time: the dashboard 'location selector lets you switch between multiple shop locations... tap the selector to choose the location you want to view'. No aggregate-across-locations view, no store-vs-store ranking, and no variance flags exist in any of the three. https://slice.com/knowledge-hub/owners-app-report/ · retrieved 2026-08-08
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
The documented multi-shop model is a one-location-at-a-time viewer: the Owner's App dashboard location selector switches between shops, and the Register likewise asks the user to "select the location you are in". Every item-level report is scoped to that selected shop - Analytics' Top and Least Selling Menu Items, the End of day report's Products section, and the Sales Mix Report, whose columns are enumerated closed as Category, Item, Discontinued Item, Quantity Sold, Gross Sales, Item Discounts, Average Price with no location column. The item record itself is enumerated closed on the New Item page with no corporate or canonical identifier under which a renamed or locally-priced item could roll up. Multi-shop accounts exist; what does not exist is an aggregate across them. https://slice.com/knowledge-hub/owners-app-getting-started/ · retrieved 2026-09-05 adversarially verified
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 order-entry guide enumerates the tenders exhaustively: 'There are three ways to pay for an order: Card, Cash, and Other.' Other is defined as the catch-all for 'anything that is not cash or card, e.g., check, paper gift certificate, running your own invoices, etc.' - i.e. a gift certificate is rung as an untracked generic tender. There is therefore no gift card account, no stored balance, no outstanding-liability figure in any report (Owner's App Report and Financials enumerate their contents and none includes gift liability), and nothing to redeem or settle between locations. https://slice.com/knowledge-hub/slice-register-order-entry/ · retrieved 2026-08-08
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
Slice's pizza-points loyalty lives in the Slice consumer app and follows the diner across all Slice shops — marketplace-wide rather than brand-wide. Whether a multi-shop owner gets a unified brand-level profile is not documented. https://slice.com/products/online-pizza-ordering-system/ · 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
VERDICT moved to no. The prior pass had the shop-selector evidence (one Register session bound to one shop) but no enumeration of the back office. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) enumerates every page of the back office in `shared.navigation.*` (56 entries) and there is no brand, concept, virtual-brand or second-menu manager among them; the menu product is a single `menuV2.*` tree per shop, and the only per-shop branding controls are cosmetic and explicitly global to the one shop - `customWebsite.configuration.description` = 'Customize your website with a color and font. Your selections will be applied across all Slice products, keeping your brand consistent', `register.printerTemplates.customerReceipt.tabDescription` = 'Customize your customer receipts to reflect your brand', `assetLibrary.title` = 'Branding studio'. Revenue reporting is likewise single-brand: `reports.createModal.salesChannel.*` splits only All orders / Online / Register, never by brand. BOUND/CONTROLS over the 7.33 MB corpus, tokenised: `virtual brand` 0, `brands` in a product sense 0, `concept` 0, `second menu` 0, `sub-brand` 0. POISON NAMED: `brand` scores 107 and every product-namespace hit is receipt/website styling as quoted above, while the remainder is Datadog's `brand` browser field and React Aria's `virtual` pointerType, which scores 33 on its own and is why a bare `virtual` control is worthless here. Bound: the Owner's Portal back office, the only place a Slice menu or receipt is configured. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 adversarially verified
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
Tax is configured per shop and Slice withholds and remits marketplace-facilitator sales tax 'where applicable'. Multiple simultaneous rates, inclusive-vs-exclusive handling and exemptions are not documented. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
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 Permissions Log in the Owner's App (web) records 'Actioned By', 'Authorized By', 'Register Profile Name', 'Task' (examples given: 'Turn off tax at order level', 'Line item clear before send'), 'Status' and a timestamped 'Date', and the doc calls it 'a clear audit trail for tracking sensitive activities performed and approved within your system'. Shortfall: it logs permissioned register ACTIONS, not configuration objects - edits to prices, tax rates, permission groups and discounts are nowhere described as logged - and no export, query, retention or immutability guarantee is documented, nor any corporate/above-store view; the log is scoped to the one shop selected in the location dropdown. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08
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
Slice's transaction-level extraction is real but is a per-shop CSV an operator generates and downloads by hand; multiple shops do sit under one login, yet the only documented cross-shop affordance is a dropdown that switches which single shop you are viewing, so no single authenticated call returns all locations. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-09-06 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
Slice assigns labor wholesale to a partner: the Register iPad carries a Homebase Time Clock app that staff clock into by PIN after exiting the Slice Register app, while scheduling, employee management and payroll happen on Homebase's own site, so Slice configures and enforces no labor rule of its own at the terminal - Slice's own 'Time Management' screen is shop hours, closures and delivery ETAs, not employee hours. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-09-06 adversarially verified
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
The POS runs on a standard iPad and prints to off-the-shelf Epson units, but hardware is supplied bundled with the Family Membership; buying your own iPad and running Register on it is not documented as supported. https://slice.com/knowledge-hub/slice-register-getting-started/ · retrieved 2026-08-01
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
iPad/iPadOS is named as the Register client and the Owner's App ships for iOS and web. No iPad model requirement, minimum iPadOS version, or device spec is published. https://slice.com/knowledge-hub/slice-register-getting-started/ · retrieved 2026-08-01
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
The included-hardware list is Register, Stand, Payment Terminal, Cash Drawer, Receipt Printer, Kitchen Printer, Network Kit. No handheld. Mobility is a second iPad plus the NYC1 Mobile Card Reader. https://slice.com/pricing · retrieved 2026-08-01
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
Slice's only second order-taking device is identified by the vendor as an iPad on a countertop, under-counter or wall-mounted stand, so there is no handheld in the line to have a hot-swappable or field-replaceable battery, and Slice publishes no rated battery life anywhere. https://slice.com/knowledge-hub/order-manager-kit/ · retrieved 2026-09-06 adversarially verified
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
Slice ships no handheld POS device at all, so neither limb of the claim can be met. Its live product page answers 'What hardware is included with Slice Register?' by calling the kit 'the complete system' and naming it exhaustively: iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, delivery card reader. The retired hardware price list captured 2026-01-21 itemises the full rental catalogue with a price in both the Family Member and A La Carte columns for every line - Online Ordering Kit, Countertop Register Kit, Starter Kit 2.0 (including Network Router), Order Manager Kit, Mobile Card Reader, Card Reader with dock, Thermal Receipt Printer, Kitchen Impact Printer, Cash Drawer, Verifone Payment Terminal - with no cellular-capable device and no handheld. The second device Slice supplies is a stationary Order Manager iPad; the driver app runs on the driver's own phone. 'cellular', 'LTE', '4G', '5G' and 'SIM' occur once in the whole 500-document corpus, in the consumer marketplace terms of service. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-09-05 adversarially verified
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
Annex 3 (Slice POS Terms) of the Online Restaurant Agreement states it directly: 'Except as provided in an Order Form, Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline. Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored. Slice reserves the right to limit the number of offline transactions that may be queued. Unless otherwise specified in an Order Form, offline transactions may not exceed $100 per transaction. Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register... is offline.' Shortfall: that is the contract, not operating documentation. No Knowledge Hub article covers offline behaviour at all; nothing states whether order entry, kitchen printing or cash-sale recording continue, the queue depth limit is unstated, and no degrade list for loyalty lookup or refunds is published. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
Corrected 2026-08-08: the earlier note's 'no KDS product appears in the catalog' is withdrawn - https://slice.com/family-membership/ does list 'Discounted kitchen displays & kiosks (coming soon)' and the unlinked draft page https://slice.com/pricing-test/ lists 'Kitchen Display System' under Family Membership. What carries the no is that neither describes a shipping first-party product. Slice's POS page answers 'What hardware is included with Slice Register?' with a closed list - 'It comes with an iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader' - no display; /pricing's Hardware key-features list is Register and Stand, Payment Terminal, Cash Drawer, Receipt Printer, Kitchen Printer, Network Kit; and Slice's own wording is 'coming soon' and 'discounted', i.e. a future reseller discount, not a first-party product today. The strings 'kitchen display', 'KDS' and 'bump' occur zero times across the 45 Knowledge Hub articles, 30 release notes and 26 FAQs pulled from the WP REST API on 2026-08-08, so nothing establishes station routing or course/fire timing either. Re-check when the 'coming soon' item ships. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-08 adversarially verified
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
The vendor itself marks kiosks '(coming soon)' on the Family Membership benefit table, so no kiosk ships today in either countertop or freestanding form, and there is no kiosk for integrated payment or documented ADA compliance to attach to. https://slice.com/family-membership/ · retrieved 2026-09-06 adversarially verified
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
CLAIM: supports drive-thru-specific hardware - outdoor digital menu boards, order confirmation displays, and speaker/headset integration - with a documented timer/speed-of-service measurement. VERDICT: no (moved from unknown). EVIDENCE: 'drive-thru', 'drive thru', 'drivethru', 'menu board', 'headset', 'speaker' and 'lane' all score 0 word-boundary hits across the 116-document census, the 74-page slice.com page index and the 177,854-character contract; 'speed of service' scores 1 and it is a marketing phrase about order throughput, with no timer behind it. The hardware Slice names is closed and indoor: 'iPad with pre-installed Slice software', 'Epson TM-M30III printer (if ordered)', an Epson U220, a payment terminal / card reader, a cash drawer, and the Driver App's Bluetooth mobile reader. The one 'order confirmation screen' in the corpus is a customer-facing review screen on the Register iPad before payment ('This setting controls whether the customer order confirmation screen is shown on your Register iPads before payment is accepted'), not a drive-thru OCD. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. MERGE NOTE (326th): graded C: the cited URL is a marketing product page. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-09-18 adversarially verified
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Two Epson models are named and configurable (TM-m30III for receipts, U220 for kitchen), with discovery, naming, deletion and test-print. Only one manufacturer is documented and no compatibility list is published. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-08-01
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Cash drawer, receipt printer, kitchen printer, payment terminal, mobile card reader, stand and caller-ID line are documented. Barcode scanners, scales and customer-facing displays are not, and no compatibility list is published. https://slice.com/pricing · retrieved 2026-08-01
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Card entry is on a dedicated reader, not the tablet: knowledge-hub/register-settings documents a 'Payment Terminals' screen that lets you 'set a default card reader for orders taken on this iPad', and Annex 3 of the Online Restaurant Agreement states 'Slice does not receive full payment card details in its provision of Slice Register and Slice Standalone Payments. Slice has engaged a Processor that conducts payment processing.' Annex 7 identifies the acquiring stack: an 'ACQUIRING ADDENDUM - WELLS FARGO BANK, N.A. (USA)' for merchants who 'entered into a Merchant Agreement with Adyen N.V.' with 'card transactions acquired via Adyen'. Shortfall: no PTS-listed model is named for the counter terminal (the only model named anywhere is the 'NYC1 Mobile Card Reader' for delivery and MOTO, in knowledge-hub/order-manager-kit), no validated P2PE listing is cited, and no merchant SAQ type is stated on any slice.com page - the strings PCI, P2PE and SAQ do not occur in the agreement or in any of the 45 Knowledge Hub articles. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
Mobile acceptance is documented as requiring the separate NYC1 Mobile Card Reader. https://slice.com/knowledge-hub/order-manager-kit/ · retrieved 2026-08-01
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
No per-SKU hardware price is published — hardware is bundled into the $399/mo Family Membership at no separate charge, which is arguably better for the buyer but fails the per-SKU transparency test. https://slice.com/pricing · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Annex 4 (Hardware Terms) answers this in both directions. Default: 'Any Hardware (including, without limitation, printers, tablets or other hardware) provided by Slice will remain Slice's sole property'; 'Restaurant shall have no right, title or interest in or to the Hardware except the right to possession and use thereof during the applicable Order Form Service Term'; the merchant pays 'the non-refundable monthly fee set forth in the applicable Order Form (Hardware Fee)' and must return the kit on termination. An outright-purchase alternative exists as a contractual category: provisions 7-10 apply to 'any Hardware designated as purchased (or other similar term) on the Order Form', where 'Title and all risk of loss of or damage to the Designated Hardware will pass to Restaurant upon delivery by Slice to the carrier.' Shortfall: which mode a given shop gets is set on a non-public Order Form, and slice.com/pricing bundles 'Register and Stand, Payment Terminal, Cash Drawer, Receipt Printer, Kitchen Printer, Network Kit' into the Family Membership without stating that the kit falls under the rental terms. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
For subscription-provided hardware, Annex 4 answers the question and answers it negatively: 'Restaurant shall only use the Hardware in connection with, as applicable, the Platform or other Services provided by Slice', and 'Upon termination of the applicable Order Form or this Agreement for any reason... Restaurant shall promptly return the Hardware to Slice... in good working order (at Restaurant's expense)', backed by a restocking fee 'of up to $100.00' and a Failure to Return Fee 'of up to $349.00' per item. Shortfall: for Hardware 'designated as purchased', title passes to the restaurant on delivery, but the agreement never states whether that hardware runs any other software after cancellation, and no Slice document addresses software locking or remote disablement in either direction. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
Annex 4 publishes a warranty term for purchased Designated Hardware: 'Slice warrants that for six (6) months after the installation date (Warranty Period), the Designated Hardware will perform in accordance with the specifications provided together with the Designated Hardware', and the remedy is shaped like an advance exchange - the merchant returns the faulty unit 'within thirty (30) days of Restaurant's receipt of the replacement Designated Hardware', with replacements 'warranted for the unexpired portion of the original Warranty Period'. Shortfall: no turnaround commitment is stated for the replacement itself (nothing like next-business-day or a depot SLA), 'Restaurant is responsible for all costs of shipping in connection with any repair or replacement', and for subscription-provided Hardware the same annex 'EXPRESSLY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS OR IMPLIED, IN CONNECTION WITH THE HARDWARE', with installation explicitly excluding 'warranty service or support'. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
BYOD is documented for delivery staff: 'To download the Slice Driver App, go to the App Store (iOS, Android) on your phone and search for Slice Driver', 'Each driver needs a unique email address to log in', and drivers take card-present payments on that personal phone via a paired Bluetooth reader. The documented prerequisites are a security model of sorts - 'Bluetooth is turned on in their phone's settings', 'The phone has a passcode or Face ID set up', and 'The reader is compatible with iPhones (iOS 17 and later) and Android phones (Android 7 and later)'. Shortfall: only the delivery app is BYOD; the ordering Register app runs on Slice-supplied iPads (knowledge-hub/slice-register-getting-started) and the Order Manager Kit ships its own iPad. Driver logins cannot be self-provisioned - 'contact Slice Support at (888) 974-9928 to add your driver's login' - and sit outside the Register Employee Permissions groups enumerated in knowledge-hub/owners-app-web-register. No MDM, remote wipe, session timeout or data-at-rest policy is documented for the personal device. https://slice.com/knowledge-hub/register-slice-driver-app/ · retrieved 2026-08-08
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
The entire back-office device surface is enumerated: 'The Register dropdown provides access to tools and settings for managing your Slice Register system' - Register Menu Layout, Employee Permissions, Printer Settings, Register Discounts, Tip Settings, System Profiles and a User Guide link. None is a device console; System Profiles only allocates one profile per iPad ('Each iPad using Slice Register will need its profile. You do not need more profiles than iPads running the Register app in your shop'). Rollout is explicitly pull-based and per-device: 'Changes made on this page will not take effect until each iPad downloads the updated menu through the Download Changes From Slice option', and knowledge-hub/register-settings repeats 'If you use multiple Register iPads, you must download changes on each device.' The only status indicator lives on the device itself (Settings > Slice Support > 'View your Connection Status to confirm your Register is online and connected'). There is no fleet view of terminals, printers or KDS, no remote reboot, no software-version visibility and no staged rollout. https://slice.com/knowledge-hub/owners-app-web-register/ · retrieved 2026-08-08
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
Verified: 'Their phone number appears on your screen, and if they've ordered before, you'll see their name and order history.' The dossier's limitations are real and if anything understated — the doc also notes the customer info disappears once the call ends and simultaneous calls queue rather than ring independently. https://slice.com/knowledge-hub/register-caller-id/ · retrieved 2026-08-01 adversarially verified
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
Upheld and re-sourced, this being the open-API conclusion-flipping cell. I fetched developers.slicelife.com myself: it serves Slice's consumer marketplace content — city browsing, pizza types, support, careers — with no API reference, no OpenAPI spec, no sandbox and no developer resources of any kind. The Knowledge Hub index has no API section either. The absence is affirmative rather than merely unfound: the host that would carry a developer portal exists and carries none. https://developers.slicelife.com · retrieved 2026-08-02 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
No API access is included in either membership because no operator-obtainable API is published at all - the developer subdomain serves the consumer ordering homepage - so the base subscription bundles no programmatic access at any price. https://developers.slicelife.com/ · retrieved 2026-09-06 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 free sandbox is by definition something a developer can obtain publicly, and every Slice-controlled developer-facing host either serves consumer marketing or refuses every path, so no test environment with seeded data is obtainable without a live paid shop. https://developers.slicelife.com/ · retrieved 2026-09-06 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
Slice's merchant agreement defines the access model for Slice POS Connect as per-user logins and passwords restricted to the pizzeria's own employees or contractors, under a licence that bars building a product against it or using it for anyone else's benefit - the opposite of scoped, operator-granted, individually revocable third-party app grants. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-06 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
Slice states that its integration with third-party providers is inbound-only, and it publishes no callback, subscriber-URL or event documentation on any host it controls, so an integrator has nothing to subscribe to and no push to receive. https://slice.com/knowledge-hub/online-ordering-third-party-orders/ · retrieved 2026-09-06 adversarially verified
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, retry and replay are properties of a documented outbound event stream; Slice documents no such stream and no delivery channel whose reliability could be specified. https://slice.com/knowledge-hub/online-ordering-third-party-orders/ · retrieved 2026-09-06 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
Third-party orders do inject into Order Management, but through Slice-operated private integrations — no public write API is offered to an operator or third-party developer. https://slice.com/knowledge-hub/register-third-party-orders/ · retrieved 2026-08-01
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
Slice documents a genuine two-way path for exactly one object - customers can be imported from and exported to CSV in the Owner's App (web) - but it is a browser upload and download capped at 10,000 rows per import, not the API round-trip this claim requires, and no write path at all is documented for orders, menu, employees or inventory. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-09-06 adversarially verified
API rate limits are published as specific numeric quotas with documented throttling behavior and headers.
extensibility-published-rate-limits
Rate limits are a property of published API reference documentation, and Slice publishes none on any host it controls - the developer subdomain serves the consumer ordering homepage - so there are no numeric quotas, throttling behaviour or headers to read. https://developers.slicelife.com/ · retrieved 2026-09-06 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 count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. 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 and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. 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
'Integrates with 30+ delivery apps including DoorDash, Grubhub, and Uber Eats' with no separate tablet or re-keying. Slice never states whether these are first-party certified or brokered through paid middleware, and the integration is one-way inbound only. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-01
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Slice does name middleware endpoints, but in the opposite direction to the claim. Online Ordering setup lists order transmission methods as 'iPad or other order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)', and knowledge-hub/settings documents a 'Point of sale integrations' section where 'Available integrations include Square, Clover, and Facebook'. Shortfall: these route Slice Online orders OUT to whatever POS the shop already runs, for shops that are not on Slice Register. Slice Register itself is documented nowhere as a supported endpoint for Deliverect, Chowly, Otter or Checkmate; knowledge-hub/register-third-party-orders describes the marketplace integration as one-way with menus 'controlled by Slice'; and there is no public API - I re-tested the host the record cites, and https://developers.slicelife.com returns the same 51.5KB consumer-storefront shell as a fabricated subdomain (zzznotreal9.slicelife.com, also HTTP 200, byte-identical layout), so it is a wildcard, not a developer portal. https://slice.com/knowledge-hub/online-ordering-getting-started/ · retrieved 2026-08-08
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
No QuickBooks Online or other GL connector is named anywhere. Accounting output is manual CSV download from the Owner's App Financials section. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
One named destination exists where previously none did: Homebase, integrated as a Time Clock app on the Register iPad. Shortfall: the claim asks for at least two named payroll providers, and the hours are captured directly in the partner's system rather than exported by Slice — there is no Slice-side export file, no documented field mapping, and no second provider. https://slice.com/knowledge-hub/homebase-partnership/ · retrieved 2026-08-02
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
The merchant agreement's portability clause defines what an operator is entitled to get out as a one-time, on-request handover in a thirty-day window after the contract ends; in-product, transaction-level data is a CSV pulled by hand from the Owner's App reporting UI, and the one scheduled delivery Slice does document is a daily Sales Summary email arranged by phoning an account manager - a summary sent to a recipient list, not raw transaction data landing in an operator-controlled S3 bucket, SFTP endpoint or warehouse share. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-06 adversarially verified
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
'Integrations' is a checkbox on the pricing page, but no browsable, self-install integrations marketplace exists on any Slice property. https://slice.com/pricing · 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
Slice's documented extensibility surface is a fixed picker of named third-party connections, scoped by the vendor to managing those connections and nothing else; there is no place to define a custom field on a POS object and no vendor-hosted scripting or rules engine, and the Owner's App Connect page routes anything the product does not already do to a live chat or a feature-suggestion form. https://slice.com/knowledge-hub/settings/ · retrieved 2026-09-06 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
Every embed Slice documents hands the customer to Slice's own ordering UI from someone else's domain - a Smart Button or popup snippet pasted into the site's head tag, a Classic Button ordering link, or a Slice-built Slice-hosted site - which is the inverse of a third-party front end driving Slice's transaction engine, and no transaction API exists for one to call. https://slice.com/knowledge-hub/owners-app-web-website-tools/ · retrieved 2026-09-06 adversarially verified
The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.
extensibility-api-versioning-deprecation
No API, no changelog, no deprecation policy. The Register app has a 'What's New' in-app notice, which is not an API policy. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-08-01
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 CSV download exists for Orders, Order Activity, Tax, Sales Mix and Sales Summary. Customers, loyalty balances, menu and payments metadata are not documented as exportable, and no contract-end export process is described. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
Annex 3 (Slice POS Terms), Offline Transactions: 'Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline. Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored.' Shortfall: offline operation is documented only as a contractual permission covering order-taking and queued payment. Neither the agreement nor any of the 45 Knowledge Hub articles says kitchen ticket routing or customer receipt printing continues offline, and the same Annex states 'Slice Register requires a consistent wired or wireless broadband connection to the Internet.' https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Annex 3 (Slice POS Terms), Offline Transactions: 'Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored.' That is store-and-forward, not a cash-only fallback. Limits are stated in the same clause: 'Slice reserves the right to limit the number of offline transactions that may be queued' and 'Unless otherwise specified in an Order Form, offline transactions may not exceed $100 per transaction.' https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
Annex 3 (Slice POS Terms), Offline Transactions: 'Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register and/or Slice Standalone Payments is offline.' The same clause publishes the cap: 'offline transactions may not exceed $100 per transaction' unless an Order Form specifies otherwise, plus 'Slice reserves the right to limit the number of offline transactions that may be queued' (a reserved rather than numeric cumulative limit). Loss on a post-restoration decline sits entirely with the merchant. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
CLAIM: 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). VERDICT: no (moved from unknown). EVIDENCE: Slice's documented architecture is per-iPad islands even while ONLINE. Register > Settings: 'Download changes from Slice: Sync updates made in the Slice Owner's App (web) to this iPad. If you use multiple Register iPads, you must download changes on each device.' Each iPad authenticates separately ('Choose the Register profile if you have more than one terminal') and its printers, payment terminals and cash drawer are configured on that device. The only documented offline mode is device-local and monetary: Annex 3, 'Transactions initiated offline will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored ... offline transactions may not exceed $100 per transaction' - a per-device queue tied to 'the applicable Hardware', not shared state. CONTROLS: 'local server' 0, 'back-office server' 0, server 0, peer 0, partition 0 in all three corpora. The local network is mentioned exactly once and only as a printer-discovery permission: 'make sure it has permission to find devices through the Local Network.' BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-09-18 adversarially verified
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
Annex 3 (Slice POS Terms) documents a device-local store-and-forward queue: offline-initiated transactions are 'queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored', capped at $100 per transaction. Shortfall: that queue is the only local processing Slice documents. No on-premise server, edge appliance or local transaction engine appears in the agreement or in any of the 45 Knowledge Hub articles; the same Annex states 'Slice Register requires a consistent wired or wireless broadband connection to the Internet', and the only on-site network device mentioned is a 'Slice-provided wireless router' which Slice expressly says does not provide Internet access. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
Upheld. Slice ships no KDS, so the claim reduces to kitchen-printer routing during an outage. Annex 3's Offline Transactions clause -- the only genuine disconnected-mode statement Slice publishes -- covers queued payment authorization and a $100 per-transaction cap and says nothing about printing. Read to its end, Annex 3's Telecommunications section holds exactly two clauses (Internet Connection, Offline Transactions) and that pair is the only published statement of offline scope in the whole corpus; it never says whether order creation, modifiers, cash tender or kitchen printing survive an outage. Every other use of 'offline' in the corpus means an in-person Register order as opposed to an online one (e.g. owners-app-web-financials: 'Offline Orders (via Slice Register): Total number of orders entered and paid for through Slice Register'), so none of them is evidence here. Printers are Bluetooth-paired to the iPad (online-ordering-getting-started; Epson TM-m30III only), which makes local printing plausible, and the contract does affirmatively permit conducting 'point of sale activities offline' -- but neither statement says kitchen tickets continue to print, and a printing capability may not be inferred from a payments clause. Would resolve: one KB or release-note sentence stating that kitchen tickets print from a queued offline order. || 326th: MERGE HOLD (proposed no/B, held unknown): a capability claim, and the evidence is only that no offline statement is published; Annex 3 shows Register does take offline transactions, so offline printing cannot be excluded from silence. PROPOSAL AS WRITTEN: CLAIM: kitchen display and/or kitchen printer routing continues to function while offline. VERDICT: no (moved from unknown). EVIDENCE: there is no KDS at all - 'KDS' 0, 'kitchen display' 0 in the census, 'bump bar' 0, 'expo screen' 0 - and the printing path carries no offline statement anywhere. Printing is configured per iPad (Receipt Settings; 'Enable Automatic Printing: Register Orders for Kitchen and Automatic Printing: Online Orders for Kitchen'; 'Automatic Printing: Third-Party Orders'), and the only failure guidance Slice publishes is connectivity troubleshooting: 'Check the WiFi connection - Ensure your iPad and printer are connected to the same network', 'Check the Bluetooth connection', 'tap Discover New Printers in the Slice Register app.' Annex 3's offline provision covers transactions and authorization only and never mentions printing or the kitchen. Consistent with this record's existing reliability-printer-fallback = no and reliability-offline-feature-matrix = no. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. || 329th: 329th: three new surfaces probed, none carries an offline-printing statement, so the 326th hold stands. (1) APP STORE PUBLISHER CENSUS. itunes.apple.com/lookup?id=699705246&entity=software returns Slice Solutions, Inc.'s complete iOS catalogue - exactly four apps: Slice - Order Local Pizza (com.mypizza.myi 7.13.0), Slice Driver (com.slicelife.drivers-app 2.6.0), Owner's Portal by Slice (com.slicelife.owners 4.10.0, 2026-09-15) and Slice Register (com.slicelife.ros-register 6.1.1, 2026-09-07). Slice Register is iPad-only (4 iPad screenshots, 0 iPhone) and its 'What's New' is 'Bug and crash fixes', so the release-note channel says nothing. Its store description does carry a CLOSED hardware enumeration for the POS - 'No unnecessary extras or expensive add-ons, just everything you need. iPad / Stand / Credit card terminal / Cash drawer / Receipt printer / Kitchen printer' - which confirms a kitchen printer ships in the standard kit but says nothing about its behaviour during an outage. (2) All four Slice Register iPad screenshots were downloaded at 1600x0w and read as images: the order-entry grid with the To go / Delivery / Pick-up / Dine in tabs, the cross-channel order list (Slice / DoorDash / Grubhub / Slice Register / Slice Phone rows with 'Orders' and 'Dispatch' tabs and '3 Other Orders Auto-Confirmed'), the pizza Type/Toppings/Extras builder with Full / Left half / Right half placement, and Cash Management > Reports, whose report list is closed at three - 'Sales Summary Report', '3rd Party Orders Report', 'Online Detail Report', each with View and Print. No connectivity banner, no offline indicator, no printer-status screen. (3) DEAD HOSTS, recorded so nobody re-probes them: support.slicelife.com and www.sliceregister.com both return HTTP 200 but are soft catch-alls that serve the slice.com CONSUMER homepage (same 13,210-byte body, 'Order Pizza Delivery Online & Support Local Pizzerias'), so neither is a separate operator KB; status.slicelife.com 301s to atlassian.com/software/statuspage, i.e. Slice publishes no status page at all and there is no incident history to mine for outage behaviour. Retrieved 2026-09-18. adversarially verified
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
VERDICT moved to no: the prior note's blocker was that 'a settings page that never claims to be exhaustive is not a positive exclusion'. The shipped configuration form is exhaustive by construction. EVIDENCE: the owners.slicelife.com Turbopack bundle (fixpoint chunk crawl, 21 chunks, 7.33 MB, 3,974 i18n keys) carries the entire Printer settings screen. `register.printing.header.content` states the scope in the vendor's own words: 'Print settings define when an order prints and the number of copies to be printed. You can create, edit, or remove print settings below.' The form's complete field list is `register.printing.form.name`, `register.printing.form.printMode` and `register.printing.form.quantity` (1-10), and the print-mode option set is closed at two values, `register.printing.table.dropdown.printMode.afterPayment` = 'After payments' and `.incremental` = 'Incremental'. The table columns are Name / Print mode / Print quantity / Actions. There is no backup-printer field, no failover target, no station fallback and no unreachable-printer alert anywhere in the screen. The sibling `register.printerTemplates.*` screen is likewise closed at two tabs, Customer receipt and Kitchen ticket. BOUND/CONTROLS over the 7.33 MB corpus, tokenised: `failover` 0, `backup` 0, `redundant` 0, `offline` in a printing context 0. POISON NAMED: `fallback` scores 41 and every occurrence is React/i18n locale-fallback and font-fallback library code, never a printer. Bound: this enumerates the printer CONFIGURATION surface (the Owner's Portal), the only place Slice lets an operator define print behaviour; the Register iPad's own runtime behaviour is not directly observed. Retrieved 2026-09-17. https://owners.slicelife.com/ · retrieved 2026-09-17 adversarially verified
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
CLAIM: 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). VERDICT: no (moved from unknown) - this is a pure documentation claim and the documentation is absent from a complete publisher corpus. EVIDENCE/CONTROLS: conflict 0 in the census, 'last write' 0, merge 0, partition 0, and 'reconcile' 3 hits all of which are cash-drawer reconciliation, in all three corpora. ('conflict' does score 13 on the site and 10 in the contract and every one is 'conflict of law' / 'conflicts with' - poison.) What Slice actually documents is a manual, operator-pulled, one-way sync with no conflict language at all: 'Download changes from Slice: Sync updates made in the Slice Owner's App (web) to this iPad. If you use multiple Register iPads, you must download changes on each device', and 'Changes made in Settings take effect immediately.' Annex 3 says only that queued offline transactions are 'submitted for authorization when Internet connectivity to the applicable Hardware is restored', and says nothing about competing edits. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-settings/ · 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
I checked independently. Register Settings offers only a Slice Support 'Connection Status' check to 'confirm your Register is online and connected'; the in-store-ordering product page and the POS page contain nothing on outages. An exhaustive operator Knowledge Hub with zero offline content is affirmative evidence that no offline matrix is published — though the underlying capability itself remains correctly scored unknown elsewhere. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-08-01 adversarially verified
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
The 325th left this unknown after finding slice.statuspage.io/api/v2/summary.json = 401 and status./trust.slicelife.com = *.slicelife.com wildcard soft-200s. NEW AND DECIDING: the PUBLISHER side is now censused and contains no status page and no link to one. VERDICT: no (moved from unknown). EVIDENCE: all 74 slice.com pages enumerated via wp/v2/pages hold no status, trust, uptime or system-status page - the support-shaped entries are exactly /support/, /support/24-7-365-customer-support/, /support/community-of-owners/, /support/dedicated-account-management/ and /support/full-service-setup-and-training/ - and none of the 116 Knowledge Hub documents links to one. The word 'uptime' occurs exactly once in the entire corpus and it is a disclaimer in the Pizzeria Agreement putting the burden on the operator: 'availability, transmission range and uptime of Restaurant's wireless equipment, for which Restaurant and Restaurant's Internet service provider are solely responsible.' 'SLA' scores 0 word-boundary hits. The in-product substitute Slice ships is per-shop and binary, not public or per-component: Register > Settings, 'Slice Support: View your Connection Status to confirm your Register is online and connected.' Together with the 401 on the Statuspage tenant, nothing public and per-component exists. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/ · retrieved 2026-09-18 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
The standard Pizzeria Agreement (updated 2026-03-05) is published in full and contains no uptime percentage, no service level and no service credit -- the strings 'service level' and 'service credit' do not occur in its ~178KB of text. The General Terms state the opposite of a commitment: 'SLICE DISCLAIMS ANY WARRANTY THAT THE PLATFORM WILL BE AVAILABLE AT ALL TIMES, FREE OF ERRORS OR THAT EVERY ERROR IN THE PLATFORM OR PROBLEM RAISED BY RESTAURANT WILL BE RESOLVED. THE PLATFORM, THE SERVICES, AND THEIR COMPONENTS... ARE PROVIDED "AS IS" AND "AS AVAILABLE."' Annex 3 adds that Slice bears no liability for 'any termination, suspension, delay or disruption of Slice Register' arising from connectivity issues. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
The vendor publishes written post-incident reports or root-cause summaries for major outages.
reliability-incident-postmortems
CLAIM: the vendor publishes written post-incident reports or root-cause summaries for major outages. VERDICT: no (moved from unknown). EVIDENCE: with no public status page (see reliability-public-status-page) there is no incident feed to post to, and the publisher corpus holds no postmortem. Controls: postmortem 0, post-mortem 0, 'root cause' 0, RCA 0, outage 0 in all three corpora. 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 respectively are the legal word 'incidental'; the real ones are the Pizzeria Agreement's defined term 'Security Incident', which obliges the RESTAURANT to notify SLICE within 48 hours with 'a description of the Security Incident' and mitigation steps - the duty runs the wrong way for this claim. The 30 release notes in the census are feature announcements, never incident reports, and the blog post type carries no outage write-up. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-18 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
Confirmed verbatim: 'We answer the phone 24/7/365 — for you and your customers' and 'No AI, robots, or chat bots — fully human support'. Included on both memberships. https://slice.com/support/24-7-365-customer-support/ · retrieved 2026-08-01 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
Citation re-pointed 2026-08-08: slice.com/in-store-ordering no longer exists in the site's page index (all 71 pages enumerated via /wp-json/wp/v2/pages). Both quotes survive on the live Slice Register product page - body copy 'Our team comes to your shop to install your hardware and train your staff in person. And whenever you need help - day or night - a real human always answers', with badges LOCAL TEAMS / ON-SITE SETUP / PERSONALIZED TRAINING / 24/7 SUPPORT, and the FAQ 'Our team comes to your shop, sets up your hardware, and trains your staff in person. You do not need to do a long self-install. We stay until your team feels ready.' Corroborated at https://slice.com/support/full-service-setup-and-training/: 'Our in-person implementation team ensures that your equipment is properly set up and ready to handle your next dinner rush' and 'white-glove implementation, a dedicated Account Manager, and 24/7/365 live support are built in'. Held at partial under the differentiator grade floor: these are vendor product pages, not documentation - nothing in the 45-article Knowledge Hub describes the on-site process. Shortfall unchanged: no coverage map or market list ('We also have in-market teams available to help in person' is unquantified), no published go-live timeline, and the service reaches only $399 Family shops, since Point of Sale and the $1,000 implementation fee appear only in that column on https://slice.com/pricing/. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-08 adversarially verified
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Annex 4 (Hardware Terms) section 8 gives a six-month limited warranty on 'Designated Hardware' with an advance-exchange flow: Slice ships the replacement first and 'Restaurant shall return the malfunctioning Designated Hardware to Slice within thirty (30) days of Restaurant's receipt of the replacement Designated Hardware.' Shortfalls: (1) no turnaround time is stated for Slice's side -- the 30 days is the merchant's return deadline, not a dispatch commitment; (2) it applies only to Designated Hardware, meaning hardware acquired before 16 April 2024 or 'designated as purchased... on the Order Form'; (3) for the standard rented hardware Slice merely 'may elect to replace any Hardware with such other Hardware as Slice deems appropriate', and Annex 4 section 5 'EXPRESSLY DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS OR IMPLIED, IN CONNECTION WITH THE HARDWARE'. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.
reliability-backup-restore
CLAIM: operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery. VERDICT: no (moved from unknown) - neither limb. CONTROLS: RPO 0, RTO 0, 'point in time' 0, snapshot 1 (a marketing 'snapshot of your sales'), archive 0 in all three corpora. 'backup' scores 1 in the census and it is Flex Delivery marketing ('a simple way to get backup when you need it'), plus the marketing page /products/backup-delivery-drivers/ - a driver-supply homonym, not data. 'restore' scores 1 and it is the bulk menu action 'Mark Items In Stock: Restore availability for all selected items.' POSITIVE EVIDENCE THE OTHER WAY: the contract's installation-services clause EXCLUDES recovery from what Slice will do - the installation service does not include '(ii) migration or transfer of data ... (v) virus removal or disaster recovery'. What Slice does offer is report and list EXPORT, a different thing already scored elsewhere in this record: CSV downloads of Order Activity, Orders, Tax, Sales Mix and Sales Summary, and a customer-list export/import capped at 10,000 rows per import. No operator-triggered backup, no restore of a prior configuration state, no recovery objective. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/owners-app-web-financials/ · 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
CLAIM: 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. VERDICT: no (moved from unknown). EVIDENCE OF ABSENCE: across all three corpora the word-boundary counts are PCI 0/0/0, 'Payment Card Industry' 0, P2PE 0, 'SOC 2' 0, SOC2 0, 'ISO 27001' 0, token 0, tokenization 0, AOC 0, 'Attestation of Compliance' 0, SAQ 0, attestation 0. That includes the entire 177,854-character Pizzeria Agreement of 2026-03-05 - whose Annex 7 is titled 'Scheme Rules' and incorporates the Adyen / Wells Fargo Acquiring Addendum, and whose Annex 8 defines 'Security Incident' and imposes data-security duties on the RESTAURANT ('Restaurant shall implement and maintain reasonable and appropriate physical, technical and organizational safeguards ... notify Slice in writing within 48 hours'), never on Slice - and the whole 74-page slice.com page index, which contains no /security, /trust, /compliance or trust-centre page. The only security statement Slice publishes is the consumer-grade FAQ 'How secure are payments?': 'Slice partners with industry-leading payment processors to ensure all transactions are secure and encrypted. Your payment information is protected and used only for processing orders - it is never shared or stored beyond what's necessary to complete the transaction.' That sentence is the ONLY occurrence of encrypt* in any corpus, it names no standard, no version, no SAQ type and no report, and it attributes the security to the processors rather than to Slice. This is consistent with this record's existing commercial-pci-dss-4-controls partial, which rests on a two-step-verification release note and not on any attestation. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/ · retrieved 2026-09-18 adversarially verified
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Role-based access is real — per-action permissions and a four-digit PIN for login and manager approval. But a four-digit PIN is single-factor, and MFA on Owner's App back-office logins is not documented. https://slice.com/knowledge-hub/register-employee-permissions/ · 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 free, public, login-free Knowledge Hub covers Register, Online Ordering, Owner's App and Delivery, and Slice markets an 'Owner Learning Center'. No terminal training/practice mode is documented. https://slice.com/knowledge-hub/ · retrieved 2026-08-01
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
OWNER RULING 2026-09-18 (Q5): a cloud-hosted POS with no in-store master/primary terminal role scores `no` on reliability-failover-terminal-role rather than unknown. Landed no/B on the evidence below, which establishes that architecture. Retrieved 2026-09-18. PRIOR EVIDENCE: Upheld. The only role concept Slice publishes is the Owner's Portal 'Front of House' / 'Back of House' profile in knowledge-hub/order-manager-kit, which changes the landing screen, plus slice-register-getting-started's 'Choose the Register profile if you have more than one terminal' -- a cloud-assigned per-iPad station identity, not a master/server election. No document in the 500-file corpus describes a primary terminal, a local server, or promotion of a secondary device, and 'failover' occurs zero times. Annex 3 treats each unit independently ('Internet connectivity to the applicable Hardware'), consistent with there being no master to fail over from -- a cloud-only POS has nothing to promote -- but Slice never says so, and inferring the architecture is not documenting it. Would resolve: a statement that Register operates cloud-only or peer-to-peer with no designated primary terminal. || 326th: MERGE HOLD (proposed no/B, held unknown): Slice Register has no local master or server role at all (cloud-backed iPads configured independently), so the claim does not apply; held unknown per the lacks-entirely rule rather than no. PROPOSAL AS WRITTEN: CLAIM: any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. VERDICT: no (moved from unknown). EVIDENCE: the claim presupposes a local master and Slice Register has none - it is an iPad app talking to Slice's cloud, each device authenticated and configured independently ('Choose the Register profile if you have more than one terminal'; 'If you use multiple Register iPads, you must download changes on each device'). CONTROLS: 'primary terminal' 0, failover 0, 'fail over' 0, standby 0, 'local server' 0, server 0, hub 6 (all 'Knowledge Hub') in all three corpora; 'master' scores 0 in the census and 34 on the site, every one 'MasterCard' or the lead-form field 'Master Address' - poison. The only degraded mode Slice publishes is Annex 3's per-device offline transaction queue, capped at $100 per transaction and explicitly tied to 'the applicable Hardware', i.e. each device alone. NOTE FOR THE OWNER: I read this as the architecture the claim describes being absent rather than as a failed implementation of it; if this record's convention is to hold such cells as 'claim does not apply', downgrade this row to unknown and keep the evidence. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. || 329th: 329th: new corroboration for the architecture reading, still no vendor statement, so the 326th hold stands. The App Store listing for Slice Register (com.slicelife.ros-register 6.1.1, 2026-09-07; publisher census of Slice Solutions, Inc. = 4 iOS apps total, consumer app + Slice Driver + Owner's Portal + Register) enumerates the entire POS kit as 'iPad / Stand / Credit card terminal / Cash drawer / Receipt printer / Kitchen printer' - a closed hardware list with no local server, no back-office PC and no master terminal in it, and the app is iPad-only with no macOS or Windows companion build. That is consistent with a cloud-only architecture having nothing to promote, but it is still an inference about the architecture rather than Slice documenting a role-election behaviour, which is exactly why the 326th held this cell. Also probed and dead: support.slicelife.com and www.sliceregister.com are soft-200 catch-alls serving the slice.com consumer homepage; status.slicelife.com 301s to atlassian.com/software/statuspage. Retrieved 2026-09-18. https://slice.com/knowledge-hub/register-settings/ · retrieved 2026-09-18 adversarially verified
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
Slice documents what actually happens when the connection drops, and it is manual Wi-Fi recovery, not a failover. Its own FAQ 'How do I reconnect to Wi-Fi if I'm having internet issues?' instructs the operator to forget and rejoin the network, restart the iPad and router, and if that fails to call support 'and we'll help you get back online' - a shop that had automatic cellular failover would not be offline at that point. Every other connectivity instruction is Wi-Fi only (online-ordering-getting-started: 'Connect to Wi-Fi: Go to Settings Wi-Fi and connect to your shop's network'; register-settings troubleshooting begins 'Check the WiFi connection'). The hardware side matches: the live product page calls the kit 'the complete system' and the only network device in it is a router, and the 2026-01-21 hardware price list prices every rental line including Network Router with no cellular modem or backup-connectivity item. Annex 3 of the merchant agreement then puts the connection wholly on the merchant - Slice Register 'requires a consistent wired or wireless broadband connection', the Restaurant 'is solely responsible for obtaining such connection', and Slice provides no Internet access even where it supplies the router. https://slice.com/knowledge-hub/ · retrieved 2026-09-05 adversarially verified
Commercial, compliance & data ownership
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
The pricing page labels both memberships 'Month-to-Month' with 'Zero locked-in contracts' and states no minimum term, but that is a sales page rather than documentation. Named shortfalls: no merchant subscription agreement is publicly readable - the public Terms of Service (https://slice.com/terms-of-service/, retrieved 2026-08-06) says only 'You may cancel your account at any time by sending us an email' and states that services 'may be governed by other terms and conditions you agree to when you sign up for such Services', so the actual term, renewal and notice provisions for the paid $399/month Family membership sit in unpublished Services Terms; and the disposition on cancellation of the $1,000 implementation fee and the bundled hardware (iPad, Epson printers, Verifone terminal, Meraki router) is undisclosed, which is why the sibling early-termination cell remains unknown. Searched: slice.com/pricing, slice.com/terms-of-service, slice.com/knowledge-hub help centre (no billing, subscription or cancellation article), sliceregister.com, and the sites.google.com/slicelife.com Register help site, which redirects to a Google login. https://slice.com/pricing/ · retrieved 2026-08-06
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
General Terms, 'Early Termination Fee': if the Restaurant terminates a Service before the end of the initial or renewal Order Form Service Term other than for Slice's material breach, it must immediately pay amounts due (including Annex 4 hardware return fees) plus 'an amount equal to the aggregate fees (calculated without any discounts) that would otherwise have been payable by Restaurant during the initial Order Form Service Term or relevant renewal term, as applicable, for all terminated Services (including, without limitation, any subscription Fees and Hardware Fees, and excluding per transaction fees)'. The agreement calls this 'a reasonable estimate of the damages' and 'a genuine estimate of damages and not a penalty' -- liquidated damages -- and adds that paying it 'shall not limit Slice's right to seek other remedies available under this Agreement or at law'. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
General Terms, Term: 'After the initial Order Form Service Term ends... the Order Form Service Term for each Service will automatically renew for consecutive periods of the same duration as the initial Order Form Service Term, unless either party provides the other with at least thirty (30) days' written notice of its intent not to renew the then-current Order Form Service Term for such Service.' A default is published for silent Order Forms: 'the initial Order Form Service Term for such Service will be one month, and such Order Form Service Term will renew for consecutive one-month periods' on the same 30 days' notice. Subscriptions are expressly auto-renewing under the Subscription Fees clause. The per-merchant term length itself still comes from the Order Form. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
2.90% + $0.30 Slice processing is the single published rate on both memberships, the terminal ships in the bundle, and 'One payout for all orders' consolidates online, phone and in-store funds. No third-party processor option is documented. https://slice.com/products/point-of-sale-for-pizza-shops/ · retrieved 2026-08-01
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
Slice publishes a single flat blended rate (2.90% + $0.30) on both plans. No interchange-plus option is offered or priced. https://slice.com/pricing · 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
General Terms, Fees: Fees are 'subject to the possibility for Slice to revise such Fees from time to time in its sole discretion, upon written notice to Restaurant (email is sufficient). In the event that Slice implements a change to its Fees, Restaurant may terminate the Services subject to such revised Fees upon written notice to Slice within fourteen (14) days of receiving the Fee change notice from Slice'; silence is deemed acceptance. Shortfalls: no cap on the size or frequency of increases and no restriction to pass-through interchange or network changes; the exit is a 14-day window rather than an open right; and the agreement nowhere states that exercising it waives the Early Termination Fee, so 'penalty-free' is not established. Card processing rates themselves sit in the Order Form and the Adyen/Wells Fargo Acquiring Addendum (Annex 7), which imposes no merchant-side rate cap. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
Exact figures published with no sales call: $399/mo + $2.00/order (Family), $39/mo + $3.00/order (Online), no per-order fee under $10, 2.90% + $0.30 processing, $1,000 implementation. Caveat: pricing for an additional terminal (the Order Manager Kit second iPad) is not published. https://slice.com/pricing · 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
The pricing page offers exactly two all-or-nothing bundles. Online ordering, phone ordering, loyalty, marketing, Flex Delivery and the POS cannot be bought or cancelled individually — dropping the POS means dropping to the $39 Online tier and losing phone ordering, Flex Delivery and the account manager. https://slice.com/pricing · 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
Annex 4 (Hardware Terms) governs all hardware acquired after 16 April 2024: 'Any Hardware (including, without limitation, printers, tablets or other hardware) provided by Slice will remain Slice's sole property'; 'Restaurant shall have no right, title or interest in or to the Hardware except the right to possession and use thereof during the applicable Order Form Service Term'; the merchant pays a 'non-refundable monthly fee set forth in the applicable Order Form (Hardware Fee)'; and on termination 'Restaurant shall promptly return the Hardware to Slice... (at Restaurant's expense)', exposed to a Restocking Fee of up to $100.00 and a Failure to Return Fee of up to $349.00 per item. That is a rental and it is the default. A purchase path survives only for hardware 'designated as purchased (or other similar term) on the Order Form' (Annex 4 sections 7-10, the Designated Hardware provisions), a negotiated designation for which no outright price is published on slice.com/pricing/ or anywhere in the 76-page site. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
The devices are genuinely standard — Apple iPad, Epson TM-m30III and Epson U220 — but Slice does not document supporting operator-supplied equivalents, and no compatibility list is published. https://slice.com/knowledge-hub/slice-register-getting-started/ · 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
'$1,000 implementation fee' published on the pricing page for Family Membership; Online Membership shows none. https://slice.com/pricing · 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 CSV download without a support ticket for Order Activity, Orders, Tax, Sales Mix and the Sales Summary. Line-item detail depth is unclear, and labor data does not exist to export. https://slice.com/knowledge-hub/owners-app-web-financials/ · retrieved 2026-08-01
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
Owner's App (web) > Customers > Profiles documents both directions: 'Import: Add your customer database from another system, with a maximum of 10,000 customers per import. The file must be a CSV in the format shown in the CSV Template' and 'Export: Download your Slice customer database for further analysis or record-keeping.' Shortfall: that is the guest record only. Loyalty exists as a feature (menu items carry a 'Loyalty reward' flag and reports show 'loyalty rewards' as a discount category) but no point ledger or per-customer balance is exportable or even displayed anywhere in the Owner's App documentation; no gift-card product is documented in any of the 45 Knowledge Hub articles, so there is no gift-card liability balance to export. The contract adds only a vendor-mediated route: on request within 30 days of termination 'Slice will make Restaurant Data available to Restaurant for export or download'. https://slice.com/knowledge-hub/owners-app-web-customers/ · retrieved 2026-08-08
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
General Terms, 'Portability and Deletion of Restaurant Data': 'Upon request by Restaurant made within thirty (30) days after the effective date of termination or expiration of this Agreement, Slice will make Restaurant Data available to Restaurant for export or download. After that thirty (30) day period, Slice will have no obligation to maintain Restaurant Data, and may thereafter delete or destroy all copies of Restaurant Data maintained by Slice.' A defined window with a defined cutoff rather than immediate loss of access; the merchant must ask within the window and the export is vendor-mediated. https://slice.com/online-restaurant-agreement/ · retrieved 2026-08-08
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
Slice publishes no merchant terms, so no clause states that the operator owns its transaction and customer data or constrains Slice's use of it. The one published ToS grants Slice a 'world-wide, perpetual, irrevocable, royalty-free' license to submitted content — and Slice operates a consumer marketplace on the same guest data. https://slicelife.com/pages/terms-of-service · 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
Slice's own GitHub organisation, enumerated in full, holds exactly ten public repositories, eight of them forks; the only two originals are an AWS VPC Terraform module (Apache-2.0) and fetch-secrets, an AWS Secrets Manager helper (MIT). No POS source, no client SDK and no self-hosting artefact of any kind is published, and the product is sold only as a hosted service on Slice-supplied iPad hardware. https://api.github.com/orgs/slicelife/repos · retrieved 2026-09-06 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
CLAIM: 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. VERDICT: no (moved from unknown). Slice names no SAQ anywhere and never uses the words P2PE, tokenize or PCI. EVIDENCE OF ABSENCE: across all three corpora the word-boundary counts are PCI 0/0/0, 'Payment Card Industry' 0, P2PE 0, 'SOC 2' 0, SOC2 0, 'ISO 27001' 0, token 0, tokenization 0, AOC 0, 'Attestation of Compliance' 0, SAQ 0, attestation 0. That includes the entire 177,854-character Pizzeria Agreement of 2026-03-05 - whose Annex 7 is titled 'Scheme Rules' and incorporates the Adyen / Wells Fargo Acquiring Addendum, and whose Annex 8 defines 'Security Incident' and imposes data-security duties on the RESTAURANT ('Restaurant shall implement and maintain reasonable and appropriate physical, technical and organizational safeguards ... notify Slice in writing within 48 hours'), never on Slice - and the whole 74-page slice.com page index, which contains no /security, /trust, /compliance or trust-centre page. The only security statement Slice publishes is the consumer-grade FAQ 'How secure are payments?': 'Slice partners with industry-leading payment processors to ensure all transactions are secure and encrypted. Your payment information is protected and used only for processing orders - it is never shared or stored beyond what's necessary to complete the transaction.' That sentence is the ONLY occurrence of encrypt* in any corpus, it names no standard, no version, no SAQ type and no report, and it attributes the security to the processors rather than to Slice. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/online-restaurant-agreement/ · retrieved 2026-09-18 adversarially verified
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
Release note dated 2026-02-05: 'Two-step verification adds an extra layer of security to your Owner's App account. After entering your password, a 6-digit code is sent by text to confirm it's really you logging in. Available on web and mobile.' The mechanism is described in owners-app-web-getting-started ('you will be asked to confirm your login with a one-time code sent to your mobile phone... You can turn two-step verification on or off from Settings in the Owner's App (web)'). Shortfalls against the claim: (1) it is opt-in and merchant-disableable, so it is not MFA for all access; (2) it covers the Owner's App only -- Register access is per-employee PINs (register-employee-permissions) with no MFA documented; (3) no payment-page script integrity monitoring per Req 6.4.3 / 11.6.1 is described for the hosted ordering pages; (4) the string 'PCI' appears nowhere in Slice's published material, including the 178KB Pizzeria Agreement, so none of this is framed as a v4.0.1 control. https://slice.com/release-notes-2/extra-protection-for-your-owners-portal-login/ · retrieved 2026-08-08
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
CLAIM: 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. VERDICT: no (moved from unknown). Slice publishes no trust centre and makes no attestation statement of any kind; its contract never offers a report on request. EVIDENCE OF ABSENCE: across all three corpora the word-boundary counts are PCI 0/0/0, 'Payment Card Industry' 0, P2PE 0, 'SOC 2' 0, SOC2 0, 'ISO 27001' 0, token 0, tokenization 0, AOC 0, 'Attestation of Compliance' 0, SAQ 0, attestation 0. That includes the entire 177,854-character Pizzeria Agreement of 2026-03-05 - whose Annex 7 is titled 'Scheme Rules' and incorporates the Adyen / Wells Fargo Acquiring Addendum, and whose Annex 8 defines 'Security Incident' and imposes data-security duties on the RESTAURANT ('Restaurant shall implement and maintain reasonable and appropriate physical, technical and organizational safeguards ... notify Slice in writing within 48 hours'), never on Slice - and the whole 74-page slice.com page index, which contains no /security, /trust, /compliance or trust-centre page. The only security statement Slice publishes is the consumer-grade FAQ 'How secure are payments?': 'Slice partners with industry-leading payment processors to ensure all transactions are secure and encrypted. Your payment information is protected and used only for processing orders - it is never shared or stored beyond what's necessary to complete the transaction.' That sentence is the ONLY occurrence of encrypt* in any corpus, it names no standard, no version, no SAQ type and no report, and it attributes the security to the processors rather than to Slice. BOUND/CONTROLS: three corpora, all re-derived by me today and all complete. (1) The Slice Knowledge Hub in full via slice.com WP REST: epkb_post_type_1 45/45 (x-wp-total: 45), epkb_post_type_2 30/30 release notes, echo_kb_faq 26/26, case-study 14/14, emergency 1/1 = 116 documents, 257,732 chars of stripped body text, covering Slice Register, Owner's App, Owner's App (web), Online Ordering, Slice Delivery, Slice Driver App, Slice Phone and the Homebase Time Clock. (2) The whole slice.com page tree: wp/v2/pages per_page=100 returns 74 pages and page 2 returns rest_post_invalid_page_number, so 74/74, 532,110 chars. (3) The standard customer contract, slice.com/online-restaurant-agreement/ ('Pizzeria Agreement', last updated March 5th 2026), 177,854 chars of stripped text including Annex 3 (Slice POS Terms), Annex 4 (Hardware Terms), Annex 7 (Scheme Rules / Adyen-Wells Fargo Acquiring Addendum) and Annex 8 (Data). Note slice.com sits behind a Cloudflare-style JS interstitial that 403s a plain browser-UA curl; it serves 200 once Sec-Fetch-Dest/Mode/Site and Upgrade-Insecure-Requests are sent. Controls are tokenised, case-insensitive and word-boundary, (?<![A-Za-z0-9])X(?![A-Za-z0-9]). POISON FOUND AND PUBLISHED, five traps: (a) in Slice's OWN vocabulary 'offline' means the IN-STORE ORDER CHANNEL, not disconnected - all 19 Knowledge Hub hits are report columns and tax rows like 'Offline Sales Subtotal - Register (POS) orders', 'Offline Tips (via Register)', 'Offline/register/phone'; a naive offline count reads as outage documentation and is not. (b) 'status page' has 5 KB hits and every one is 'the Shop Status page' (shop availability). (c) on slice.com 'SLA' scores 637 RAW substring hits and 0 word-boundary hits. (d) 'incident' scores 9 on the site and 9 in the contract, of which 8 and 5 are 'incidental'. (e) 'master' scores 34 on the site and every hit is either 'MasterCard' or the lead-form field 'Master Address'; 'break' scores 2 in the KB and both are 'this will break the integration'. Retrieved 2026-09-18. https://slice.com/knowledge-hub/ · retrieved 2026-09-18 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
Slice runs a consumer data-rights portal at privacy.slicelife.com covering diner CCPA/GDPR requests. No operator-facing in-app DSAR tooling and no publicly available DPA for restaurants were found. https://privacy.slicelife.com · 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
This marketing FAQ is the strongest accessibility statement Slice publishes and it is a screen-reader assurance with no standard, no version, no conformance level and no report behind it - not a VPAT or ACR - and it covers only the consumer web surface, while the kiosk half of the claim is placed in the future by the vendor's own '(coming soon)'. https://slice.com/products/pizzeria-websites/ · retrieved 2026-09-06 adversarially verified
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
The Register Sales Summary Report itemises both mechanisms as things the POS actually applies: 'Credit Card Surcharge - A fee charged when a customer pays with a credit or debit card' and 'Cash Discounts - Discounts applied to orders paid in cash', with Register Sales defined as gross sales 'minus refunds, discounts, and cash discounts'. owners-app-web-financials repeats them as report columns ('Credit Card Surcharges', '# of Credit Card Surcharges Collected', 'Cash Discounts', '# of Cash Discounts'). Shortfalls against the claim's compliance requirements: Slice's own wording applies the surcharge to debit cards, which the card networks prohibit, and no documentation describes automatic exclusion of debit or prepaid cards; no receipt-line or menu-board disclosure control is documented; no Knowledge Hub article covers enabling the surcharge or setting its rate; and the Pizzeria Agreement pushes the entire compliance burden onto the merchant -- 'Restaurant agrees that it shall not add a surcharge to transactions, except as expressly permitted by, and in full compliance with, applicable law and any relevant Scheme Rules.' https://slice.com/knowledge-hub/register-cash-management-and-reporting/ · retrieved 2026-08-08
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 154 values — 126 upheld, 27 downgraded, 1 upgraded. It separately resolved 95 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.implementation_fee | upheld | '$1,000 implementation fee' confirmed on the Family column; Online column shows none. source |
| pricing.contract_length | upheld | Both plans show 'Month-to-Month' and 'Zero locked-in contracts' on the pricing page. Note this is a marketing assertion — no merchant MSA is published to corroborate it. source |
| pricing.hardware | downgrade-to-partial | The base kit at $0 separate charge is verified, but the pricing page also carries 'Additional configurations available' with no prices, and three cost-bearing items are unpriced anywhere: the second iPad (Order Manager Kit), the NYC1 mobile card reader, and the per-delivery courier fee for Flex Delivery. 'Hardware costs $0' overstates a bundle whose add-on tier is entirely unpublished. source |
| pricing.software | upheld | Re-retrieved today, unchanged: '$399/month + $2.00/order' and '$39/month + $3.00/order', both with 'No per-order fee under $10', and '$1,000 implementation fee' on the Family column only. One correction to the record's feature split: Loyalty Rewards, Automated Marketing, Integrations, 24/7 Customer Service and Owner's Portal appear on BOTH columns — only Phone Ordering, Flex Delivery, Supplies and Account Manager are Family-exclusive alongside the POS and hardware. source |
| pricing.processing_rate | upheld | Re-retrieved today: '2.90% + $0.30' on both plan columns, and the POS product page independently states '2.9% plus $0.30 per transaction'. No interchange-plus option, no card-type differential and no monthly, PCI or statement fee appears anywhere on either page. source |
| api_posture.public_api | upheld | I fetched developers.slicelife.com rather than taking the record's word for it. The host resolves and serves Slice's consumer marketplace content — city browsing, pizza-type pages, support and careers links — with no API reference, OpenAPI spec, sandbox, OAuth model or developer resource of any kind. The Knowledge Hub index likewise has no API section. This is affirmative rather than unfound: the domain that would carry a portal exists and carries none. source |
| org.domains | upheld | Both listed domains are live and first-party, so the field is not wrong — but it is incomplete in a way worth recording: sliceregister.com resolves and 301-redirects to slicelife.partners/in-store-ordering, a third Slice-operated host neither listed nor cited anywhere in the record. Two further first-party hosts are used as evidence elsewhere in this file, privacy.slicelife.com and developers.slicelife.com. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| digital-loyalty-attach | yes / claimed — 'Every order earns pizza points toward free pizza' | downgrade-to-partial | The loyalty program is Slice's marketplace-wide diner program, not the operator's. The Slice App page gives the shop no configuration surface and never states who funds the free pizza, whether points are portable to the shop's own channels, or whether the operator can see or adjust a balance. A vendor-run diner loyalty scheme the operator cannot configure is not a 'yes' on native loyalty attach. source |
| guest-loyalty-native-email-sms | yes / claimed — Slice sends email, SMS and in-app natively | downgrade-to-partial | Sourced only to a marketing page, and the same page frames it as a done-for-you service ('Our marketing experts handle all emails, texts, and app messages — you don't lift a finger'). No operator-facing composer, audience builder, send scheduler, or consent surface appears in the Knowledge Hub. Native sending by the vendor on the operator's behalf is a managed service, not an operator messaging capability. source |
| digital-fulfillment-modes | yes / claimed — pickup, curbside, dine-in via QR, delivery | downgrade-to-partial | Marketing-page-only evidence, and it conflicts with product documentation: the Register docs define dine-in as counter-service orders that 'do not require customer information', with no table or check object. Pickup and delivery are documented; curbside and QR dine-in are claim-level with no supporting Knowledge Hub article. source |
| digital-menu-single-source | yes / documented — 'sync everywhere' including third-party platforms | downgrade-to-partial | The POS page text I fetched is narrower than quoted: 'Update your menu one time and it changes on your website, your app, and your Slice Register at the same time' — third-party is not in that sentence. Third-party menus are covered separately and are 'controlled by Slice', with the operator warned 'Do not edit third-party menus directly—this will break the integration', no per-item sync status, and 86ing that provably does not reach the marketplaces. Single source for three Slice-owned surfaces, brokered and unverifiable for the rest. source |
| delivery-menu-push | yes / documented — Slice menu is source of truth for third-party menus | downgrade-to-partial | Verified verbatim, but the same paragraph shows the operator has no control of the push: menus are 'controlled by Slice', direct edits 'will break the integration and cause service interruptions', and order edits 'need to be communicated with the third party'. There is no sync status, no rejection surface, and no operator-initiated publish. Vendor-operated menu maintenance is not a menu-push capability the buyer holds. source |
| order-capture-split-merge | partial / documented — 'divide amounts evenly or assign custom portions' | downgrade-to-unknown | The order-entry doc describes split TENDER, not split CHECK: it lets you 'divide the amount into equal parts', enter custom amounts, or 'apply the full amount to the payment method' across payment methods on one order. No second check is created, no items move, and merging is absent entirely. Splitting a payment is already scored under payments-split-tender; scoring it again as check splitting double-counts a capability that is not documented to exist. source |
| commercial-no-early-termination-fee | partial / claimed — 'Zero locked-in contracts' | downgrade-to-unknown | There is no publicly readable merchant agreement on any Slice property — the only published Terms of Service is diner-facing. A four-word marketing badge on a pricing page cannot establish the absence of a contract term, and it is silent on the fate of the $1,000 implementation fee and the bundled hardware on cancellation. This is unknown, not partial. source |
| commercial-hardware-purchase-outright | no / documented | downgrade-to-unknown | Confidence 'documented' is wrong — no Slice source affirmatively states hardware cannot be purchased outright. The pricing page says the opposite-adjacent thing, 'Additional configurations available', with no terms. Absence of a published purchase option is not documentation of its absence. source |
| extensibility-doordash-preferred | no / documented, sourced to a Slice knowledge-hub URL | upheld | Conclusion correct, sourcing invalid — a Slice page cannot evidence a DoorDash program roster. Independently confirmed against DoorDash's own newsroom: the 2026 DPIP cohort is Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, UrbanPiper, and DPIP requires live item availability and order-ready notifications, both of which Slice's own docs say it cannot do. source |
| hardware-callerid-integration | yes / documented | upheld | Verified: 'Their phone number appears on your screen, and if they've ordered before, you'll see their name and order history.' The dossier's limitations are real and if anything understated — the doc also notes the customer info disappears once the call ends and simultaneous calls queue rather than ring independently. source |
| reliability-247-live-support | yes / documented | upheld | Confirmed verbatim: 'We answer the phone 24/7/365 — for you and your customers' and 'No AI, robots, or chat bots — fully human support'. Included on both memberships. source |
| menu-pricing-modifier-price-by-parent-size | yes / documented | upheld | Confirmed in the menu doc as an explicit three-way toggle per modifier group: 'Modifiers have the same price for all sizes', 'Set different modifier prices for sizes', or 'Modifiers are free for all sizes'. Real per-size modifier pricing, not duplication. source |
| order-capture-scheduled-orders | yes / documented | upheld | Confirmed: 'Scheduled: Orders set for a future time or date' is a first-class status alongside In Progress and Complete. source |
| kitchen-station-routing | partial / documented | upheld | Verified and slightly stronger than described — routing targets are named ('kitchen, pizza, bar, etc.') and bulk edit can reassign printers across many items. Still printer-only routing with no KDS, so partial is the right ceiling. source |
| reliability-offline-feature-matrix | no / inferred | upheld | I checked independently. Register Settings offers only a Slice Support 'Connection Status' check to 'confirm your Register is online and connected'; the in-store-ordering product page and the POS page contain nothing on outages. An exhaustive operator Knowledge Hub with zero offline content is affirmative evidence that no offline matrix is published — though the underlying capability itself remains correctly scored unknown elsewhere. source |
| digital-native-app | no / documented | upheld | Verified verbatim and stronger than cited: 'This means you get the benefits of having an app, without the cost or work of building your own.' Slice explicitly positions the shared marketplace app as the substitute for a branded app. source |
| delivery-driver-roster | yes / grade B — native driver module with active-driver list and Delivery Management Report | downgrade-to-partial | I retrieved the Driver App article, which the record never cites, and it undercuts the roster half of the claim. The operator cannot administer drivers at all: 'contact Slice Support at (888) 974-9928 to add your driver's login to your account. Each driver needs a unique email address.' Assignment state is a single binary — 'Tap the Available toggle to receive batch assignments... Drivers must be logged in and marked Available to be assigned' — not the in-store / on-run / returning model the claim specifies, and the article documents no clock-in/out or shift concept. What survives is dispatch plus per-batch settlement, which is partial, not a first-class driver entity. source |
| delivery-driver-tracking | yes / grade B — 'the driver's current location on the map' | downgrade-to-partial | A differentiator yes resting on one clause. I read both the dispatch article and the Driver App article. The dispatch page does show 'The driver's current location on the map' but states no cadence; the Driver App article documents GPS only outbound to the driver — 'Tap Start Navigation to use GPS directions to the customer' — and never says the app reports position back. The only thing Slice itself calls real-time tracking is for its outsourced couriers: the release note Track Slice Delivery Drivers in Real Time covers 'your Slice Delivery driver's progress... real-time updates like driver name, status, and estimated timing'. Continuous in-house driver GPS is not established. source |
| digital-google-order | yes / grade B — Slice manages Google Food Ordering to the shop's own link | downgrade-to-partial | Grade B was wrong: the source is a vendor feature page written to sell, not documentation, and a differentiator yes needs A or B. I retrieved it — 'It's the Order Online button on your GBP listing. We make sure it links to a direct ordering channel — not a third-party app' — and it contains no setup steps, no verification path and no mention of the 'Preferred by Business' designation the claim names. No Knowledge Hub article documents the provisioning, and the operator has no configuration surface; Slice claims and runs the listing on their behalf. The capability is claimed, not shown. source |
| reliability-onsite-install | yes / grade B — on-site hardware setup and in-person training | downgrade-to-partial | The quote is real — I retrieved 'Our team comes to your shop, sets up your hardware, and trains your staff in person. You do not need to do a long self-install' and 'We stay until your team feels ready' — but slice.com/in-store-ordering is a marketing landing page, which is grade D, and this is a differentiator. Nothing in the Knowledge Hub documents the on-site process, no market coverage is stated ('in-market teams available to help in person' is unquantified), no go-live timeline is published, and the service can only reach $399 Family shops because the $39 Online membership has no POS and no implementation fee. source |
| digital-account-saved-payment | yes / grade B — saved payment accounts and profiles, cited to register-customer-management | downgrade-to-partial | I read the cited article end to end and it does not mention stored cards. It documents editing 'their name, phone number, or address', that 'All Slice Online Customers are already in the system', phone as 'the most unique identifier' for search, and order history with a 'Reorder button in the top right'. Saved payment exists only as a marketing bullet on the online-ordering product page — the identical grade-D evidence on which this record scores payments-card-on-file merely partial. Two cells cannot read the same sentence as yes and partial. source |
| digital-first-party-web | yes / grade B — website plus commission-free online ordering, cited to the pricing page | downgrade-to-partial | The claim requires the ordering site to sit on the restaurant's own branding and domain, and no Slice source says it does. I retrieved the Website Tools article: the site is Slice-hosted and Slice-designed — the operator sets 'font and background color that best represent your shop' and edits the tagline and 'Our story', while designs are set by Slice's team and a different one must be requested from support — and the integration path for a site the operator actually owns is a Smart Button, a Smart Popup or 'a direct URL to your shop's menu'. Custom-domain connection is documented nowhere, and ordering carries $2.00/order (Family) or $3.00/order (Online) rather than being fee-free. source |
| payments-emv-nfc | unknown / grade F — terminal never named, chip and contactless never stated | resolve-to-partial | Recorded as a downgrade-to-partial only because the schema has no upgrade-to-partial verdict; the movement is upward, from unknown. The Slice Driver App article — cited by no previous pass — states chip and contactless acceptance in Slice's own words: 'Ask the customer to insert, tap, or swipe their card on the reader', on a reader paired over Bluetooth. Named shortfall: this is the door-side mobile reader only. The countertop Payment Terminal in the Family bundle is still never named or described, PIN debit is unmentioned, and Apple Pay / Google Pay appear only at online checkout. source |
| menu-pricing-channel-price-books | unknown / grade F — only availability toggles documented, no markup rules | resolve-to-partial | Upward movement from unknown, recorded under the only partial verdict the schema offers. The Third-Party Orders article documents exactly the mechanism the claim names: the operator can 'set fixed percentage upcharges for each third-party platform to help cover their fees' — a percentage rule against the base price, per marketplace, not manual per-item entry. Shortfall: third-party platforms only. No price book for dine-in, pickup, first-party delivery or kiosk is documented, and the remaining channel controls are the two availability toggles the record already found. source |
| reporting-guest-cohorts | unknown / grade F — no cohort reporting documented | resolve-to-partial | Upward from unknown. The record asserts in four separate cells that the Financials article enumerates the entire Owner's App report catalogue; the Knowledge Hub index shows it does not — there is also an Analytics section, which I retrieved. Its Customers half carries 'Your Customers' (recently ordered customers with an engagement level) and 'Most Valuable Customers' ranked on spending, order frequency and loyalty, with a period filter and an 'Online Only or Register' toggle. Shortfall: no new-versus-returning counts, no lifetime-spend cohort bands, and no export of the underlying guest list. source |
| guest-loyalty-rfm-segmentation | unknown / grade F — no lifecycle segmentation surface documented | resolve-to-partial | Upward from unknown, on the same previously uncited Analytics article. Slice precomputes two guest views without the operator writing anything: 'Most Valuable Customers' on spending and order frequency, and recently-ordered customers with an engagement level — recency, frequency and monetary in substance, which is what the claim asks be computed automatically. Shortfall: no named lifecycle segments (new, regular, at-risk, lapsed, VIP), no membership counts, and no documented route from a view to a campaign audience, since Slice's own staff build the sends. source |
| payments-dual-pricing | unknown / grade F — no dual-pricing or cash-discount mode documented | resolve-to-partial | Upward from unknown on downstream evidence. The Financials article carries 'Cash Discounts' as an Orders Report column and, in the Sales Summary, as 'Total discounts applied when customers paid with cash', while the Sales Summary's Service Fees line includes 'Credit Card Surcharges'. Slice reports on a cash-discount programme, so one exists. Shortfall, and it is large: Register Settings documents no cash-discount or surcharge configuration at all, nothing states two prices are stored per item, and no receipt or guest-check display of both totals is described. source |
| menu-pricing-fractional-placement | partial / grade B — halves only, pricing rule undocumented | upheld | Re-fetched the order-entry article myself because this is the conclusion-flipping cell for a pizza record. It supports one gesture and no more: 'For pizzas, use Choose Toppings to select half toppings. First, tap the half where you want to add toppings. Then, select the topping.' No quarters, no thirds, no per-section pricing, and no pricing statement of any kind for half toppings. Partial is the correct ceiling — placement exists, independent per-section pricing does not. source |
| menu-pricing-half-and-half-rule | unknown / grade F — pricing rule never described as configurable | upheld | Re-read both the order-entry and the menu articles looking specifically for a rule. Neither contains one: no charge-the-higher-half, no average-the-halves, no fractional multiplier, and no operator setting. Toast's per-portion price multiplier has no counterpart in anything Slice publishes. This is an absence of documentation rather than documented absence, so unknown stands rather than no. source |
| delivery-daas-dispatch | yes / grade B — assign a delivery to Uber or DoorDash from dispatch | upheld | Re-retrieved; the sentence survives verbatim: 'If you are using Flex Delivery, you can also choose to assign a delivery to your selected Slice Delivery provider, Uber or DoorDash', alongside 'Simply select that option, tap Reassign Delivery, and we will send an outsourced driver'. Register Settings corroborates with 'Outsource delivery orders: Toggle this setting on to have our partners deliver your Slice orders'. Scope caveats stand — Slice-channel orders only, and the per-delivery courier cost is published nowhere. source |
| delivery-dispatch-board | yes / grade B — four-section board with batching and route sequence | upheld | Verified independently rather than accepted. The article shows Unassigned, Awaiting, In progress and Delivered; batching via 'tap the arrow to open the list of active drivers and select the driver for the batch'; sequencing via 'The order in which you select the deliveries sets the delivery route'; and an in-progress view giving which orders were delivered, the time of each, and the driver's location. This is a genuine native dispatch surface — one of the few places Slice's product exceeds its marketing. source |
| delivery-cash-reconcile | yes / grade B — per-driver settlement in the Delivery Management Report | upheld | Retrieved the Cash Management article myself. Per driver: 'Total amount', 'Cash collected', 'Credit card' with a nested tips line, 'Delivery fees', and 'Cash due to driver' — the last computed by comparing cash collected against card tips, so the shop pays the driver the difference when tips exceed cash and the driver returns the surplus when cash exceeds tips. That is a settle-up, not merely a report of takings. Caveat: no explicit over/short variance per driver. source |
| delivery-3p-injection | yes / grade B — third-party orders land in Order Management and print uniformly | upheld | Checked at the source article rather than the settings page the record cited. Marketplace orders 'appear in their own column on the New Orders page' and either take a confirming tap or none — 'enable Auto-Confirm Orders so they go straight to the kitchen as soon as they arrive'. Register Settings corroborates that auto-confirm 'allows Slice and third-party orders to be automatically confirmed', with automatic kitchen-ticket printing for online and third-party orders. Inbound injection is the one direction of this integration that genuinely works. source |
| delivery-store-pause | no / grade B — pause does not reach third-party marketplaces | upheld | Re-retrieved the shop-status article and the disqualifying sentence is exact: 'Pausing or closing orders affects Slice online orders and Slice Phone orders—third-party orders will not be impacted.' Pause 'temporarily stops receiving pickup, delivery, or both for a set time' and Close stops orders for the rest of the day, but the marketplaces must still be paused in their own portals. This is documented absence, which is what a no requires. source |
| commercial-month-to-month-contract | yes / grade B — 'Month-to-Month' and 'Zero locked-in contracts' | upheld | I contested this as a differentiator yes evidenced by a pricing page, which the rubric grades C. On retrieval I am upholding it: both columns read 'Month-to-Month' with 'Zero locked-in contracts' and no minimum term anywhere, and the claim is about what the vendor publishes — the pricing page is the artifact the claim asserts exists, not marketing copy being read as capability. The unresolved half stays where the previous pass put it: no merchant agreement is readable, and the fate of the $1,000 implementation fee and bundled hardware on cancellation keeps the early-termination cell at unknown. source |
| payments-published-rates | yes / grade B — '2.90% + $0.30' on both plans | upheld | Contested on the same grade-floor ground and upheld on the same reasoning. I re-retrieved the page: '2.90% + $0.30' on both plan columns, corroborated on the POS product page as '2.9% plus $0.30 per transaction'. What is published is a flat blended rate and nothing else — no interchange-plus schedule, no card-type or keyed differential, and no monthly, PCI or statement fee — which the note now says explicitly. source |
| reporting-realtime-dashboard | partial / grade B — five fixed CSV reports, no live tile set | upheld | Value upheld, reasoning replaced. The previous pass concluded from the Financials article that the Owner's App has only five fixed CSV reports; the Knowledge Hub index shows an Analytics section as well, which I retrieved. It is a visual dashboard set — Delivery & Pickup, Sales by Day, Top and Least Selling Menu Items, Your Customers, Most Valuable Customers — with a period filter and an 'Online Only or Register' source toggle, available on web and in the Owner's App. What keeps it partial is different from what the record said: not the absence of a dashboard, but the absence of any stated refresh interval, and no Slice document using the words live or real-time for sales data. source |
| reporting-channel-profitability | partial / grade B — Sales Summary breaks out Register, Online and Third-Party | upheld | Upheld with the shortfall sharpened. On retrieval, Net Sales splits only 'Register Sales' and 'Online Sales'; Payments splits Credit Card Collected, Cash Collected, Slice Online Payment and Other Payment; Dining Option splits Delivery, Pickup, To Go, Dine In and the Slice online variants. Third-party is one aggregate block at the end — 'All Third-Party Orders are prepaid', with total order sales, tips and average order value — so marketplaces are never separated from each other, and the Service Fees line covers Register delivery fees, credit-card surcharges and Slice online delivery fees only. No commission is netted anywhere. source |
| menu-pricing-countdown-auto-86 | no / grade B — availability options are timed windows only: 12h, 24h, indefinite | upheld | Value upheld but the record's enumeration was wrong while asserting itself exhaustive: the stock dropdown also offers a Custom user-defined return date alongside 12 hours, 24 hours and indefinitely. All four are timed or manual windows restored on expiry. Nothing decrements a per-item unit count as units sell and nothing 86s at zero, so no stands — but a claim of exhaustiveness that omits an option is exactly the kind of overreach this pass exists to catch. source |
| menu-pricing-dual-pricing | unknown / grade F — no dual-pricing configuration in menu, settings or payment docs | upheld | Upheld even though I found evidence the record missed. 'Cash Discounts' is a column in the Orders Report and 'Total discounts applied when customers paid with cash' in the Sales Summary, so a cash-discount programme exists somewhere — but that is a discount applied at tender, and this claim requires a card price stored as the item's base price, applied consistently across POS and online ordering, and printed on the receipt. Nothing in the menu, settings or receipt documentation describes item-level dual pricing. Unresolved, not partial. source |
| labor-clock-in-at-pos | partial / grade B — Homebase-powered Time Clock on the Register iPad | upheld | Value upheld; one quote in the note was misattributed and is corrected. The employee-permissions article does not say the Register is not a time clock — it says 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions—it does not function as a time clock or track when employees log in or out.' The clock itself is real: 'Time Clock is powered by Homebase, a Slice Partner', on the Register iPad, punched by PIN there or on employees' own phones. It remains partial because it is the partner's product — a joinhomebase.com account is a prerequisite, activation requires you to 'reach out to Slice Support for help getting started', timecards live in Homebase, and Slice discloses no price for the Homebase side. source |
| reporting-labor-productivity | no / grade B — the Financials article enumerates the whole report catalogue and none carries labour | upheld | Value upheld, base widened. The stated reasoning was unsound — the Financials article is not the whole catalogue, since the Owner's App also ships an Analytics section — so I read that too: Orders (Delivery & Pickup, Sales by Day, Top and Least Selling Menu Items) and Customers (Your Customers, Most Valuable Customers). No labour hours, labour cost or sales-per-labour-hour dimension exists on either surface, and clocked hours sit in partner Homebase. Absence is now positively evidenced across both report surfaces rather than one. source |
| reliability-offline-card-auth | unknown / grade F — no store-and-forward behaviour documented | upheld | Re-tested deliberately, since offline card authorisation is a conclusion-flipping cell. I read the Knowledge Hub index in full — Register, Online Ordering, Owner's App (web), Owner's App, Delivery, Phone Ordering — and no section carries an offline article; Register Settings offers only a Slice Support 'Connection Status' check 'to confirm your Register is online and connected'. Slice ships a Network Kit router with every Family bundle and publishes nothing about degraded operation. That is silence, so unknown is correct and no would be a false assertion about a named business. source |
| extensibility-public-api-docs | no / grade F — inferred, developers.slicelife.com serves marketing content | upheld | Upheld and re-graded from inference to retrieved evidence, since a genuinely open API versus a partner-gated one is a conclusion-flipping cell. I fetched developers.slicelife.com: it serves Slice's consumer marketplace — city browsing, pizza types, support and careers — with no API reference, OpenAPI spec, sandbox or developer resource of any kind, and the Knowledge Hub index has no API section. The absence is affirmative: the host that would carry a portal exists and carries none. source |
| order-capture-voice-ai | no, grade B - Slice Phone is explicitly human agents: 'our trained support | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-menu-single-source | partial, grade B - The POS page text I fetched is narrower than quoted: 'Update | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-native-app | no, grade B - Verified verbatim and stronger than cited: 'This means you g | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-fulfillment-modes | partial, grade B - Marketing-page-only evidence, and it conflicts with product | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-loyalty-attach | partial, grade B - The loyalty program is Slice's marketplace-wide diner progra | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| guest-loyalty-native-email-sms | partial, grade B - Sourced only to a marketing page, and the same page frames i | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-tier-paywall | partial, grade B - Owner's Portal reporting is included on both memberships, bu | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-peripherals | partial, grade B - Cash drawer, receipt printer, kitchen printer, payment termi | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-pricing-transparency | no, grade B - No per-SKU hardware price is published — hardware is bundled | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-interchange-plus-published | no, grade B - Slice publishes a single flat blended rate (2.90% + $0.30) o | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-pricing-published | yes, grade B - Exact figures published with no sales call: $399/mo + $2.00/ | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-module-unbundling | no, grade B - The pricing page offers exactly two all-or-nothing bundles. | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-implementation-fee-published | yes, grade B - '$1,000 implementation fee' published on the pricing page fo | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| payments-published-rates | yes / B - Upheld after re-retrieval: '2.90% + $0.30' appears on both plan columns, and the POS | downgrade-to-partial | The cited artifact is the first-party pricing page, which the evidence rules grade C; a differentiator yes needs A or B and no Slice documentation states a rate. The vendor's own Owner's Portal Help statement definitions place the actual percentage and swipe fees in the merchant agreement rather than in any published schedule, and the help centre publishes no pricing or fee article. Publication of one blended headline rate with no interchange-plus, keyed or card-type detail is a partial, not a yes. source |
| commercial-month-to-month-contract | yes / B - Upheld after re-retrieval. Both columns read 'Month-to-Month' alongside 'Zero locked- | downgrade-to-partial | The prior pass held the pricing page at B on the argument that a publication claim makes the sales page its own artifact; the rules grade a first-party pricing page C regardless, and a differentiator yes requires A or B. Searching for documentation found none: the public merchant Terms of Service contains no term, auto-renewal or notice language and points to separate unpublished Services Terms for the paid membership, and the knowledge-hub help centre carries no billing or cancellation article. The month-to-month posture is asserted but the governing agreement is not public, so partial with the named shortfall. source |
| order-capture-split-merge | unknown / F - 'The order-entry doc describes split TENDER, not split CHECK ... merging is absent entirely.' | resolve-to-partial | Re-retrieved the Order Entry article via slice.com/wp-json/wp/v2/epkb_post_type_1. It contains BOTH a 'Splitting a Payment' section (split tender) and, under 'More Order Actions', a separate 'Split - Allows splitting checks' entry, which the earlier rationale missed. Check splitting therefore exists; merging does not appear in Order Entry, Order Management or the Register permission enumeration, and there is no seat/table model to split or merge by. source |
| order-capture-bar-tab-preauth | unknown / F - 'No bar tab or pre-authorization concept appears in any published doc; Slice is not sold to bars.' | resolve-to-no | Read the full Order Entry and Cash Management articles from the WP REST API. Order Entry states its tender set is closed ('There are three ways to pay for an order') and describes the card flow end to end with no auth/capture split; 'Preauthorized' appears only once in the corpus, as a manager-approval status in the Owner's App permissions log, not a card pre-auth. source |
| order-capture-transfer-audit | unknown / F - 'Order transfer between employees or devices is not addressed in the order-management documentation.' | resolve-to-no | Read the complete Owner's App (web) Register article (permission groups, permissions log) and the Financials Register Orders column list. The permission enumeration is explicit and fine-grained and contains no transfer; the order record has no employee/server field; Register has no table model. source |
| order-capture-qr-same-check | unknown / F - 'QR dine-in ordering exists on the online-ordering side, but whether those items land on an existing open Register check is not documented.' | resolve-to-no | Grepped all 101 first-party documents pulled from the WP REST API for 'QR' and 'scan': zero hits. The only QR text Slice publishes is the online-ordering marketing FAQ describing QR codes on menus, boxes and signs as ordering links. Order Management documents the arrival path for those orders and it is a separate new order. source |
| menu-pricing-included-allowance | unknown / F - 'No included-topping allowance or overage-only charging is described in the menu documentation.' | resolve-to-no | Read the complete Owner's App (web) Menu article (updated April 9, 2026) from the WP REST API. It walks the Create-modifier-group screen field by field. An included allowance with automatic overage charging would have to be a field there and is not one. source |
| menu-pricing-allergen-nutrition | unknown / F - 'Item fields documented are name, display name, kitchen name, category, description, photo, sizes/prices. Allergen and nutrition fields are not mentioned.' | resolve-to-no | Read the complete Menu article from the WP REST API and grepped the whole 101-document first-party corpus for 'allergen' and 'nutrition' - zero occurrences. The New Item page is documented as a closed field list; the only allergy affordance is the free-text Item Notes field at order entry. source |
| menu-pricing-dynamic-pricing | unknown / F - 'No rule-based dynamic pricing documented.' | resolve-to-partial | Read the Register Third Party Orders article, which was not previously cited for pricing. It documents per-platform percentage upcharges - genuine channel-based price variation - while the Menu and Manage articles show no time- or demand-based rule and no guardrail settings. source |
| payments-surcharge-guardrails | unknown / F - 'No surcharging engine documented; no BIN/debit-exclusion or network-cap logic described.' | resolve-to-partial | Read the Register Cash Management and Reporting article and the Owner's App (web) Financials Sales Summary column list, neither previously cited for surcharging. Both document a credit card surcharge; the Sales Summary Report defines it as applying to credit or debit, which rules out documented debit exclusion. source |
| payments-qr-guest-pay | unknown / F - 'QR is documented for ordering (menus, boxes, signage, curbside, dine-in), not for scanning a printed check to pay it.' | resolve-to-no | Grepped all 101 first-party documents for 'QR' and 'scan' (zero hits) and read the Order Entry payment section, which asserts its own completeness. Also read the 30 release notes, which surfaced the SMS pay-link for Slice Phone orders - a different mechanism from the one claimed. source |
| payments-gift-cards | unknown / F - 'Gift cards appear in no product page, pricing bundle, or Knowledge Hub article.' | resolve-to-no | Read the Order Entry tender section, which enumerates three tender types and names paper gift certificates as an Other-tender workaround, and checked the complete Financials report column lists for a gift-card balance line. Grepped the whole 101-document corpus for 'gift card': zero hits. source |
| payments-house-accounts | unknown / F - 'No house-account or on-account tab functionality documented.' | resolve-to-no | Grepped the full corpus for 'house account' (two hits) and read both in context, plus the Order Entry tender enumeration and the Financials Statements/Payouts sections. No customer-account entity, balance or statement generation exists. source |
| payments-payout-timing | unknown / F - 'A Payouts section shows payout ID, creation date, payment date, amount, method and status, but no deposit schedule is published and no instant/next-day funding option is offered.' | resolve-to-yes | The prior rationale was wrong on both points, and both correcting sources were uncited: the payout FAQ (echo_kb_faq, none of the 26 FAQs had ever been cited) publishes the schedule options, and the Owner's App (web) Settings article documents debit-card payout acceleration, matching the 'Instant' Method value and the 'paid to your Debit Card today' line already in Financials. source |
| kitchen-all-day-counts | unknown / F - 'No all-day or aggregated outstanding-quantity view documented.' | resolve-to-no | Read Register Getting Started (hardware), the printer FAQ, Owner's App (web) Register Printer Settings and the Menu article's Register printing field, plus the Register Reporting tab list. Slice's kitchen output is Epson thermal printers routed by prep station; there is no station display to aggregate on. source |
| kitchen-sla-alerts | unknown / F - 'No target cook times, color escalation, or ticket-age alerting documented.' | resolve-to-no | Read the Printer Settings section of the Owner's App (web) Register article, which enumerates the whole prep-station configuration, plus Register Settings > Order Settings and Order Management's scheduled-order banners. Cook-time targets exist nowhere; the alerting that does exist is about order arrival. source |
| kitchen-printer-fallback | unknown / F - 'Printers can be discovered, named, deleted and tested, but no automatic failover to a backup printer is documented.' | resolve-to-no | Read Printer Settings in the Owner's App (web) Register article and Receipt Settings in the Register Settings article - the two complete printer configuration surfaces - plus the troubleshooting steps and Order Management's manual reprint action. source |
| kitchen-offline-operation | unknown / F - 'No offline documentation of any kind.' | resolve-to-no | Established the absence of a KDS from Register Getting Started's hardware list, the printer-only supported-hardware FAQ, Printer Settings (prep stations = printers), the Menu article's Register printing field and the marketing POS page, plus zero corpus hits for KDS/kitchen display/bump. source |
| kitchen-order-modification-alerts | unknown / F - 'Order edits are supported (adjustments up to 25% of order total) but there is no documented mechanism flagging changes on an already-printed ticket.' | resolve-to-no | Read Printer Settings' Print Modes (the complete kitchen print-trigger surface), the Register permission list's before-send/after-send line-item clear pair, and Order Management's Adjust and Print actions. Nothing conveys a change to the kitchen after the ticket prints. source |
| kitchen-speed-of-service-reporting | unknown / F - 'Reports cover sales, tax, tips, payment mix and delivery; ticket-time or per-station timing reports are not documented.' | resolve-to-no | Read the complete column enumerations in Owner's App (web) Financials (five reports), Register Cash Management and Reporting (two reports), and the Owner's App Report article (Orders, Scheduled Orders, Statements, End of Day, Sales, Insights). No timing metric appears in any of them. source |
| kitchen-prep-forecasting | unknown / F - 'No prep list or forecast-driven prep quantity feature documented.' | resolve-to-no | Read the Analytics article, the Financials Reports enumeration and the Owner's App Report article including Insights. Nothing predicts quantities or produces a prep task list. source |
| delivery-zones-polygon | unknown / F - 'Delivery zone geometry is not documented anywhere in the Knowledge Hub.' | resolve-to-partial | Retrieved the previously uncited FAQ set (slice.com/wp-json/wp/v2/echo_kb_faq, 26 entries, none of them cited in the record). 'What is my delivery zone and how do I edit it?' states that Slice draws a virtual zone with the shop and that multiple zones with different fees and minimums are supported. source |
| delivery-zone-pricing | unknown / F - "Slice's consumer FAQ states 'Every restaurant sets their own minimum order amount and delivery fee', but per-zone fee/minimum/promise-time configuration is not documented." | resolve-to-partial | Retrieved the merchant FAQ set from the WP REST API - a source the record had never cited, and a different document from the consumer FAQ the prior rationale quoted. The zone FAQ states multiple zones carry different fees and minimums; Order Entry documents automatic application from the address; the ETA settings in Register Settings are shop-wide. source |
| delivery-address-validation | unknown / F - 'Address geocoding at order time and out-of-zone rejection are not documented.' | resolve-to-yes | Re-read the Delivery Orders section of the Order Entry article in full from the WP REST API; it names Google Maps as the address source, documents auto-fill of city/state/ZIP, and documents the out-of-zone notification. The prior rationale missed all three. source |
| delivery-3p-reconciliation | unknown / F - 'Sales Summary separates Register, Online and Third-Party sales, but no payout-to-order reconciliation itemizing commission, marketing fees or missing orders is documented.' | resolve-to-no | Read the Third-Party section of the Sales Summary Report, the full Statement Summary and Transactions field lists in Owner's App (web) Financials, and the Register Third Party Orders article, which states Slice has no back-channel to the providers. source |
| digital-guest-data-ownership | unknown / F - customer import documented, bulk export not; no merchant terms on ownership | resolve-to-partial | The Owner's App (web) Customers article documents Export as well as Import ('Download your Slice customer database'), which the prior pass missed; the profile fields it exports include email and phone. Consent status and a contractual ownership statement remain undocumented, so the compound claim is only partly met. source |
| digital-checkout-pci-sca | unknown / F - no PCI DSS 4.0 statement, hosted-fields description, script-integrity note or 3DS support published | resolve-to-partial | The hosted-checkout half of the claim is documented - ordering and payment happen on Slice-hosted app and website surfaces, not on a merchant page - and Slice publishes a (thin) payment security FAQ. The compliance-publication half is genuinely absent from every slice.com page, so the claim resolves to partial rather than staying unexamined. source |
| digital-surcharge-transparency | unknown / F - no surcharge or service-fee configuration documented on any channel | resolve-to-partial | The Financials article's exhaustive report field lists (retrieved via the open WP REST API) show credit card surcharge, cash discount and service fee amounts being collected and reported on both Register and Slice Online orders, which the prior pass did not find. Configuration, disclosure and jurisdiction handling remain unpublished, so partial with that shortfall named. source |
| guest-loyalty-thirdparty-identity-attach | unknown / F - third-party orders arrive one-way; whether usable guest identity attaches is not documented | resolve-to-no | The Owner's App (web) Customers article enumerates the customer-data surface by source - Register, Online, or both - across all three of its pages, with no marketplace option, and scopes the whole dropdown to 'Slice online and Register orders'. Combined with the one-way third-party integration statement, that is an enumeration of the entire guest-identity surface with marketplaces outside it. source |
| guest-loyalty-tiers | unknown / F - no status tiers with promotion/demotion documented | resolve-to-partial | The Customers article documents automatic promotion and demotion driven by a rolling-window visit count, which is the mechanism the claim asks for, but the tiers are hard-coded analytics segments with no guest-facing status and no benefits, so the claim is met only in part. source |
| guest-loyalty-offer-stacking-rules | unknown / F - promo codes have limits and date ranges, but stacking/precedence not exposed as documented configuration | resolve-to-partial | The Owner's App (web) Register article documents a per-discount Combinable field, which is exactly the exclusive-vs-combinable configuration the claim asks for. It is confined to Register discounts and no order-of-application rule is published, so the claim resolves to partial rather than yes. source |
| guest-loyalty-data-export-portability | unknown / F - CSV export exists for orders/sales/tax reports; guest list or transaction-history export including PII not documented | resolve-to-yes | The prior pass found the report CSVs but missed the Export control on Customers > Profiles, which the Owner's App (web) Customers article documents alongside Import; the profile record it exports is defined as including email and phone. Both halves of the claim - guest list with contact PII, and transaction history - are self-serve downloads in the Owner's App (web). source |
| guest-loyalty-redemption-fraud-controls | unknown / F - no velocity limits, manual-adjustment approval, or self-redemption flagging documented | resolve-to-partial | The Owner's App (web) Register and Register Employee Permissions articles document manager approval on discount and refund actions plus a Permissions Log recording actioner, authorizer, action, status and timestamp - two of the three controls the claim names, applied to the discount surface. Velocity limits and self-redemption flagging are absent and point adjustment is not an operator surface at all. source |
| guest-loyalty-stored-value-gift | unknown / F - gift cards / stored value absent from all product and pricing documentation | resolve-to-no | Two independent exhaustive enumerations settle it: the Order Entry article states the Register has exactly three tender types and explicitly files a paper gift certificate under the catch-all Other, and the Financials statement breakdown lists every payment type collected with no stored-value line. Absence here is enumerated, not merely unfound. source |
| labor-tip-pooling-rules | unknown / F - per-driver tip reconciliation and cash settlement described but no pooling or tip-out rules | resolve-to-partial | The Financials article publishes the actual settlement formula, so Slice does automatically compute per-shift tip distribution rather than leaving it to a spreadsheet - but for drivers only and with no configurable rule basis, which is the shortfall the claim's 'configurable rules (percentage of sales, hours worked, points, or role)' language targets. source |
| reporting-multiloc-drilldown | unknown / F - single-shop product; no consolidated multi-location view documented | resolve-to-no | The Financials article enumerates every report and every field within each, and the login flows in both Getting Started articles show multi-shop accounts selecting one location before anything renders. That is an enumerated absence of a location dimension rather than a failure to find one - and it confirms multi-shop accounts do exist, so the cell is not merely out of scope. source |
| reporting-scheduled-delivery | unknown / F - reports downloaded on demand as CSV; scheduled recurring email delivery not documented | resolve-to-partial | The Financials article documents automated daily Sales Summary Report emails to multiple named recipients, which the prior pass missed. It is one report on a fixed daily cadence provisioned by telephone rather than a general report scheduler, so partial with those three limits named. source |
| reporting-anomaly-alerts | unknown / F - order alerts exist for incoming orders, but no metric-threshold or anomaly alerting documented | resolve-to-partial | The Owner's App Report article documents an Insights feed that proactively flags whether sales rose or fell against previous periods and by how much, with unread marking - a historical-deviation alert, which the prior pass did not distinguish from new-order alerts. It is not operator-configured and not delivered by push or email, so the claim is met only in part. source |
| multi-location-org-hierarchy | unknown / F - 'No enterprise/region/location hierarchy is documented; Slice's product is scoped to a single shop.' | resolve-to-partial | The prior rationale was wrong that Slice is single-shop-only. owners-app-getting-started documents multi-shop accounts with a location selector, and slice-register-getting-started documents shop selection at Register login. What is absent is a second and third tier, so the claim as worded (three levels, not just a flat list) lands on partial. source |
| multi-location-price-zones | unknown / F - 'No location-group price tiers documented.' | resolve-to-no | The Owner's App (web) Menu admin guide enumerates the fields of the item record and the item Options list; Price is one scalar and the channel controls are availability booleans. Combined with locations being a flat selector with no group object, all three price dimensions the claim asks for are absent from the configurable surface. source |
| multi-location-consolidated-reporting | unknown / F - 'No above-store aggregation or store-vs-store ranking documented.' | resolve-to-no | Three separate admin guides each enumerate their full report list and each is shop-scoped, and the dashboard doc positively describes the multi-shop model as switching to view one location at a time. That is an enumerated surface, not a failed search. source |
| multi-location-cross-location-giftcard | unknown / F - 'No gift card product is documented at all.' | resolve-to-no | Upgraded from an unexamined assertion to an enumeration: the Register's payment screen is documented as exactly three tenders, with paper gift certificates handled under the generic 'Other' tender. That is positive evidence there is no gift card instrument to redeem across locations. source |
| multi-location-config-audit-log | unknown / F - 'No configuration change audit log is documented. The one log that exists tracks assigned permissions only.' | resolve-to-partial | The prior rationale conflated two logs. knowledge-hub/register-employee-permissions says the log 'only tracks assigned permissions' in the sense that it is not a time clock, but knowledge-hub/owners-app-web-register documents it recording who performed and who approved each sensitive action with a timestamp and profile. That is a genuine partial against the claim, whose remaining gap is config objects, export and corporate scope. source |
| hardware-offline-mode | unknown / F - 'Slice ships a router in every Family bundle yet publishes zero documentation on what the Register does when the internet is unavailable. This is the single largest documentation gap in the product.' | resolve-to-partial | The prior rationale was written before the merchant agreement was found. slice.com/online-restaurant-agreement/ Annex 3 has an 'Offline Transactions' clause permitting offline POS activity with store-and-forward authorization, a $100 per-transaction ceiling and merchant-borne risk. Card behaviour is therefore documented; the operational surface (printing, cash, refunds) still is not. source |
| hardware-p2pe-terminal | unknown / F - 'The payment terminal model is never named publicly and no PTS listing, P2PE validation, or merchant SAQ type is stated.' | resolve-to-partial | Two new first-party facts move this off unknown: the agreement's statement that Slice never receives full card details and that a Processor handles authorization, and Annex 7 naming Adyen N.V. with Wells Fargo Bank N.A. as acquirer of record. The attestation half of the claim (PTS listing, P2PE validation, SAQ type) remains entirely unpublished, so partial rather than yes. source |
| hardware-ownership-vs-lease | unknown / F - 'Hardware arrives included with a month-to-month subscription. Slice never states whether the operator owns it, leases it, or must return it on cancellation - a material gap given the no-contract pitch.' | resolve-to-partial | Slice does state it, in a place the earlier pass did not find: Annex 4 of the published Online Restaurant Agreement. Provided hardware is a rental (Slice's sole property, non-refundable monthly Hardware Fee, returnable); purchase exists only for hardware 'designated as purchased' on the Order Form. Partial because the public pricing page still does not say which applies to the Family kit. source |
| hardware-usable-after-churn | unknown / F - 'No statement about post-cancellation hardware usability or software locking.' | resolve-to-partial | Annex 4 of slice.com/online-restaurant-agreement/ does make a post-cancellation statement for the standard case - use restricted to the Slice platform, mandatory return at the merchant's expense with named fees - so the claim is partly documented. The software-lock question for purchased Designated Hardware remains unanswered, which is why this is partial and not a resolved yes or no. source |
| hardware-rma-sla | unknown / F - 'No warranty term or advance-exchange turnaround is published.' | resolve-to-partial | A warranty term is published after all - six months from installation for purchased Designated Hardware, in Annex 4 of the Online Restaurant Agreement - together with a replacement-then-return procedure. What is genuinely absent is any stated turnaround, and the same annex disclaims all warranties for the rented Family-kit hardware, so the claim is half met. source |
| hardware-byod | unknown / F - 'No BYOD permission or security model documented.' | resolve-to-partial | knowledge-hub/register-slice-driver-app documents installing the payment-capable Driver App on the employee's own phone, with per-driver credentials and an explicit device requirement that the phone have a passcode or Face ID. That is a documented, if thin, BYOD security model; the permission side and the ordering app are not covered, hence partial. source |
| hardware-remote-device-management | unknown / F - 'Register Settings shows a Slice Support Connection Status check and a Download changes sync, but no fleet console with per-device online/offline state, remote reboot, or staged rollout is documented.' | resolve-to-no | Moves off unknown on an enumeration the earlier pass did not use: knowledge-hub/owners-app-web-register lists the complete set of back-office Register tools and none is a device console, while both admin guides state that updates must be downloaded on each iPad individually - the opposite of staged central rollout. source |
| extensibility-middleware-compatibility | unknown / F - 'Slice is not named as a supported endpoint by any middleware source I could reach, and Slice names none. Because Slice has no public API, third-party middleware would have no documented way to integrate.' | resolve-to-partial | The prior rationale's premise that Slice names no middleware is wrong: knowledge-hub/online-ordering-getting-started names Square, Clover and Checkmate POS as order transmission targets and knowledge-hub/settings has a Point of sale integrations panel. The direction is inverted relative to the claim and Slice Register is not itself an aggregator endpoint, so partial with the direction named as the shortfall. source |
| reliability-offline-order-entry | unknown (grade F) | resolve-to-partial | Read the full Pizzeria Agreement (slice.com/online-restaurant-agreement/, updated 2026-03-05). Annex 3 expressly permits offline point-of-sale activity with queued transactions, which resolves the order-entry limb; the ticket-routing and printing limb is addressed nowhere in the agreement or the Knowledge Hub, so partial rather than yes. source |
| reliability-offline-card-auth | unknown (grade F) | resolve-to-yes | The prior pass searched only the Knowledge Hub, which has no offline article, and correctly refused to infer. The mechanism is documented instead in the merchant contract, Annex 3 Slice POS Terms, which was not previously known to be published. The grade-A floor for a differentiator is met by a binding first-party contract; the $100 per-transaction ceiling is recorded in the note rather than treated as disqualifying, since the claim asks only whether card payments can be taken offline. source |
| reliability-offline-decline-liability | unknown (grade F) | resolve-to-yes | Both limbs of the claim are met in one clause of the published Pizzeria Agreement: who bears the loss (the Restaurant, expressly) and a stated per-transaction cap ($100). The claim asks for a per-transaction OR cumulative figure, so the reserved-but-unquantified queue limit does not reduce this to partial. source |
| reliability-local-transaction-engine | unknown (grade F) | resolve-to-partial | The claim asks whether the ordering path is documented as something other than purely cloud-hosted request/response. Annex 3's offline queue is documented local behaviour on the terminal itself, so the answer is not nothing; there is no documented edge server or local engine, so it cannot be yes. Shortfall named in the note. source |
| reliability-contractual-uptime-sla | unknown (grade F) | resolve-to-no | This is a positive finding rather than absence of evidence: the claim asks about the standard agreement, the standard agreement is now in hand in full, and it carries an express availability disclaimer exactly where an SLA would sit. Searched the entire text for uptime, service level, service credit and availability commitments; none exist. source |
| reliability-hardware-replacement-sla | unknown (grade F) | resolve-to-partial | The previously unseen Annex 4 does describe an advance-exchange program, so unknown is no longer right; but it is scoped to purchased Designated Hardware and states no replacement turnaround, which is the specific thing the claim asks for. Partial with those shortfalls named. source |
| commercial-no-early-termination-fee | unknown (grade F) | resolve-to-no | The prior pass held this unknown on the stated ground that no merchant agreement was publicly readable. It is: slice.com/online-restaurant-agreement/, updated 2026-03-05, blocked to plain curl but served in full to a browser UA and readable as JSON at wp-json/wp/v2/pages?slug=online-restaurant-agreement. The Early Termination Fee clause is positive evidence, not absence of evidence, and it also answers the earlier note's question about hardware on cancellation. source |
| commercial-autorenew-terms-published | unknown (grade F) | resolve-to-yes | The claim asks whether the renewal mechanic and the cancellation notice window are publicly accessible rather than quote-only. Both are, in the posted Pizzeria Agreement, together with a published fallback term. The merchant-specific term length remains on the Order Form, which the claim does not require to be public. source |
| commercial-rate-increase-clause | unknown (grade F) | resolve-to-partial | Found the fee-revision clause in the newly located published agreement. It grants a termination right on any fee change, which is the claim's second limb, but only for 14 days and without an express waiver of the Early Termination Fee, and there is no cap on increases. Partial with those shortfalls named. source |
| commercial-hardware-purchase-outright | unknown (grade F) | resolve-to-no | The earlier pass correctly rejected an over-confident reading and left this unknown because no Slice source affirmatively stated hardware could not be bought. Annex 4 is that source: title stays with Slice, the charge is a monthly Hardware Fee, and return is mandatory on termination. The residual Order-Form purchase path is recorded in the note, but it carries no published price, so the claim as worded fails. source |
| commercial-export-customer-and-loyalty | unknown (grade F) | resolve-to-partial | The prior rationale said the docs describe importing customer details but never exporting them; the same article's Profiles section does document an Export control alongside the import. Loyalty ledgers and gift-card balances remain undocumented, so the claim is met on one of the three data types it names. source |
| commercial-post-termination-export-window | unknown (grade F) | resolve-to-yes | Located the clause in the published Pizzeria Agreement the earlier pass did not know existed. It states precisely what the claim asks for -- a numeric post-termination data retrieval window (30 days, on request) -- and what happens after it expires. source |
| commercial-pci-dss-4-controls | unknown (grade F) | resolve-to-partial | One of the two controls the claim names is documented and shipped -- SMS-based two-step verification on the back-office login, released 2026-02-05 -- which is more than unknown. It is optional rather than enforced, absent from the Register, and never tied to PCI DSS, so it cannot be yes. source |
| commercial-dual-pricing-compliant | unknown (grade F) | resolve-to-partial | The prior rationale said no dual pricing, cash discount or surcharging capability was documented on any channel. Register cash-management reporting documents both, at order level, and the Owner's App (web) financial reports count them. What is missing is every compliance control the claim names -- debit and prepaid exclusion (Slice's text says the surcharge applies to 'a credit or debit card'), receipt and menu-board disclosure -- so partial, not yes. source |
| kitchen-all-day-counts | no / B - 'Slice ships no kitchen display system: the Register hardware set is enumerated as your iPa' | downgrade-to-unknown | The load-bearing premise - Slice ships no kitchen display system - is refuted by Slice's own live pages. https://slice.com/pricing-test/ (published 2026-06-30, live today) lists "Kitchen Display System" under what a Family Membership shop gets, and https://slice.com/family-membership/ lists "Discounted kitchen displays & kiosks (coming soon)". The hardware sentence relied on is also open-ended by its own wording ("install your hardware, including your iPad, printer, card reader, and cash drawer"). Whether that KDS has shipped or is still 'coming soon' is exactly what is now unresolved, and the claim cannot be false about a product surface whose existence is unsettled. source |
| kitchen-sla-alerts | no / B - 'The Printer Settings page in Owner's App (web) is the entire kitchen-routing configuration' | downgrade-to-unknown | Two failures. The cited Printer Settings block bounds only printer routing (Name, Print Modes, Print Quantity) and cannot speak to cook-time targets on a display device; and the no-KDS premise it is paired with is contradicted by https://slice.com/pricing-test/, which lists "Kitchen Display System" for Family Membership, and https://slice.com/family-membership/ ("Discounted kitchen displays & kiosks (coming soon)"). Whether that KDS has shipped or is still 'coming soon' is exactly what is now unresolved, and the claim cannot be false about a product surface whose existence is unsettled. source |
| kitchen-printer-fallback | no / B - 'The full printer configuration surface is enumerated in two places and neither has a fall' | downgrade-to-unknown | The claim is worded over both surfaces - "If a KDS screen or kitchen printer goes offline ... fail over to a designated backup printer or screen" - so it cannot be false while the KDS surface is unsettled, and it is: https://slice.com/pricing-test/ lists "Kitchen Display System" for Family Membership and https://slice.com/family-membership/ says "Discounted kitchen displays & kiosks (coming soon)". The printer half of the argument is sound but is only half the claim. source |
| kitchen-offline-operation | no / B - 'Slice ships no kitchen display system: the Register hardware set is enumerated as your iPa' | downgrade-to-unknown | This cell is the pure form of the refuted premise - its note says outright that the finding is about "the claimed capability's subject", i.e. that no KDS exists. Slice's own live pricing page https://slice.com/pricing-test/ lists "Kitchen Display System" among what a Family Membership shop gets, and https://slice.com/family-membership/ lists "Discounted kitchen displays & kiosks (coming soon)". The premise that Slice ships no kitchen display system is therefore contradicted by first-party vendor pages, not merely unproven. The hardware sentence it rested on is also explicitly open-ended - Register Getting Started says "install your hardware, INCLUDING your iPad, printer, card reader, and cash drawer" - and the supported-hardware FAQ is scoped to printers ("Non-Epson printers are no longer supported"), not to display devices. source |
| kitchen-order-modification-alerts | no / B - 'There is no live ticket to flag. Slice ships no kitchen display system: the Register hardw' | downgrade-to-unknown | The note's opening sentence is "There is no live ticket to flag", which is the refuted premise doing all the work. Slice's own live pricing page https://slice.com/pricing-test/ lists "Kitchen Display System" among what a Family Membership shop gets, and https://slice.com/family-membership/ lists "Discounted kitchen displays & kiosks (coming soon)". The premise that Slice ships no kitchen display system is therefore contradicted by first-party vendor pages, not merely unproven. The hardware sentence it rested on is also explicitly open-ended - Register Getting Started says "install your hardware, INCLUDING your iPad, printer, card reader, and cash drawer" - and the supported-hardware FAQ is scoped to printers ("Non-Epson printers are no longer supported"), not to display devices. source |
| kitchen-speed-of-service-reporting | no / B - 'Slice's reporting surface is enumerated exhaustively, column by column, and contains no ti' | downgrade-to-unknown | The report enumeration does not assert completeness. The cited Financials page introduces its report set as "The Reports page provides access to VARIOUS financial and sales reports", and its field lists are hedged throughout - "Displays key financial metrics for the selected timeframe, INCLUDING:" and "Lists all register orders with details SUCH AS:". That is a walkthrough, not a closed schema. source |
| kitchen-prep-forecasting | no / B - 'Every analytical surface Slice publishes is enumerated, and all of them look backwards at ' | downgrade-to-unknown | Same defect: the analytical surfaces are described, not enumerated. Financials introduces "various financial and sales reports" and the Analytics article is descriptive prose ("The Analytics page provides detailed insights into your shop's performance"). The predecessor itself flagged that Insights - the one place a forecast could live - has a one-line description. source |
| order-capture-transfer-audit | no / B - 'The Owner's App (web) Register article enumerates every Register permission Slice gates - ' | downgrade-to-unknown | The cited page enumerates PERMISSIONS, not features - "The listed permissions define specific actions employees can be granted access to" - so 'no transfer permission' does not entail 'no transfer'. Most Register actions are not permission-gated, and the article says so: "If Employee Permissions are not enabled, all users can access these tools." The note's own device finding cuts the other way - any logged-in iPad opens the same cloud order list, which is device portability, not its absence. source |
| payments-qr-guest-pay | no / B - 'Register's tender set is stated as closed - There are three ways to pay for an order: Card' | downgrade-to-unknown | The closure sentence relied on does not bound the guest-self-pay surface, and Slice itself proves it: the release note "Let Phone Customers Pay by Text" (2026-02-05) has customers "receive a text with their order details and a secure link to pay online" - a fourth, guest-side payment path that sits entirely outside "There are three ways to pay for an order: Card, Cash, and Other", which describes cashier tender at the Register. source |
| hardware-kds | no / B - 'The kitchen device Slice ships and documents is an Epson U220 impact printer. No KDS produc' | upheld | The premise as written is refuted: slice.com/family-membership/ lists 'Discounted kitchen displays & kiosks (coming soon)' and slice.com/pricing-test/ lists 'Kitchen Display System'. slice.com HTML 403s to curl behind Cloudflare, so I retrieved every page through /wp-json/wp/v2/pages (71 pages) and read the rendered content directly. The value nonetheless holds on evidence the first pass did not use: the POS product page's included-hardware FAQ is a closed seven-item list with no display, /pricing's Hardware block likewise, and 'coming soon' is itself a stated limitation. Value unchanged, grade B -> C, note and URL replaced. source |
| kitchen-expo-consolidation | no / E - 'No KDS product exists; the included kitchen device is an Epson U220 impact printer.' | upheld | The stated premise is contradicted by slice.com/family-membership/ ('Discounted kitchen displays & kiosks (coming soon)'), and grade E was miscoded for a first-party vendor URL. I re-read the POS product page and /pricing through the WP REST API (slice.com HTML 403s behind Cloudflare): the included-hardware answer is a closed seven-item list with no screen, so there is no surface on which items from multiple stations could be consolidated or bumped. Value unchanged, grade E -> C, note replaced. source |
| kitchen-bump-bar-hardware | no / F - 'No KDS, therefore no bump bar. Kitchen output is a thermal/impact printer.' | upheld | The inference's premise is contradicted in the form the researcher stated it, so I replaced it with a retrieved first-party statement: slice.com/family-membership/ lists kitchen displays as 'coming soon', i.e. not currently available, and the POS product page's closed included-hardware list contains no display or keypad. A bump bar needs a shipping display to attach to and Slice documents no supported models - zero hits for 'bump' in 101 first-party documents. Value unchanged, grade F -> D with a retrievable URL, rationale replaced by a sourced note. source |
| kitchen-recall-refire | partial / B - 'Kitchen tickets and customer receipts can be manually reprinted... No bump/unbump model exi' | upheld | I re-pulled register-order-management through /wp-json/wp/v2/epkb_post_type_1 (slice.com HTML 403s behind Cloudflare) and located the reprint action myself - 'Print : Print a receipt or kitchen ticket for an In Progress order if your Register app is connected to a printer'. That is what makes this partial and it is independent of any display product, so the value is unaffected by the KDS question. Only the shortfall's wording was defective: it was stated as a consequence of 'no KDS' rather than as what the article shows, and it is now grounded in the In Progress scoping and the zero corpus hits for refire or per-item recall. source |
| kitchen-guest-ready-notification | partial / D - "'Real-time order tracking via text and app' is included for Slice-channel orders, but it i" | upheld | I re-retrieved slice.com/products/online-pizza-ordering-system/ via /wp-json/wp/v2/pages/1072 (HTML 403s behind Cloudflare) and the researcher's quoted sentence is not on the current page; the equivalent FAQ answer is 'Customers get an order confirmation by text and via the Slice app, and can track their order's progress in real time in the app.' The capability is still included and still not tied to a ready event, but the shortfall no longer needs the KDS premise: Order Management's own status model has no ready state, only Scheduled / In Progress / Complete with manual movement. Value and grade unchanged; citation re-quoted and shortfall re-grounded. source |
| reliability-onsite-install | partial / D - 'Downgraded from yes under the differentiator grade floor... slice.com/in-store-ordering is' | upheld | The cited URL is dead as a page - I enumerated all 71 slice.com pages via /wp-json/wp/v2/pages and neither in-store-ordering nor pos is among them; the content lives at /products/point-of-sale-for-pizza-shops/ (page 1072), where I retrieved both quoted sentences verbatim, plus a second first-party page, /support/full-service-setup-and-training/ ('Our in-person implementation team ensures that your equipment is properly set up'). slice.com HTML 403s to curl behind Cloudflare, so this was verified through the REST API's rendered content, not by status code. The evidence is a vendor product page (C), still below the A/B floor a differentiator yes requires, and no Knowledge Hub article documents the process - partial stands with the citation corrected. source |
| kitchen-offline-operation | unknown / F - 'Unknown. The `no` was explicitly a finding about the claim's subject rather than about outa' | resolve-to-no | Retrieved https://slice.com/family-membership/ and https://slice.com/products/point-of-sale-for-pizza-shops/ myself (direct curl 403s behind Cloudflare; both render fine through a fetch proxy, and the Knowledge Hub is readable via the WP REST API with a Googlebot UA). The family-membership benefit line is "Discounted kitchen displays & kiosks (coming soon)" - the vendor saying the product is not available, which is positive evidence of absence, not the unsettled existence the previous pass inferred. The product page's included-hardware answer is closed and contains no display: "iPad interface, kitchen printer, cash drawer, receipt printer, credit card terminal, router, and delivery card reader". "kitchen display" and "KDS" appear zero times in all 45 Knowledge Hub articles. With no KDS in the product, the claim is false rather than undetermined. source |
| kitchen-order-modification-alerts | unknown / F - 'Unknown. The `no` opens "There is no live ticket to flag" and everything after it follows f' | resolve-to-no | Pulled the Owner's App (web) Register article from the WP REST API and read the Printer Settings block verbatim: the only configurable fields are Name, Print Modes (Incremental / After Payments) and Print Quantity. That is the whole kitchen-routing surface and it carries no modification alert. The display half of the claim is closed by https://slice.com/family-membership/ - "Discounted kitchen displays & kiosks (coming soon)" - which states the displays are not available, so the previous pass's "existence is unsettled" no longer holds. "reprint" and "refire" appear zero times in the 45 Knowledge Hub articles. source |
| kitchen-sla-alerts | unknown / F - 'Unknown. The `no` combined two arguments and neither reaches the claim. First, the Printer ' | resolve-to-no | Re-read the Printer Settings block verbatim from the WP REST API copy of the Owner's App (web) Register article: it is introduced as the page that manages "how orders are printed and routed to the appropriate stations" and enumerates Name, Print Modes and Print Quantity only. That is the per-station configuration surface, and it has no cook-time target. The escape hatch the previous pass left open - an unshipped display that might carry escalation - is closed by https://slice.com/family-membership/, whose benefit line "Discounted kitchen displays & kiosks (coming soon)" states the displays are not available. "cook time" appears zero times in the 45 Knowledge Hub articles. source |
| kitchen-printer-fallback | unknown / F - 'Unknown. The printer half of the prior argument holds up on re-reading: Owner's App (web) >' | resolve-to-no | Read the Receipt Settings section of https://slice.com/knowledge-hub/register-settings/ end to end from the WP REST API: the printer verbs are exactly discover, install, rename, delete and test, and the add-a-printer procedure is manual tap-and-test. No backup designation, no automatic re-route; "backup printer" and "failover" appear zero times in all 45 Knowledge Hub articles. The KDS-screen half, which is why the previous pass parked this at unknown, is closed by https://slice.com/family-membership/ - "Discounted kitchen displays & kiosks (coming soon)" states the displays are not available - so the claim can no longer be true through the screen path either. source |
| kitchen-all-day-counts | unknown / F - 'Unknown. The prior `no` rested entirely on the premise that Slice ships no kitchen display s' | resolve-to-no | Pulled https://slice.com/knowledge-hub/register-order-management/ from the WP REST API and read its view enumeration: three status tabs (Scheduled, In Progress, Complete) and four order-type filters, all order-scoped, with no item-quantity rollup anywhere; "all day" and "all-day" appear zero times in the 45-article Knowledge Hub. The premise that kept this at unknown - that a possibly-shipping KDS might carry an all-day view - fails against https://slice.com/family-membership/, which states the kitchen displays are "coming soon", i.e. not available. I am not resting on the reporting surface, which is genuinely open-ended. source |
| kitchen-course-firing | no / F - "No coursing anywhere in Register or kitchen documentation." | upheld | The value is right but the printed reasoning was not: "no coursing anywhere in the documentation" is absence-of-mention, which this project does not accept for a `no`. I retrieved the Register > Order Entry article myself (slice.com HTML 403s to curl behind Cloudflare; readable as JSON via /wp-json/wp/v2/epkb_post_type_1 with a Googlebot UA) and it is a complete walkthrough, not an overview: it enumerates the item-level actions on the check (Modify, Item Notes, Line Item Discount, Remove, Adjust Quantity) and the order-level More menu (Add Note, Copy, Split, Discounts, Extra Charge, Hold, Clear Order, Taxes). No course object exists at either level. The only hold is whole-order and releases on payment or Send - "The order will not print to the kitchen until it is paid for or sent" - and Printer Settings offers exactly two firing modes, Incremental and After Payments. Zero occurrences of "course"/"fire" across 45 Knowledge Hub articles, 30 release notes and 26 FAQs re-pulled today. Value unchanged; grade F -> B, rationale replaced with a sourced note. source |
| kitchen-prep-time-pacing | no / F - "Prep-time ETAs are per-shop and manually edited, not per-item cook times with staggered" | upheld | I retrieved the two articles the claim needs rather than reasoning from silence. Owner's App (web) > Menu (updated 2026-04-09, via /wp-json/wp/v2/epkb_post_type_1 with a Googlebot UA) enumerates the New Item page field by field - Item type, Item details (Name, Display name, Kitchen name, Category, Description, Photo), modifier groups, Sizes and pricing, six Options toggles, Register printing - and no cook-time field exists; that is an enumeration, not an absence. Set Delivery and Pickup ETAs in Owner's Portal (updated 2026-01-20) confirms the shop-level default plus per-order manual override, and Register > Settings > Order Settings caps those overrides at 10-90 minutes pickup / 20-120 delivery. The staggering half needs no inference from the coming-soon wording either: with no display device in the product there is no surface that could stagger item display times, and the only firing controls are the two Print Modes. Value unchanged; grade F -> B, rationale replaced with a sourced note. source |
| order-capture-seat-level | no / E - 'Check splitting is by even division or custom dollar amounts. No seat concept exists in the ord' | upheld | Re-retrieved the Order Entry article in full rather than relying on a corpus-wide grep for 'seat'. The value is carried by two closed on-screen enumerations, not by absence of mention: the documented per-line action set after an item is added (Modify, Item Notes, Line Item Discount, Remove an Item, Adjust Quantity) contains no seat assignment, and the Split Payment screen's three options are 'Split payment evenly', 'Pay custom amount' and 'Pay total owed'. The 'Split' entry under More Order Actions is described only as 'Allows splitting checks' with no seat dimension. Value unchanged; the citation is first-party product documentation, so grade E is corrected to B and the note now quotes the enumerations rather than asserting that no seat concept exists. source |
| payments-pay-at-table | no / E - 'The mobile card reader is documented for taking payment at the customer's door on delivery, no' | upheld | The researcher cited a marketing page and leaned on 'no table checks exist'. I retrieved the Slice Driver App article, which documents the mobile reader end to end: it pairs to the driver's phone inside the Slice Driver App, is gated on 'the driver has an assigned order', and its payment walkthrough is explicitly at the delivery address ('Tap Start Navigation... Once at the delivery address... Tap Pay with card reader'). Getting Started enumerates the Register kit as 'iPad, printer, card reader, and cash drawer', and Order Entry states card payment and tipping are completed on the shop's reader with the iPad tilted to face the customer. So the only card-present device that leaves the counter is bound to a delivery batch, which is positive evidence rather than silence. Value unchanged; grade corrected E to B and the citation moved off the marketing page. source |
| digital-qr-table | partial / D - "'QR code ordering options for menus, boxes, and signage' plus curbside and dine-in QR. Attac" | upheld | Re-retrieved the cited product page through a renderer after curl returned a Cloudflare 'Checking your browser' interstitial. The page carries exactly one QR sentence - 'you can place ordering links on social pages or QR codes on menus, pizza boxes, or signs' - and no mention of curbside, dine-in, table or check splitting, so the researcher's 'plus curbside and dine-in QR' is not supported by it. The QR ordering link itself is real, so 'no' would be wrong; the limitation is now shown rather than inferred, from Order Entry's closed statement 'There are three ways to pay for an order: Card, Cash, and Other' and its cashier-driven Split Payment screen, neither of which admits a guest-side scan against an open check. Value and grade stand; the note is rewritten to withdraw the unsupported half. source |
| order-capture-offline-order-entry | unknown / F - Still unresolved after pulling Slice's entire first-party documentation set through the open WP REST | resolve-to-partial | Moved off unknown on a document earlier passes never read: Slice's own Terms and Conditions (Slice POS Terms, 'Telecommunications > Offline Transactions'). Slice contractually permits offline operation of the POS - 'Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline' - and states the payment half of the behaviour: offline transactions are queued and submitted for authorization on reconnect, capped at $100 per transaction unless an Order Form says otherwise. SHORTFALL: the only offline scope Slice publishes anywhere is this contractual sentence. Nothing states whether order creation, modifier application, kitchen-printer routing or cash tender continue during an outage, and no supported/unsupported offline table exists in the 45 Knowledge Hub articles, 30 release notes or 26 FAQs. The claim's second limb - 'the vendor publishes what does and does not work offline' - is therefore met only for card capture. Note also the vocabulary trap that misled earlier passes: 'offline orders' in Slice's REPORTING means in-person Register orders, not disconnected ones; this T&C section is the one place the word means disconnected. source |
| payments-offline-store-and-forward | unknown / F - Still unresolved, and now checked against everything Slice publishes rather than asserted. I pulled | resolve-to-partial | Moved off unknown. Slice's Terms and Conditions ('Offline Transactions') document store-and-forward explicitly: transactions initiated while disconnected are queued and submitted for authorization when connectivity is restored. A per-transaction limit is published and it is $100 ('Unless otherwise specified in an Order Form, offline transactions may not exceed $100 per transaction'). SHORTFALL, which is why this is partial and not yes: neither limit is operator-configurable. The per-transaction cap is varied only by negotiating an Order Form with Slice, and the cumulative limit is not published at all - Slice merely reserves the right to set one ('Slice reserves the right to limit the number of offline transactions that may be queued'), with no stated ceiling and no operator-visible setting. No Register Settings screen in the Knowledge Hub exposes an offline limit. The claim asks for configurable per-transaction AND cumulative limits; Slice ships fixed, vendor-set ones. source |
| payments-offline-decline-liability | unknown / F - Still unresolved. This claim is about disclosure, so I looked for the disclosure itself rather than | resolve-to-partial | Moved off unknown. The claim's first limb is now squarely met: Slice publicly and unambiguously allocates the loss to the merchant in its Terms and Conditions - 'Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register and/or Slice Standalone Payments is offline.' That sits directly beneath the sentence establishing that offline transactions are queued and authorized later, so it is squarely about a stored transaction that fails on reconnect. SHORTFALL: the second limb is not met. No post-reconnect report of failed offline payments is documented. The Owner's App (web) Financials report set (Order Activity, Orders, Tax, Sales Mix, Sales Summary) contains no failed-offline-payment view, and the only order-level failure signal published is the Register Order Management colour icon - 'a red dollar icon means payment failed, the order was canceled, or it was refunded' - which conflates three causes and is per-order, not a reconciliation report. source |
| payments-p2pe-pci4 | unknown / F - Still unresolved, and the one page that speaks to it is too thin to score. The FAQ 'How secure are p | upheld | Upheld unknown, but the search is now exhausted rather than merely unsuccessful, and one new first-party datum is on the record. The strings 'PCI', 'P2PE', 'DSS', 'EMV', 'tokeniz' and 'point-to-point' occur ZERO times across all 490 wp-json documents and all 10 Wayback-recovered pages, including the 178KB Terms and Conditions - the single 'PCI' hit in the corpus is inside a Spanish word in slice.com/es/restaurantes-mexicanos/, not an acronym. What the T&C does add is the card-data path: 'Slice does not receive full payment card details in its provision of Slice Register and Slice Standalone Payments. Slice has engaged a Processor that conducts payment processing...', and the Adyen Acquiring Addendum in the same document names the processor as Adyen N.V. acquiring under the licence of Wells Fargo Bank, N.A. That establishes vendor-side card-data isolation and identifies the acquirer, but it names no encryption technology, so it does not establish point-to-point encryption, and no AoC or P2PE listing is offered or referenced anywhere. I declined partial because neither conjunct of the claim - P2PE, and a current PCI DSS 4.x AoC/P2PE listing available on request - is actually evidenced; scoring partial would assert P2PE is present, which no document says. WHAT WOULD RESOLVE IT: a Slice trust/security/compliance page or a merchant-facing AoC request path (none exists in the wp/v2/pages census); an Adyen P2PE solution listing on the PCI SSC validated-solutions register tied to the Verifone terminal Slice rents ('Verifone Payment Terminal', slice.com/hardware-pricing/); or the Order Form / Annex documents referenced by the T&C but not published. |
| order-capture-transfer-audit | unknown / F - Unknown. Re-read the complete Owner's App (web) Register article. Its permission list is genuinely c | upheld | Upheld unknown against the full 500-document corpus. The word 'transfer' appears in the Knowledge Hub only in the T&C sense of a wire transfer; it never describes moving an open check. Per the batch rule, absence is not measurable on slice.com (the href-fixpoint probe showed absent real paths and fabricated control slugs answering identically), so that absence cannot carry a `no`. The nearest thing to a positive closure is the Employee Permissions article's statement that 'The Employee Permissions Log in the Owner's App (web) only tracks assigned permissions - it does not function as a time clock or track when employees log in or out', which is a genuine 'only' about the one audit surface Slice publishes and does exclude order-level transfer entries from THAT log. I stopped short of `no` because it bounds one log rather than the product, and the claim is conjunctive over transfer between servers, tables and devices - Register has no table model at all (dining options are To Go, Delivery, Pickup, Dine In), so the table limb may be vacuous rather than absent. WHAT WOULD RESOLVE IT: a Register Order Entry or Order Management article documenting reassigning an open/held order to another employee or iPad, or a Permissions Log field list showing (or provably not showing) an order-reassignment event type. |
| menu-pricing-half-and-half-rule | unknown / F - Upheld unknown a second time, now against Slice's complete published menu surface rather than a re-r | upheld | Upheld unknown, now including 302 previously unread blog posts and three Wayback-only Knowledge Hub articles. Capture and customer-side selection are fully documented - the Wayback-recovered Custom Website article (https://web.archive.org/web/20260128id_/https://slice.com/knowledge-hub/online-ordering-custom-website/) says 'If your shop offers half toppings, customers can add them to the left half, right half, or the whole pizza', and Register Order Entry documents tapping a half then a topping. PRICING is still nowhere. The new blog material is marketing and asserts only existence, not a rule: 'Half-and-half topping support | Workaround or manual fix | Native (no workaround needed)' (first-year-technology-costs-for-pizza-shops) and 'half-and-half pizza customization'. The strings 'dual pricing', 'split pricing' as a Slice feature, 'higher half' and 'average the halves' do not occur. The only closed enumeration on the configuration side remains the Menu article's three mutually exclusive modifier-pricing modes, all of which are about pricing ACROSS SIZES, not fractional placement, so they do not exhaust the surface. WHAT WOULD RESOLVE IT: a Menu article or release note showing a per-shop half/fraction pricing setting, or a screenshot/worked example giving the price of a half topping relative to a whole one. |
| menu-pricing-dual-pricing | unknown / F - Upheld unknown, with more evidence than the previous pass had but still not the claim. Slice does op | upheld | Upheld unknown, and the newly read Terms and Conditions push slightly AGAINST rather than toward the claim without settling it. Slice's cash/non-cash differential remains a tender-time line item, not an item-level base price: the Register Sales Summary defines 'Credit Card Surcharge' and 'Cash Discounts' as report lines, and the T&C treats the mechanism as surcharging under card-brand rules, restricting rather than configuring it - 'Restaurant agrees that it shall not add a surcharge to transactions, except as expressly permitted by, and in full compliance with, applicable law and any relevant Scheme Rules.' The claim requires the CARD price stored as the item's base price with the cash price as the discount, shown identically on POS, kiosk and online ordering, and printed on the receipt. The Menu article's item and modifier field lists carry no second price; Kitchen and Customer Receipt Settings expose only font and content ordering; nothing addresses online-ordering parity. Absence cannot yield `no` on this host. WHAT WOULD RESOLVE IT: a Menu article field list showing a cash/card price pair on the item, or a Receipt Settings option to print both prices. |
| menu-pricing-versioning-effective-dates | unknown / F - Still unresolved. I read the complete Owner's App (web) Menu article (updated April 9, 2026), the Ow | upheld | Upheld unknown. Nothing in the 302 blog posts, 14 case studies (all zero-length in the corpus), 72 pages or the Wayback-recovered pages adds a staging or rollback surface. What is documented remains immediate-effect editing: 'Once you save your changes, they will go live instantly' (menu FAQ), echoed by the Wayback help-center capture ('Once you click Save Changes, your changes will go live instantly') and by the Wayback Custom Website article ('Changes made in the Owner's App - Web update your Slice Online Ordering Page in real time'). Bulk price change, timed out-of-stock return and day-of-week category availability are all scheduling of AVAILABILITY, not effective-dated price versions. There is no publish step, no version list and no rollback. I did not write `no` because no document makes a closed statement about the menu surface - the Menu article's 'Here is what you can do' is an overview framing - and on slice.com absence is not measurable (fabricated control slugs and real absent slugs probe identically). WHAT WOULD RESOLVE IT: a Menu or release-note article showing a scheduled/effective-dated price change or a menu revision history. |
| payments-qr-guest-pay | unknown / F - Unknown. The `no` leaned on Order Entry's \"There are three ways to pay for an order: Card, Cash, an | upheld | Upheld unknown. The 302 new blog posts add QR material but none of it is guest check payment at Slice: slice.com/products/online-pizza-ordering-system/ answers 'Can customers order through social media or via QR codes?' with 'Yes - you can place ordering links on social pages or QR codes on menus, pizza boxes, or signs', which is a QR route into ORDER ENTRY, not a scan-to-pay-an-open-check flow; and slice.com/blog/how-to-use-qr-codes-to-boost-your-pizza-shop/ is generic third-party-neutral advice about QR codes in restaurants ('QR codes can be used for payments too'), describing the industry rather than Slice's product. The adjacent Slice-operated guest pay surface is still the SMS one from the 'Let Phone Customers Pay by Text' release note, which sends 'a secure link to pay online'; whether that hosted pay page is reachable by QR from a printed check, and whether settlement auto-closes the order in Register, is unstated. WHAT WOULD RESOLVE IT: a Receipt Settings option to print a pay-by-QR code, or documentation of the hosted pay link being generated for a Register check rather than only a Slice Phone order. |
| payments-multi-entity-routing | unknown / F - Still unresolved after checking the surfaces where it would live. Multi-location accounts do exist - | upheld | Upheld unknown, though the newly read Terms and Conditions sharpen the picture. The T&C requires 'a deposit account ("Merchant Deposit Account")' per Restaurant and forbids changing it unilaterally, and the Adyen Acquiring Addendum routes card settlement to 'bank accounts held by Member and paid out to Merchant directly from such bank accounts' - all framed at the level of one Merchant, with no per-location or per-entity split described. But 'Restaurant' and 'Merchant' are contract parties, not locations, so a group could equally sign several agreements; the document neither grants nor denies split settlement under one login. The product side is unchanged and remains unpublishable: Owner's App (web) Statements/Payouts show no bank-account or entity column, the Settings > Payments section contains only a card for paying Slice and payout-speed management, and the bank-account control is explicitly off-platform - the FAQ answers in full, 'Please call (888) 974-9928 to change your direct deposit settings.' WHAT WOULD RESOLVE IT: a multi-location Owner's App article showing per-location payout destinations, or an Order Form/Annex specimen showing multiple Merchant Deposit Accounts under one agreement. |
| kitchen-pizza-fractional-display | unknown / F - Still unresolved, and I can now say precisely where the gap is. Capture is unambiguous - Order Entry | upheld | Upheld unknown. The corpus expansion confirms the capture side twice over - Register Order Entry for the cashier and the Wayback-only Custom Website article for the guest ('customers can add them to the left half, right half, or the whole pizza') - and still publishes nothing about how the half assignment RENDERS on the production surface. That surface is thermal paper: slice.com/hardware-pricing/ (Wayback, 2026-01-21) itemises the entire Register hardware catalogue - iPad, card reader, thermal receipt printer, kitchen impact printer, paper, router, cash drawer, Verifone terminal - with no display of any kind, and a KDS appears only as unshipped future scope ('Discounted kitchen displays & kiosks (coming soon)', slice.com/family-membership/). The only ticket-formatting documentation remains Register Settings > 'Kitchen Receipt Settings: Customize kitchen tickets by choosing the font, order of items on the ticket, and the additional information included', which enumerates no fields and shows no sample. WHAT WOULD RESOLVE IT: a sample kitchen ticket image or a field list in the Kitchen Receipt Settings documentation showing a LEFT/RIGHT or section label. |
| kitchen-speed-of-service-reporting | unknown / F - Unknown. Re-read the cited Owner's App (web) Financials article in full from the WP REST API. It nev | upheld | Upheld unknown. Nothing in the 302 blog posts, the pages census or the Wayback pages adds a timing report. The one new 'speed of service' string in the corpus is a menu-layout aside in the Owner's App (web) Register article - 'Register Menu Layout: View and manage your Slice Register menu to keep it organized and improve the speed of service' - which is a rationale for reordering menu tiles, not a report. The reporting surface remains open-ended by construction and therefore unfalsifiable here: the Financials article introduces its reports as 'various financial and sales reports', its summaries with 'including:' and its order tables with 'such as:'. The one closed enumeration, the Register Sales Summary ('The Sales Summary Report consists of:'), is a single end-of-day cash-and-sales report, not the reporting surface. No ticket-time, per-station or percentile column is documented, and there is no public API to export from. WHAT WOULD RESOLVE IT: a column list for the Order Activity or Orders report showing a prepared-at/completed-at timestamp, or any documented CSV export carrying ticket times. |
| kitchen-prep-forecasting | unknown / F - Unknown. The `no` rested on treating Slice's analytical surfaces as exhaustive lists, and they are n | upheld | Upheld unknown. The string 'predict' occurs nowhere in the Knowledge Hub and 'prep list' nowhere in the 500-document corpus; the only 'forecast' hit is generic business-plan advice in a blog post, not a product description. The surface where a forecast would live is described but not enumerated: Owner's App Report > 'Insights: View business recommendations from Slice based on your shop's activity, such as adding menu photos or running promotions to help increase orders' and 'Business Recommendations: Slice provides suggestions to improve your shop's performance, such as adding menu photos, adjusting delivery fees, or offering promotions' - both 'such as', both about marketing actions rather than predicted prep quantities, and neither closed. The 'no screen to surface a prep list on' reasoning also remains unsafe: a KDS is priced on slice.com/pricing-test/ and listed as 'coming soon' on the Family Membership page. Absence is not measurable on slice.com, so `no` is unavailable. WHAT WOULD RESOLVE IT: an Insights article enumerating the insight types, or any documented prep/production list with quantities. |
| delivery-injection-error-visibility | unknown / F - Still unresolved, but the picture is sharper than 'not documented'. What Slice publishes on integrat | upheld | Upheld unknown. The re-read of Register Order Management (updated 2026-04-30) adds two things and neither is per-channel integration health. First, a per-ORDER payment flag - 'a red dollar icon means payment failed, the order was canceled, or it was refunded' - which conflates three causes and is not an injection-failure view. Second, an explicit hand-off of integration problems away from Slice: 'While Slice controls your third party menus and hours, if there's a problem, reach out to the third-party provider directly.' Alongside the previously found one-way statement ('Slice receives the Third-Party orders but does not have a way to communicate back to those providers'), the three-minute confirmation deadline and the warning that editing third-party menus 'will break the integration', this is an operator told to detect and escalate failures himself. What is still nowhere documented is a per-channel connection state, a failed/rejected injection list, or an alert on integration failure. I stopped short of `no` because Register Settings introduces itself as 'key configuration areas' rather than a complete list and no document positively closes the set of status views. WHAT WOULD RESOLVE IT: a Third Party Orders article showing a per-provider connection indicator, or a support page stating that integration failures are not surfaced in-product. |
| delivery-offline-behavior | unknown / F - Still unresolved. This claim asks whether the vendor DOCUMENTS offline delivery behaviour, and havin | upheld | Upheld unknown - and this is the cell where the session's biggest find deliberately does NOT reach. Slice's Terms and Conditions do document disconnected operation for the first time ('Restaurant may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline', with queued authorization and a $100 per-transaction cap), so the vendor is no longer wholly silent on outages. But that section is scoped to POS payment transactions and says nothing about the three things this claim names: whether cash delivery orders can still be taken, whether driver assignment continues, and whether driver settlement continues. The delivery documentation assumes connectivity throughout - Delivery Management batching, the note that 'Drivers must be logged in and marked Available to receive batch assignments', live driver tracking, and the Cash Management Delivery Management Report reconciling cash due to driver against card tips - and the Driver App article documents no offline queue. Keyword matches on 'offline' elsewhere in Slice's reporting are false positives: there it means an in-person Register order. WHAT WOULD RESOLVE IT: a Driver App or Delivery Management article stating what works during an internet outage, or an outage-behaviour support page covering dispatch and driver settlement. |
| digital-group-ordering | unknown / F - Checked all 45 slice.com/knowledge-hub articles, all 30 slice.com/release-notes-2 posts and all 26 e | upheld | The ~465 readable new files change nothing here. 'Group order' occurs only in blog advice about catering and party occasions (e.g. posts__blog_top_tips_for_attracting_pizza_party_orders_to_your_pizzeria), never as a product surface; 'shareable', 'share a cart' and 'split the bill' return no product hit. The two checkout walkthroughs (epkb knowledge-hub online-ordering-pizzeria-website and the Wayback-only online-ordering-custom-website) describe one cart, one payer: review the order, log in or enter contact details, select a payment method, choose utensils, tip, promo code. The newly pulled consumer FAQ at slicelife.com/pages/faq has an ORDERING section that covers minimums, guest checkout, payment methods and promo codes with no multi-participant cart. None of these asserts a closed set of ordering flows, and absence is not measurable on slice.com (the href-fixpoint probe answered identically for real absent paths and fabricated controls behind Cloudflare's 403). RESOLVES: a Slice KB article or slicelife.com page describing a shareable order link with per-person or total spend caps, or a Slice statement that group ordering is unsupported. |
| digital-sms-ordering | unknown / F - knowledge-hub/slice-phone/ and release-notes-2/let-phone-customers-pay-by-text/ (dated 2026-02-05) d | upheld | All new SMS material is outbound and post-order. Release note 'Send Slice Phone Order Confirmations by Text' (epkb_post_type_2) says the customer receives 'a text message with a link to view their order details', and knowledge-hub/slice-phone/ adds pay-by-text on that link; both are triggered by a VOICE order taken by the Slice Phone team, and the same article states positively 'Orders cannot be edited through the text' and that the customer must call back. The one new hint of a marketing text is grade-C copy on slice.com/products/online-pizza-ordering-system ('Our marketing experts send up to 3,000 emails & text messages to your customers every week'), which does not say those texts carry an ordering or reorder link. Slice's SMS Terms describe inbound keywords only for HELP, STOP and RESUBSCRIBE to short code 69362 - never an order keyword - but that list bounds the alerts programme, not Slice's ordering channels. No inbound text-to-order, and no positive exclusion. RESOLVES: a KB/release note showing a text-initiated order or reorder link that lands in the Register, or a Slice statement that text ordering is not offered. |
| digital-subscriptions | unknown / F - knowledge-hub/owners-app-web-marketing/ enumerates the entire guest-facing promotion surface as Onli | upheld | The new corpus resolves the vocabulary but not the claim: every 'membership' and 'subscription' string in it is MERCHANT-side. slice.com/family-membership/ sells Family Membership to the pizzeria ('Join Slice Family Membership to make more money and save time'); the merchant contract (pages__online_restaurant_agreement) prices the Digital Marketing Product as a 'Cycled Subscription' or 'Auto-renewal Subscription' on an Order Form; knowledge-hub/owners-app-web-financials/ deducts 'Register Subscriptions'. On the consumer side the newly pulled slicelife.com/pages/slice-rewards describes a FREE programme ('FREE PROGRAM', 8 Pizza Points = 1 free pizza) with no paid tier, no delivery-fee waiver and no recurring billing, and the consumer terms of service incorporate only the Privacy Policy, the Slice Rewards T&C and the SMS Terms - no membership agreement. That is suggestive but is an enumeration of incorporated documents, not a statement that guest subscriptions do not exist. RESOLVES: a slicelife.com or KB page documenting a paid guest membership/entitlement, or a Slice statement ruling one out. |
| guest-loyalty-offline-behavior | unknown / F - Searched the full text of all 45 knowledge-hub articles, 30 release notes and 26 FAQs pulled from sl | upheld | The contract sense of 'offline' is real and I read it: pages__online_restaurant_agreement 'Offline Transactions' says the Restaurant 'may use Slice Register and Slice Standalone Payments to conduct point of sale activities offline', that such transactions 'will be queued and submitted for authorization when Internet connectivity to the applicable Hardware is restored', caps them at $100 each and reserves Slice's right to limit the queue depth. That is queue-and-reconcile for PAYMENT AUTHORIZATION only - the clause says nothing about loyalty lookup, accrual or redemption, and it defers to Order Forms we do not hold ('Except as provided in an Order Form'). The loyalty programme itself is Slice's marketplace scheme: slicelife.com/pages/slice-rewards accrues 'a Pizza Point' on 'Every order in the Slice app with a subtotal of $15 or more' and redeems from the app's Rewards tab, i.e. an online path that a disconnected Register order does not obviously touch - but no document states what happens to points on a queued offline Register order. Separately, the KB's 'Offline Sales Subtotal' is an in-person/online accounting term and was excluded from this reasoning. RESOLVES: an Order Form or KB article stating whether Pizza Points and shop coupons accrue or redeem on queued offline Register transactions. |
| guest-loyalty-consent-management | unknown / F - Checked every marketing-adjacent article on slice.com: knowledge-hub/owners-app-web-marketing/ (Disc | resolve-to-partial | Slice operates the guest messaging itself and publishes real revocation machinery that is NOT keyword-only: the privacy policy honors opt-out 'by following the unsubscribe instructions provided in those communications or by contacting us', the Slice SMS Terms (https://slice.com/slice-sms-terms/, updated 2026-02-25) accept any of STOP, CANCEL, END, UNSUBSCRIBE, REVOKE, OPT-OUT or QUIT and add 'You may also call the Slice support team at 888-974-9928', the rewards programme can be exited 'by reaching out to [support], through chat on the Slice app, or through SMS', and the policy honors browser Opt-Out Preference Signals including GPC. The SMS Terms also enumerate the SOURCE of consent (a form on slice.com or slicelife.com, texting short code 69362, or sign-up via an account manager or marketing event) and separate marketing from transactional consent ('you are not required to consent to receive Slice Alerts with marketing as a condition of purchasing'). SHORTFALLS, three: (1) no consent TIMESTAMP or stored source-of-consent record is documented anywhere; (2) revocation is expressly scoped to one channel rather than all - 'Your opt-out of Slice Alerts will apply to the channel through which you opted-in' - and the SMS Terms govern SMS only, with email opt-out handled separately by unsubscribe link; (3) SUBJECT: this is Slice-the-marketplace's consent record for messages Slice sends to diners, not an operator-controlled surface - knowledge-hub/owners-app-web-customers/ shows the pizzeria's customer profile carrying only name, address, email, phone, creation date and most recent order with no opt-in flag, and for operator-sent messages the merchant contract makes the Restaurant 'solely responsible for ... obtaining and retaining records of any required consent to communications and honoring opt-out requests', with no tooling described. source |
| guest-loyalty-10dlc-registration | unknown / F - Full-text searched all 45 knowledge-hub articles, 30 release notes and 26 FAQs from slice.com/wp-jso | upheld | '10DLC', 'A2P', 'brand registration' and 'campaign registration' occur nowhere in the ~465 readable files, including the two legal texts that would carry them (slice.com/slice-sms-terms/ and pages__online_restaurant_agreement). New positive facts point both ways and neither closes the cell. FOR 'no operator registration is needed': Slice is itself the sender - the SMS Terms are Slice's own programme, opt-in and HELP/STOP run through SHORT CODE 69362 (short codes are outside 10DLC), business texts to owners 'will come from (646) 542-1877' per pages__scamadvice, and grade-C copy says Slice's own 'marketing experts send up to 3,000 emails & text messages to your customers every week'. AGAINST: the merchant contract contemplates operator-sent SMS - 'Communications Tools' that 'permit Restaurant to draft, schedule and/or transmit outbound communications to Consumers ... including phone calls, recorded phone messages, text messages' - and makes the Restaurant solely responsible for legal compliance, without saying who registers the traffic. The claim is disjunctive ('handles OR explicitly documents'), and Slice neither documents registration nor states that its own registration covers merchant traffic. RESOLVES: any Slice page naming 10DLC/A2P registration, or an onboarding doc for the Communications Tools showing whose brand and campaign the traffic runs under. |
| guest-loyalty-referral-program | unknown / F - Searched all 45 knowledge-hub articles, 30 release notes and 26 FAQs: 'refer', 'referral' and 'invit | upheld | The four referral documents new to the corpus are all the MERCHANT bounty, not a guest mechanic: pages__referrals ('Know a great shop? Earn up to $1,500 for every one that joins'), pages__exporeferral (a trade-show variant), pages__referrals_2 (empty in REST) and the full pages__referrals_termsandconditions, whose scope sentence defines the programme as governing 'the Slice Solutions, Inc. Restaurant Referrals program' with 'Eligible Product' meaning 'Slice's Family Membership or Slice Online Ordering' - restaurant acquisition, with no per-guest code and no reward to a diner. On the guest side: the operator's whole promotion toolset in knowledge-hub/owners-app-web-marketing/ is Online Discount, Promo Codes (usage limit no-limit / one-time / once per customer) and Deals, none of which attributes a referred guest's first order; the newly pulled slicelife.com/pages/slice-rewards and /pages/faq describe points and promo codes with no refer-a-friend; and the consumer terms of service incorporate only the Privacy Policy, Rewards T&C and SMS Terms. Countervailing and unresolved: third-party reporting (bankcheckingsavings.com, grade E, undated refresh) describes a $5/$5 consumer referral at slicelife.com/share; that path returns HTTP 404 to us today (probed 2026-09-05) and the Wayback CDX index shows it serving 200 only in 2017 before becoming a permanent 301, so the diner mechanic may be retired - but a 404 is not a vendor statement, and none of the above is a positive exclusion. RESOLVES: a live slicelife.com referral page or Slice Rewards T&C section, or a Slice statement that guest referrals were discontinued. |
| guest-loyalty-wallet-pass | unknown / F - Full-text search of the WP REST corpus (45 knowledge-hub articles, 30 release notes, 26 FAQs) return | upheld | 'Apple Wallet', 'Google Wallet', 'wallet pass' and PKPass return zero hits across the ~465 readable slice.com files and all nine newly pulled slicelife.com files. The newly pulled slicelife.com/pages/slice-rewards makes the carrier explicit - enrollment is automatic with a Slice account and the balance lives in the app ('You can find your Pizza Points balance in the Rewards tab of the Slice app'; 'Head to the Rewards tab on your Slice app') - so the app is the documented pass, but nothing states whether a wallet alternative exists for a guest who does not install it. The only wallet-adjacent strings in the corpus are Apple Pay / Google Pay as payment credentials at the Register. No positive exclusion, and absence is not measurable on slice.com. RESOLVES: a slicelife.com help page, app-store listing or release note showing an 'Add to Apple Wallet' pass with a push-updatable balance. |
| guest-loyalty-ai-offer-recommendation | unknown / F - The strings 'AI', 'artificial intelligence', 'machine learning' and 'predictive' do not occur in any | upheld | New material adds one genuinely new fact and it is not enough: the merchant contract defines 'AI Features' as 'any artificial intelligence features provided as part of the Platform', with 'Input' meaning Restaurant Marketing Materials fed to them and 'Output' the content returned, and a clause requiring the Restaurant to review Output for accuracy. That establishes the Platform contemplates generative AI over merchant marketing material; it names no shipped feature and says nothing about offer content, audience selection or send timing. Everything else cuts the other way: slice.com/support/24-7-365-customer-support and /support/dedicated-account-management both say 'No AI, robots, or chat bots - fully human support', the marketing service is repeatedly described as run by human 'marketing experts', and the only AI-and-offers text in the corpus is generic advice in posts__blog_pizzeria_marketing_trends_to_watch ('you could use AI to send targeted offers based on a customer's favorite toppings'), which is a blog recommendation, not a Slice feature. The nearest shipped surfaces remain rule-based (Best Sellers ranked on 30-day sales; 'Business Recommendations' operational nudges). RESOLVES: a KB article or release note describing an AI-generated offer, audience or send-time recommendation inside the Owner's App. |
| labor-photo-punch-verification | unknown / F - knowledge-hub/homebase-partnership/ (updated 2026-02-18) and knowledge-hub/homebase/ (updated 2026-0 | upheld | Unchanged by the new material, and the subject is not Slice. knowledge-hub/homebase-partnership/ (2026-02-18) and knowledge-hub/homebase/ state 'Time Clock is powered by Homebase, a Slice Partner' and require the shop to hold its own Homebase account at joinhomebase.com; the punch Slice documents is PIN-only (exit Register, open Time Clock, 'Enter your PIN on the keypad', tap Clock In, confirmation). No camera, selfie, facial or biometric step appears, and 'photo' occurs in the corpus only for menu photography. A step-by-step happy path is not an assertion that no photo mode exists, and the Employee Permissions sentence that the permissions log 'does not function as a time clock' bounds that log, not the product. Whether photo-at-punch is available is a question about HOMEBASE's product, which no Slice source answers. RESOLVES: scoring this against Homebase's own documentation under Homebase's record, or a Slice KB statement about Time Clock punch options. |
| labor-geofenced-mobile-punch | unknown / F - knowledge-hub/homebase-partnership/ and knowledge-hub/homebase/ both state 'Your team can clock in u | upheld | Both Homebase articles establish the mobile punch exists - 'Your team can clock in using the Register iPad or their own phones - whichever works best for your shop' - but the documented flow is PIN entry with no location step. 'Geofence', 'GPS', 'radius' and 'location' appear nowhere in a timekeeping context in the ~465 readable files (GPS occurs only in the Driver App and delivery-map articles). The restriction is the substance of the claim and it belongs to the partner app: Time Clock is 'powered by Homebase, a Slice Partner' and requires a separate Homebase account, so whether a phone punch can be fenced to the shop is Homebase's setting, undocumented on Slice's side, and Slice never says it is unavailable. RESOLVES: Homebase's own Time Clock location settings scored under Homebase, or a Slice KB statement on phone-punch restrictions. |
| labor-offline-time-punch | unknown / F - The two Homebase articles (knowledge-hub/homebase-partnership/, knowledge-hub/homebase/) describe th | upheld | I checked the contract sense of 'offline' rather than the KB accounting sense. pages__online_restaurant_agreement 'Offline Transactions' covers 'point of sale activities offline' - transactions queued and 'submitted for authorization when Internet connectivity to the applicable Hardware is restored', capped at $100 each - which is payment authorization, not timekeeping, and the clause is expressly subject to Order Forms we do not hold. Time punches are not taken in Slice Register at all: they are entered in a separate Time Clock app on the iPad that is 'powered by Homebase, a Slice Partner' and requires the shop's own Homebase account, so the offline clause does not reach them and Slice documents no queueing, sync, reconnection or duplicate handling for punches. Whether Homebase's app buffers punches offline is Homebase's fact, not Slice's, and no Slice source states it either way. RESOLVES: an Order Form or KB article covering Time Clock behavior during an outage, or scoring the punch behavior under Homebase's own record. |
| labor-demand-labor-forecast | unknown / F - Searched the full WP REST corpus: 'forecast', 'projected', 'predicted' and 'recommended staffing' do | upheld | I came close to a 'no' here and declined. Positive scoping does exist - knowledge-hub/homebase-partnership/ describes the entire Slice-Homebase surface as the Time Clock app and says 'You'll use the Homebase website or mobile app separately to set up schedules, manage employees, and run payroll', describing no sales-data flow - and Slice's own analytics are backward-looking (owners-app-web-analytics: sales by day, top and least selling items, customer engagement; owners-app-report: week-over-week Sales Insights), with 'forecast', 'projected' and 'recommended staffing' absent from the corpus; Homebase's published POS sales integrations (Square, Toast, Clover, Lightspeed, PAR - joinhomebase.com/integrations, grade E) do not list Slice. But an instruction to do scheduling in a partner's product is an escalation, not a statement that staffing recommendations are unavailable, and a third party's integration list is not Slice speaking. Absence on slice.com is not measurable. RESOLVES: a Slice statement that it passes sales history to Homebase (or does not), or a Homebase-side integration record naming Slice. |
| labor-overtime-prevention | unknown / F - 'Overtime', 'OT' and 'threshold' do not occur anywhere in the 45 knowledge-hub articles, 30 release | upheld | 'Overtime', 'OT' and 'threshold' occur nowhere in the ~465 readable files. The punch Slice documents is PIN entry followed by 'Tap Clock In to begin your shift' and a confirmation message - no approaching-hours warning, no block, no configurable threshold - and Slice positively places scheduling, employee management and payroll in Homebase's own product, used separately with the shop's own Homebase account. So any overtime guardrail would be Homebase's, at the moment of a punch taken in Homebase's app; Slice neither claims it nor disclaims it, and Slice's own Owner's App has no labor surface at all (knowledge-hub/owners-app-web-time-management/ is shop OPERATING hours, pauses, closures and ETAs, not employee hours). RESOLVES: Homebase's own clock-in warning behavior scored under Homebase, or a Slice KB statement about Time Clock warnings. |
| labor-break-compliance-by-state | unknown / F - The clock-out sequence in knowledge-hub/homebase-partnership/ and knowledge-hub/homebase/ is: open t | upheld | The clock-out sequence in both Homebase articles is: open Time Clock, enter PIN, 'Tap Clock Out', optionally rate the shift and leave a note, then a confirmation showing the time. No break start/end action, no meal or rest attestation, no missed-break flag; 'meal break', 'rest break', 'attestation' and 'premium pay' return nothing across the ~465 readable files, and the only jurisdiction-aware Slice article remains marketplace-facilitator sales tax. Break rules would be configured in Homebase - the Time Clock app is 'powered by Homebase, a Slice Partner' and the shop holds its own Homebase account - which is a different subject from Slice, and Slice makes no statement that per-state break rules are unavailable. RESOLVES: Homebase's break-rule configuration scored under Homebase, or a Slice KB statement on break prompts at the Register iPad. |
| reporting-history-retention | unknown / F - Checked every reporting surface on slice.com: knowledge-hub/owners-app-web-financials/ (Reports run | upheld | Still unresolved against the enlarged 500-document corpus. No retention window, archival tier, truncation warning or retrieval fee appears in any of the nine WordPress post types, the ten Wayback-recovered pages, the merchant Online Restaurant Agreement or the consumer Terms of Service. Reports are generated over an operator-chosen date range with no stated maximum lookback; the mobile Orders report's filter list ("today, yesterday, or the last 7, 14, or 30 days") is prefixed by "like", so it is open and cannot bound the window either. Absence is not measurable on slice.com - the HTML route 403s every client we may send, and probed absent slugs answer identically to fabricated controls - so silence cannot be converted into a verdict. Resolved by: a merchant-facing data-retention clause, a support answer stating the lookback limit, or a report UI showing the earliest selectable date. |
| reporting-nl-query | unknown / F - 'AI', 'assistant', 'ask', 'natural language' and 'chatbot' return no product hits across the 45 know | upheld | No natural-language or AI query surface found in the enlarged corpus, but nothing positively excludes one. Reporting is documented as pick-a-report-and-a-date-range across all five surfaces (Owner's App (web) Reports, Analytics, mobile Report, Register Cash Management Reporting, Statements). The nearest AI-adjacent objects are non-query: Insights is a push recommendation engine ("Business Recommendations: Slice provides suggestions to improve your shop's performance"); the merchant agreement licenses Restaurant Trademarks for use "in AI Features and any Output from Input" without describing a merchant-facing assistant; and the support page's AI mention is a disclaimer about support channels ("You'll never deal with a chatbot, AI voice, or frustrating phone menu"), not about querying the operator's own data. None of these closes the Analytics feature set. Resolved by: a Knowledge Hub article or release note for an ask-a-question reporting surface, or a vendor statement that none exists. |
| reporting-sales-forecast | unknown / F - Full-text search of the WP REST corpus finds no 'forecast', 'projection' or 'predicted sales'. knowl | upheld | No forward sales forecast found and no closed statement excluding one. Every documented analytic is retrospective: Analytics (Sales by Day, Top and Least Selling Menu Items over a chosen past period), the mobile Sales Report ("today's total sales compared to the same day last week"), the End of day report, and the five Owner's App (web) reports. Insights compares weekly sales to previous periods rather than projecting. The forward-looking objects Slice publishes are operator-entered rather than modelled - scheduled orders, delivery and pickup ETAs, Adjusted Time rules - and no scheduling or ordering workflow consumes a predicted figure, scheduling being done in partner Homebase. None of that is a closed enumeration of the Analytics feature set, and absence is not measurable on this host. Resolved by: an Analytics or Insights article naming a forecast, or a vendor statement that forecasting is not offered. |
| multi-location-new-store-template | unknown / F - knowledge-hub/slice-register-getting-started documents onboarding as a call with an Implementation L | upheld | Provisioning is documented only as a human service, which does not settle whether a template is cloned behind it. The vendor FAQ says "Our team comes to your shop, sets up your hardware, and trains your staff in person", and slice-register-getting-started describes an Implementation Lead who reviews the existing POS, network and contracts and assists with menu configuration; slice.com/pricing prices this as a $1,000 implementation fee. Because Slice staff perform the build, an internal cloning tool is entirely compatible with everything published, and no document enumerates the provisioning toolset. The published time-to-open is ambiguous rather than absent - the product FAQ declines a figure ("We stay until your team feels ready") while the home page asserts "Most shops are up and running within a few days", which is a first-shop go-live claim, not a cloned-location figure. Resolved by: an implementation article describing copying configuration from an existing shop, or a vendor statement that each shop is built from scratch. |
| multi-location-multi-brand | unknown / F - Searched the whole retrievable corpus (45 Knowledge Hub articles, 30 release notes, 26 FAQs via slic | upheld | Re-tested against the full 500-file corpus (302 blog posts, 72 pages, 45 KB articles, 30 release notes, 26 FAQs, 14 case-study records and 10 Wayback pages; 32 of the 500 -- all 14 case studies among them -- carry headers only, their bodies being page-builder content the REST API does not return). New positive finding, but on the wrong axis: MULTI-LOCATION is documented -- knowledge-hub/owners-app-getting-started says the dashboard location selector 'lets you switch between multiple shop locations using a dropdown menu', and slice-register-getting-started says 'If you have multiple shops, select the location you are in.' That binds one Register session to one shop, which is the opposite of what the claim requires (two brands on ONE terminal and drawer). 'virtual brand', 'multi-brand' and 'second concept' occur zero times in all 500 documents, and receipt branding is described only as a single shop logo. Absence is not measurable on slice.com (the HTML route 403s every client we may send, and fabricated control slugs answer identically to genuinely absent paths), so this is silence, not a documented limit. Would resolve: an Owner's App menu article describing per-brand menus or receipt headers on one Register profile, or an Order Form line item for a second concept. |
| reliability-lan-degraded-multi-terminal | unknown / F - Re-checked against sources the earlier pass did not have. Read Annex 3 of the Pizzeria Agreement (sl | upheld | Upheld against the enlarged corpus. Annex 3's Offline Transactions clause is genuinely the disconnected sense of 'offline' (unlike every KB use of the word, which means an in-person Register order), but it speaks only to payment authorization queued until 'Internet connectivity to the applicable Hardware is restored' -- per device, and silent on whether check state is shared between iPads over the LAN. knowledge-hub/register-settings still documents only a manual per-device cloud pull ('If you use multiple Register iPads, you must download changes on each device'). I read the Telecommunications section to its end: it contains exactly two clauses, Internet Connection and Offline Transactions, and the latter is the ONLY published statement of offline scope anywhere in the corpus -- it says nothing about order creation, modifiers, kitchen printing, cash tender or shared check state. Nothing in the 302 previously unread blog posts or 72 pages describes degraded operation; 'failover' occurs zero times and no document contains a phrase such as 'when the internet is down'. Per-device queuing plus a cloud-only sync primitive strongly suggests per-terminal islands, but that is inference, and absence is not measurable on this host. Would resolve: a Register article stating what a second iPad shows for an order started on the first while the WAN is down. |
| reliability-offline-kds-printing | unknown / F - The earlier rationale reasoned from 'printers are LAN-attached'; that premise is wrong. slice.com/kn | upheld | Upheld. Slice ships no KDS, so the claim reduces to kitchen-printer routing during an outage. Annex 3's Offline Transactions clause -- the only genuine disconnected-mode statement Slice publishes -- covers queued payment authorization and a $100 per-transaction cap and says nothing about printing. Read to its end, Annex 3's Telecommunications section holds exactly two clauses (Internet Connection, Offline Transactions) and that pair is the only published statement of offline scope in the whole corpus; it never says whether order creation, modifiers, cash tender or kitchen printing survive an outage. Every other use of 'offline' in the corpus means an in-person Register order as opposed to an online one (e.g. owners-app-web-financials: 'Offline Orders (via Slice Register): Total number of orders entered and paid for through Slice Register'), so none of them is evidence here. Printers are Bluetooth-paired to the iPad (online-ordering-getting-started; Epson TM-m30III only), which makes local printing plausible, and the contract does affirmatively permit conducting 'point of sale activities offline' -- but neither statement says kitchen tickets continue to print, and a printing capability may not be inferred from a payments clause. Would resolve: one KB or release-note sentence stating that kitchen tickets print from a queued offline order. |
| reliability-printer-fallback | unknown / F - Read slice.com/knowledge-hub/register-settings/ end to end. Its Receipt Settings section enumerates | upheld | Upheld, with the search widened rather than repeated. All 30 release notes were re-read for printer changes: the only one touching printing is 'Make Printed Reports Easier to Read' (a font-size control on printed reports). slice-register-getting-started documents printer setup as discover-name-test only, with per-surface automatic-printing toggles; register-settings adds no backup-printer assignment, no failover target and no unreachable-printer alert. The nearest thing to health monitoring anywhere is 'Slice Support: View your Connection Status to confirm your Register is online and connected', which reports the iPad's link, not a printer's. 'failover' occurs zero times in all 500 documents. A settings page that never claims to be exhaustive is not a positive exclusion, and absence is not measurable on slice.com. Would resolve: a Receipt Settings article naming a backup-printer field, or a release note announcing printer-offline alerts. |
| reliability-sync-conflict-handling | unknown / F - slice.com/knowledge-hub/register-settings/ documents the only sync primitive Slice publishes: 'Downl | upheld | Upheld. The claim asks whether the vendor DOCUMENTS its conflict-resolution behaviour, and no document in the 500-file corpus states one. The only published sync primitive remains the one-way manual pull in knowledge-hub/register-settings ('Download changes from Slice... If you use multiple Register iPads, you must download changes on each device'), and knowledge-hub/order-manager-kit still permits editing orders and issuing refunds from a second iPad without saying what happens if both edit at once. Annex 3 allocates all offline risk to the merchant ('Restaurant assumes all risk, responsibility and liability associated with any transaction that Restaurant conducts while Slice Register and/or Slice Standalone Payments is offline') but states no last-write-wins, merge or operator-prompt rule -- a liability allocation is not a conflict-resolution specification. Would resolve: any statement of precedence between two devices' edits. |
| reliability-public-status-page | unknown / F - Probed hosts rather than searching. status.slice.com does not connect; status.slicelife.com returns | upheld | Upheld, and the corpus was asked directly this time rather than only the DNS. 'statuspage', 'status.slice', 'system status' and 'service status' occur zero times in all 500 documents; the only 'status page' hits are knowledge-hub/online-ordering-shop-status and register-shop-status, which are the shop's own open/paused/closed toggle, not a vendor availability page. Two full Wayback captures of the site chrome (hardware-pricing 2026-01-21, products/support-team 2026-01-03) reproduce the entire PRODUCTS / RESOURCES / SUPPORT navigation with no Status or Trust entry, and the 72-page census contains no status, trust or security page. Against that, slice.statuspage.io returns 'Slice Status - Page Inactive' and cannot be attributed to Slice Solutions, Inc.; nothing in the vendor's own corpus links to it, which weakens attribution rather than settling it. Absence is not a no on this host -- the corpus itself misses at least ten paths recoverable only from Wayback -- so this stays unknown. Would resolve: a Slice-published link to a status host, or a Statuspage tenant that identifies Slice Solutions, Inc. |
| reliability-incident-postmortems | unknown / F - Pulled all 30 release notes (slice.com/wp-json/wp/v2/epkb_post_type_2, dated 2025-10-09 and 2026-02- | upheld | The one gap the previous rationale named -- the unread blog archive -- is now closed, and the answer did not change. All 302 blog posts, 14 case studies, 30 release notes, 45 KB articles, 26 FAQs and 72 pages were searched: 'outage', 'postmortem', 'post-mortem' and 'root cause' occur zero times, and 'incident' appears only in the contract's and SMS terms' liability language. The single 'emergency' post type (slice.com/blog/emergency/this-is-the-title-of-the-emergency/, modified 2026-06-05) is an unfilled page-builder placeholder whose title is literally 'this is the title of the emergency' -- an unused template, not an incident report -- and its rendered body sits behind the same Cloudflare 403 that blocks every HTML route. There is also no status page to host postmortems. This is a complete census of what the WordPress type registry exposes, but that registry demonstrably misses live paths, so it is a floor and cannot carry a no. Would resolve: an engineering or trust section, or one dated outage write-up. |
| reliability-backup-restore | unknown / F - Checked both limbs of the claim. Self-service: owners-app-web-financials and owners-app-web-customer | upheld | Upheld; nothing in the 412 previously uncited documents touches either limb. Self-service: owners-app-web-financials and owners-app-web-customers still document only CSV report generation and a customer-database export -- no snapshot, no restore, no point-in-time recovery. Contract: the 'Portability and Deletion of Restaurant Data' clause obliges Slice, on request within thirty days of termination, to 'make Restaurant Data available to Restaurant for export or download', which is an end-of-life portability right rather than an operator-triggered backup; and Annex 4 excludes 'virus removal or disaster recovery' from installation services, which removes a task from a one-time install visit rather than denying a platform capability. 'RPO', 'RTO', 'recovery point' and 'recovery time' occur zero times in the 180KB agreement. Neither limb is met and neither is affirmatively denied. Would resolve: published RPO/RTO figures, or an Owner's App restore control. |
| reliability-pci-dss-4-attestation | unknown / F - Enumerated the whole first-party corpus rather than searching it: all 76 published slice.com pages ( | upheld | Upheld. 'PCI', 'attestation' and 'AoC' occur zero times across all 500 corpus documents including the 180KB Pizzeria Agreement; the sole PCI-shaped hit anywhere is an unrelated Spanish landing page. Annex 7 names the acquiring chain (Adyen N.V., with Wells Fargo Bank, N.A. as acquirer of record) and lists under Important Merchant Responsibilities 'Ensure compliance with cardholder data security and storage requirements' -- but a processor's or acquirer's compliance is not Slice's attestation, and an obligation placed on the merchant is not a statement about Slice's own AoC. The strongest security statement Slice publishes remains the FAQ 'How secure are payments?': 'Slice partners with industry-leading payment processors to ensure all transactions are secure and encrypted', which names no standard. An AoC is customarily supplied to merchants on request rather than posted publicly, so its absence from a public corpus is weak evidence either way. Would resolve: a trust page or a dated AoC summary naming PCI DSS v4.0/4.0.1. |
| reliability-failover-terminal-role | unknown / F - slice.com/knowledge-hub/order-manager-kit/ describes the only role concept Slice publishes: 'In Owne | upheld | Upheld. The only role concept Slice publishes is the Owner's Portal 'Front of House' / 'Back of House' profile in knowledge-hub/order-manager-kit, which changes the landing screen, plus slice-register-getting-started's 'Choose the Register profile if you have more than one terminal' -- a cloud-assigned per-iPad station identity, not a master/server election. No document in the 500-file corpus describes a primary terminal, a local server, or promotion of a secondary device, and 'failover' occurs zero times. Annex 3 treats each unit independently ('Internet connectivity to the applicable Hardware'), consistent with there being no master to fail over from -- a cloud-only POS has nothing to promote -- but Slice never says so, and inferring the architecture is not documenting it. Would resolve: a statement that Register operates cloud-only or peer-to-peer with no designated primary terminal. |
| commercial-pci-p2pe-tokenization | unknown / F - Checked the two places this would appear. Annex 3 of the Pizzeria Agreement says only 'Slice does no | upheld | Upheld, and a partial was considered and rejected. 'P2PE', 'SAQ', 'DSS', 'EMV' and 'tokeniz' occur zero times across all 500 corpus documents including the 180KB Pizzeria Agreement; the single 'PCI' hit anywhere is a fragment of a Spanish word on a landing page. What the contract does establish, so the next pass need not re-derive it: Annex 3 states 'Slice does not receive full payment card details in its provision of Slice Register and Slice Standalone Payments' and that Slice 'has engaged a Processor that conducts payment processing of transactions submitted through Slice Register', and Annex 7 names that chain as Adyen N.V. with Wells Fargo Bank, N.A. as Member and acquirer of record. That is vendor-side card-data isolation plus a named processor -- it names no encryption technology, no tokenization scheme and no SAQ type, so it cannot carry even a partial on this claim; and any P2PE validation Adyen holds is Adyen's attestation, not Slice's. Annex 7 runs the other way, listing under Important Merchant Responsibilities 'Ensure compliance with cardholder data security and storage requirements'. Would resolve: Slice naming a validated P2PE solution or the merchant SAQ type its estate qualifies for. |
| commercial-soc2-attestation | unknown / F - Tested against the complete first-party corpus: 76 published slice.com pages (wp-json/wp/v2/pages), | upheld | Upheld against the complete 500-document corpus, 412 documents larger than the set the previous pass tested. 'SOC 2', 'SOC2', 'ISO 27001', 'trust center' and 'attestation' occur zero times in any of them, including the 302 blog posts read here for the first time, and the 72-page census contains no trust, security or compliance page. Annex 8 (the DPA -- and note it is not listed in the agreement's own preamble index of annexes, which stops at Annex 7) sets Slice's data-protection and subprocessor obligations without referencing any audit report, and Annex 3 pushes security responsibility toward the merchant. The claim's second limb, whether Slice will furnish a report under NDA on request, is untestable from published sources, and absence is not measurable on this host. Would resolve: a trust center, a security page, or a procurement-facing statement naming a SOC 2 Type II or ISO 27001 report. |
| labor-qualified-tips-w2-reporting | unknown / F - knowledge-hub/owners-app-web-financials/ does separate tips by channel and tender - 'Tips - All tips | resolve-to-no | I tested the direction of the partner inference, which is the failure the brief named. The verdict does NOT run 'Homebase ships payroll therefore Slice lacks it'. Slice's own KB states affirmatively that payroll is run in a separate product on a separately-created Homebase account (knowledge-hub/homebase and knowledge-hub/homebase-partnership both carry the sentence), i.e. Slice is describing where the function lives, not merely omitting it. The second instrument is the closed export surface: owners-app-web-financials enumerates all five report types and then every field of each, including a Sales Summary CSV of roughly sixty named columns running from Net Sales to Average Order Value. A payroll export with a tipped-occupation code would have to appear there and does not; every tip field in that ~60-item list is channel- or tender-dimensioned (Register Tips, Online Tips, Credit Card Tips, Slice Online Tips). That is an enumeration of the right thing at the right size, not silence. Upheld at B (vendor KB). source |
| labor-server-performance-metrics | unknown / F - Two per-employee surfaces exist and neither answers the claim as worded. knowledge-hub/owners-app-we | resolve-to-no | I ran the brief's 'each column' test in context and it passes. In owners-app-web-financials the phrase introduces the schema of a downloadable CSV, and the parallel sections prove it: the Sales Summary section under the same construction lists roughly sixty fields with no prose between them, which is a header dump, not a walkthrough. The analyst was also consistent about openness rather than opportunistic - the same document's genuinely open constructions are 'Lists all online orders with details such as' (twice, for on-screen order breakdowns) and 'access to various financial and sales reports', and neither was leaned on; the 'various' sentence is in fact immediately followed by the closed five-item tab list. Second instrument, which the analyst under-used: the Register's report set is independently closed from the other side, by the permission enumeration in owners-app-web-register, which names every grantable report (X, Z, ODR, Delivery Management, Sales Summary, 3rd Party, Historical Cash Drawer) with no employee-sales report among them. I also pressed the one counter-example, the Permissions Log, which does key line-item clears and tax-off actions to a named employee - but it carries no sales figures and no rates, so it is an audit trail, not a performance metric, and buys no partial. Upheld. source |
| reporting-server-scorecards | unknown / F - knowledge-hub/owners-app-web-financials/ enumerates the whole reporting menu - 'Order Activity Repor | resolve-to-no | Same 'each column' test as the row above, same result. The instrument here is the right one for the claim: the claim asks for per-server average check, items per check, category attachment rate and tips as a share of sales, and every report that could carry a category or tip dimension is enumerated field-by-field with no person dimension - Sales Mix (7 columns), Orders Report (12 columns), Sales Summary (~60 fields), Analytics (Top/Least Selling Menu Items, Delivery & Pickup, Sales by Day, customer panels). I tested the strongest counter-example myself: the Delivery Management Report in register-cash-management-and-reporting does give each assigned driver a per-person summary (total amount, cash collected, credit card, tips, other, delivery fees, cash due to driver), from which tips as a percentage of that person's sales is derivable. That is a genuine per-employee sales report, so I considered partial - but it covers drivers, not servers or cashiers, carries no per-driver order count and therefore no average check, and no item or category dimension at all. One of four asked-for metrics, for the wrong role, is not 'materially present'. Upheld. source |
| multi-location-central-menu-publish | unknown / F - Walked the whole slice.com Knowledge Hub through the open WP REST API (wp-json/wp/v2/epkb_post_type_ | resolve-to-no | The brief is right that the per-device pull describes only how a device refreshes and cannot by itself exclude a cloud-side publish. So I tested the cloud side directly rather than the device side. owners-app-web-menu is the cloud side, and it is documented exhaustively - matrix, item type, item details, modifier groups, sizes and pricing, options, register printing, edit ('All of the fields will be the same as the New Item screen'), bulk edit, categories, online menu layout, best sellers. Across that whole surface there is no location selector, no target-set picker and no scoping control of any kind; the account's only location construct sits above it in owners-app-getting-started as a dashboard dropdown that selects one shop 'to view'. Bulk edit exists and is item-scoped, not location-scoped, which shows Slice does build multi-select where it has one. The claim's second limb dies separately and positively: the documented activation path is a per-device pull with no record of what was pushed, when or by whom. I also checked the one place Slice uses publish language - the live product page FAQ 'Update your menu one time and it changes on your website, your app, and your Slice Register at the same time' - and it is explicitly cross-channel, not cross-location, so it does not rescue the cell. Upheld. source |
| multi-location-local-override-policy | unknown / F - knowledge-hub/owners-app-web-menu enumerates the item record (Item name, Price, Category, Availabili | resolve-to-no | The verdict survives but the analyst's stated instrument was partly wrong and I have rewritten the note and quote accordingly. 'The matrix breaks down the following details for each menu item' enumerates the columns of a table VIEW, not the item record - treating a grid's columns as the object's schema is exactly the over-reading the brief warned about, and if that had been the only instrument I would have overturned. It is not: the same article documents the New Item page attribute by attribute, including an Options section that is expressly the availability-and-behaviour surface and contains six toggles and no lock, and then states editing exposes the identical field set. That is a genuine closed enumeration of the thing the claim asks about. Corroboration from the other direction: locking presupposes two tenants, and Slice's multi-shop construct is one owner login switching a dashboard dropdown between its own shops. Upheld, re-quoted. source |
| multi-location-scheduled-publish | unknown / F - Checked knowledge-hub/owners-app-web-register (Register Discounts carry a 'Start Date' and optional | resolve-to-partial | Overturned upward, not to unknown. The analyst's own note disclosed that scheduled activation exists for discounts and for hours, then wrote 'no' anyway - a verdict that contradicts the shortfall it names. The claim is a conjunction (menu, price and promo changes, per-location timezone, rollback) and one conjunct is documented, first-party, at grade B, so the state that fits the evidence rules is partial with the shortfall named, which I have done. I verified both scheduling surfaces myself in owners-app-web-register (Register Discounts) and owners-app-web-marketing ('Define a start date for the promo, and optionally add an end date'), and confirmed the menu article contains no date field of any kind. Precedent is 0 yes / 68% partial / 16% no across 25 records, so this also stops an outlier no from resting on a self-contradicting note. source |
| multi-location-corp-vs-franchisee-roles | unknown / F - knowledge-hub/owners-app-web-register enumerates the whole permission model - Register Users, Regist | resolve-to-no | I re-anchored this row: the analyst led with the merchant agreement's franchise-conflict warranty, which is boilerplate about the Restaurant's third-party obligations and bears none of the weight, so the cited url and quote have been moved to the instrument that does. On the brief's trap - a permission enumeration bounds what can be GATED, not what a product can DO - I checked whether the claim is actually about the permission model, and it is, verbatim: 'The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant'. So the enumeration is the correct instrument here, not a proxy, and the 'If Employee Permissions are not enabled, all users can access these tools' caveat in slice-register-order-entry is irrelevant: it says gating is optional, not that an ungated tenancy tier exists. The account model closes the other half - owners-app-getting-started shows one login reaching its own shops through a dropdown, which is the opposite shape from two asymmetric tenants. This is a no against 0 of 25 precedent and I held it deliberately: the peers scoring partial have corporate tiers to be partial about, and Slice's own product page says it 'is not enterprise software built for big chains'. Upheld, re-cited. source |
| multi-location-royalty-calculation | unknown / F - Read knowledge-hub/owners-app-web-financials in full (Online Orders, Register Orders, statements wit | resolve-to-no | I read Annex 5 in full and rejected the analyst's primary instrument. Annex 5 is 'Product Specific Terms and Descriptions' - the Services that carry extra contractual terms (Online Ordering, Listing, Listing Management, Phone Management, Phone Ordering, Integrated Delivery, Digital Marketing, Direct Mail), with the POS itself living in Annex 3 and Hardware in Annex 4. It is a list of separately-ordered Services, not an enumeration of what the POS does, so a royalty engine's absence from it proves nothing; the runbook's storefront rule bites, and the analyst's quote is a preamble sentence that closes nothing. The verdict nonetheless survives on a different and correct instrument, to which I have moved the citation: royalty calculation would have to surface as a report or a statement line, and owners-app-web-financials enumerates the entire reporting and statement schema down to individual fields. The 'various reports' sentence I have quoted is open in the abstract but is immediately followed by the closed five-item tab list, and each tab is then broken out column by column - so the surface is bounded even though that sentence is not. Upheld on rebuilt grounds; precedent is 32% no / 48% unknown, so this is not an outlier. source |
| multi-location-royalty-collection | unknown / F - The only automated debit mechanics Slice documents are its own: the merchant Online Restaurant Agree | resolve-to-no | I read the debit clause in full at Annex 3 section 9. Unlike the Annex 5 catalogue argument, which I rejected on the sibling row, this clause is the right instrument and it is closed by its own drafting: it is the grant of debit authority, it is exhaustive about whose fees may be swept ('all Fees for the Slice POS owed to Slice'), and the escalation ladder that follows it - late fee, wire, guaranty, charge another card - is likewise entirely Slice-to-Restaurant. A money movement made on a franchisor's behalf would need an authorisation, and the authorisation section grants none. I required a second, non-legal instrument before upholding, because a contract can be silent about a feature it does not need to license, and found it in the enumerated Statement Summary and Payouts schema, which carries no third-party remittance line. The claim's second limb (a franchisee-visible statement of what was charged) therefore fails positively rather than by silence. Upheld; precedent 40% no. source |
| multi-location-normalized-item-rollup | unknown / F - Item-level reporting is documented in knowledge-hub/owners-app-web-analytics ('Top Selling Menu Item | resolve-to-no | This is the furthest-from-precedent row in the batch (1 no in 25 records, 64% partial) so I held it to the highest bar. Two positive instruments, not silence. First, the selector's own wording is exclusive rather than merely singular - 'choose the location you want to view', with no all-locations or combined option documented anywhere in owners-app-getting-started, owners-app-web-getting-started or the Analytics article. Second, the report that would have to carry a rollup is enumerated column by column and has neither a location dimension nor a shared item key: Sales Mix is Category / Item / Discontinued Item / Quantity Sold / Gross Sales / Item Discounts / Average Price. The claim's distinguishing element - a shared corporate item ID surviving a local rename or reprice - additionally requires an item attribute, and the item attributes are enumerated on the New Item page with no such identifier. The precedent gap is explained rather than ignored: the partial-scoring peers are chain platforms with a corporate tier, and Slice's product page states it is not enterprise software for big chains. Upheld. source |
| hardware-handheld-lte | unknown / F - Searched all 45 Knowledge Hub articles, 30 release notes and 26 FAQs pulled from slice.com/wp-json/w | resolve-to-no | The value stands, the analyst's evidence does not, and I have replaced it. The Annex 3 telecommunications clause is a liability allocation - who buys the connection and who eats the outage - and reading 'any related services needed to access the Internet' as a product-capability exclusion is precisely the conflation the brief named; a vendor that shipped an LTE handheld could sign that same clause without contradiction. So the contract has been demoted to context and the citation moved to the hardware enumerations. On the brief's other objection, that a price list enumerates what is SOLD rather than what is SUPPORTED: that objection is decisive for software integrations and weak here, because Slice's POS is a closed rental appliance - the merchant is issued Slice's iPads and peripherals, so the catalogue of what Slice rents IS the catalogue of what exists. And the load-bearing citation is not the price list but the live product FAQ, which is Slice describing its own kit as 'the complete system' and then listing it - closure asserted by the vendor, not inferred by me. Graded C, not the analyst's B, because a product FAQ is a vendor feature page; the verdict survives at C since this is a no, not a differentiator yes, and the Wayback price list corroborates independently. source |
| reliability-cellular-backup | unknown / F - Annex 3 of the Pizzeria Agreement (slice.com/online-restaurant-agreement/) is the only place the shi | resolve-to-no | This was the weakest of the twelve as filed and I nearly overturned it. The brief is right that the telecommunications clause is a liability disclaimer, and it is weaker here than on the handheld row: a Slice router with an LTE failover SIM would be entirely consistent with Slice disclaiming the provision of Internet access and the data plan. The hardware list is also thinner than it looks, because 'Network Router' is unqualified and does not settle whether that router has a WAN backup. So the analyst's two instruments do not carry the cell. The instrument that does, which neither analyst used, is Slice's own documented outage behaviour: the vendor's dedicated FAQ for 'I'm having internet issues' prescribes a manual Wi-Fi reconnect, a router restart, and then a phone call to support to get back online. That is a positive, closed statement of what the product does when the WAN link fails, and it is incompatible with an automatic failover - it is the vendor answering the exact question the claim asks. Upheld at B on that KB text, with the hardware kit and the contract clause demoted to corroboration; url and quote rewritten accordingly. source |
| guest-loyalty-cdp-event-api | no / F - Slice publishes no API and no webhooks of any kind, so no CDP subscription surface exists." | upheld | KEPT at no/B. Carrier re-verified verbatim in the frozen corpus (present once in each of /knowledge-hub/register-third-party-orders/ and /knowledge-hub/online-ordering-third-party-orders/, both full-body, 3.4 KB). Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. I narrowed the note accordingly: the carrier no longer claims a global inbound-only pipeline, only that no subscribable documented stream is published. Re-tokenised corroboration only, never the carrier: webhook 0 and oauth 0 across all 490 documents. Falsified by any Slice document describing an outbound guest or order event feed or a CDP connector. source |
| reporting-public-api | no / F - No developer portal exists (developers.slicelife.com serves marketing content). No REST or GraphQL r | upheld | KEPT at no/C. This is one of the four OFFCORPUS rows; verified by hand against FINDINGS.md, which records developers.slicelife.com at HTTP 200 serving a 50 KB consumer homepage titled 'Order Pizza Delivery Online & Support Local Pizzerias' - the quote is that page's own title, not a corpus sentence, and is correctly attributed. Grade C is right: the page is vendor marketing. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. The claim asks whether a documented public API with self-service credentials is PUBLISHED, so 'our new API' existing internally does not touch it. Falsified by any reachable reference document or credential self-signup. source |
| reporting-webhooks | no / F - No webhook documentation exists." | upheld | KEPT at no/B. Carrier verified verbatim. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. The Checkmate/Square/Clover order-transmission finding is the strongest thing in the corpus against this cell and I weighed it explicitly: it is a Slice-operated connector to named POS products, not a customer-supplied endpoint, and no payload, signature or retry behaviour is published for it - the claim's own wording ('to a customer-supplied endpoint, with documented retry behavior and payload signature verification') is untouched by it. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. Corroboration only: webhook 0 across 490 documents, re-tokenised by me. Falsified by any subscriber-URL, retry-policy or signature documentation. source |
| reporting-api-not-upcharged | no / F - There is no API to include or upcharge." | upgrade-to-partial | KEPT at partial/B - RULED EXPLICITLY, since this is the batch's only value change and the row most likely to be re-litigated. The taxonomy is a conjunction ('API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee'). One conjunct is satisfied on affirmative vendor evidence: the export path is documented in the Knowledge Hub and the pricing table shows Owner's Portal Included on BOTH memberships (I re-read the table: Hardware, Point of Sale, Website, Online Ordering, Slice App, Phone Ordering, Google Listing Management, Loyalty Rewards, Automated Marketing, Flex Delivery, Supplies, Integrations, 24/7 Customer Service, Owner's Portal, Account Manager, Owner Community, Contract - read positively only, for what it says IS Included, never for what its silence implies). The other conjunct is not FAILED but VOID: there is no API to gate. Scoring it 'no' would publish the proposition that Slice gates data access behind a fee, which is affirmatively false on the vendor's own pricing table and would mislead every reader of this cell; 'partial' with the note stating which half is void is the only reading that says something true. The distinguishing rule, applied consistently in this batch: where the claim is ONLY about the unavailable object (extensibility-api-access-cost), the operator gets nothing at any price and 'no' is correct; where the claim conjoins a second object that IS available and IS satisfied, 'partial'. Falsified by a published fee for data export, or by discovery of a bundled API. source |
| extensibility-api-access-cost | no / F - There is no API to price." | upheld | KEPT at no/C. OFFCORPUS row verified by hand against FINDINGS.md. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. This claim is solely about the price of API access; with no operator-obtainable API published, an operator gets no programmatic access at any tier, so 'no' rather than 'partial' - the deliberate contrast with reporting-api-not-upcharged, which conjoins a satisfied raw-data half. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. Falsified by any published API together with a plan line showing it bundled or surcharged. source |
| extensibility-free-sandbox | no / F - No sandbox or test environment exists without an API." | upheld | KEPT at no/C, but I re-founded the reasoning the orchestrator flagged. The analyst's stated ground ('a sandbox needs a developer program') is an inference chained off another cell and I do not rely on it. The instrument reaches this claim DIRECTLY instead: the claim requires the sandbox be 'available to developers without owning a paid production account', i.e. publicly obtainable, and public obtainability is exactly what honest-host probing measures. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. api.slicelife.com refuses /docs and /openapi.json with the same 96-byte 403 it gives /, so nothing is obtainable there either. Corroboration only, re-tokenised by me: sandbox 0 across 490 documents, a floor. Falsified by any signup for a test, demo or seeded environment. source |
| extensibility-oauth-partner-apps | no / F - No OAuth, no scopes, no operator-granted app permissions documented." | upheld | KEPT at no/B. I re-read the clause in the frozen corpus: 'Users of Slice POS Connect shall be limited to Pizzeria's employees or contractors ... solely responsible for maintaining the confidentiality of all user logins and passwords'. Slice POS Connect is named 33 times in that agreement (the brief said 14; the higher count only strengthens it), and the adjoining Annex 3 restriction bars any attempt to 'build a product or service using similar ideas, features, functions or graphics of Slice POS Connect'. CONFIRMED PER THE ORCHESTRATOR'S INSTRUCTION: A used POS Connect correctly, as a human-credential product, and no row in this batch treats it as an API. Corroborated by /knowledge-hub/settings/ ('This is where you connect or manage your point of sale integrations with Slice ... This section is used only to manage those connections'), a fixed vendor-built panel, not a credential issuer. Corroboration only: oauth 0 across 490 documents. Falsified by any documented scope list, consent screen or revocation flow. source |
| extensibility-webhooks-push | no / F - No outbound event delivery documented." | upheld | KEPT at no/B with the note re-scoped. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. I take the Checkmate/Square/Clover order-transmission line seriously as the best available counter-evidence: Slice does move orders outward. But it moves them into named POS products through a connector Slice itself operates and documents only as a setup step, with no endpoint, payload or subscription an integrator can register - the claim asks for real-time webhooks the platform pushes 'rather than requiring polling', which requires a documented interface. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. Corroboration only, re-tokenised: webhook 0 across all 490 documents. Falsified by any documented event callback or subscriber URL. source |
| extensibility-webhook-reliability | no / F - No webhooks exist, so no signing, retry, or replay behavior." | upheld | KEPT at no/B. Inherits its carrier from extensibility-webhooks-push and I checked that the inheritance is legitimate rather than a chain of cells: the same verified vendor sentence plus Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. This claim is strictly narrower than webhooks-push (it requires HMAC signing AND documented retry AND a replayable log), so a bound on the existence of the channel bounds every property of it. Corroboration only: webhook 0 across 490 documents. Falsified by any Slice document specifying signing, backoff or replay. source |
| extensibility-published-rate-limits | no / F - No API, no rate limits." | upheld | CHANGED - CITATION STRUCK AND RE-FOUNDED, grade B -> C. The analyst carried this on 'Once your shop is connected, Slice automatically syncs your key business details to Google via our new API' from /knowledge-hub/google-business-profile/. I strike that citation: it is a sentence about an internal Slice-to-Google server-to-server sync (repeated verbatim at /knowledge-hub/owners-app-web-online-presence/, and the same article says the sync runs 'every day at 3 AM UTC'), it bounds nothing about quotas, and it is EVIDENCE THAT SLICE HAS AN API, not evidence of absence - using it as an absence carrier was the corpus-zero-wearing-a-citation defect the brief names. Re-founded on the only instrument that reaches the claim: Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. That bundle is not measured on Cloudflare-fronted slice.com and is exempt from the record's absence rule, and it bounds published API DOCUMENTATION, which is what 'published rate limits' is a property of. Grade drops to C because the carrier is now a vendor marketing page rather than a Knowledge Hub sentence. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. Falsified by any Slice API reference stating a per-minute or per-day quota or 429 behaviour. source |
| extensibility-menu-write-api | no / F - Menu is editable only through the Owner's App UI; no API." | upheld | KEPT at no/B. Carrier verified verbatim and it is a genuine reassignment sentence, not a scope sentence, paired in the same article with the explicit bar 'Do not edit third-party menus directly - this will break the integration and cause service interruptions'. Instrument that could have said yes and did not: /knowledge-hub/owners-app-web-menu/ (read, full body), an exhaustive item/category/modifier/price walkthrough describing only UI controls, with no import, feed or endpoint affordance. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. AUDIT CORRECTION carried on every API/webhook cell in this batch: the analysts' presence control "api 23 hits" is a substring artefact (Apizza, shaping, capitalize). Re-tokenised, \bAPIs?\b occurs 3 times in running prose across 3 documents (4 counting a URL slug): twice as the Uber Direct API in the merchant agreement, twice as "syncs your key business details to Google via our new API". Slice therefore HAS an API and says so in operator documentation; the defensible claim is that Slice publishes no API DOCUMENTATION, not that it has no API. Second correction: /knowledge-hub/online-ordering-getting-started/ documents "order transmission methods (Square, Clover, Checkmate POS, Fax, or Phone TM)", so Slice does push its own orders outward to third-party systems - the "does not have a way to communicate back" sentence is scoped to marketplace providers and is NOT a global inbound-only bound. Neither correction produces a documented, operator-callable interface. Falsified by a Slice menu endpoint or an operator-drivable menu import. source |
| extensibility-data-symmetry | no / F - No API exists in either direction." | upheld | KEPT at no/B, and I checked the taxonomy wording as instructed rather than the analyst's preference. The claim reads: 'Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API.' 'Via the same API' is explicit in the taxonomy text, so a UI-driven CSV round-trip fails on the wording, not on taste - and it fails a second, independent way, since with no API published there is no read side for a write side to be symmetric with. Carrier verified verbatim in a 6.9 KB full-body article. Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. Falsified by a Slice API that both reads and writes any core object. source |
| extensibility-headless-embedded | no / F - No headless or embedded transaction-engine mode; no API to drive it." | upheld | KEPT at no/B, WITH A DISCLOSURE THE ANALYST DID NOT MAKE. Carrier verified verbatim. New finding I must record against my own verdict: the same article twice refers the operator to a 'Website Integrations Page' for 'additional support and technical documentation' - a vendor-named technical document that is NOT among the 490 corpus documents and is unreachable, since slice.com HTML is a blanket Cloudflare 403. That is a concrete demonstration that the registry is a floor, and it lands on this cell's exact topic. I still keep 'no' because the claim requires the third-party UI to drive the transaction engine 'via API', and the API bound is independent of that unread page: Honest-host bundle (exempt from the Cloudflare rule because it is not measured on slice.com): developers.slicelife.com returns HTTP 200 serving the consumer pizza-ordering homepage, and Wayback CDX holds ZERO captures of that subdomain ever while the positive controls api.slicelife.com (2025-03-23) and partner.slicelife.com (2018-11-02) show the archive does index this domain's subdomains; api.slicelife.com answers a uniform 96-byte 403 to /, /v1, /docs and /openapi.json; the vendor-controlled GitHub org slicelife enumerates exactly 10 public repos, 8 forks, with no SDK or API client. A reader should treat this as the weakest surviving 'no' in the batch. Falsified by the Website Integrations Page turning out to document an order-injection or transaction endpoint. source |
| multi-location-enterprise-api | no / F - No API of any kind is published, so no cross-location authenticated data call exists." | upheld | KEPT at no/B, wording checked as instructed. The taxonomy requires an interface that 'returns transaction-level data across all locations in one authenticated call, without per-location credentials', with '(or data warehouse/BI export)' as the alternative route. I tested the alternative directly against the export surface: /knowledge-hub/owners-app-web-financials/ (24.6 KB, read in full) enumerates the Reports page tab by tab - Order Activity, Orders, Tax, Sales Mix, Sales Summary - each a manual Create New Report then download, all scoped to the selected shop. So the CSV route fails on 'across all locations in one call', which is the taxonomy's own wording and not a preference. IMPORTANT: this row does NOT rest on single-shop-ness - the analyst correctly used the multi-shop location selector as an affirmative bound, and it is the record's PROSE, not this cell, that carries the false single-shop premise. Falsified by an all-shops report, a chain console, or any warehouse feed. source |
| order-capture-drive-thru | no / F - No drive-thru functionality in the product catalog or Register docs." | upheld | KEPT at no, CARRIER REPLACED. The analyst cited the hero line 'handling phone, online, and counter orders all in one place', which is marketing prose and reads as a floor. I substituted the FAQ sentence, which is the strongest exhaustiveness assertion the vendor makes anywhere: Slice itself equates the phrase 'all order types' with a three-item list that excludes a lane, and the equation is the vendor's own, not mine. Two further repetitions of the triple ('Counter, phone, and online orders appear in one system and follow the same steps'; the 'One system for every order' heading) corroborate it. I HONOUR C'S ABSENCE CONTROL REPORTING AGAINST ITSELF and re-ran it myself: drive-thru/drive thru/drivethru 0, curbside 0, headset 0, lane 2 (both a 'prep lane' in one kitchen-layout blog post) - this corpus barely uses car or lane vocabulary in any circumstance, so the zero is largely a vocabulary artefact and is not corroboration I lean on. The verdict rests on the vendor's enumeration alone, at grade C because it is a marketing page. Falsified by any vendor sentence naming a lane, window or car-side order mode. source |
| order-capture-drive-thru-timers | no / F - No drive-thru product, therefore no segment timers." | upheld | KEPT at no/C, carrier replaced to match order-capture-drive-thru, and the derivation defended rather than assumed. The orchestrator is right that a derived verdict is not a cited verdict, so I checked whether the step is an entailment or a leap: this claim is explicitly drive-thru-scoped ('drive-thru speed-of-service timers by segment (order, total, window)'), so a vendor bound excluding a lane bounds the claim by its own terms - it is a second application of the same vendor sentence, not a chain through another cell's verdict. Independent instrument that could have said yes and did not: /knowledge-hub/owners-app-web-financials/ (24.6 KB, full body) enumerates the entire Reports surface - Order Activity, Orders, Tax, Sales Mix, Sales Summary - column by column, with no elapsed-time or segment-time field; /knowledge-hub/register-cash-management-and-reporting/ adds none. I re-ran the analyst's own finding: 'speed of service' occurs exactly once in 490 documents, in /knowledge-hub/owners-app-web-register/ describing menu layout, and the token 'timer(s)' occurs 3 times, all of them 'first-timers' in blog copy. Falsified by any Slice report exposing per-order segment times. source |
| digital-kiosk | no / F - No kiosk in the product catalog or hardware bundle." | upheld | KEPT at no/C. This is the good half of the brief's item 3: the carrier is a 'coming soon' bound with a date, not a 'kiosk returns zero' argument, and I verified the string verbatim in /family-membership/ (12.5 KB, full body - not one of the 18 zero-body pages). A bounded no with a known expiry. Corroboration only: kiosk occurs exactly twice in 490 documents and the other is third-party-voice trend prediction in a blog post, worth nothing as a vendor claim. Falsified the moment the benefit table drops '(coming soon)' or a kiosk article appears. source |
| digital-drivethru-ai | no / F - No drive-thru product at all." | upheld | KEPT at no/C. Two affirmative carriers on one vendor page, both verified: the phone-order function is assigned to a staffed team, corroborated in /knowledge-hub/slice-phone/ ('Agents use your Register menu, quote your ETAs, and follow your upsell preferences') and by the Spanish phone support article ('bilingual phone agents who can greet and take orders'), so the vendor's own description of its voice channel is human throughout; and the order-mode equation excludes a lane. Corroboration only, never the carrier: 'voice order', 'AI voice', 'conversational' and 'speech' return zero across 490 documents, but the corpus is a floor. Falsified by any Slice announcement of automated voice order-taking. source |
| hardware-kiosk | no / F - No kiosk in the product catalog or hardware bundle." | upheld | KEPT at no/C. Carrier is the '(coming soon)' bound, verified verbatim, and it is the whole of the verdict. I deliberately do NOT lean on the pricing hardware list (Register and Stand, Payment Terminal, Cash Drawer, Receipt Printer, Kitchen Printer, Network Kit): I re-read slice.com/pricing/ and that list carries the softener 'Additional configurations available' immediately beneath it, which makes it a floor and not a ceiling - the analyst said so too and was right to. Falsified by a kiosk line item appearing in the pricing hardware list or a kiosk article in the Knowledge Hub. source |
| hardware-drive-thru | no / F - No drive-thru hardware, menu boards, or headset integration." | downgrade-to-unknown | CHANGED: cited no/C -> unknown/F. The orchestrator's suspicion is correct and this was the worst row in the batch. The carrier was a scope sentence, which the brief forbids by name, and it does not say Slice has no menu boards or headsets - it says where Slice puts the hardware it installs. I then attempted the re-founding the orchestrator offered, on the pricing hardware table, and it fails on the vendor's own wording: 'Additional configurations available' is printed inside the table, so the list is introduced as incomplete, and the product page's alternative list is introduced by 'What hardware is included with Slice Register?', an includes-list and therefore a floor. The Knowledge Hub Register table of contents (fifteen topics, no lane or outdoor-display topic) is a documentation index, not a hardware census. With no affirmative bound and a vocabulary-artefact zero, unknown at F is the only honest outcome. The resulting asymmetry with hardware-kiosk is deliberate and correct: the vendor supplied a '(coming soon)' bound for kiosks and supplied nothing at all for drive-thru hardware. |
| hardware-handheld-battery-swap | no / F - No handheld device exists, so no battery rating is published." | upheld | KEPT at no/B. Carrier verified verbatim; the affirmative move is the vendor's own identification of the device class ('an additional iPad', with 'What's included in the Kit' listing iPad, VAULT Simplicity Stand (countertop, under-counter, or wall-mounted), and power cables and accessories - I corrected the analyst's note, which had compressed that bullet list into a single misquoted string). The taxonomy offers a second, independent route to yes - 'or the vendor publishes a rated battery life for a full shift' - and I tested it at the instrument where it would live: the KB FAQ 'What should I do if my tablet is not charging?', which could have stated a rated life and instead answers only 'check the cable connection at both the iPad and power adapter' and 'try turning it off and charging it overnight'. This is the strong control the brief distinguishes from the drive-thru one, and my own re-tokenisation confirms it: battery 0, handheld 0, mAh 0, hot-swap 0 across 490 documents, while charge/charging matches 153 times in 41 documents - the vocabulary is demonstrably not filtered, so this zero is not an artefact. Falsified by a Slice handheld SKU or any published battery-life figure. source |
| menu-pricing-franchise-hierarchy | no / F - Single-shop product. No corporate template, no location groups, no field-level governance anywhere i | upheld | KEPT at no/B, and this is the row that vindicates itself against the record's own prose. Carrier verified verbatim in a 6.4 KB full-body article: it is an affirmative vendor description of Slice's multi-location model as a per-shop view selector, which is exactly the instrument this claim needs, and it does NOT rest on single-shop-ness - the analyst got this right where the narrative does not. Instrument that could have said yes: /knowledge-hub/owners-app-web-menu/, read in full, which documents bulk edits within one menu and no copy-to-location, template or per-attribute lock. Corroboration only: 'location group' and 'multiple locations' return 0 corpus-wide, and franchise's 36 occurrences across 9 documents are blog comparisons, a warranty clause and a referral rule excluding shops 'over 10 franchise locations' - none of them product. Falsified by a documented corporate template or field-level override. source |
| kitchen-waste-logging | no / F - No inventory module, so no waste logging or depletion." | upheld | KEPT at no/B. Carrier verified verbatim and it is a definitional bound on what Slice's stock control IS, which is the right shape for this claim - the claim requires that the entry 'depletes inventory', and a boolean availability flag has nothing to deplete. Reinforced by the Register Settings article ('Tap Stock Availability to view your inventory list'), so even where the vendor uses the word 'inventory' the surface holds no counts, and by /family-membership/'s 'Discounted kitchen displays & kiosks (coming soon)', which removes the KDS the claim requires the logging to happen at. Corroboration only: 'reason code', 'deplete' and 'depletion' return 0 corpus-wide; waste appears 30 times but only 3 times in the 45 Knowledge Hub articles. Falsified by a documented on-hand count, a waste reason list, or a KDS waste button. source |
| multi-location-central-labor-policy | no / F - No labor module exists to configure or enforce." | upheld | KEPT at no/B. Carrier verified verbatim; a reassignment sentence naming a third party is the strongest instrument class available in this record and it is used correctly here. The mechanical detail matters and is documented: the Time Clock is a separate iOS app reached by leaving the Register app, so the Register cannot gate a shift on a break or overtime rule even in principle - which is precisely what the claim requires ('enforced at the terminal, not just reported after the fact'). Corroboration only: labor's 56 occurrences are all marketing and blog copy with zero in the 45 Knowledge Hub articles, and 'meal break', 'predictive scheduling' and 'fair workweek' return 0. Falsified by a Slice-side break or overtime rule enforced by the Register. source |
| extensibility-bi-data-warehouse | no / F - CSV download only; no scheduled export to a customer-controlled destination." | upheld | KEPT at no/B WITH A MATERIAL NOTE CORRECTION. The analyst's note asserted 'nothing is delivered on a schedule', and that is FALSE: /knowledge-hub/owners-app-web-financials/ documents 'You can get automated daily sales summaries by calling your Account Manager at (888) 974-9928 to set up daily Sales Summary Report (SSR) emails ... can be sent to multiple recipients, including managers and accountants.' That is a scheduled delivery, and a reader who found it would have discredited the cell as written. The verdict survives on the taxonomy's two remaining requirements, which the SSR email fails on both counts: it is a summary, not raw transaction-level data, and email to a recipient list is not 'a customer-controlled destination (S3/SFTP/warehouse/Snowflake share)'. Carrier verified verbatim in the legal page, backed by the affirmative product sentences in the Financials and Customers articles. Falsified by a destination configuration screen or a warehouse share. source |
| extensibility-custom-fields-scripting | no / F - No custom fields or hosted scripting surface documented." | upheld | KEPT at no/B. Carrier verified verbatim. The analyst's handling of the sentence is exactly right and I checked it specifically: the 'Available integrations include...' clause is a FLOOR on which connectors exist and is not used as a ceiling; the bounding half is 'This section is used only to manage those connections', which bounds what the surface DOES rather than what it lists. Instrument that could have said yes: /knowledge-hub/owners-app-web-menu/, read in full, which has no custom-attribute editor; /knowledge-hub/owners-app-connect/ confirms the escalation path is chat and a feedback form. Corroboration only: 'custom field', 'sdk', 'plugin' and 'zapier' return 0 corpus-wide and 'developer' returns 2 occurrences in 2 documents, neither in the Knowledge Hub. Falsified by any scripting or rules surface. source |
| commercial-source-available-selfhost | no / F - Fully proprietary SaaS. No source repository, no license, no self-hosting option, and not even a pub | upheld | KEPT at no/B. OFFCORPUS row verified by hand against FINDINGS.md, which records the org as created 2017-10-17 with exactly 10 public repos, 8 forks, and names both originals - the quoted repo name is one of them. This is the strongest instrument in the whole batch and the one least exposed to the record's absence rule: api.github.com ENUMERATES an org's public repositories rather than refusing, so this is a census and not an empty answer, and it is measured on a host that answers honestly rather than on Cloudflare-fronted slice.com. Grade B is correct for a vendor-controlled registry. Falsified by any POS, register or SDK repository under the org, or a source-available licence page. source |
| commercial-wcag-kiosk-accessibility | no / F - No kiosk product exists, and no VPAT/ACR or WCAG conformance claim is published for the consumer web | upheld | KEPT at no/C. Carrier verified verbatim; it is an affirmative sentence bounding the claim Slice actually makes, on a marketing page, so grade C is correct and not inflated. Second bound is /family-membership/'s 'Discounted kitchen displays & kiosks (coming soon)', which removes the kiosk surface the claim requires a conformance report for. Corroboration only: wcag returns 0 across all 490 documents while accessib returns 19 occurrences in 14 documents, so the general vocabulary is present and only the conformance term is missing - a non-artefact zero, though still a floor and still not the carrier. Note /accessibility/ answers a Cloudflare 403 like every slice.com HTML path, so its status establishes nothing either way. Falsified by a VPAT or ACR, or a named WCAG 2.1 AA claim. source |
| reporting-history-retention | unknown, grade F | upheld | Proposed partial from Slice's live WP REST / Wayback slicelife.partners, sliceregister.com, slice.com and Google Sites help surface (268th session); rejected on verification: Re-fetched Wayback 20241107012749id_ slice.com/help-center (305 KB, real Help Center page, not an error page). The quote is verbatim; the phone number sits inside a tel: link. It documents a 30-day self-serve window, with older orders only through a Partner Success Manager. That is a shortfall against the claim's substance (at least 24 months queryable in the UI, with no support-assisted archive retrieval), not a limited form of it, so partial is self-refuting. Retired pre-2025 Owner's Portal material cannot make the current product `no`, so the cell stays unknown; the 30-day finding should go into the rationale as evidence of a historical shortfall. source |
| digital-sms-ordering | unknown, grade F | upheld | Proposed partial from Slice's live WP REST / Wayback slicelife.partners, sliceregister.com, slice.com and Google Sites help surface (268th session); rejected on verification: Re-fetched Wayback 20230615051042id_ slicelife.partners/slice-assist-line (473 KB, real Squarespace page; the quote is verbatim in the FAQ accordion). It is a 2023 launch landing page ('VIP LAUNCH PRICING $0 PER MONTH', grade D at best). The flow starts with a voice call, so it is not conversational SMS ordering. The page never says the website order lands in the POS: it names no tablet, Register or POS injection, only that Slice 'can report ... how many callers became online orders'. The current Slice Phone article limits texts to order details and pay-by-text. Also, slicelife.partners/robots.txt today serves 'User-agent: *' / 'Disallow: /' (the record measured it WALLED 401 on 2026-09-02), so citing this host's content needs a policy decision first. source |
| guest-loyalty-ai-offer-recommendation | unknown, grade F | upheld | Proposed partial from Slice's live WP REST / Wayback slicelife.partners, sliceregister.com, slice.com and Google Sites help surface (268th session); rejected on verification: Confirmed via wp-json/wp/v2/pages?slug=why-slice (modified 2026-09-11): the quote is verbatim under 'LOYALTY MARKETING / Reorders without the work.', followed directly by 'Fully managed by expert team' and 'Personalized to your restaurant'. It is a one-sentence brand slogan for a done-for-you service. Every corroborating hit in the 500-document corpus is also marketing copy ('AI-Automated MARKETING' page 18078, 'Automated marketing at just the right times' page 16930). No Knowledge Hub article, release note or setting documents AI send-time optimisation, offer content or audience selection. The claim explicitly requires verifying a shipped product feature, and a slogan does not meet that on a differentiator claim. source |
| menu-pricing-dual-pricing | unknown, grade F | resolve-to-partial | Re-fetched the cited chunk live (HTTP 200, 6,410,389 chars). Every quote was verbatim at its stated character offset: @1485081 description, @1486341 mutual-exclusion message (the bytes escape it as can\'t), @4001832 the shop-discount-rates POST, @4003451 the min 1e-4 / max .04 check, @1373552 the column label (the real ICU label is 'Cash discount ({rate, number, ::percent .##})'), @5771330 the per-item and per-variant cashDiscountPrice cell, @1297861 and @3637254 the order-detail lines. One caveat is corrected: the proposal said the item cash price is 'derived rather than stored'. The client actually reads it from the server as itemVariants[].itemCashDiscountPrice (@4977369, schema @4975048), so how it is stored cannot be seen from here. What does hold is that no UI edits it per item. I found 30 cashDiscount/nonCash i18n keys; none is a receipt, online or kiosk key. Partial rather than yes because the claim needs item-level pricing, parity across channels and a printed receipt line, and only the shop-wide card-base rule is shown. Grade A stands, since this is the shipped client code. The note does not contradict the other cells. payments-dual-pricing (partial/B) says the help articles document no setting, and this note limits itself to the portal. The surcharge cells say surcharge setup is not self-service, which matches 'contact support to disable card surcharge'. Toast's peer cell (partial/B, shop-level discount at tender) sets the same bar. source |
| kitchen-pizza-fractional-display | unknown, grade F | resolve-to-partial | Re-fetched live 2026-09-15 with a Chrome UA: HTTP 200, 6,465,345 B, sha256 86fa846f96754b40de50f1ddd16cad7336f3df63cef9aed5ddac8daf89e4f0a9 (identical to the proposal). The quotes are verbatim at the UTF-8 string offsets: tabs.kitchenTicket @1455263, kitchenForm.displayWholeModifier @1458114, halfPizzaTopping L/R and wholePizzaTopping W lists @3897174 (ef4) and @3903293 (ef6), LEFT_HALF/RIGHT_HALF @3634450, "on half" @1297588. Controls: QUARTER has 0 hits in this chunk. The only kds/KDS hits are inside base64 image data. The value holds at partial: letter-labelled half lists meet part of "unambiguous", and halves-only is the same shortfall as revel-systems (partial/B). HungerRush got yes for a drawn half/half column layout, and this has no graphic. The grade drops from A to B. The code is source, but what it proves is a hardcoded preview inside the Portal’s template editor. It is Slice’s own picture of the printed ticket, closer to product documentation, and not the Register code that renders tickets. The step from preview to real printout is supported only by the W-marker setting sitting in the same form. The "on half" suffix @3634450 comes from the Portal’s order-detail modal, not from a kitchen surface, so it supports capture, not display. source |
| menu-pricing-half-and-half-rule | unknown, grade F | resolve-to-partial | Re-fetched the chunk live: HTTP 200, 6,410,389 bytes. All quotes are verbatim at the cited offsets (1404080, 1404161, 1398464, 1402121, 1402741, 5612304). The claim's third option is 'charge each topping at a fraction of full price', so a per-topping half price counts toward this claim and belongs to no separate claim. Partial is not self-refuting. It also matches the peers with one lever: cake-pos (fixed half price, partial/B), toast (Price Multiplier, partial/B), microworks-prism (hand-entered 1st Half and 2nd Half rows, partial/B). Vendors with no half concept at all (clover, square) got no. Yes would need two or more rules to choose from, and the full dictionary census shows no rule selector. I also tried a different value. The bulk 'Switch to percentage amount' and 'Increase or decrease price' controls only adjust existing prices and do not set a half-pricing rule, so no value above partial holds. Kept grade A: the source is the vendor's own served product code. The prior verification rows kept this unknown for lack of any pricing evidence, and the portal chunk supplies that evidence. Removed the note's claim that there is no two-specialty-pizza pricing mode: it rests only on dictionary silence. source |
| reporting-history-retention | unknown, grade F | resolve-to-partial | Re-fetched the cited chunk live (200). Every quote is verbatim, but three offsets had drifted and are corrected (1466646->1466744, 1465278->1465322, 3935581->3935585). Challenge: a hard-coded minValue on a date picker only bounds the UI, and neither retention nor completeness is published. The merchant-facing copy 'order data is available from {date}' still makes the history an explicit, queryable UI statement going back more than 24 months. That meets the claim's core conjunct in limited form, so partial is not self-refuting. Yes is barred: there is no retention commitment, no fee or truncation statement, and a history of a 30-day window. No is barred because the UI positively exposes history of 24 months or more. A was kept because the source is the vendor's own served product code, as with the erpnext/nexopos peers. Amended: the proposal presented the 31-day cap as the only per-report limit, and two other report forms allow 365 days. source |
| digital-sms-ordering | unknown, grade F | resolve-to-partial | Claim text expressly admits text-a-link, and peers earned partial for exactly that (flipdish partial off an SMS prompt to order online; square, toast). So order-via-SMS is not required, but conversational ordering is absent, so partial is the ceiling. Quotes verified verbatim live. The proposal's offsets were wrong by 5-86 bytes and are corrected. Added the marketplace-attribution fact. Kept grade A as served first-party code, but the note states the SMS is inferred. source |
| guest-loyalty-wallet-pass | unknown, grade F | resolve-to-no | The researcher's evidence holds up when I re-run it: every wallet-token control over all 12 dumps is either zero or Google's own play-services-wallet/Google Pay code, never a Slice class, and the web dictionaries give only a payment-picker placeholder. The live rewards page still names the in-app Rewards tab as the only place the balance lives. Precedent allows a `no` here: chowly's no/C rests on the vendor naming its app as the loyalty carrier, clover and chownow rest on documented lists of where the balance can be seen, and past no verdicts have rested on a whole-client census (urbanpiper Prime). This case has a vendor-named carrier plus a binary census with no Slice-owned pass code, so B is fair; A would overstate an absence read from a mirrored build with iOS unseen. AMENDED because the proposed url (play.google.com details page) is not a key in notes.json. It is re-homed to the APKCombo storefront 7.13.0 key, which is the artefact the census actually read. The note now records the in-app 'loyaltycard' false positive and the iOS and email-pass limits. source |
Sources
Every URL this record cites. 100 in total.
- https://slice.com/pricing
- https://slice.com/knowledge-hub/
- https://slice.com/knowledge-hub/homebase-partnership/
- https://slice.com/knowledge-hub/homebase/
- https://slice.com/knowledge-hub/owners-app-web-time-management/
- https://slice.com/knowledge-hub/slice-register-order-entry/
- https://slice.com/knowledge-hub/register-order-management/
- https://slice.com/knowledge-hub/register-third-party-orders/
- https://slice.com/knowledge-hub/register-delivery-management/
- https://slice.com/knowledge-hub/register-cash-management-and-reporting/
- https://slice.com/knowledge-hub/register-customer-management/
- https://slice.com/knowledge-hub/register-employee-permissions/
- https://slice.com/knowledge-hub/register-settings/
- https://slice.com/knowledge-hub/register-slice-driver-app/
- https://slice.com/knowledge-hub/owners-app-web-menu/
- https://slice.com/knowledge-hub/owners-app-web-financials/
- https://slice.com/knowledge-hub/owners-app-web-marketing/
- https://slice.com/products/point-of-sale-for-pizza-shops/
- https://slice.com/in-store-ordering
- https://slice.com/why-slice
- https://slicelife.com/pages/terms-of-service
- not refetchable
- https://slicelife.partners/in-store-ordering
- not refetchable
- https://en.wikipedia.org/wiki/Slice_(app)
- https://hospitalitytech.com/slice-launches-pos-system-exclusively-built-local-pizzerias
- https://www.slicelife.press/press-releases
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://slice.com/support/24-7-365-customer-support/
- https://slice.com/products/slice-app/
- https://slice.com/products/online-pizza-ordering-system/
- https://slice.com/products/marketing-for-pizza-shops/
- https://slice.com/products/backup-delivery-drivers/
- https://slice.com/products/google-business-profile/
- https://slice.com/products/phone-ordering/
- https://slice.com/knowledge-hub/register-caller-id/
- https://slice.com/knowledge-hub/register-shop-status/
- https://slice.com/knowledge-hub/order-manager-kit/
- https://slice.com/knowledge-hub/slice-register-getting-started/
- https://privacy.slicelife.com
- not refetchable
- https://slice.com/knowledge-hub/owners-app-web-analytics/
- https://slice.com/knowledge-hub/owners-app-web-website-tools/
- https://slice.com/release-notes-2/track-slice-delivery-drivers-in-real-time/
- https://developers.slicelife.com
- https://sites.google.com/slicelife.com/owners-portal-help/home/statement-definitions/slice-payments
- https://slice.com/pricing/
- not refetchable
- https://sites.google.com/slicelife.com/registerhelp/home
- https://slice.com/terms-of-service/
- https://slice.com/help-center
- https://slice.com/knowledge-hub/owners-app-web-register/
- https://slice.com/knowledge-hub/settings/
- https://slice.com/knowledge-hub/owners-app-report/
- https://slice.com/?echo_kb_faq=what-is-my-delivery-zone-and-how-do-i-edit-it
- https://slice.com/?echo_kb_faq=when-and-how-will-i-receive-my-payout
- https://slice.com/?echo_kb_faq=how-secure-are-payments
- https://slice.com/?echo_kb_faq=can-i-connect-a-printer-to-my-tablet
- https://slice.com/?echo_kb_faq=how-do-i-add-or-update-my-bank-account
- https://slice.com/release-notes-2/let-phone-customers-pay-by-text/
- https://slice.com/release-notes-2/manage-your-full-menu-in-one-place/
- https://slice.com/pos
- https://slice.com/wp-json/wp/v2/epkb_post_type_1
- https://slice.com/knowledge-hub/slice-phone/
- https://slice.com/wp-json/wp/v2/epkb_post_type_1?per_page=100
- https://slice.com/wp-json/wp/v2/epkb_post_type_2?per_page=100
- https://slice.com/wp-json/wp/v2/echo_kb_faq?per_page=100
- https://slice.com/knowledge-hub/owners-app-web-customers/
- https://slice.com/knowledge-hub/how-secure-are-payments/
- https://slice.com/knowledge-hub/online-ordering-slice-app/
- https://slice.com/knowledge-hub/owners-app-getting-started/
- https://slice.com/online-restaurant-agreement/
- https://slice.com/knowledge-hub/online-ordering-getting-started/
- https://slice.com/release-notes-2/extra-protection-for-your-owners-portal-login/
- https://slice.com/wp-json/wp/v2/pages?per_page=100
- https://slice.statuspage.io
- https://slice.com/pricing-test/
- https://slice.com/family-membership/
- https://slice.com/products/pizzeria-websites/
- https://slice.com/support/full-service-setup-and-training/
- https://slice.com/knowledge-hub/set-delivery-and-pickup-etas-in-owners-portal/
- https://slice.com/robots.txt
- https://slice.com/wp-json/wp/v2/types
- https://slice.com/wp-json/wp/v2/posts?per_page=100
- https://slice.com/wp-json/wp/v2/case-study?per_page=100
- https://slice.com/atlas-fabricated-9a7f
- https://developers.slicelife.com/
- https://slicelife.com/sitemap.xml
- https://slicelife.com/pages/privacy
- https://slicelife.com/pages/slice-rewards
- https://slicelife.com/pages/copyright-policy
- https://web.archive.org/cdx/search/cdx?url=slice.com&matchType=domain
- https://web.archive.org/web/20260121id_/https://slice.com/hardware-pricing/
- https://web.archive.org/web/20260118id_/https://slice.com/knowledge-hub/owners-app-web-hours/
- https://web.archive.org/web/20260128id_/https://slice.com/knowledge-hub/online-ordering-custom-website/
- https://web.archive.org/web/20260121id_/https://slice.com/knowledge-hub/slice-phone-spanish-phone-ordering/
- https://web.archive.org/web/20241107id_/https://slice.com/help-center/
- https://owners.slicelife.com/_next/static/chunks/2uwqhg6bmkr3v.js
- https://slicelife.com/sf2/public/app-da4cd548-bundle.js
- https://apkcombo.com/slice-local-pizza-delivery/com.slicelife.storefront/download/phone-7.13.0-apk