Thrive POS

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

Table Service feature described as 'visual alerts and drag-and-drop floor layout editor' for dining room management. Multiple saved layouts and server-section assignment not documented. https://www.thrivepos.com/en-us/features · 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

Subtotal Tickets documents per-person tagging AT ENTRY: enable 'Enable Subtotals On Tickets' in Configuration > General > Store Setup, then 'After ordering items for the first person, click on the Subtotal button... Type the customer's name in the Subtotal Name box and click Add.' Later items 'default to a Shared group' and can be moved to an existing subtotal, and at tender 'you can select one or multiple subtotals to pay for' with the subtotal name recorded under the tender type - no re-keying. Shortfall: the grouping key is a free-text name, not a seat number; no seat field exists anywhere in the Table order type setup, which prompts only for customer name, tent number or table number; and the article states 'You must pay for all subtotals at once. You can not partially tender an order and then pay later or cancel. Those partial tenders will be voided.' The only alternative, Split Tickets, works by dragging items onto additional tickets after the fact. https://thrivepos.uservoice.com/knowledgebase/articles/898755-subtotal-tickets · 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

CLAIM: items assignable to courses and held, with a fire-next-course action from a handheld or terminal releasing only that course. VERDICT: no. EVIDENCE: `coursing`, `course fire`, `fire course`, `hold and fire`, `send later` and `seat number` all return ZERO files across the 372-article census. Every `course` hit is 'of course'; every `fire` hit is a GTM tag, a fire-extinguisher table-design graphic or 'putting out fires'; every `hold` hit is caller-ID hold time, a press-and-hold gesture or a cash safe. The current table-service articles ('TV - ...') describe tables, tents and subtotal-driven printing and never a course. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

Split Tickets is documented in detail: recall the order, drag items onto additional tickets, 'Add Ticket' for more splits, with documented discount-splitting behaviour and the caveat that a coupon requiring a paired item is removed if the items land on different tickets. Ticket Transfer to another clocked-in staff member is separately documented. https://thrivepos.uservoice.com/knowledgebase/articles/491597-split-tickets · retrieved 2026-08-01 adversarially verified

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

Bar Tabs documents two configurable pre-auth modes: '$1 Pre-auth and Void' (authorizes $1 to validate the card and tokenize it, then a full authorization runs at close) and a 'Pre-auth Amount $25 or Higher' mode where the operator sets a starting pre-auth 'on the high side of your average ticket size'; at close the pre-authorization is 'modified to post-auth for the actual amount, whether it is higher or lower' (with a noted processor downgrade risk when the final amount exceeds the original auth). Shortfall: no auto-close of stale/abandoned tabs at end of day is documented anywhere in the article — tab closure is described as a manual staff action only. https://thrivepos.uservoice.com/knowledgebase/articles/924735-bar-tabs · retrieved 2026-08-04

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

Transferring a Ticket Via Orders Screen documents the mechanism: from Server Status, select the ticket, choose Transfer, 'Select the server you wish to transfer the ticket to from the dropdown, and click the Transfer button' — the ticket disappears from the original server's queue and appears 'under the new server's name'; it is permission-gated ('You will need permissions to do this function... in Manager > Config > Security') and settled tickets cannot be transferred. Shortfall: no article documents a queryable audit log or report naming both the transferring and receiving employee with a timestamp — the transfer is reflected only in current ticket ownership, not in a retrievable log. https://thrivepos.uservoice.com/knowledgebase/articles/711480 · retrieved 2026-08-04

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 Requirements states 'Workstations can be Android or iPad tablets, or PC-based Linux or Windows', and the recommended catalogue is a 15.6-inch Android, a 14-inch Android, a 10.2-inch iPad and an all-in-one PC. The Thrive client is a native tablet app, not a mirrored desktop - release notes track 'Added support for Android tablet cash drawer', 'Added support for Android Tablet: HID credit card reader', 'Resolved issues with the iOS 11 iPad app menu scroll function' and 'Resolved inability to access support portal from iPad app' - and a tablet station rings and prints to the kitchen like any other station. Shortfall: no handheld form factor is offered - every device in the catalogue is a counter workstation with a foldable base or wall mount, and the T2 Android tablet 'comes complete with a built-in printer in the base' - and tableside card payment is impossible with the documented payment hardware, because EMV devices are ethernet units: 'Plug them into a network cable that is attached to your router... Navigate to Manager Home > Configuration > General > Station Device. Select the 1st station that will have an EMV device. Enter the EMV terminal ID.' The only first-party mobile app that leaves the building is DR!VE, which is driver/delivery only. https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements · retrieved 2026-08-08

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

Order entry is local and the vendor documents outage behaviour, but only in a legacy release note. Architecture: Hardware Requirements (kb 423702) - 'The server is the workhorse of the system which powers your operation and stores data', 'All systems require at least one server which can be used as a workstation', 'All systems should have a backup server/workstations to use if primary fails'; stations, Ethernet kitchen printers and cash drawers sit on the in-store LAN, so an internet outage (as distinct from a server or LAN failure) does not stop ringing, kitchen printing or cash tender. Version 7.7.x, 'Improved Tools for Internet Connectivity Problems' (retrieved live 2026-08-08), states what degrades: 'Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollments, transactions and redemptions, Thr!ve Online or Let's Get menu updates, Dr!ve status updates, E-mail notifications are all sent as soon as [we] have a connection'; 'Other actions that can't be saved for later - such as mapping or driving directions, will time out quickly so as not to interfere with your POS processes'; 'Credit card processing will still attempt to connect, and give you an "authorize later" option if a connection is not available'; unreachable sites are flagged in the POS Instant Messaging panel. Credit Batch - WorldPay Element / EMV (kb 1857904) confirms orders were taken and tendered through an outage: 'This can occur if you had an internet outage and the system was unable to reach the processor at the time of the transaction.' Shortfall: that published account is a single 2017-era 7.7 release note, not maintained documentation - it is silent on gift cards, refunds, manual card entry and text-to-pay, and nothing restates it for 8.1+, which moved menu, pricing and most configuration into the cloud Control Center. Withdrawn from the earlier note: the assertion that no offline behaviour is published, and the reading of thrivepos.com's cellular-backup blog post ('it can bring your entire operation to a halt', retrieved 2026-08-08) as the vendor's account of outage operation - it is a marketing post recommending a third-party backup service and is contradicted by the 7.7 documentation. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · retrieved 2026-08-08 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

CLAIM: guest QR at-table ordering writes items onto the SAME open check as server-entered items. VERDICT: no. EVIDENCE: the 372-article census contains no guest QR ordering surface at all (`QR code` = 1 file, a loyalty sign-up link; `scan to order` = 0), so there is nothing that could write to a check. The documented at-table flow is server-entered - 'TV - Using the Orders Screen to Find and Manage Orders', table and tent search - and Thrive Online creates its own ticket. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

First-party, not a resold kiosk: Granbury publishes a dated kiosk release stream of its own ('Release notes - FireFly Thr!ve P O S - Kiosk 0.1.31 1/14/2026') and the kiosk is built on Thrive Online - 'Kiosk now follows TOL rules for available modifiers and adheres to EX OL rules set on items/mod...'. The menu comes from the same TCC catalogue as the POS ('Fixed bug where modifiers categories were not following sort order set in TCC>Kiosk Menu'; TCC 1.1.38 'Unhide Kiosk, Kiosk Menu and Kiosk Design'). SHORTFALLS: (1) the kiosk is a separate menu build in TCC - Kiosk Menu and Kiosk Design are their own screens, and TCC 1.1.14 'Added ability to merge categories together for the kiosk menu in TCC like Thrive Online' - so it is the same item catalogue re-laid-out, not literally the POS menu tree; (2) no ADA or accessibility conformance is published for the kiosk. The only accessibility statement Granbury publishes is about the website: 'Thrive Online, in its base configuration, has passed these scans at a level "AA" compliance' (WCAG 2.1), with the disclaimer that 'Granbury Solutions is not liable for any legal actions or settlements related to accessibility'. Nothing extends that to kiosk hardware, reach ranges or screen-reader support. https://granburysolutions.my.site.com/KnowledgeBase/s/article/KIOSK-RELEASE-NOTES-0-1-26-and-Up · retrieved 2026-08-08

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

'In House Orders - Drive Thru' confirms Drive Thru is a distinct, configurable order type alongside Table/Bar/To-Go, with settings for customer-name prompts, tent/table numbers, customer lookup requirements and open-ticket handling. Shortfall: the article covers only these generic order-entry settings — no order-point/pay-window/pickup-window separation, no lane sequencing or tandem-lane assignment, and no pull-forward/parking-spot assignment is documented anywhere in it or elsewhere in the Learning Center. https://thrivepos.uservoice.com/knowledgebase/articles/850887-in-house-orders-drive-thru · retrieved 2026-08-04

Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.

order-capture-drive-thru-timers

CLAIM: captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders. VERDICT: no. EVIDENCE: `drive.?thru` and `drive through` return ZERO files across the whole 372-article census, so the current product documentation carries no drive-thru surface of any kind, let alone segment timers. The only drive-thru document Thrive ever published is the 8.0-era Learning Center page 'In House Orders - Drive Thru', an order-type preferences screen, and it is not part of the published current set. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

CLAIM: a FIRST-PARTY AI voice ordering agent for phone and/or drive-thru injecting orders directly as POS orders, OR a documented API partner program for third-party voice AI. VERDICT: no, on both disjuncts. EVIDENCE: zero files for `voice ai` / `ai voice` / `IVR` / `speech` across the census and the site crawl; and there is no published partner program - the integrations page enumerates seven named partners and routes every request to 'your account manager or Thrive support'. No developer portal exists: developer.thrivepos.com does not resolve, and `swagger` occurs exactly once in the whole census, as an internal Jira ticket - 'TOL-5408 Make Altura swagger documentation accessible again' - i.e. an INTERNAL spec, not a published one. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://www.thrivepos.com/integrations · retrieved 2026-09-17 adversarially verified

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

Promise Times (version 8.1+) is Thrive's documented answer to kitchen load, and it is manual throughout: 'Promise times are configured with defaults for each day part and order type. However, sometimes when things get busy you will want to change the promise time on the fly... the slide bars allow you to set a new time. For example: If you are exceptionally busy during dinner and you're short handed, you can set the slider for delivery to be 70 mins instead of the defaulted 65 mins.' It is permission-gated ('Alter Promise Times'), bounded ('Users will not be able to set the time below or above the default settings of the min and max times that are set in Configuration > Order Types > Promise Times'), pushed to Thrive Online on save, and reset automatically only by daypart rollover. The per-order-type configuration screens enumerate every available setting - prompt for name/tent/table/lookup, allow save of open tickets, show in server details, display promise time, 'Minimum, Maximum promise times... for breakfast, lunch, dinner' and 'Alert if extended promise times not updated within x min' - and there is no capacity limit per time slot for any channel, and no automatic extension driven by a load threshold. The only order cap in the product is per driver ('limit the maximum # of orders a driver can take at a time'), not per slot or per channel. https://thrivepos.uservoice.com/knowledgebase/articles/1960270-promise-times-version-8-1 · retrieved 2026-08-08

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

Deferred orders are documented in the Learning Center: the order carries a Desired Order Date plus a separate 'When To Print' timestamp controlling when it 'should become an open order and print to production', with an optional additional early print 'to print all deferred orders for the day first thing in the morning for planning purposes'. Cards on deferred delivery orders sit 'in a deferred authorized state' until the order goes live. 7.x release notes add a default online-order lead time (print time uses the longer of the lead time sent by the online site or the configured default). Caveat from the vendor's own forum: a single deferred lead-time default is shared between delivery and pickup (suggestion #38222512). https://thrivepos.uservoice.com/knowledgebase/articles/676885-create-a-deferred-order · retrieved 2026-08-03

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

Paid-in / Out documents recording a catering deposit as a generic Paid In transaction ('If you're catering an event and require a deposit, you can log it as a Paid In... a convenient way to accept money for things that are not on the menu'), and Managing Customer House Accounts (v8.1+, kb 1960294) documents invoicing a Customer Account balance later, described as 'popular for business and school orders as well as catering.' Shortfall: both are generic mechanisms (any-purpose paid-in, any-purpose house account) reused for catering — no distinct catering order flow, catering menu/minimums, quote object, or a delivery/event schedule separate from the standard order queue is documented. https://thrivepos.uservoice.com/knowledgebase/articles/727443-paid-in-out · retrieved 2026-08-04

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

Checked 2026-08-08. The no rested on the DoorDash Drive article (kb 1922671), which covers Thrive's own dispatch-a-Dasher product, plus the statement that marketplace orders arriving 'via our Chowly integration' bypass the dispatch screen. Chowly is no longer the marketplace path: thrivepos.com's Software Integrations page and the Thrive/Deliverect FAQ name Deliverect as the Third Party Order Integration, 'a 3rd party order aggregator that will integrate directly with your POS to sync menu items and insert orders directly into the POS from 3rd party order providers such as DoorDash and GrubHub'. The FAQ does not say what order-status events Thrive sends Deliverect, and no other Thrive document does either. An enumeration of a superseded integration cannot establish that no ready signal is pushed today. || 324th: NEW SURFACE (324th), cell still unresolved. The 372-article Salesforce Knowledge REST census adds 'Automatic SMS Order Updates in Thrive POS', the closest thing Thrive publishes, and it signals the GUEST, not a marketplace: 'Order Ready: For all non-delivery order types, an order ready message is sent to the customer based on manual input. That input can be found in the POS on Orders', with a Cheftab KPS optionally driving it - 'the Cheftab allows us the opportunity to accurately communicate order status such as "Order is in the oven" or "Order is out of the oven"'. A 2026 release note adds 'TPOS-9695 Added 5 minute Timeout to SMS Order Ready on Orders Page'. The marketplace path is Deliverect and the census's Deliverect material (12 files, 133 hits) is inbound only - the POS exposes '/pos/order' and the release notes record only inbound mapping failures. `status back`, `mark ready` and `order status` (3 files, all internal UI filters) give no evidence either way about whether Deliverect relays a Thrive state onward, so the absence would be bounded to Thrive's documentation rather than to the integration's behaviour. Unknown, not no. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. || 325th: MERGE HOLD (proposed no/B, held unknown): the SMS article enumerates customer text-message events only; the marketplace channel (Deliverect, Chowly) is bounded only by silence in 12 integration articles, and a manual POS 'order ready' input could still be relayed. The agent flagged this as its weakest row. PROPOSAL AS WRITTEN: CLAIM: pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. VERDICT: no - the prior pass could not find any statement of how Thrive produces an order-ready event; a new article now states it. EVIDENCE: 'Automatic SMS Order Updates in Thrive POS' is a complete enumeration of every order-state event Thrive emits and of every recipient, and the recipient is always the CUSTOMER by text message. Its order-ready trigger is explicitly manual: 'Order Ready: For all non-delivery order types, an order ready message is sent to the customer BASED ON MANUAL INPUT. That input can be found in the POS on Orders.' The KDS-derived triggers it adds are also SMS-only and optional - 'For Cheftab users, you can optionally set an Order in Oven trigger. Upon bump of an order, the customer will be sent the following text message' and a 'Packaging Order' trigger - and both require the vendor: 'Support will first license your location to allow the ChefTab to send SMS Order Updates ... a member of our support team will help configure the Cheftab'. The full trigger list is Order Placed, Order Dispatched, Order Ready, Order Complete, Order Cancelled, plus the two optional ChefTab triggers; no marketplace is a recipient of any of them (https://granburysolutions.my.site.com/KnowledgeBase/s/article/SMS-Order-Update). Third-party marketplace traffic runs through Deliverect, and across the 12 Deliverect articles (133 tokenised hits) the documented flow is inbound only - menu and item publish out to Deliverect, orders inserted into the POS - with no outbound order-status channel; 'webhook' 0 hits and 'callback' 0 hits across all 884 articles. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. || 327th: NEW SURFACE (327th), cell still unresolved but the marketplace path has CHANGED AGAIN and the old note's premise is now stale. Granbury has launched a FIRST-PARTY aggregator product, Thrive Connect, out of beta: 'Connect brings your delivery orders into Thrive POS. They print to the same kitchen printer, hit the same tickets, and land in the same reports as a phone order ... Channels: DoorDash, Uber Eats, Grubhub and more', and it is Granbury's own, not a partner's - 'Connect is a Thrive POS product. It shows up as a line on the invoice you already get, priced by how many channels you run, with no separate vendor to set up or pay' (https://www.thrivepos.com/thrive-connect). So the cell no longer depends on what Deliverect relays; it depends on what Granbury's own bridge does. The page's complete feature list and its Common questions section are inbound-and-menu-outbound only - 'Orders come into Thrive POS, so nobody is keying them in a second time | Menu, pricing, and availability publish out to every connected channel | One set of reports across your channels and your own orders | One line on your Thrive POS bill' - with no order-status, order-ready or fulfilment event in either direction. Surface enumerated by the HubSpot content-search API (https://www.thrivepos.com/_hcms/search?term=<t>&limit=100, 49 terms paged to exhaustion, 254 distinct URLs incl. unlinked pages), which is a route no prior pass used; the complete /integrations/* set is 7shifts, deliverect, doordash-drive, pizzacloud, restaurant-365, valutec, wookai. Not scored: these are marketing pages (grade C) and a feature list that omits a status callback is not a statement that none is sent. Resolved by a Thrive Connect KB article or release note naming an outbound order-status event. Retrieved 2026-09-18. || 329th: 329th: THE TWO DOCUMENTS THE 327th NOTE ASKED FOR EXIST AND HAVE NOW BEEN READ IN FULL, and neither names an outbound order-status event - but the cell is still held, because Thrive Connect's DSP plumbing is an unpublished server-side integration. (a) 'Thrive Connect User Guide' (KB kA0Ri000000AwltKAC, published 2026-07-24, grade B) describes the whole Connect UI. Everything it pushes OUT is menu or commerce control: 'A catalog update is when the menu from TCC is updated and published to Thrive Connect ... The Publish All indicator is for all third-party ordering platforms', 'Pause Menu: Pauses orders from some, or all DSPs', 'Adjust Price %', and per-order 'you can contact the customer or cancel the order ... Voiding an order that hasn't been made yet will cancel the order'. The order view READS status rather than sending one: 'Open orders provide information such as order content, placement time, and fulfillment status, as well as the option to bypass default prep times.' No order-ready, order-accepted or food-ready event appears anywhere in the guide. (b) '3rd Party Order Handling in 8.3.40' (KB kA0Ri000000AxjZKAS, published 2026-06-24, grade B) is the POS-side rulebook and it carries a CLOSED action table for a 3rd-party ticket: View yes, Recall into virtual ticket yes, Close an open order yes, Void the entire order yes; Edit or modify items NO, Add items NO, Void a single item NO, Re-open a closed ticket NO, Use the Finish button NO. It also states, for marketplace pickup orders, that no fulfilment trigger exists at all: 'Since the 3rd party delivery partner picks up the order with no further staff interaction required, there is no natural trigger to close the ticket - this setting gives you flexibility in how you manage that' (the TCC setting being whether such orders 'arrive automatically closed or open-Settled'). It scopes itself to exactly this cell's channel - 'That is orders from Deliverect, or Thrive Connect (coming soon)' - and the only outbound POS action it permits is a full void. NEW SURFACE (329th): a COMPLETE anonymous census of THRIVE CONTROL CENTER, Granbury's own back-office/configuration app, which no prior pass touched. The public login page https://thrive-control-center.grs-tcc.com/ (1,310 bytes, Vue CLI) names /js/app.b3306bf3.js; that bundle carries the webpack chunk-name table ("js/"+({}[e]||e)+"."+{"chunk-0198d488":"68b133db",...}) with 121 entries. All 121 chunks AND all 121 matching .js.map files fetched: 121/121 HTTP 200, 0 misses, 1 round to a fixpoint (no chunk referenced a chunk outside the table). Plus app.b3306bf3.js.map. Soft-200 control: app.b3306bf3.js.NONSENSE.map = 404/135 bytes and the real maps begin {"version":3,; / = 200 but /zzz-nope-12345 = 404, so the host is not a catch-all. The maps carry sourcesContent: 6,783 source entries, 3,278 distinct sources, 2,763 of them the vendor's own (./src/** and ../shared-js/src/**), 19.9 MB of original source. Module census: menu 828, location-settings 473, common 278, shared-js 176, employment 58, user-management 54, locations 54, kiosk 53, user-roles 52, offers 42, ticket-finder 25. Grade B (production JS the vendor does not publish as documentation). THIS BOUNDS THE BACK-OFFICE APP ONLY, not the store-level POS binary. In that app the ticket lifecycle model is also a closed enumeration: ticket-finder/TicketDetails.vue builds its Timeline from exactly eight event kinds - taken, closed, promise, delivery (dispatchTime, arrivalTime, returnTime), voids, tenders, combined, deferred - with a third-party order rendered as 'Order received from <span class="third-party">' + salesChannel, and there is NO ready/bump/fired event and no outbound status call; 'webhook' returns 0 hits and 'order ready'/'orderReady' 0 hits across all 19.9 MB, while 'status' returns 937 and 'offer' 1,291. Also re-read today: the vendor's own ready state exists and is published to the GUEST only - 'SMS messages are triggered automatically as an order moves through your system. Order placed ... Order ready - customer is notified to pick up. Order dispatched ... Order completed or canceled' (https://www.thrivepos.com/en-us/thrive-product-news/sms-order-updates). A re-page of the Salesforce Knowledge REST listing today returns 372 articles, identical ids to the 324th's pull (0 new, 0 retired), so the KB census is unchanged and complete. WHY STILL UNKNOWN: per the 327th merge rule, a capability `no` on an integration the vendor runs as an unpublished server-side service is not bounded by a publication census - Connect's DSP-side plumbing is documented nowhere public, and a relayed ready event would not have to appear in an operator guide. Retrieved 2026-09-18. adversarially verified

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

Voids require a reason and manager override when unauthorized (kb 510694/510178/510219); void reasons can be made mandatory per workgroup (kb 1007758); discount overrides require a password when an employee's discount % authorization is exceeded (Apply A Discount, kb 711744); the Void Details Report attributes each void to the employee and 'who authorized the void', with reason, timestamps and amounts. Shortfall: this is two separate controls (void reason/approval, discount override) rather than one unified reason-code-and-approval gate spanning voids, comps AND discounts, and no single exception report combines all three — the Void Details Report covers voids only, with no comparable comp/discount exception report documented. https://thrivepos.uservoice.com/knowledgebase/articles/439741-void-details-report · retrieved 2026-08-04

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

menu-pricing-nested-modifiers

Thrive calls modifier groups 'requirements'. Version 8.1 documents min/max on them: 'Better control over quantity for requirements, setting # of items required and then additional items none, up to X or unlimited', plus 'Modifiers can be set to a max quantity per item, for instance you can allow pepperoni x5 as a maximum', 'New option to exclude sizes when applying requirements to items, so you can apply Choose a sauce to the small size and Choose 2 sauces to the large' and 'New option to select channel (POS or Online) when applying requirements'. Creating a New Requirement enumerates the pre-8.1 screen - Requirement Name, Include No Option, Required Choices ('You can set how many choices must be selected... Set the Required Choices to 0 to allow unlimited selections'), Up-charge Based On Item Selection, Up-charge Based on # of Selections - and a requirement is forced by construction: 'a pop up box appear with an option that must be selected before the order can be completed'. Shortfall: nesting depth is never documented. Nested requirements demonstrably exist - release notes fix 'Resolved issues with Repeated Nested Requirements', 'nested Requirements not saving in proper order in order submit' and 'requirements selected in Quantity popping subsequent nested requirements' - but no article states a supported depth, nothing demonstrates three levels, and no worked example shows independent min/max at each level. https://thrivepos.uservoice.com/knowledgebase/articles/1936528-version-8-1-current-release · retrieved 2026-08-08

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

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

Per-modifier pricing is a single flat charge — 'Extra Charge Per Pizza Topping: Set the price to add for this topping' (kb 401660). Size-sensitive topping pricing exists only via category-level Topping Based Pricing: a matrix of topping-count price rows added to the base price, whose defaults can be overridden by 'altering the Size and Sub-Size Up Charge columns'. So topping cost can vary with parent size only through the category topping-count grid, not per modifier. Shortfall: no documented way for an individual modifier to carry its own per-size price matrix. https://thrivepos.uservoice.com/knowledgebase/articles/401664-topping-based-pricing · retrieved 2026-08-03

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

menu-pricing-fractional-placement

The researcher's only source was exactly the class of third-party roundup the rules forbid as evidence. Vendor product documentation exists and is explicit: press 'F' to make an item fractional, press again for 1/2, 1/3 or 1/4, then click the portion of the pizza to edit and add/remove toppings per section, or swap a different pre-designed pizza onto each fraction. Native, documented, thirds and quarters — stronger than the researcher scored. https://thrivepos.uservoice.com/knowledgebase/articles/471541-order-a-fractional-pizza · retrieved 2026-08-01 adversarially verified

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

menu-pricing-half-and-half-rule

It is documented. Configuration > Items > department > Edit > 'Allow Fractional Orders' exposes an explicit pricing-rule choice: 'Use the price of the most expensive fraction' or 'Use the average price of the fractions' (worked example: $15.99 combo + $12.99 cheese = $14.49 averaged), plus an Exclude Size control (e.g. no fractional smalls) and a Fractional Type control for which of 1/2, 1/3, 1/4 are permitted. This is the configurable rule the researcher declared unfindable. https://thrivepos.uservoice.com/knowledgebase/articles/397724-setting-up-fractions · retrieved 2026-08-01 adversarially verified

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

menu-pricing-topping-quantity-tiers

Topping quantity is an integer count — 'Need to change quantity on a topping or included item? Just click on the green half to add, the red half to subtract' — so double is achievable as quantity 2. Shortfall: no named light/regular/extra/double tiers and no configurable per-tier price multiplier are documented anywhere in the Learning Center; the only reduced-charge behaviour documented is removing an inclusion with the 'Reduce Price' box checked (kb 402988), so light-at-reduced-charge or extra-at-1.5x tiering is undocumented. https://thrivepos.uservoice.com/knowledgebase/articles/922596-tips-for-quantity-ordering-the-same-item-many-tim · retrieved 2026-08-03

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

menu-pricing-size-style-matrix

Setting Up Pricing - Basic, Item Based documents a two-axis grid: 'the columns we set up for your Department Size are here. Enter prices for these columns. These will be default for the category,' and 'Below the size chart are the additional Styles you have set up. If you charge more for a particular style (i.e. your stuffed crust, or gluten free bread), put that upcharge in the proper cell' — a size x style grid with a per-cell upcharge. It further documents override at the individual item level: 'You have now set up your pricing at the category level. You can override this pricing at the item level once you have set up your items in this category,' which supplies the per-cell override for exceptions. https://thrivepos.uservoice.com/knowledgebase/articles/400972-setting-up-pricing-basic-item-based · retrieved 2026-08-04

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

menu-pricing-included-allowance

'Inclusions' are a documented first-class construct — default ingredients attached at category or item level that print on the order and can be removed or substituted, with inclusion usage tracked separately in ingredient costing. Whether an inclusion count drives an upcharge threshold (N-toppings-included-then-charge) is only partly evidenced; topping-based pricing by total topping count is separately documented. https://thrivepos.uservoice.com/knowledgebase/articles/402988-inclusions-setup · retrieved 2026-08-01 adversarially verified

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

menu-pricing-combos

Version 8.1 release notes: 'New value option: Combo. Set a fixed price for a set of items and the system will automatically calculate the discount on each item' — native fixed-price combo construction with per-item discount allocation. Shortfall: neither this release note nor any other Learning Center article documents component swapping with a price delta, or automatic detection/conversion of eligible a-la-carte cart items into the combo price — the documented mechanism is a manually-selected combo value applied to a pre-built set of items. https://thrivepos.uservoice.com/knowledgebase/articles/1936528-version-8-1-current-release · retrieved 2026-08-04

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

menu-pricing-upsell-prompts

Suggestive selling configured in Thrive Control Center, settable per individual item or per menu department; documented for online ordering checkout only. No attach-rate reporting. $100 setup service. https://www.thrivepos.com/en-us/thrive-product-news/boost-your-ticket-average-with-suggestive-selling · retrieved 2026-08-01

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

menu-pricing-86-propagation

One action, two destinations. TV - Out of Stock / Countdown (Version 8.1): 'To mark an item as out of stock, from the Home screen, click on Manager and then click on Stock/Countdown', 'Note: Saving an item as "Out of Stock" will automatically update its status in Thrive Online as well', with 8.1 extending it to a size or style ('you've run out of dough for an individual size or crust') and modifiers cascading ('IF you mark a modifier as out of stock, this will make all items that contain that modifier as an inclusion also unavailable to order'). Countdown does the same: 'When it reaches 0 the item will appear as out of stock (and Thrive Online will also be updated).' SHORTFALL: the only automatic destination named is Thrive Online, the vendor's own ordering site. Third-party marketplaces are reached through the Deliverect aggregator, and Thrive's own Deliverect Quick Guide states the break: 'To get that pricing to the third party channels, you will need to sync from within Deliverect to the third parties as this feature isn't supported directly from the POS to the third party yet.' No KDS/KPS destination and no kiosk destination is named for stock status in either corpus, and no propagation latency figure is published anywhere. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Out-of-Stock-Countdown-Version-8-1 · retrieved 2026-08-08

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

menu-pricing-countdown-auto-86

Out of Stock & Countdown (v8.1+): turn Countdown ON for an item with an on-hand quantity; 'Each time an item is ordered, the quantity is reduced' and 'When it reaches 0 the item will appear as out of stock (and Thrive Online will also be updated)'. The earlier v8.0-era article (kb 1097011) confirms online orders also decrement the count and going back above zero restores the item online. Shortfall: no scheduled auto-restore — restoration is manual ('To mark an item back in stock, simply turn OFF the out of stock indicator and save'), with managers updating on-hand counts daily by hand. https://thrivepos.uservoice.com/knowledgebase/articles/1955140-out-of-stock-countdown-version-8-1 · retrieved 2026-08-03

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

menu-pricing-dayparting

Genuine time-of-day menu scheduling exists, on the online channel: TCC > Menu > Online Layout, 'Check the box "Restrict availability for category to certain times of day", Select the available time from the drop downs', after which 'if they try to order outside the time, they will be encouraged to schedule an order' - i.e. lunch specials or a late-night menu activate and deactivate on their own. DayPart Hours in TCC (Configuration > Hours) let an operator define named parts of the day - defaulting to Breakfast, Lunch and Dinner, with 'Add DayPart Hour' for more - but the article states their purpose narrowly: 'DayParts are used to define sections of your day, primarily for reporting purposes and to set different default "promise" times for your orders.' SHORTFALLS: (1) the scheduled activation documented is category-level and applies to the Thrive Online layout, not to the POS menu or to individual items; (2) no scheduled base-price change exists - price movement by clock is either a coupon with a validity window ('only Valid between the hours of 3pm and 5pm for happy hour') or a manual pricing-scheme switch ('just change them in a new scheme, then set that scheme as the default when the day comes'); (3) neither corpus states how the location's own timezone is handled. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TOL-Restricting-a-Menu-Category-by-time-of-day · retrieved 2026-08-08

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

menu-pricing-channel-price-books

Vendor states operators can 'set different pricing tiers' for third-party platforms versus their own site. Per-channel percentage-markup rules and full price-book model not documented. https://www.thrivepos.com/olo-mobile · retrieved 2026-08-01

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

menu-pricing-dual-pricing

ThrivePay documents both credit surcharge and cash discount as distinct programs, but item-level dual price storage and cross-channel consistency are not documented. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01

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

menu-pricing-versioning-effective-dates

All three elements are documented on one page. STAGED AND EFFECTIVE-DATED: 'You can publish immediately, or schedule for the publish to occur in the future ... If you wish to have an update take effect later, such as after close of business, you can press the Schedule button. Select the date and time for the publish.' PREVIEWED: the publish screen lists locations with their status and last update, and 'You can click the 3 dots next to the Last Update date to see the menu version the POS is currently using and the pending version'; release notes add the diff itself - 'TCC-1334 Added controls to show differences between current and published blobs on menu publish' and 'TCC-1715 Diff viewer in the override indicator to get a list of changes vs next hierarchy'. ROLLED BACK AFTER PUBLISH: 'If a menu is published in error, it is possible to rollback to a previous version from TCC. In the Publish screen, click on the Last Update information to see the menu versions. Use the Revert button to rollback to the most recent version the POS had.' Caveats, neither of which is part of the claim: the Revert button restores the most recent prior version rather than an arbitrary one, and a publish is all-or-nothing across domains - 'Publishing will include all menu, configuration and hardware changes. There is not currently a way to separate these', and 'If you schedule a publish event, then make changes to the menu after, those changes will be included in the menu that is published.' (Withdraws the earlier note's shortfall, which asserted that no preview and no post-publish rollback were documented; that was an absence read off the Learning Center corpus, and the current doc host documents both.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-Control-Center-Publish-changes-to-stores · retrieved 2026-08-08

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

menu-pricing-franchise-hierarchy

'Dispatch specific updates to individual stores, tailor pricing strategies, and control item availability with precision.' No field-level override governance documented. https://www.thrivepos.com/en-us/location-management · retrieved 2026-08-01

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

menu-pricing-allergen-nutrition

Item Descriptions is the only documented carrier and it is explicitly intended for this purpose: 'The Item Description is a handy way to provide additional details about a menu item's ingredients, allergens, nutritional content, calories etc.' It is entered in item setup and read back at the POS two ways - 'Press and hold on an item button to see the description pop up' or the three dots next to the item in the virtual ticket - added in version 7.6.0. Shortfall: it is one unstructured free-text string per item, not allergen flags and not nutrition values, so it cannot be filtered, validated or totalled; the article documents display at the point of sale only and says nothing about publishing the description to Thrive Online or to third-party menus; and the ingredient/recipe cluster (Ingredients Overview, Add An Ingredient, Add A Inventory Ingredient Recipe, Associate An Ingredient To A Menu Item) is purely costing and usage oriented - unit conversions, yields, ideal usage - carrying no nutrition fields, so nothing can be derived from linked recipe components. https://thrivepos.uservoice.com/knowledgebase/articles/1097002-item-descriptions · retrieved 2026-08-08

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

menu-pricing-recipe-linkage

The Item Ingredients Report documents per-item ingredient setup showing 'ingredient usage per size, with inclusion usage listed below, and a total food cost per size' — i.e. recipes are attached to menu items, size-aware, and costed natively. A scored 'no' on a documented native capability is the worst failure mode in this dossier. https://thrivepos.uservoice.com/knowledgebase/articles/439853-item-ingredients-report · retrieved 2026-08-01 adversarially verified

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

menu-pricing-3p-menu-push

Menus reach the marketplaces through the Deliverect aggregator, on an integration Thrive built itself: 'The entire development was from Thrive POS and TCC to the Deliverect api interface. Communication between the two products will be conducted through SQS/SNS in AWS', 'Deliverect will receive all Menu Categories, Menu Items, Modifiers and Requirements', and 'when you publish to your POS from Thrive Control Center, it will automatically update the items, including descriptions, prices, modifiers, etc to Deliverect.' Sync visibility exists one hop out: 'you can simply go to the Deliverect Operations Report Tab to validate a sync has occurred... any subsequent menu publishes will only display any changes that were published.' SHORTFALLS, all vendor-stated: (1) it is not a direct certified marketplace integration and the last hop is not automatic - 'To get that pricing to the third party channels, you will need to sync from within Deliverect to the third parties as this feature isn't supported directly from the POS to the third party yet'; (2) it is a paid third-party subscription, 'a monthly charge per location... Low - up to 750 orders $99, Medium - from 750 - 1250 orders a month $149, High - over 1250 orders a month $199' (as of Jan 2023), and the 2026 Thrive pricing matrix counts it against a per-tier integration allowance (Starter none, Delivery Plus 1, The Works 3); (3) hard menu limitations - 'Pricing by Topping is not supported', 'Tax inclusive items are not supported currently', 'we will merge the item and size into a single item', and combined item+modifier Requirements 'will be omitted from import to Deliverect'; (4) no per-item rejection-error surface is exposed inside Thrive itself. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Quick-Guide · retrieved 2026-08-08

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

menu-pricing-dynamic-pricing

Alternate Pricing creates a complete second price book that applies without per-order intervention along two axes. By station: 'Default Price Scheme By Store/Station: Select Store to set the default scheme your store will use. Select individual stations to have your pricing vary by station.' By channel, as of version 8.0.13: '3rd Party Online Order Scheme: Use this setting to select a default pricing scheme that will be used by 3rd party online ordering (everything except Let'sGet or Thr!ve Online). Combat the high fees of 3rd party sites like UberEats and GrubHub by charging higher menu prices for these integrations. The XML Export that is provided to your integrator will use this scheme for the pricing export as well.' Version 8.1 adds 'Publish menu changes immediately or schedule them for a future time', and Multiple Pricing lets a scheme be applied to an individual order. Shortfall: the article enumerates every field on the screen - Pricing Scheme, Name, Comments, PLU #, Copy From, Default Price Scheme By Store/Station, 3rd Party Online Order Scheme - and there is no rule that moves an item's own price by time of day or by demand, and no floor or ceiling guardrail concept anywhere in the Config - Pricing or Config - Special Pricing topics; time-varying discounting exists only as coupons with validity windows, and switching the store to a scheme is a manual act. https://thrivepos.uservoice.com/knowledgebase/articles/401035-alternate-pricing · retrieved 2026-08-08

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

Upheld commercially — the pricing page does require ThrivePay on all published plans. But the reasoning is wrong: the platform is not technically processor-locked. Thrive's own KB publishes 'Supported Credit and Gift Processors' naming direct integrations (Vantiv/Worldpay, OpenEdge, Cayan/TSYS) and gateway platforms (Elavon, Heartland, Chase Paymentech, First Data Omaha/Nashville/Buypass/North, Global East, RBS Worldpay, TSYS) plus gift processors Givex, Valutec, ValueLink, STS. The lock is contractual on new plans, not architectural, which is a materially different negotiating position for a https://thrivepos.uservoice.com/knowledgebase/articles/632905-supported-credit-and-gift-processors · retrieved 2026-08-01 adversarially verified

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

payments-published-rates

ThrivePay page markets 'competitive rates' and 'transparent rates' but publishes no percentage or per-transaction figure anywhere. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01

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

Cash discount and credit surcharge both offered as programs; two-price storage per item and dual totals printed on the guest check are not documented. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01

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

Documents a 3% cap or cost-of-acceptance whichever is lower, the 30-day card-brand notice (which ThrivePay files on the merchant's behalf), and required signage at entry, terminal and receipt. Debit/prepaid BIN exclusion is NOT stated. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01

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

payments-emv-nfc

Hardware with 'NFC and EMV technology' and support for 'contactless transactions'. Ingenico Lane 3000 EMV device announced as supported. Apple Pay/Google Pay not named explicitly. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01

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

payments-softpos-tap-to-pay

P4 retested and holds, so a hardware absence carries weight: Thrive's own store sells iPads only with a strap-on magstripe swipe - the opposite of reader-less acceptance - and no softPOS SKU. Independently the Salesforce KB article 'What EMV devices are supported' answers with a closed device list (Verifone Mx915, Ingenico iPP320 / Lane 3000 / Link 2500 / Lane 7000 / Lane 3600), all tethered pinpads - a within-document enumeration, not an absence resting on the unenumerable P3 host. 'Tap to Pay' and 'SoftPOS' return zero corpus-wide. AUDIT (2026-09-04): The only verdict in the set with a within-document enumeration on a CURRENT surface: 'Supported EMV Devices - WP and WP Gateway' (Jun 26, 2024) is scoped by its own question and answers with device lists across four processors, every entry a tethered Verifone/Ingenico pinpad. That is the vendor enumerating the acceptance alternatives with softPOS not among them. Corroborated positively by the iPad/iDynamo5 pairing and a corpus-wide zero on Tap to Pay / SoftPOS / NFC. Note two caveats: the article says the list grows as devices are certified, and it is processor-scoped. https://www.thrivehardware.com/products/cayan-swipe-for-ipads · retrieved 2026-09-04

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

payments-pay-at-table

A wireless away-from-counter payment option exists as a paid add-on, but Thrive documents it for line-busting and car-side rather than as a table-service pay-at-table workflow. Thrive product news, 22 June 2021: 'Looking for a mobile line-busting or car-side order management solution? Combine a handheld Thrive tablet with the Ingenico Link 2500 EMV device. Adding a handheld table[t] to your Thrive system gives you the flexibility to take orders from anywhere. With the WiFi-enabled Link 2500 EMV, you can accept payments, including contactless, Google Pay, and Apple Pay, from anywhere your WiFi connection will allow.' Tip prompting is on the device - Credit Configuration - Worldpay | Element EMV (kb 1858063) lets the merchant set up to three suggested tip amounts plus 'Custom tip' - and the POS has Split Tickets and Pay An Order With Evenly Split Tenders. Named shortfalls: it is a quote-only add-on ('Contact us to learn more about these great add-ons'), not standard kit; Table Service itself is only on the top Pizza Pro tier; the cabled path remains the documented default ('If you are using EMV devices, you'll need to install them on your network. Plug them into a network cable that is attached to your router ... Select the 1st station that will have an EMV device'); and no article walks a split-check-at-the-table flow on the handheld - Settle A Ticket Via The Table Screen still sends the server to a station. https://www.thrivepos.com/en-us/thrive-product-news/go-mobile-with-wifi-enabled-emv-device-ingenico-2500-handheld-tablet · 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

CLAIM: guest scans a QR code on the printed check or table tent to view and pay from their own phone, the payment closing the check in the POS. VERDICT: no. EVIDENCE: `scan to pay` returns zero files across the 372-article census and the sole `QR code` occurrence is the loyalty sign-up tip. The control is not vacuous: the census documents the alternative payment surfaces in detail - EMV devices (Ingenico Lane 3000, Lane 3600), pre-auth (13 files, 32 hits), bar-tab pre-auth, MSR and gift - so this is a documented payments corpus that contains no guest-scanned check payment. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · 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

Both flows and a documented adjustment window are confirmed: 'If the EMV tips are on, card present transactions will be processed as a Sale which is final. Tips can not be adjusted' versus 'If the EMV Tips are off, card-present transactions will be processed as Pre-Auth, so tips can be entered and adjusted later,' with delivery/pickup orders 'always Pre-Auth.' Add A Tip Via The Order Screen (kb 508632) documents the entry mechanism (flat amount or %Tip), and a separate release note states 'Tips cannot be added to transactions after you complete your Daily Close' — the adjust window is bounded by Daily Close. Shortfall: no manager screen or report specifically surfacing unadjusted/pending tips before that close is documented. https://thrivepos.uservoice.com/knowledgebase/articles/1858063-credit-configuration-worldpay-element-emv · retrieved 2026-08-04

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

Close Register documents three tip dispositions at register close: 'Pay Tips (pays out generally, as to a tip pool), Pay Tips to Server (attributes tips specifically to the employee who took the order...) or Retain Tips.' Shortfall: the pooled 'Pay Tips' path is a single lump payout, not a configurable distribution engine — no article documents splitting the pool by hours worked, sales percentage, role, or points, and no per-employee pooled-tip allocation export to payroll is documented (same gap already recorded on labor-tip-pooling-rules and labor-tip-distribution-audit-trail). https://thrivepos.uservoice.com/knowledgebase/articles/1132084-close-register-improved-in-v-7-7-0-with-video · retrieved 2026-08-04

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

Cards taken while the processor was unreachable are captured and completed later: 'At the bottom of the screen, you may see information about unauthorized charges. This can occur if you had an internet outage and the system was unable to reach the processor at the time of the transaction. You must authorize these transactions before closing the batch, so click the button to authorize. Use the checkbox to select the payments to authorize, and click Authorize Selected.' Store and forward is named as a distinct product behaviour in the 8.0.73 release note 'Blocking store and forward MSR transactions with Cayan'. Shortfall: no configurable per-transaction or cumulative offline limit is documented on the Credit Configuration screen or anywhere else - that screen's enumerated controls are merchant IDs, URL, port, password, CVV enforcement, card-data archiving, minimum AVS result, signature requirement and threshold, and an 'Allowable Excess Multiplier' governing post-auth headroom, none of which caps offline exposure. Forwarding is a manual operator action at batch close rather than an automatic background retry, declines surface only at that point, and the behaviour is processor-dependent (blocked outright for Cayan MSR). https://thrivepos.uservoice.com/knowledgebase/articles/1857904-credit-batch-worldpay-element-emv · retrieved 2026-08-08

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

The claim tests whether the vendor PUBLISHES a liability allocation, so it is answered by enumerating what is published. Read live 2026-08-08: thrivepos.com's sitemap lists 247 pages and exactly two legal instruments, /en-us/privacy-policy and /en-us/sms-messaging-tos - there is no merchant agreement, processing agreement or terms of service on the site at all, so no published instrument allocates the loss on a store-and-forward decline, and the ThrivePay /payment-processing page is silent (its only use of the word is marketing: transactions are 'fast, secure, and reliable'). Both documentation hosts were then swept: across the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase, store-and-forward appears only as engineering work - 8.1.3 'TPOS-5803 Save Thrive Payments key rotations and store-and-forward requests to Mysql so that RabbitMQ can be removed' and 8.2 'TPOS-7448 Fixed Failed/declined store and forward TP transaction fail to clear' - which confirms post-reconnect declines occur and are treated as a defect, never as a commercial allocation. A live search of the Learning Center for 'offline' returns no article. Nearest published surfaces, neither of which meets the claim: Credit Batch - WorldPay Element / EMV lists 'unauthorized charges ... if you had an internet outage and the system was unable to reach the processor', which the operator must authorize before closing the batch - a pre-authorization queue, not a report of payments that failed after reconnect; and Declined Deferred Credit Card Orders covers a different mechanism (a minimal validation authorization taken on a deferred order that declines when the order goes live), instructing the operator to void the declined payment and re-tender - it allocates no loss and is not offline capture. No per-transaction or cumulative offline cap is stated anywhere. (Withdrawn from the earlier note: the assertion that the UserVoice knowledgebase is Thrive's corpus, its index page as the citation, the claim that release note 8.0.73 is the sole store-and-forward reference, and the claim that no offline capture is described.) https://www.thrivepos.com/sitemap.xml · retrieved 2026-08-08

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

Gift Cards listed as an included feature of the $99 Starter plan, i.e. available at every tier. https://www.thrivepos.com/pricing · retrieved 2026-08-01

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

payments-house-accounts

Delivery page cites 'process payments and customer charges directly in the POS', suggesting on-account charging. Credit limits, running balances and statement generation are not documented. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

payments-split-tender

Pay An Order With Multiple Tender documents entering a partial amount, selecting a tender type, then repeating with the remaining balance against a second tender ('this method can also be applied to using two different credit cards in the same way'). Shortfall: the article and worked examples only ever show a two-way split by amount — no stated maximum number of tenders (so a cap below eight is not confirmed either), and no seat- or item-based split-tender mechanism is documented; splitting by seat/item is documented only for splitting into separate tickets (Split Tickets, kb 491597), not for a single check settled across multiple tenders. https://thrivepos.uservoice.com/knowledgebase/articles/599376-pay-an-order-with-multiple-tender · retrieved 2026-08-04

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

payments-refund-void-controls

Authorization gating is documented: 'Voiding is a secure function. If the cashier doesn't have authorization to void, a manager override will be required' (kb 510694); discounts prompt a manager override when the workgroup lacks the permission or exceeds its discount percentage limit; void reasons can be made mandatory per workgroup (kb 1007758). The Void Details Report records the employee who performed the void, 'who authorized the void', the reason, ticket status, timestamps, void and refund amounts. Shortfall: approver-attributed audit reporting is documented only for voids/refunds — no article documents approver attribution for discounts, and no-sale/drawer-open events have no documented log at all. https://thrivepos.uservoice.com/knowledgebase/articles/439741-void-details-report · retrieved 2026-08-03

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

payments-chargeback-tooling

Thrive's documented answer to disputes is prevention, not tooling. Preventing Chargebacks - Decline on AVS / CVV mismatch offers configuration strategies only: 'Using an EMV/chip card will help to reduce your liability for charge backs. It also removes credit card data from your POS system', plus the AVS strictness and CVV-on-keyed-order settings in Credit Configuration. The in-product card surface is fully enumerated by the Manager - Cash/Credit topic's ten articles and by Credit Batch - WorldPay Element / EMV, which walks the entire screen: Batch Summary broken out by card type and card-present/not-present, expandable Transaction Details with authorized/voided/open filters and per-ticket expansion, Reprint Slip, authorize-unauthorized, Close Batch, and Settled Batches. There is no dispute or chargeback list, no representment workflow, and no evidence upload assembled from the transaction record anywhere in that surface; problems are referred out - 'If you experience any errors during the batch close process, please contact Technical Support or your processor.' https://thrivepos.uservoice.com/knowledgebase/articles/1887328-preventing-chargebacks-decline-on-avs-cvv-mism · retrieved 2026-08-08

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

Branded app supports 'reorder with one tap' and online ordering supports accounts, which implies stored tokenized payment, but tokenization is not documented explicitly. https://www.thrivepos.com/en-us/features · retrieved 2026-08-01

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

payments-payout-timing

The claim turns on publication, and Thrive publishes nothing. Re-fetched 2026-08-08: thrivepos.com/payment-processing markets ThrivePay on competitive rates, EMV/NFC hardware, real-time analytics and a credit-card surcharge program, and states no deposit schedule, no funding interval and no next-day, same-day or instant funding product. Neither documentation corpus supplies one: across the 511 Learning Center articles and the 251 Granbury KB articles there is no funding-interval statement, and the guidance instead defers to the merchant's processor - 'You should batch your credit cards daily to ensure timely deposits from your processor!' and, at setup, 'confirm that the deposit went to your bank account.' The only settlement-adjacent control documented is the 'Use current credit card batch in deposit' flag, which posts a midday deposit line from the closed batch (TV - credit cards deposited in a separate midday bank deposit) - cash-reconciliation bookkeeping, not card funding. Timing therefore sits with WorldPay/Thrive Payments, Open Edge, Cayan or the gateway, and Thrive states no schedule of its own. https://www.thrivepos.com/payment-processing · 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

Merchant credentials are per store, so settlement does land per location: Credit Configuration is a store-level screen (Manager Home > Config > Tax/Tender/Cash > Credit) taking 'Card Present Merchant ID', 'Card Not-Present Merchant ID', URL, port and password for that location's own processor account, alongside a processor picker covering the three direct integrations and the Cayan gateway list. Unified reporting sits above it: Thrive Analytics is 'a powerful multi-store reporting tool that lets you easily access your data for all your locations', with a location filter on every dashboard ('You can choose which locations to include... Just touch on the location names to turn them on or off'), refreshed every 2-3 hours, and 8.1's Thrive Control Center manages one company menu across locations with field-level overrides. Shortfall: this is separate per-store installations each configured with their own MID, not a single account routing settlement funds. No article documents split settlement, more than one bank account under one merchant account, per-legal-entity routing, or any funds-routing control inside Thrive; deposit reconciliation (Deposit, Bank Deposit Report) is single-store only, and 8.1's multi-store improvements are described entirely in terms of menu, pricing, configuration and reporting - never settlement. https://thrivepos.uservoice.com/knowledgebase/articles/816108-credit-configuration · retrieved 2026-08-08

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

Encryption and tokenization are asserted for every payment path - Supported Credit and Gift Processors describes each preferred partner as a '100% encrypted, tokenized direct integration' (Vantiv/WorldPay, Open Edge, Cayan/TSYS) and Credit Configuration adds 'all card data is tokenized (so card #s are never stored in your system)' and 'our data is encrypted at the time of the swipe' - and Thrive does point merchants at a public listing: 'The PCI Security Standards organization certifies payment processing applications for PCI compliance. Visit their site at https://www.pcisecuritystandards.org/assessors_and_solutions/payment_applications. Search for Granbury Restaurant Solutions as the company.' SHORTFALL: that listing is PA-DSS, a programme the PCI Council retired in October 2022, so it is not a current PCI DSS 4.x artefact. Across thrivepos.com and both documentation corpora there is no P2PE validated-solution listing, no PCI DSS 4.x Attestation of Compliance, no named SAQ type and no offer to supply one on request; PCI is otherwise invoked generically ('In version 8.0 and higher, some settings are restricted for PCI compliance'). Encryption remains the processor's, not a Thrive-validated P2PE solution. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-How-can-I-validate-that-Thrive-is-a-PA-DSS-Certified-application-for-PCI-Compliance · retrieved 2026-08-08

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

KPS Category / Item Setup: 'Navigate to Configuration > Items > Pizza > Specialty Pizza ... Click KPS on the sub navigation menu. Select the screen you would like to have the specialty pizzas display on from the Available Screens section and add them to the Selected Screens area' - routing is set at category or item level, and screens are named by the operator (kb 408232: 'Screen Names ... name your screen. Example: Kitchen or Pizza'). KPS Configuration adds 'you need to designate which KPS screen is used for each station by order type. This is done on the Printer Station configuration screen.' So item, category, station and order type routing are all documented, all inside Manager Home > Configuration with no vendor involvement. Revenue-centre routing is not a documented dimension; KPS screens themselves are a paid add-on ('This is an optional feature. If you have not purchased KPS screens ... contact your account manager'). https://thrivepos.uservoice.com/knowledgebase/articles/408304-kps-category-item-setup · retrieved 2026-08-08

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

KPS Configuration: 'Show Entire Ticket on Screen: If selected, the entire ticket will display on the screen. If not selected, only the relevant items will display.' That gives a consolidated single-order view on a designated screen (Printer Ticket Configuration, kb 408231, likewise contemplates 'an expedite printer' with its own ticket template). Shortfall: KPS Operations (kb 1139926) enumerates the screen modes as Select, Orders, Bump and By Item and each screen bumps independently ('Use the Enter button to bump an order off the screen when you've made it'); nothing in either KPS article ties an order's completion to every contributing prep station having bumped its items, and there is no documented cross-station completion state. https://thrivepos.uservoice.com/knowledgebase/articles/408232-kps-configuration · retrieved 2026-08-08

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

CLAIM: items assignable to courses and held, then fired to the kitchen on demand from a server terminal, handheld or expo screen. VERDICT: no. EVIDENCE: identical controls to order-capture-coursing-hold-fire over the same 372-article census - `coursing` 0, `hold and fire` 0, `fire course` 0 - with all `course` / `fire` / `hold` hits accounted for as poison. The KDS documentation that IS published (Cheftab KPS, department and category KPS display settings, Expo and box-cutting stations) enumerates display and routing settings and contains no course construct. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

CLAIM: per-item cook times are configurable AND the KDS staggers item start/display times so all items on an order finish simultaneously. VERDICT: no. EVIDENCE: across all 884 articles, 'cook time' 0 hits, 'cooking time' 0, 'make time' 0, 'preparation time' 0, 'fire time' 0, 'stagger' 0, 'staggered' 0, 'finish together' 0. The single tokenised 'prep time' hit is a DoorDash Drive support-contact line ('If a store needs to adjust hours or prep time'), i.e. a store-level marketplace setting, not a per-item field. Both halves of the claim therefore fail on a census, and the per-department and per-category KDS setting enumerations in the TCC menu articles contain no timing field at all. Thrive MEASURES production time instead of pacing by it: KPS Configuration says 'Tip: KPS can help you track your production times. See the Production Time report for analysis of how long orders take to make' (https://thrivepos.uservoice.com/knowledgebase/articles/408232-kps-configuration) and the KPS Operations article says 'One of the main advantages of the KPS is that it tracks production times, so you can report on efficiency'. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. https://thrivepos.uservoice.com/knowledgebase/articles/408232-kps-configuration · retrieved 2026-09-17 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

Quoted times move with load, but by measurement and by hand rather than by rule. Promise times default per daypart and order type, and 'sometimes when things get busy you will want to change the promise time on the fly... if you need to account for high customer volume (or lower) the slide bars allow you to set a new time', bounded ('Users will not be able to set the time below or above the default settings of the min and max times') and self-resetting ('at the change of a daypart, the times will automatically set back to the default daypart times'); the change reaches the ordering site - 'If you are using Thr!ve Online, once you click on "Save" or "Set to default" those changes will automatically update.' Underneath that, promise times are computed from measured throughput: 'Promise times calculate average production and deliver times', 'Current average production time, plus one way drive time are combined to reach the promise time', with an operator alert 'Alert If Promise Time Is Over X Mins Over Default'. There is also a blunt intake control - the Thrive Analytics app can 'turn off online orders during a rush or staffing shortage' and enable/disable individual online order types, taking effect 'almost immediately' for Thrive Online. SHORTFALL: every one of these is either a continuously recalculated average or a manual action. Neither corpus documents a configurable order-volume or ticket-time threshold that automatically paces, queues or delays release of incoming digital orders; the only documented volume cap, 'Max of X Orders Per Run... Enforce', limits driver runs, not kitchen intake. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Adjusting-Promise-Times-version-8-1 · retrieved 2026-08-08

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

A real pause exists, but it stops at Thrive's own channels. The Thrive Analytics app carries an online-ordering kill switch - 'Thrive Online enabled/disabled... This turns on or off online ordering for Company wide / Location Specific. NOTE: this will take affect almost immediately for the online ordering' - plus per-order-type enable/disable ('Toggling online order types enabled/disabled can take up to 10 minutes to affect a particular location'). Item-level 86ing likewise propagates automatically to Thrive Online only: 'Saving an item as "Out of Stock" will automatically update its status in Thrive Online as well.' SHORTFALL: neither reaches DoorDash, Uber Eats or Grubhub. Those channels are brokered by Deliverect, and Thrive states that the last hop is not driven from the POS - 'To get that pricing to the third party channels, you will need to sync from within Deliverect to the third parties as this feature isn't supported directly from the POS to the third party yet.' No article in either corpus documents a store-pause action that deactivates the store on a marketplace, and channel-side pausing is done in the Deliverect portal, which is the aggregator's product and not Thrive's. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Online-Ordering-Control-for-Analytics-App · retrieved 2026-08-08

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

Readiness events exist and are bump-driven, but they are addressed to the guest, not the marketplace. SMS Order Updates enumerates the triggers: "Order Ready: For all non-delivery order types, an order ready message is sent to the customer based on manual input", plus optional ChefTab KPS triggers - "Order in Oven... Upon bump of an order, the customer will be sent the following text message" and "Packaging Order... Upon bump of an order". Toward the delivery side the signal is a time, not an event: the POS sends Deliverect the promise time (release notes TPOS-9120 "Fixed bug where Deliverect received Promise Time for wrong Order Types", TPOS-7363 promise times when an order is not ASAP), and DoorDash Drive Integration has the POS send "the requested delivery time, so they can respond with an appropriate pick-up time... If the food will not be ready by this time, you can delay the pick up by selecting the # of minutes on this screen." Named shortfall: no KDS bump raises an order-ready callback to any third-party marketplace. Automatic marketplace status traffic is inbound only - DoorDash "will be updated automatically... the order will be closed automatically" once delivered, and cancellations pushed from the channel print and void in the POS (TPOS-7473) - and Deliverect orders are handed over already assigned to the channel's courier. https://granburysolutions.my.site.com/KnowledgeBase/s/article/SMS-Order-Update · retrieved 2026-08-08

KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.

kitchen-bump-bar-hardware

KPS (Kitchen Production System) Operations: 'The KPS system requires a monitor, a controller, and a bump bar' and 'The KPS system generally uses a bump bar which is an oversized keyboard substitute with just a few buttons. These buttons are programmed to control functions on the KPS.' The programmed keys are enumerated - LEFT ARROW (orange) scroll left, RIGHT ARROW (green) scroll right, ENTER (light yellow SP) select/bump/unbump, DOWN ARROW (blue) toggle bump screen, SPACE (red CTRL) back to Select. Two shortfalls against the claim as worded: bump-bar control is not 'in addition to touchscreen interaction' but instead of it - 'You can not control the KPS with a touch screen or a mouse. It requires the use of the bump bar or keyboard' - and no supported bump-bar make or model is documented anywhere in the 511-article Learning Center; the hardware is simply purchased from Granbury Solutions. https://thrivepos.uservoice.com/knowledgebase/articles/1139926-kps-kitchen-production-system-operations · retrieved 2026-08-08

An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.

kitchen-all-day-counts

KDS page cites 'customizable display options for orders, ads, and item tracking'. Whether 'item tracking' means a true all-day aggregate count is not established. https://www.thrivepos.com/k-d-s · retrieved 2026-08-01

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

Two configurable lateness models, both order-level. Table service: 'Navigate to Thrive Control Center > Configuration > Table & Bar > Table Settings. Set your table alerts to indicate your expected service time from seating to order, from order to settle, from settle to clear', each with colour escalation - the thumbs-up icon 'will turn red after the alert time', the fork/knife icon 'will turn from green to red', the $ icon likewise. Order types: 'Order Is Late After: Allows you to specify the # of minutes to allow before an order is considered late. Late orders are reported as such and are colored on the orders screen', plus 'Alert If Promise Time Is Over X Mins Over Default', with the release notes recording the three-state scheme 'Color coded orders. Late = Red, Nearly late = Orange, New = White'. SHORTFALLS: the configurable target is a service-stage or promise/lateness time per table or order type, never a cook target per prep station; the colour escalation lives on the POS table, orders and dispatch screens, and neither KPS article documents ageing colour on the makeline screens themselves; and no audible alert for an aged ticket appears in either the 511-article Learning Center or the 251-article Granbury KB. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Table-Service-Status-and-Alerts · retrieved 2026-08-08

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

CLAIM: if a KDS screen or kitchen printer goes offline, tickets AUTOMATICALLY fail over to a designated backup printer or screen with no ticket loss. VERDICT: no. EVIDENCE: across all 884 articles - 'backup printer' 0 hits, 'secondary printer' 0, 'spare printer' 0, 'printer offline' 0, 'printer failure' 0, 'printer error' 0, 'fail over' 0, 'reroute' 0, 'fall back' 0 - while 'printer' returns 338 hits and 'printers' 141 across the general printer setup, printer station configuration, printer ticket configuration and TCC print-routing articles, so the printing module is thoroughly documented. The single 'alternate printer' hit is the opposite of the claim: it is a MANUAL, permissioned operator action - 'Toggle print setting: Authorize this employee to activate an alternate printer setting' (https://thrivepos.uservoice.com/knowledgebase/articles/720465-security-settings-configuration) - matching the TCC print-routing article's named settings an operator switches between by hand. The 2 'failover' hits are one article about legacy online-order offer PLU matching ('Legacy OLO default offers / coupons and failover 8.1'), nothing to do with printers. No automatic fail-over and no no-ticket-loss guarantee exists in the vendor's documentation. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. https://thrivepos.uservoice.com/knowledgebase/articles/720465-security-settings-configuration · retrieved 2026-09-17 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 off the marketing KDS page onto product documentation. KPS is documented as a local-network application served by the on-premise Thrive server: 'Once connected in the kitchen, the KPS can be reached at this URL (this is based on our typical network setup - yours could vary if your network is set up differently) http://10.10.10.99/firefly/final//frontend/kps/'. KPS Configuration (kb 408232) sets 'Refresh Screen Every X Seconds: Controls how often the screen will check for new orders' - a LAN poll of the local server, not a cloud subscription. Store Setup Overview (kb 632761) reinforces that the POS is built to run with the line down: 'Enable Internet Functions: This allows the system to use the internet for functions such as customer address verification, delivery mapping, emails and alerts, and weather checking. Turn this off if your internet is temporarily down.' The 7.7.x outage contract enumerates the services an outage affects - SalesBuilder loyalty, Thr!ve Online / Let's Get menu updates, Dr!ve status updates, e-mail, mapping, card processing - and kitchen production is not among them. Shortfalls: no article states in terms that KPS continues to receive and display tickets during an internet or cloud outage, so continuity is inferred from the local-server architecture rather than documented; the vendor's ChefTabX marketing line, 'Independent screen operation eliminating single points of failure', is about screen-to-screen independence, not connectivity; and KPS is a purchased add-on requiring monitor, controller and bump bar. https://thrivepos.uservoice.com/knowledgebase/articles/1139926-kps-kitchen-production-system-operations · retrieved 2026-08-08

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

Build detail on the makeline stops at the item's included components, and the current TCC menu documentation enumerates exactly what a KPS screen can show: 'Department KPS: The KPS settings (Kitchen Display) allow you to specify which screens these items will appear on, if you use the Kitchen Display module. Settings include: Display Bold, Display Red, Display Included items (i.e. list all topping items), Exclude Sizes.' The same four settings recur at category and item level ('The KPS settings default from the department'), and KPS Configuration adds a per-screen 'Show Entire Ticket on Screen' toggle. SHORTFALL: 'Display Included items' is the whole of the build detail - it lists the toppings that come with the item. Neither corpus puts recipe steps, portion quantities or preparation instructions on a KPS screen; the recipe data that exists (Item Ingredients / Ingredient Tracking) is costing and usage reporting, not a makeline display. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Building-Menus-in-Thrive-Control-Center-Departments · retrieved 2026-08-08

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

Production tickets render fractional topping placement as labelled section groups. The 8.0 release notes record 'Resolved issue with Overall printing alongside 1st Half for fractional orders if nothing is on Overall'; the same headings appear in earlier fixes ('Resolved printing issues with Fractional Pizza with specialty as base, prints overall next to first half' and 'Resolved Fractional Printing Issues where occasionally Overall or 1st Half will appear with no items'), and 7.3.0 item 1115 states 'specialty pizzas can be in the overall with topping modifications on the 1st half and 2nd half'. Order A Fractional Pizza (kb 471541) confirms the underlying model - press F once for 1/2, twice for 1/3, three times for 1/4, with 'A' indicating toppings on All the pizza - so the ticket distinguishes Overall from each numbered section unambiguously. KPS screens render the same ticket lines (kb 408232 'Show Entire Ticket on Screen'). Caveat: the display is labelled text sections, not a graphical pizza diagram, and no article shows the makeline screen rendering itself. https://thrivepos.uservoice.com/knowledgebase/articles/1867636-version-8-0-legacy · retrieved 2026-08-08

A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.

kitchen-recall-refire

KPS Operations documents recall/unbump directly: 'If you need to Unbump an order, select it and use the Enter button (Light Yellow) to move it back to the main Orders screen.' Reprint Ticket (kb 1189915) separately documents reprinting production tickets to selected kitchen printers ('For kitchen printing, you will have the added option to select which kitchen printers to send the reprint to'). Shortfall: unbump/reprint both operate at the whole-ticket level — no article documents refiring or reprinting a single item independently of the rest of the order. https://thrivepos.uservoice.com/knowledgebase/articles/1139926-kps-kitchen-production-system-operations · retrieved 2026-08-04

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

Other Printing Options (Configuration > Printers > Printer Ticket > Other options) carries three revision controls: 'Print Entire Production Ticket for Revisions: If revised, will reprint the entire production ticket. Otherwise just the revised items print'; 'Automatically Reprint on Voids: Voids will automatically reprint the entire ticket when they occur'; and 'Auto Reprint on Changed Order Details: If order details such as order type, customer information are changed without any change to items, will reprint another ticket.' The 8.0 release notes confirm the isolate-the-delta behaviour - 'Revised Reprint Entire Ticket on Revision, if unchecked, only void items or additional items will reprint'. Shortfall: this is a print-path mechanism. Nothing in either KPS article documents a live KPS ticket visually flagging added, changed or removed items; the only KPS statement about post-bump edits is a 7.x bug fix, 'Resolved issues with some items not going to the KPS if order was previously bumped'. Edits are also visible to managers after the fact on the Full Review screen ('Track Adds & Edits to Tickets on the Full Review Screen', 7.7.x), which is a review tool, not a kitchen alert. https://thrivepos.uservoice.com/knowledgebase/articles/410417-other-printing-options · retrieved 2026-08-08

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

First-party guest order-status texting exists: 'Thrive POS now offers the ability to automatically send customers order updates via SMS Text Message', with a documented trigger list and hard-coded messages using [customername], [order#], [restaurantname], [promisetime] and [drivername]. Bump-driven triggers are documented for ChefTab KPS users - 'Order in Oven... Upon bump of an order, the customer will be sent the following text message: "Great news! Your order #[ordernumber] is cooking now and will be ready shortly."' and 'Packaging Order... Upon bump of an order... "we're boxing your order now! Your order #[ordernumber] can be picked up at [restaurantaddress] soon!"' It is configured per order type in TCC ('SMS Order Updates are turned on by order type so that unnecessary messages aren't sent for table or in-store orders'). SHORTFALLS, three: (1) it is not included by default - 'Once SMS Order Updates are licensed by support, Order Process messaging will become available for selection in Configuration>Order Types', and TCC 1.1.x records an 'Order Progress SMS Messaging Subscription', so it is a separately licensed subscription whose price is unpublished; (2) the literal ready message is not bump-driven - 'Order Ready: For all non-delivery order types, an order ready message is sent to the customer based on manual input'; (3) the two genuinely bump-triggered messages require a ChefTab KPS and a support-configured licence, and no app push or order-status display board is documented. https://granburysolutions.my.site.com/KnowledgeBase/s/article/SMS-Order-Update · retrieved 2026-08-08

Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.

kitchen-waste-logging

Inventory Adjustments documents recording waste/spoilage with a selected reason and optional note, depleting on-hand quantity ('quickly record waste, spoilage, transfers, and other changes to your on hand quantity... select a reason, and type a note if desired'); a separate Waste function on the Options screen sets item price to zero while creating the inventory deduction. Shortfall: this is a manager/back-office Options-screen and Inventory-Adjustments workflow, not documented as available directly at the KDS/kitchen screen — no KPS article mentions a waste-logging action from the kitchen display itself. https://thrivepos.uservoice.com/knowledgebase/articles/938937-inventory-adjustments · retrieved 2026-08-04

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

Production Time Report (Manager Home > Reports > Operations > Production Time): 'used in conjunction with the KPS Monitors ... you'll have data to analyze how long each station is taking to make the food ... The report will be broken into sections, 1 for each KPS screen you have set up. Each section will be divided into day parts. You can expand each daypart to see specific orders, and how long it took to bump that order. An average is calculated for the daypart and for the screen.' Station and daypart slicing with averages and per-order detail are therefore covered. Shortfalls: averages only, no percentile figures; no slice by order channel (order-type slicing lives on separate reports - Order Type By Interval, and the Store Summary's Sales by Order Type); and unlike most report articles in this Learning Center, which end with 'You can print and/or export the report to Excel', the Production Time article documents no export, and there is no public API - TicketStream is described as a data API for the DoorDash integration, with no published reference. Note the KPS itself is a paid add-on, so this reporting requires purchased KPS screens. https://thrivepos.uservoice.com/knowledgebase/articles/439839-production-time-report · retrieved 2026-08-08

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

Item Forecast Report (Manager Home > Reports > Trends > Item Forecast): 'If you are looking for a way to predict how many items you'll sell and what you need to order and prep for ... This report will use historical data to predict into the future exactly how many of each item you'll sell.' It shows the same weekday last week and the week before, then min/average/max over the past six weeks (the window is set in Sales Forecast configuration), then a forecast for today, today+1 and today+2 - the worked example returns 6.33 wings today. The article's stated use case is prep: 'A popular use for this report is to help plan dough preparation ... This can help us determine exactly how many dough balls to prep for each size.' The Deferred Item Sales Report (kb 439713) complements it from booked orders - 'how many items and $ sales are expected for each day, with a breakdown for each deferred time. This way you can plan for exactly how much you need to prep, when' - and can be printed or exported. Shortfall: both are manager-run reports with no generated prep list, no task or completion state, and nothing pushes them to kitchen staff as a daily prep list; the related Production Requisitions Report is documented as 'not yet available in Thr!ve - coming soon'. https://thrivepos.uservoice.com/knowledgebase/articles/439865-item-forecast-report · retrieved 2026-08-08

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

Native in-house driver module: 'Driver Dispatch & Tracking' plus 'Cash & Driver Control' tracking driver cashouts and delivery accountability, first-party not an add-on. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

Dispatch screen assigns deliveries and tracks driver activity 'with visibility into every run'. Multi-order run batching is not explicitly documented. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

delivery-route-map

Driver app provides turn-by-turn routing and restaurants 'view all driver locations in real time' on a map. System-generated multi-stop sequence optimization is not documented. https://www.thrivepos.com/en-us/features · 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

The capability is real and documented: DR!VE Overview states 'POS map of in process deliveries shows driver location (updated every 30 sec.)' and that the store can 'navigate to the dispatch screen in your POS and view a map that shows where all of your dispatched drivers are at any given time... by clicking In Process > Map All'. SHORTFALL: not part of the base product. The same article calls DR!VE 'a subscription product that can enhance your delivery service', and the published pricing page lists driver-app dispatch only under PIZZA PRO, the quote-only unlimited-terminal tier — it is absent from STARTER $99, DELIVERY PLUS $149 and THE WORKS $199. Live driver tracking is therefore a separately-priced add-on on a quote-only plan, not an included capability. https://thrivepos.uservoice.com/knowledgebase/articles/588228-dr-ve-overview · 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

Documented as free-form polygon on Google Maps: a lasso tool draws arbitrary areas, each saved zone is named and carries its own delivery charge and mile radius, with 'Charge By Zone' vs 'Flat Fee' selectable at Configuration > Order Types > Delivery. This also hardens delivery-zone-pricing from claim-level to documented. https://thrivepos.uservoice.com/knowledgebase/articles/499356-phone-orders-delivery-area-google-maps · retrieved 2026-08-01 adversarially verified

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

delivery-zone-pricing

'Delivery Zone Control - Set delivery areas, fees, minimums, and service rules by zone.' Per-zone quoted promise time not explicitly named. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

Phone Orders - Delivery Area (Google Maps) documents both address geocoding and zone rejection: 'as you type the street address, suggested addresses from Google will appear for you to select from,' and 'anytime an order is placed for delivery; the customer's address will be verified automatically. If the customer is outside of the delivery zone you will receive an alert stating they are not in the delivery area,' with 'a warning... at the bottom of the screen' and a manager-password override to allow the delivery anyway. https://thrivepos.uservoice.com/knowledgebase/articles/499356-phone-orders-delivery-area-google-maps · retrieved 2026-08-04

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

Driver app captures tips and the POS tracks driver cashouts; mileage capture and separate reimbursement-vs-wage payroll export lines are not documented. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

'Cash & Driver Control - Track driver cashouts and delivery accountability.' Explicit per-driver over/short figure not named but settle-up flow is documented. https://www.thrivepos.com/delivery · retrieved 2026-08-01

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

Native DoorDash Drive: 'just assign the delivery to DoorDash Drive like any other driver'; returns estimated cost and arrival time; works for web and phone orders. https://www.thrivepos.com/blog/solve-labor-problems-delivery-delays-with-thrive-doordash-drive-integration · retrieved 2026-08-01

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

Held to the highest bar per instruction. Manual assignment of an order to DoorDash Drive 'like any other driver' is documented on a vendor blog post; no configurable auto-overflow rule, no threshold, no fallback trigger appears in the blog or the public KB. Partial is the ceiling, and note the source is a vendor blog, i.e. claim-level, not product doc. https://www.thrivepos.com/delivery · retrieved 2026-08-01 adversarially verified

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

Vendor claims it 'directly integrates' with GrubHub, Uber Eats and DoorDash. Whether these are vendor-owned certifications or resold middleware is not disclosed; Thrive is absent from DoorDash's 2026 Preferred Integration Partner list. https://www.thrivepos.com/delivery · 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

Granbury's own knowledge base: "Deliverect is a 3rd party order aggregator that will integrate directly with your POS to sync menu items and insert orders directly into the POS from 3rd party order providers such as DoorDash and GrubHub." Injection is hands-off at the store: "Printers work the same as your Thrive Online Ordering. There is nothing to configure. Item Notes and Order notes print directly onto your tickets or KPS", the channel and channel order number print on the ticket, and "Can I Quick Close Deliverect orders? Yes! This works the same as a prepaid credit card." Menu upkeep is automatic, not a hand-off: "when you publish to your POS from Thrive Control Center, it will automatically update the items, including descriptions, prices, modifiers, etc to Deliverect." Named shortfalls: it is a separately purchased, order-metered middleware subscription ("The fee is a monthly charge per location... Low - up to 750 orders $99... Medium 750-1250 $149... High over 1250 $199") requiring POS 8.1.60+; the last hop is still manual - "To get that pricing to the third party channels, you will need to sync from within Deliverect to the third parties as this feature isn't supported directly from the POS to the third party yet"; and Pricing by Topping, tax-inclusive items and mixed item/modifier requirements are not supported to the channels. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Quick-Guide · retrieved 2026-08-08

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

delivery-menu-push

Cloud menu control claims updates propagate 'across POS, online ordering, and delivery platforms' and per-platform pricing tiers can be set; per-item sync status is not surfaced publicly. https://www.thrivepos.com/en-us/point-of-sale · retrieved 2026-08-01

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 and modifier 86ing syncs automatically, to first-party channels. TV - Out of Stock / Countdown (Version 8.1): 'Saving an item as "Out of Stock" will automatically update its status in Thrive Online as well'; restoration is symmetric ('To mark an item back in stock, simply turn OFF the out of stock indicator and save'); modifiers cascade to every item containing them as an inclusion; sizes and styles can be 86'd individually ('you've run out of dough for an individual size or crust'); and countdown reaching zero does the same, with resetting it clearing the flag. SHORTFALL: the documented destination is Thrive Online (and legacy Let'sGet), not DoorDash, Uber Eats or Grubhub. Those are brokered by Deliverect, and Thrive states the POS does not drive the channel hop - 'To get that pricing to the third party channels, you will need to sync from within Deliverect to the third parties as this feature isn't supported directly from the POS to the third party yet.' No item or item-option 86 is documented as reaching a marketplace, and no propagation latency is published. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Out-of-Stock-Countdown-Version-8-1 · retrieved 2026-08-08

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

The article enumerates its own control surface as exactly two options - '#1. Thrive Online enabled/disabled' and '#2. Allowed order types' - and 'This turns on or off online ordering for:' company-wide or location-specific, with 'NOTE: this will take affect almost immediately for the online ordering'. That is an in-document enumeration, not a corpus absence, so P3 does not bar it. Named shortfall: the pause reaches only Thrive's own first-party ordering site, there is no timed auto-reactivation anywhere in the option list, and the Deliverect book puts marketplace channel state in Deliverect's own console. partial, not yes. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Online-Ordering-Control-for-Analytics-App · retrieved 2026-09-04

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

Thrive segregates marketplace revenue by channel automatically: "Deliverect will send down a channel ID for each channel that submits an order. We use that channel name to match to a payment method so that all the payment will match up, but each channel must be put in manually. If no match to any channel, we default to Online" - the published channel list is UBER_POSTMATES, DELIVERECT, DOORDASH, GRUBHUB, UBER_EATS, FACEBOOK and CHOWNOW - and "if you setup a custom payment for the channel, such as DoorDash... your payments will be split out by channel as well" (Deliverect Q and A). For courier fees, DoorDash Drive Integration prescribes the arithmetic: "To reconcile the amount you owe DoorDash (or DoorDash owes you), take the cash amount collected as indicated above, and then subtract the Tips and Fees for DoorDash from the Delivery Performance Report", against DoorDash's "monthly invoice to reconcile money owed". Named shortfall: this is per-channel sales segregation plus an operator-performed calculation against the marketplace's own statement. Across both documentation hosts no report ingests marketplace payout deposits, itemises commission or marketing fees, reconciles refunds and adjustments, or flags missing or unpaid orders; the only fee figures Thrive holds are its own driver fees and the DoorDash Drive fee quoted at assignment. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Payment-Methods · 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

Two documented health surfaces, neither complete. In the POS, version 7.7.x added "active network monitoring for all the sites you might need to connect to - like Google maps, SalesBuilder, Thr!ve Online, Dr!ve, etc. If a site is unreachable, or if your internet is down, you'll be notified in the Instant Messaging section of your POS system", with outbound updates queued until connectivity returns. For the marketplace channel, Granbury's Deliverect Overview points the operator at the middleware's console instead: "you can simply go to the Deliverect Operations Report Tab to validate a sync has occurred. If you expand that report on the right, it will show details of what was done... any subsequent menu publishes will only display any changes that were published." Named shortfalls: the POS-side monitor watches Thrive's own services, not Deliverect or the marketplaces; the sync report is a menu-publish log in Deliverect, not a failed-order queue; and per-order ingestion failures are real but surface as support cases and release-note bug fixes rather than an operator view - "Invalid HTTP result from POS THRIVEPOS: 500 - {...\"path\":\"/pos/order\"}" and "Order Ingestion Failure Due to Missing PLU" (Deliverect Integration Releases; 8.2.x notes), with the vendor's instruction being "If any questions on setup or anything not functioning as described, please contact support and open a ticket." https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Overview · retrieved 2026-08-08

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' is marketed and drivers check in at arrival; a branded guest-facing tracking page on the restaurant's own domain is not explicitly documented. https://www.thrivepos.com/en-us/point-of-sale · 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

Phone Orders - Delivery (Configuration > Order Types > Delivery), Promise Times section: 'Promise times calculate average production and deliver times, allowing your employees to give customers an accurate estimate of when their order will arrive', and, on the Minimum Drive Time (One Way) field, 'This field is used in calculating customer promise times. Current average production time, plus one way drive time are combined to reach the promise time.' The quote therefore moves with measured kitchen throughput rather than being a fixed per-store constant, is floored by 'Minimum Promise Time (Breakfast, Lunch, Dinner)', can be hand-adjusted in 5-minute increments if 'Allow Editing Promise Time' is on, and raises an alert when it exceeds the default by X minutes. Shortfalls: the drive-time term is the configured Minimum Drive Time constant, not a live per-zone or traffic-aware drive time (the separate 'Traffic Radius' field only governs real-time traffic alerting on the dispatch screen), and driver availability is not an input - the Late Deliveries Report (kb 439837) likewise computes lateness by 'adding the 1 way average drive time to the dispatch time'. Deferred/online orders take a different path: the 8.x notes say online-order print time uses 'the longer of the lead time specified by the online site OR the default online order lead time'. https://thrivepos.uservoice.com/knowledgebase/articles/428690-phone-orders-delivery · retrieved 2026-08-08

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

delivery-offline-behavior

Version 7.7.x, 'Improved Tools for Internet Connectivity Problems', states the outage contract per service: 'If a site is unreachable, or if your internet is down, you'll be notified in the Instant Messaging section of your POS system. Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollments, transactions and redemptions, Thr!ve Online or Let's Get menu updates, Dr!ve status updates, E-mail notifications are all sent as soon as we have a connection. Other actions that can't be saved for later - such as mapping or driving directions, will time out quickly so as not to interfere with your POS processes. Credit card processing will still attempt to connect, and give you an authorize later option if a connection is not available.' Phone Orders - Delivery (kb 428690) adds an explicit operator instruction: 'If you do not have internet access, set Mapping to Inactive to prevent the system from attempting to validate the customer's address', and 'Verify Delivery Area' can be overridden by an employee with the right security. Card payment on a delivery taken during an outage is captured rather than refused: the 'authorize later' path above, with the held transactions authorized at batch close per Credit Batch - WorldPay Element / EMV (kb 1857904). Shortfalls: no article states in terms whether cash delivery order entry, driver assignment or driver settlement continue during an outage - they are local functions on an on-premise system, but that is inference, not documentation - and no offline duration limit or reconciliation-on-reconnect behaviour is published for the delivery module. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · retrieved 2026-08-08

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

'Fully branded, mobile-ready ordering site with unlimited orders — no per-order fees, ever.' Included in every plan from $99. https://www.thrivepos.com/en-us/features · retrieved 2026-08-01

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

digital-menu-single-source

Menus 'stay synchronized from the POS'; cloud menu control updates POS, online ordering and delivery platforms together. https://www.thrivepos.com/olo-mobile · retrieved 2026-08-01

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

digital-native-app

Native per-restaurant app builds are documented in Thrive Control Center's own release stream, not just marketed: 'TCC-402: Mobile app for TOL supported for 8.1 / TCC locations', 'TCC-1711 Updated endpoint to send App URLs only after mobile apps were built', 'TCC-1851 Expose Company's mobile app version and bundle id thru API', 'TCC-1859 Fixed Mobile app build status API endpoint returns false', and 'TCC-1687: Add form for Mobile Build only visible to Granbury employees.' A per-company bundle id and store URL is what an iOS/Android store submission requires, so the app is a real native build published under the restaurant's brand rather than a web shortcut. SHORTFALLS: (1) tier-gated - the branded mobile ordering app is sold as a DELIVERY PLUS ($149/mo) inclusion and is not in STARTER ($99/mo); (2) the build is operated by Granbury, not self-service - the Mobile Build form is 'only visible to Granbury employees'; (3) no end-user documentation exists for it in either corpus - nothing on app branding, push notifications or store submission - while Thrive's own online-ordering marketing also describes a 'fully mobile responsive website', so the app's feature parity with Thrive Online is undocumented. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Release-Notes · retrieved 2026-08-08

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

One-tap reorder and loyalty account registration imply guest accounts with saved payment; saved addresses and tokenization not explicitly documented. https://www.thrivepos.com/en-us/features · retrieved 2026-08-01

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

digital-upsell-engine

Rules-based suggestive selling at online checkout, configurable per item or per menu department. No personalization from order history and no attach-rate reporting. https://www.thrivepos.com/en-us/thrive-product-news/boost-your-ticket-average-with-suggestive-selling · retrieved 2026-08-01

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

Future/scheduled orders are documented (Create A Deferred Order, already scored yes on order-capture-scheduled-orders) with a configurable default online-order lead time, and 'when inserting an online order for print time, the system uses the longer of the lead time specified by the online site OR the default online order lead time.' Shortfall: this paces a single order's print time, not per-daypart capacity — no article documents a limit on the number of orders/items per time slot that automatically closes the slot once the kitchen is saturated. https://thrivepos.uservoice.com/knowledgebase/articles/676885-create-a-deferred-order · retrieved 2026-08-04

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

digital-fulfillment-modes

Pickup and delivery are clearly supported. Curbside with arrival check-in, and dine-in/QR table ordering, are not documented. https://www.thrivepos.com/olo-mobile · retrieved 2026-08-01

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

digital-qr-table

CLAIM: guest-facing QR scan-to-order and/or scan-to-pay at the table attaching to the existing POS check, including splitting and tipping. VERDICT: no. EVIDENCE: across the 372-article census `QR code` occurs in exactly ONE article and it is neither ordering nor payment: 'SB - What is the URL for customers to sign up for loyalty' says 'TIP: Use a QR code generator to turn this URL into a QR code image that can be placed on the restaurant's customer facing rear display' - a loyalty ENROLMENT link the operator makes himself. `scan to order` and `scan to pay` return zero. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

digital-kiosk

Thrive's kiosk is its own product with its own dated release stream (KIOSK RELEASE NOTES 0.1.21-0.1.25 and 0.1.26 and Up, latest 0.1.31 dated 1/14/2026), built on Thrive Online. Same menu and modifier logic as the POS is documented by the fixes themselves: 'Kiosk now follows TOL rules for available modifiers and adheres to EX OL rules set on items/modifiers' (0.1.25), 'Fixed bug where modifiers categories were not following sort order set in TCC>Kiosk Menu' (0.1.27), plus topping limits on topping-based items, nested requirement minimums/maximums, half toppings submitted as half toppings, and fractional pizza handling. Payment at the kiosk is documented: 'selecting a tender prompts payment, no Submit required' (0.1.25), 'Fixed an error when switching from Card payment to Cash' (0.1.30), 'Cash orders placed on Kiosk now come through as Pay Later', and 'Cash Discount for Kiosk'. Shortfalls: nothing in either corpus states the kiosk meets an accessibility standard - the only accessibility article, 'TOL: Accessiblity for disabled users', is about the Thrive Online website ('Thrive Online, in its base configuration, has passed these scans at a level AA compliance') and does not extend itself to the kiosk; and no article names the unattended EMV device or its certification. https://granburysolutions.my.site.com/KnowledgeBase/s/article/KIOSK-RELEASE-NOTES-0-1-26-and-Up · retrieved 2026-08-08

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

CLAIM: 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. VERDICT: no/B. Thrive's first-party guest ordering client, Thrive Online (TOL), was held in full and its cart, route and deep-link enumerations carry no participant, invite, shared-cart or spend-cap concept. BOUND (re-fetched live 2026-09-16 with a browser UA; the host 403s bot UAs): https://orderonline.granburyrs.com/slice/ 302s to index.html (6,569 bytes), which loads exactly four webpack files: vendor.48b8597e31d646d579eb.chunk.js (2,889,237 bytes), modern.83c8bca1a5ad16e5cf99.chunk.js (98 bytes, empty), app.419c06d297a040883238.bundle.js (1,015,748 bytes), polyfills.7fee97afccf640590276.bundle.js (1,724 bytes, the runtime), plus vendor/moment.js and moment-timezone-with-data.js. Checks that the four files are the whole client: the runtime defines no async chunk loader (no __webpack_require__.e and no jsonpScriptSrc); there are 0 import() calls and 0 '.chunk.js' references in any file; the five createElement('script') sites are jQuery globalEval, a reCAPTCHA loader, a JSONP helper and a setImmediate polyfill; the iframes are the Worldpay hosted payment page and Google Tag Manager. The PostHog snippet can only toggle code that is already in the bundle. OTHER SURFACES CHECKED: (a) the KB-announced new-site host orderonline.thrivepos.com/slice/ serves a byte-identical index.html with the same four hashed scripts. (b) The branded mobile app is this same page: index.html injects /slice/vendor[/mobile/vN]/cordova/<platform>/cordova.js when the UA matches /Thr!ve/. (c) /ThriveOnline/ is the admin, and the host root is a WildFly welcome page. (d) The kiosk is an in-store surface with no shareable link. (e) Third-party channels (DoorDash, Grubhub, Uber Eats via Deliverect; Thrive Connect/Stream) are aggregators, not Thrive features, and none is presented as a group-ordering partner. ENUMERATIONS in the app bundle: 95 API_*_URL constants (97 distinct /slice/ paths), including 31 /slice/cart/* routes (clear, coupon/add, coupon/byCode/add, getCart, getCartUpdatetime, historical/find, item/add, item/message/add, item/qty/set, item/remove, item/split, item/split/remove, item/withSize/add, items/remove, order/name/set, order/time/asap|check|set, order/type/set, reorder, required/add, required/instance/remove/all, required/no/choose, requirements/change, status/check, style/add, tender/set, toppings/change, user/set (a single user), zone/remove, zone/set). None adds a participant, issues a share or invite token, or sets a spend cap. There are 30 router path literals and none is a join or group page. The deep-link params read are accountId, appPassword, locationId, modernThemeColors, offerId, orderId, orderType, route, source, customizeTheme, locationFinder and token (password reset); none is a cart or group token. item/split is pizza half-and-half, not a payment split. CONTROLS (tokenised, case-insensitive): over the 5 held client files (3,884,004 chars): group order/ordering 0, groupOrder 0, office order 0, party order 0, team order 0, shared cart 0, invite(s/d/ation) 0, participant(s) 0, guest(s) 0, friend(s) 0, per person 0, spend limit/cap 0, split payment/bill/check 0, catering 0, ezCater 0. Over all 257 www.thrivepos.com sitemap URLs (256 at 200) plus 29 linked pages missing from the sitemap, including /olo-mobile (the 'Online & Mobile Ordering' product page): group order 0, office order 0, team order 0, shared cart 0, participant 0, per person 0, spend limit/cap 0, ezCater 0. Over the 253-slug Granbury KB (251 live): group order/delivery/pay 0, large group 0, shared cart 0. POISON found and excluded: 'group' in the app is Tailwind/Bootstrap CSS classes (group, form-group, group-hover) and coupon requirement groups (groupType DEPARTMENT/CATEGORY/ITEM); 'share' is 'Share your order on social media:' and 'do not share your password' in the app, and core-js 'shared' in vendor; 'party order' on marketing and KB is 'third-party order'; 'invite' on marketing is blog prose; marketing 'catering' (16 docs) is blog advice, the Pizza Inn case study and a Restaurant 365 page, with no catering or group ordering flow; KB 'split check/payment' is staff-side POS split tenders and Split Ticket, and the closest KB item remains staff-built Customer Subtotals ('You must pay for all subtotals at once'). The KB is NOT a census (52 of 251 live articles are in neither the sitemap nor the link graph), and the marketing sitemap is a strict subset of its own links, so neither is relied on for the no; they are corroboration only. SCOPE: bounds Thrive's first-party guest ordering (TOL web on both hosts plus the branded Cordova app). The native app shells were not downloaded. Grade B because this is a minified UI bundle, not vendor prose. Retrieved 2026-09-16. https://orderonline.granburyrs.com/slice/app.419c06d297a040883238.bundle.js · retrieved 2026-09-16 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

The catering pieces Thrive does document are POS-side and the vendor names them as such. Deferred Order Defaults in Config > Order Types (kb 428690): 'Lead Time: Defaults the deferred print time to the selected number of minutes prior to the customer want time', and 'Active Serving Time: If checked, activates a field that will ask you to enter the Serving Time for the deferred order ... This can be used for catering / bakery type orders where delivery may occur in advance of planned serving time.' Deposits use the generic Paid In function - 'if you're catering an event and require a deposit you can log it as a Paid In' (Paid In/Out article). Invoicing uses Customer Accounts - 'a great way to track customer purchases and invoice them later. This is popular for business and school orders as well as catering' (kb 1960294 / 575088). Planning uses the Deferred Item Sales Report (kb 439713) - 'If you do a lot of catering orders, this report is for you!' Shortfalls, all material: there is no distinct catering ordering flow for guests - Tracking your Catering Sales (kb 945445) concedes 'You can't necessarily designate an order type for Catering' and the vendor's own workaround is to name items with the word 'Cater' so reports can bucket them; there is no separate catering menu, no order minimum specific to catering (only a per-order-type Minimum Order Amount), no quote or proposal artifact, and no ACH or stated payment terms beyond a generic house account. https://thrivepos.uservoice.com/knowledgebase/articles/428690-phone-orders-delivery · retrieved 2026-08-08

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

CLAIM: AI voice phone ordering, native or a named certified partner, answering inbound calls and injecting the order into the POS without staff transcription. VERDICT: no. EVIDENCE: over the 372-article census the tokenised case-insensitive controls `voice ai`, `ai voice`, `IVR`, `speech`, `conversational ordering` and `transcription` return ZERO files each; over the 255-page site crawl `voice AI` and `AI voice` are also zero. The vendor's own closed partner enumeration at https://www.thrivepos.com/integrations names seven software integration partners and none is a voice agent. The telephony Thrive does document is human: caller-ID assisted answering, plus the separately announced call-centre partner Kanekt 365 (https://www.thrivepos.com/en-us/thrive-product-news/new-partnership-call-center-services-kanekt365), which is staffed order-taking - the opposite of the claim. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://www.thrivepos.com/integrations · retrieved 2026-09-17 adversarially verified

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

digital-drivethru-ai

CLAIM: AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers, with escalation-to-human handoff. VERDICT: no. EVIDENCE: the regex `drive.?thru` and the phrase `drive through` return ZERO files across the entire 372-article census - the current documentation set does not mention the drive-thru at all - and `voice ai` / `ai voice` / `IVR` / `speech` are likewise zero. No drive-thru AI partner appears in the seven-name integration enumeration. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

digital-sms-ordering

Thrive has a first-party outbound SMS channel but not a conversational one. 'Automatic SMS Order Updates in Thrive POS' (Apr 7, 2026) documents order-status texts fired on Order Placed, Order Dispatched, Order Ready, Order Complete and Order Cancelled, plus optional ChefTab KPS bump triggers ('Order in Oven', 'Packaging Order'), licensed by support and toggled per order type in Configuration > Order Types. The article states the limit explicitly: 'While the content of each SMS message is pre-defined and hard-coded, some variables exist that may change one message to another' - [customername], [order#], [restaurantname], [promisetime] and the rest - and the only inbound keyword handled is 'reply STOP anytime to opt-out.' Separately, Thrive Advanced Loyalty 'communicate[s] with customers via e-mail and text', and a phone-only enrolee 'will receive a text link to complete their profile', so text-a-link exists as a marketing mechanic. Shortfall: nothing in either corpus documents a guest texting an order or a reorder that lands in the POS; there is no inbound message parsing, no conversational agent and no text-to-order menu. https://granburysolutions.my.site.com/KnowledgeBase/s/article/SMS-Order-Update · retrieved 2026-08-08

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

Vendor-endorsed but merchant-DIY. Thrive's own blog walks the operator through Google Business Profile > Food Ordering > 'Accept Orders on Your Profile', then 'Select your preferred provider from the list and click Set as Preferred', concluding 'By setting your internal POS online ordering as the preferred option, your customers can place orders directly through Google without needing to visit other websites or apps.' Named shortfall: the merchant self-configures the Google Business Profile — no Thrive-side provisioning of the ordering link is documented anywhere, and the source is a marketing blog, not product documentation. https://www.thrivepos.com/blog/keep-more-pay-less-prioritize-your-pos-system-over-third-party-delivery-channels · retrieved 2026-08-04

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

CLAIM: Apple Business Connect ordering placement - an 'Order Food' action on the Apple Maps place card pointing at the vendor's first-party ordering flow. VERDICT: no. EVIDENCE: `apple business`, `apple maps` and `place card` return ZERO files across the 372-article census and zero across the 255-page site crawl. Non-vacuous: the census documents Google Business Profile promotion and Google Tag Manager configuration for Thrive Online, so third-party listing surfaces are within the documentation's scope and Apple's is not among them. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

digital-loyalty-attach

KB: with loyalty integrated in SalesBuilder the Thrive Online checkout screen shows the 'Yes I want to join' option on every guest checkout (default on, switched in TCC > Configuration > Marketing > Thrive Loyalty > 'Online Loyalty Sign up at Checkout'), and appending &route=rewards to the ordering URL takes the guest 'straight to Thrive Online to log in & see their rewards page' to use the offer attached to their loyalty message; &route=register creates the online-ordering account and the rewards enrollment 'in 1 step'. Same identity as in store, where 'Prompt with Available Offers' pops the same SalesBuilder offers at the POS. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TOL-Direct-Link-to-Loyalty-Rewards-Page-Loyalty-Coupon-Walk-Through · retrieved 2026-08-08 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

CLAIM: guest subscription / membership programs - recurring billing for a delivery-fee waiver, a per-period entitlement, or a paid loyalty tier - managed in the platform. VERDICT: no. EVIDENCE: `membership` and `recurring billing` return ZERO files across the 372-article census; `subscription` returns two files and BOTH are the vendor billing the OPERATOR ('Disable Kiosk locations when the subscription is inactive in TCC'; 'Added Order Progress SMS Messaging Subscription and Cheftab to SalesForce'). The loyalty documentation that is published - Thrive Basic Loyalty, Advanced Loyalty / SalesBuilder configuration, user-defined fields and groups - enumerates points, offers and groups and contains no paid tier or recurring guest charge. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · 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

Coupons are managed centrally in the cloud Control Center and promo offers link into online ordering, implying shared definition; channel eligibility controls are not documented. https://www.thrivepos.com/en-us/location-management · 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

Customer Advanced Search Marketing (v8.1+): after segmenting on criteria such as First Order Date, Items Ordered, Number of Orders or online spend, 'you can export, merge, apply an offer, or delete. Select all the customers in the list by checking the box at the top of the results ... Pressing Export will download a .csv file with customer details.' The mapping article adds the field choice - 'click Output List and choose Export Mailing Info to .csv. Check the bottom two checkboxes to make sure you get all the data ... If you export Customer Details instead of just mailing information, you will have additional data fields ... such as total orders and total $ spent.' The 7.8.x notes confirm the permission model: 'Merge, Delete and Export can be done from the POS customer search (with proper security)'. So bulk export is self-serve, unlimited in the docs, and needs no vendor action or fee. Shortfalls: the claim's ownership half is undocumented - no MSA, terms of service or data-processing addendum is published by Granbury Solutions stating that the operator owns first-party guest records, matching this record's existing findings on commercial-data-ownership-clause; consented-marketing status is only partly represented (a 'Mailing List' flag and a reply-YES SMS opt-in held in SalesBuilder rather than the POS, and 'Customers w/Mobile Opt In: This field is not used in Thr!ve'); and the export carries summary attributes such as total orders and total spend, not the order-line history, which is viewable per customer (kb 970297) but not documented as exportable in bulk. https://thrivepos.uservoice.com/knowledgebase/articles/1960300-customer-advanced-search-marketing-version-8-1 · 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

The architecture half is documented, the attestation half is not. Thrive Online takes card payment on a vendor-hosted form: 'Client was just set up or switched to Thrive payments (WorldPay express) and the hosted payment form will not appear in Thrive Online ... Account must be set up for PAAS / tokenization to allow hosted payments' - so card entry happens on the processor's hosted form under tokenization, not on the restaurant's page. Shortfalls, both material: the only compliance attestation Thrive publishes is the obsolete predecessor standard - 'TV - How can I validate that Thrive is a PA-DSS Certified application for PCI Compliance?' directs the reader to search 'Granbury Restaurant Solutions' in the PCI SSC validated payment applications list, and PA-DSS was retired in 2022 - while 'PCI DSS 4', 'script integrity' and the 6.4.3 / 11.6.1 client-side requirements effective March 2025 return zero hits across both the 511-article Learning Center and the 251-article Granbury KB; and '3DS' and '3-D Secure' likewise return zero hits, with no SCA or step-up authentication described in any TOL release note through 5.0.36 (2026-04-22). https://granburysolutions.my.site.com/KnowledgeBase/s/article/TOL-Hosted-Payment-Form-does-not-appear-on-a-new-Thrive-Payments-set-up · 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

Channel-differentiated pricing and dual pricing are documented on digital channels; guest-facing disclosure and jurisdiction handling are not. Channel pricing: the third-party pricing scheme is a first-class TCC concept - 'Deliverect will utilize the pricing scheme from TCC that is set to 3rd Party Default to build the menus from', and the POS setting 'Combat the high fees of 3rd party sites like UberEats and GrubHub by charging higher menu prices for these integrations.' Dual pricing reaches the kiosk: 'TOL-5234 Cash Discount for Kiosk' and 'TPOS-8609 Fixed bug where cash discount price was showing as normal price in POS' (KIOSK 0.1.25, 7/17/2025), with the configuration gated in TCC - 'TCC-2056 Added toggle in Credit and Gift Cash Discount' and 'TCC-2085 Hide Cash Discount Offer from Non-GRS employees if offer has been editted. Offer only accessible from Credit/Gift Settings.' Card surcharging itself remains a tender-type-restricted offer evaluated at tender time ('Tender Types - Offer will only be valid if certain tender types are used. This is for setting up a cash discount or credit surcharge'), still live in the current stream ('TPOS-9706 Fixed bug where Split Credit Card Payments caused incorrect surcharge values'), with disclosure only at the terminal rear display. Shortfalls: no guest-facing online disclosure text, no jurisdiction table and no card-brand exclusion logic appears in either the 511-article Learning Center or the 251-article Granbury KB - the only jurisdictional engine published is Tax Rates by Zone (POS 8.3.40), which varies sales tax by delivery zone and says nothing about where surcharging is prohibited. https://granburysolutions.my.site.com/KnowledgeBase/s/article/KIOSK-RELEASE-NOTES · retrieved 2026-08-08

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

Shortfall: no automatic identity merge, and the POS merge does not reach the loyalty engine. KB: 'sometimes, duplicate records can get created' - the operator selects records in POS customer search and presses Merge, choosing a Primary; 'Any point balances will be added to the primary record and order history will be merged', but 'If these customers have different e-mail addresses they may have different loyalty accounts. Merging them in the POS will not impact SalesBuilder accounts... SalesBuilder offers / points will not be merged through this action.' In-store and online do share one customer record when the guest registers through Thrive Online, and Advanced Search exposes an 'Order Channel = Online' filter on that record. https://thrivepos.uservoice.com/knowledgebase/articles/1960297-merge-customer-records-version-8-1 · retrieved 2026-08-08 adversarially verified

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

guest-loyalty-thirdparty-identity-attach

Marketplace orders do attach to customer records. Granbury's POS release notes, 8.1.65 (01/10/2024): "TPOS-7910 Fixed Bug Where Customers from Deliverect Were Being Linked to The Same Customer Account" - i.e. orders arriving from the Deliverect channels (DoorDash, Grubhub, Uber Eats, Postmates, ChowNow) each resolve to their own customer account in Thrive, and the defect was that they collapsed onto one. The originating channel is tracked separately from the guest: "the ordering channel will be recorded in the POS... Additionally the ordering channel will be displayed as the 'Server' in order lookups and print the channel on the tickets with the channel order number" (Deliverect Q and A), and TPOS-7245 added "3rd Party Channel as Server on the Order Lookup Screen for support of Deliverect". Named shortfall: no article states WHICH identity fields the marketplace supplies (name, phone, address; marketplaces commonly mask contact details), whether an arriving order is matched against an existing Thrive customer or creates a duplicate - the only documented merge path is the manual Merging Customer Records screen - or that SalesBuilder loyalty enrolment and offers can attach to a marketplace-sourced guest. The identity exists; its usability is undocumented. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-POS-Release-Notes-8-1-57-and-up · 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

All three models are configuration. Points-per-dollar: TCC > Configuration > Marketing > Customer Loyalty > Basic - 'set your point ratio. Here we earn 1 point for every $1 spend, and can redeem 10 points for $1 off the ticket', plus Point Bonus rules by item, day of week, time of day, first order or online order. Visit count: SalesBuilder's Visits trigger - 'X - message will send after customer reaches X visits... set the z value to Y' to repeat on multiples of X. Spend tier: Program Levels - name a level, set 'the amount of points earned for each $ spent', auto-enroll on 'the amount of spending required over the time period', with nightly downgrade evaluation. SalesBuilder is the vendor's own loyalty engine, not a bolt-on, and no custom development is involved. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Marketing-Thrive-Basic-Loyalty · retrieved 2026-08-08 adversarially verified

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

guest-loyalty-tiers

Thrive Loyalty / SalesBuilder documents a 'Point Level Expiration' campaign trigger, 'used in conjunction with program "levels" which can put customers on different campaigns automatically based on their historical spend. Since this level can be re-evaluated on a periodic basis, you can use this trigger to let customers know that their level is nearing expiration' - i.e. automatic level assignment from spend, periodic re-evaluation, and demotion by expiry. Shortfalls: levels are described only incidentally inside one trigger definition and have no configuration article anywhere in the 8-topic SalesBuilder knowledge base ('Managing Your Point Settings', kb 300684, covers only point ratios, bonus days and reward thresholds and never mentions levels), so the promotion/demotion window is not documented; and this is the separate paid SalesBuilder module (bundled from the $199/mo 'The Works' plan), not the POS's internal loyalty program, whose configuration screen (kb 439050) enumerates every option - earn/redeem formula, expiry days, minimum redemption, bonus point rules by day/time/order type/item - with no tier construct at all. https://grsalesbuilder.uservoice.com/knowledgebase/articles/905961-use-campaign-triggers-to-automatically-send-messag · 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

Version 7.7.x release notes explicitly document queue-and-reconcile behavior: 'Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollments, transactions and redemptions... are all sent as soon as [you] have a connection.' Non-deferrable actions (e.g. mapping/driving directions) 'will time out quickly so as not to interfere with your POS processes,' and credit card processing offers an 'authorize later' option when offline — giving a clear queue-vs-timeout distinction across the platform, with loyalty explicitly named as a queued category. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · retrieved 2026-08-04

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

guest-loyalty-offer-stacking-rules

Creating A Coupon documents two exclusivity controls: 'Not Valid With Other Auto Offers' (excludes this coupon from combining with other auto-apply offers) and 'Not Valid With Other Offers' ('you can prevent this coupon from being valid with other offers on a specific item, the entire order, or any other specific coupon types') — explicit exclusive-vs-combinable configuration. Shortfall: no order-of-application or precedence rule is documented for when multiple eligible, combinable offers could apply to the same order — the controls only prevent combinations, they do not sequence them. https://thrivepos.uservoice.com/knowledgebase/articles/566835-creating-a-coupon · retrieved 2026-08-04

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

KB (8.1+): Advanced Search adds criteria including 'First Order Date', 'Number of Orders', 'Amount Spent', 'Items Ordered' and 'Order Channel = Online', combined with AND/OR, and the criteria set can be saved and re-run ('Keeping it generic is great if you plan to reuse this criteria next month'); 'Now that you have a segmented list... you can export, merge, apply an offer, or delete.' The older Manager > Customer Advanced Search adds last-order date, ticket average, daypart, void count and '% of orders using a special pricing offer', with Save/Load Criteria. In SalesBuilder, a triggered campaign message carries 'Limit To Customers From List' and 'Exclude Customers From List' - the documented example limits a birthday offer to customers who ordered in the past 90 days. https://thrivepos.uservoice.com/knowledgebase/articles/1960300-customer-advanced-search-marketing-version-8-1 · retrieved 2026-08-08 adversarially verified

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

guest-loyalty-rfm-segmentation

The v7.8.0 release notes ship the lifecycle segments as presets: 'Added some preset advanced customer search criteria to help you with common marketing queries. Navigate to Manager Home > Customer > Load Criteria button ... to select from searches like "Big Spender: Ticket average > $30", "New Customer Last 30 days", "Regular: 6 or more orders in last 4 months"', and the Manager-Customer topic carries a 'Marketing To Lazy Customers' walkthrough for the lapsed segment. On the loyalty side SalesBuilder fires 'Lost Customer' (after a period without transactions), 'Visits', 'All time spending award' and program-level triggers with no query authoring. Shortfalls: these are on-demand saved searches and message triggers, not a computed RFM score or lifecycle label stored on the guest record and visible as a segment set; anything outside the four shipped presets is operator-built criteria in the Advanced Search builder (kb 1960300); and there is no at-risk/churn model - 'lapsed' is a fixed days-since-last-order filter. https://thrivepos.uservoice.com/knowledgebase/articles/429421-version-7-8-x · retrieved 2026-08-08

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

SalesBuilder campaign triggers, each parameterised by X/Y/Z: 'Welcome: this is sent when a customer is first enrolled in the campaign'; 'Web Signup Welcome'; 'Activation'; 'Birthday: this is sent prior to the customer birthday. You can specify how many days prior using the X variable'; Half Birthday, Extra Birthday, Anniversary; 'Lost Customer: sent after time has passed since the last transaction... Many programs will include several Lost customer messages with escalating offers for longer periods, such as 30, 60, 90 days'; plus Point Certificate, Point Balance, Visits and Transaction Value. These hang off the default campaign every customer is auto-enrolled in, so they fire without a manual send. https://grsalesbuilder.uservoice.com/knowledgebase/articles/905961-use-campaign-triggers-to-automatically-send-messag · retrieved 2026-08-08 adversarially verified

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

The configuration article states it directly: 'Thrive Advanced Loyalty takes advantage of our SalesBuilder loyalty engine to issue offers to customers based on behavior triggers, and communicate with customers via e-mail and text. These offers are available in store and online.' Setup is in-platform - Configuration > Marketing > Customer Loyalty, select Advanced, then enter the SalesBuilder company and location IDs in the Thrive Loyalty section - and the SMS half is a first-party toggle: 'Allow mobile phone # without email - if ON, customers can join with just a mobile phone and will receive a text link to complete their profile. They will receive campaign messages via text. Texting must be activated in your account for this to be valid.' Campaign composition and the trigger set live in SalesBuilder, Thrive's own loyalty product, not a third-party ESP the operator brings. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Marketing-Thrive-Advanced-Loyalty-SalesBuilder-Configuration · retrieved 2026-08-08

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

SMS loyalty enrollment is documented as double opt-in: staff confirm the number is a mobile and 'The customer must reply YES to the text (opt-in) to complete enrollment' (external SalesBuilder loyalty, v7.8+). Shortfall: no documentation of per-channel consent records with timestamp and source of consent, and no documented handling of revocation received by means other than the SMS keyword — the Learning Center describes the opt-in flow but says nothing about how revocation is honored across channels. https://thrivepos.uservoice.com/knowledgebase/articles/1189906-using-the-external-salesbuilder-loyalty-program-v · retrieved 2026-08-03

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

guest-loyalty-10dlc-registration

Positive absence in the exact document where the disclosure would live, and a near-miss worth stating plainly. Thrive does send guest SMS on the operator's behalf - the SMS Order Updates release describes customers 'automatically receiv[ing] text updates about their order status, from the moment it's placed to when it's ready or on the way', with 'no manual texting' - so A2P 10DLC brand and campaign registration is in scope for its operators. But the only SMS terms Thrive publishes run the other way: they govern 'automated SMS business notifications to restaurant operators and owners who have opted in during merchant account onboarding', covering platform alerts, support ticket updates and billing notices, with STOP/START/HELP handling for the merchant's own number. A2P, 10DLC, brand registration and campaign registration appear nowhere in that document, nor anywhere in the 250-URL site or the 511-article Customer Learning Center. https://www.thrivepos.com/en-us/sms-messaging-tos · retrieved 2026-09-04 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

Customer Credits Summary Report documents a Redemption Rate ('the percentage rate of offers that have been credited'), and text campaigns are described as able to 'link directly to Thrive POS promo offers and online ordering.' Shortfall: this reports redemption volume/rate per offer, not incremental sales — no article ties a redeemed campaign offer to the actual check total it produced or nets it against a control/baseline, which is what the claim requires. https://thrivepos.uservoice.com/knowledgebase/articles/439807-customer-credits-summary-report · retrieved 2026-08-04

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

Customer Advanced Search documents a self-serve Output List export: 'Export mailing info to .csv: Creates a file with just address fields', 'Export detailed info to .csv: Creates a file with all fields', plus mailing labels, a printable report and 'Export e-mail addresses' - all performed by the operator in-product, with no support ticket or vendor fee mentioned. Named shortfalls, both first-party: the loyalty-side export truncates, per 'SB - Export customer list does not include all results' - 'SalesBuilder export has a limit of approximately 34,000 customers. If your list is larger than that, it will be truncated. You may need to run the export on fewer locations at a time to keep each file under 34,000 customers, then combine them in Excel'; and the POS export narrows the guest list by default - 'Include no mail list customers - By default, any customer who is not opted-in for marketing mailings will not be included in the output' and the same for customers with an incomplete address - so a full list requires the operator to tick both boxes. Whether 'detailed info' carries full transaction history and loyalty point balances is not stated in the article, and no API export path is documented on either side (CSV only). https://thrivepos.uservoice.com/knowledgebase/articles/952507-customer-advanced-search · 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

An outbound event stream exists and is first-party documented in the release notes: 'Thr!ve Ticket Stream: We've added components to Thr!ve to enable the system to submit data about orders, timeclock events, paid in / out, end of day deposit to Ticket Stream, our cloud-based future reporting platform. Ticket Stream will also offer an API for 3rd party integrations' (v7.5.x), later 'TicketStream is our cloud-based reporting engine used for API access to POS data' with enumerated feed changes - 'Add Customer Group to customer data on order feed', 'include customer info in the dispatch report', 'Added a data feed event when a ticket is Assigned / Dispatched', 'Added Category ID and Name to Order Feed Item Section' - and by v8.0.30 the DoorDash Drive integration requires the store to be 'configured to use TicketStream, our new data API' (kb 1922671). Shortfalls: nothing is published that a CDP could subscribe from - no endpoint, no auth model, no event catalogue or payload schema, no subscription or webhook interface, and no self-service enablement (the DoorDash article tells the operator to phone Granbury support to have TicketStream turned on). No CDP or marketing platform (Olo, Punchh, Bridg, Klaviyo) is named anywhere in either knowledge base. https://thrivepos.uservoice.com/knowledgebase/articles/429421-version-7-8-x · retrieved 2026-08-08

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

Thrive Loyalty / SalesBuilder documents both halves of the capture-and-branch mechanic. 'Customer Satisfaction Survey: sent when a transaction is received. You can specify the minimum transaction amount using the "X" variable, and the minimum # of days between surveys per customer using the "Y" variable. The survey is no longer available after 40 days.' And 'Completed Survey: sent when a completed survey is received from a customer. If you wish to limit the message to customers who score you >= X, enter the numeric score in the X box (scores are typically from 1 - 4 with 4 being high). Use the "Z" field to enter < or = or another operator to evaluate score' - so a low-score branch and a high-score branch can be built. Shortfall: both branches terminate in a SalesBuilder email/text message with an attached offer. Searched both published documentation corpora - the 511-article UserVoice Learning Center and the 251-article Granbury KnowledgeBase where the current 8.2/8.3 product is documented - for any handoff to a public review site or a service-recovery queue: none exists. The closest current-generation surface is TCC - Marketing - Social Media, which is an untargeted static link block on the online-ordering confirmation page ('Enter your page names for Facebook, Yelp, Twitter and Instagram. These will be displayed on the final confirmation page ... This is a great place to ask for reviews!'), shown to every guest regardless of score. The operator gets a segmented send, not a review-gating funnel. https://grsalesbuilder.uservoice.com/knowledgebase/articles/905961-use-campaign-triggers-to-automatically-send-messag · retrieved 2026-08-08

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

Thrive Loyalty / SalesBuilder point settings: 'Bonus points can be issued for a number of actions, including completing a customer satisfaction survey, referring customers (at sign up and/or at 1st transaction) and for completing their profile. Residual points are issued as a % of normal points. These are given to the referring customer when their referral spends money.' That is first-order attribution plus an ongoing revenue share to the referrer. The referred side is rewarded by the 'Member Referral' campaign trigger - 'sent to any new member referred by a customer via the customer survey or their personal referral page. Set the offer expiration using the "Y" variable' - which also establishes the per-guest referral link. A parallel Affiliate mechanic (kb 297563) gives schools, teams and clubs their own PURL sign-up page with member association and point rewards at set levels. Scope note: this is the SalesBuilder / Thrive Loyalty module, bundled from the $199/mo 'The Works' plan; the POS-internal loyalty program (kb 439050) has no referral construct. https://grsalesbuilder.uservoice.com/knowledgebase/articles/300684-managing-your-point-settings · retrieved 2026-08-08

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

CLAIM: issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance. VERDICT: no. EVIDENCE: `wallet`, `apple wallet`, `google wallet`, `pkpass`, `loyalty pass` and `digital pass` return ZERO files each across the 372-article census. Non-vacuous: `apple pay` (2 files) and `google pay` (1 file) DO appear, as contactless acceptance at the EMV terminal, so the vendor's Apple/Google vocabulary is present in the corpus and only the wallet-pass sense is absent. The documented loyalty credentials remain a magstripe swipe card, phone/email lookup and the branded app. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

'Customer Advanced Search Marketing (version 8.1+)' documents admin-side access and deletion over an arbitrary customer set: build or load criteria, then 'now that you have a segmented list ... you can export, merge, apply an offer, or delete. Select all the customers in the list by checking the box at the top of the results. Use the functions at the bottom of this screen to apply an offer, delete, or merge ... Pressing Export will download a .csv file with customer details.' Shortfalls: this is a general marketing screen, not a documented CCPA/CPRA request workflow - there is no request log, no identity-verification step, no response-deadline tracking, and no statement of what the export contains relative to a statutory access request. Critically, nothing documents deletion propagating outward: the SalesBuilder loyalty/marketing database is a separate system, and its own knowledge base offers only 'How Customers Can Opt-Out' (unsubscribe, 'a guest can always text the word STOP'), not erasure, so a POS-side delete is not shown to remove the loyalty and campaign records. thrivepos.com/en-us/privacy-policy commits Granbury only as processor acting 'in accordance with the instructions of such customers'. https://thrivepos.uservoice.com/knowledgebase/articles/1960300-customer-advanced-search-marketing-version-8-1 · retrieved 2026-08-08

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

Manual point adjustment is a gated, semi-logged action: the security workgroup matrix includes a customer-points permission (kb 720465), and the Adjust Points screen shows 'all of the customer's previous point history' and lets staff 'add a note as to why you are making an adjustment'. Shortfall: the adjustment note is optional, and no redemption velocity limits, employee self-redemption flagging, or dedicated loyalty audit report are documented. https://thrivepos.uservoice.com/knowledgebase/articles/796977-adjust-a-customer-s-loyalty-points · retrieved 2026-08-03

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

329th: MOVED unknown -> no/B. The 325th merge held this cell for ONE reason: the absence was bounded to Thrive's own 884-article census while 'Thrive's loyalty and marketing run on an external product (postmyrewards.com / SalesBuilder)', i.e. the wrong publisher. THAT PUBLISHER IS NOW CENSUSED. NEW SURFACE: the Granbury SalesBuilder help centre itself, https://grsalesbuilder.uservoice.com/knowledgebase - 8 topic pages, href fixpoint over all article bodies run to 2 rounds, 50 article ids held, of which 1 (1969770) is a hard 404 and 5 (1836538, 1869865, 1944613, 1969767, 302785, 419741) are UserVoice's soft redirect to the index for deleted articles, leaving 44 live articles + index, 134,270 chars of stripped text. Nothing is gated, 401ed or paginated away. postmyrewards.com 302s to /login.php (a gate, recorded, not counted as an absence). CLAIM: vendor documents AI/ML-generated recommendations for offer CONTENT, target AUDIENCE, or SEND TIMING as a shipped feature. VERDICT: no, on the publisher that actually ships the feature. CONTROLS over the SalesBuilder census, tokenised, case-insensitive, word-boundary: 'artificial intelligence' 0, 'AI' 0 (no standalone occurrence), 'machine learning' 0, 'learning' 0, 'algorithm' 0, 'predict' 0, 'predictive' 0, 'recommendation' 0, 'suggest' 0, 'optimal' 0, 'best time' 0, 'send time' 0, 'dynamic' 0. POSITIVE controls pass on the same corpus: campaign 132 hits/29 files, offer 118/26, broadcast 71/22, trigger 62/12, points 69/15, tag 31/6. POISON FOUND AND EXCLUDED: 'recommend' 2 hits are advice to the READER ('We recommend that you include a link to your online ordering rewards page on every landing page'); 'personalized' 4 hits are merge tags and referral URLs ('share their personalized referral link, or PURL'); 'audience' 1 hit is Foursquare prose ('customers who use Foursquare are a great target audience'); 'segment' 9 hits are all the MANUAL tag feature ('SalesBuilder allows you to segment your customers using Tags. You can ask customers questions on your sign up page ... and then you can use this information to group customers'); 'smart' 1 hit is 'a smart idea to enter the Alternative Text'. The send automation is rule-based and human-authored end to end: 'Use Campaign Triggers to Automatically Send Messages', 'Setting Up A Campaign', 'How To Edit Your Campaign Messages', 'Broadcast Approval', 'Broadcast Blackouts', 'Message or Reward Customers on Visit Count', 'Using the "Near A Reward" Message', 'Retaining Lost or Lapsed Customers' - offers are authored ('Adding A New Offer', 'Multi-Use Offers') and audiences are tag/point/visit predicates. NEW SURFACE (329th): a COMPLETE anonymous census of THRIVE CONTROL CENTER, Granbury's own back-office/configuration app, which no prior pass touched. The public login page https://thrive-control-center.grs-tcc.com/ (1,310 bytes, Vue CLI) names /js/app.b3306bf3.js; that bundle carries the webpack chunk-name table ("js/"+({}[e]||e)+"."+{"chunk-0198d488":"68b133db",...}) with 121 entries. All 121 chunks AND all 121 matching .js.map files fetched: 121/121 HTTP 200, 0 misses, 1 round to a fixpoint (no chunk referenced a chunk outside the table). Plus app.b3306bf3.js.map. Soft-200 control: app.b3306bf3.js.NONSENSE.map = 404/135 bytes and the real maps begin {"version":3,; / = 200 but /zzz-nope-12345 = 404, so the host is not a catch-all. The maps carry sourcesContent: 6,783 source entries, 3,278 distinct sources, 2,763 of them the vendor's own (./src/** and ../shared-js/src/**), 19.9 MB of original source. Module census: menu 828, location-settings 473, common 278, shared-js 176, employment 58, user-management 54, locations 54, kiosk 53, user-roles 52, offers 42, ticket-finder 25. Grade B (production JS the vendor does not publish as documentation). THIS BOUNDS THE BACK-OFFICE APP ONLY, not the store-level POS binary. The offer-authoring module is IN this app (../shared-js/src/references/menu/offers/*, ./src/menu/offers 42 sources, offers-service.js, offers side-effects) and across all 19.9 MB the controls 'machine learning', 'recommend', 'recommendation', 'predict', 'audience', 'webhook' and 'generative' all return 0, while 'offer' returns 1,291 hits in 255 files - so the app where a Thrive offer is actually built ships no recommendation surface either. Three publishers (Thrive KB 372 + Thrive UserVoice 511 + SalesBuilder 44), the 254-URL HubSpot census of www.thrivepos.com, and the 121/121-chunk TCC app now all agree. The only ML statement Granbury publishes anywhere remains 'Offer Interactions in Thrive Control Center' - 'advanced machine learning to optimize application of available offers' - which is basket-time selection among human-authored offers, and the one AI-branded partner, WookAI (https://www.thrivepos.com/integrations/wookai, read in full today), is inventory and food-cost only ('WookAI is a separate subscription and they bill it directly'), with its AI feature being a cost question box ('What is WookAI GPT? A question box on the dashboard'). Retrieved 2026-09-18. https://grsalesbuilder.uservoice.com/knowledgebase/articles/905961 · retrieved 2026-09-18 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

Gift cards included from the $99 Starter tier and marketed alongside the loyalty platform. https://www.thrivepos.com/pricing · retrieved 2026-08-01

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

KB: 'To clock in to Thr!ve click on the Timeclock button on the main screen. A keypad will popup > Enter in the pass-code you selected or was assigned when your employee profile was made > click Enter.' A finger reader is an alternative, not a requirement, and employees with several job types pick the job type from a drop-down at clock-in. Breaks, lunches, time-off requests and time-record views run from the same screen, and Config > Employees > Timeclock & Payroll offers 'Disable Timeclock Features... typically done if you are using a different timeclock system', confirming the built-in clock is the default rather than an add-on. https://thrivepos.uservoice.com/knowledgebase/articles/514766-how-to-clock-in · retrieved 2026-08-08 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

Thrive's supported-hardware page enumerates every peripheral class the POS supports - touch screens, printers, customer displays, magnetic strip readers, cash drawers, router, WiFi, Caller ID - and its biometric entry reads in full: 'Biometric: we support the Digital Persona UrU fingerprint reader on Linux workstations. Fingerprint Log on is not supported on iPads or Android tablets.' There is no camera in the list and no customer-display or tablet camera role. The punch flow is enumerated to match: Store Setup exposes one switch, 'Enable Biometric Reader: this enables finger print readers; to be used for clocking in and out instead of using a keycode' (kb 634675 topic, Config > General), and 'How To Clock In' (kb 514766) documents exactly two identification paths - 'a keypad will popup > enter in the pass-code' or 'if you are using the finger reader instead of pass-codes the finger reader will popup'. Employee setup offers the same two, 'Set' a pass-code or 'Register Finger' (kb 534556). No photo capture at punch, no facial verification, and therefore no photo-only non-biometric mode exists. https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements · retrieved 2026-08-08

Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.

labor-geofenced-mobile-punch

Thrive has two staff-facing mobile apps and neither punches. The Dr!ve driver app's overview enumerates its feature set - orders sent to the driver at dispatch, map and driving directions, 'Arrive' when within .25 mi., order messages and tender type, promised-time countdown, on-screen signature and tip, driver location on the POS map - with no clock-in or clock-out function, and its FAQ scopes GPS to mapping, the .25-mile arrive gate and the in-process driver map. The Thrive Analytics App's own feature list is 'Track Sales and Labor in Real Time', multi-location views, and toggling online ordering and online order types; its companion article 'Online Ordering Control for Analytics App' enumerates the two controls the app exposes (Thrive Online enabled/disabled and allowed order types, at company or location level) - no timeclock. Punching is documented only at a station: 'From the Thrive Home Screen, click the TimeClock button. Enter your employee log on ID in the pop up window. If biometric fingerprint recognition is used, you can touch the fingerprint reader here instead', and the article's list of reasons clock-in fails (required messages, inactive employee, no security workgroup, no job types, expired employee requirements, not on the schedule under schedule enforcement) contains no location or geofence condition. 'Geofence' returns zero hits in either the 511-article Learning Center or the 251-article Granbury KB. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Timeclock-Functions-Clock-In-Out-Breaks-Review-Timeclock-Records · retrieved 2026-08-08

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

Re-checked 2026-08-08 across the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase, neither certified complete. Correction to the earlier reasoning: 'offline'/'store and forward' are not absent from the corpus - '[TPOS-5803] Save Thrive Payments key rotations and store-and-forward requests to Mysql so that RabbitMQ can be removed' (8.1.3), 'TPOS-7448 Fixed Failed/declined store and forward TP transaction fail to clear' (8.2.21) and 'Blocking store and forward MSR transactions with Cayan' (8.0.73) all appear - but every one of them is card-processing engineering, and none touches timekeeping. Version 7.7.x's 'Improved Tools for Internet Connectivity Problems' does enumerate what queues during an outage (loyalty enrollments and redemptions, online menu updates, Dr!ve status, e-mail) and time punches are not in that list either way. Thrive is an on-premises system - station licences counted in Store Setup, a local jBoss/database (a v7.4 note covers 'auto jboss restart when database connection is lost'), and an 'Enable Internet Functions' switch gating address verification, delivery mapping, e-mail, alerts and weather with the instruction 'turn this off if your internet is temporarily down' - which suggests punches are written to the local server and are indifferent to internet loss, but that is inference, not documentation. The current 'TV - Timeclock Functions: Clock In / Out / Breaks / Review Timeclock Records (8.1+)' article enumerates the punch flow and the reasons a clock-in fails without mentioning connectivity at all, and the only recovery it describes is manual - 'Timeclock records can be edited by a manager in the Payroll > Payroll Details report. A timeclock record can also be added there if needed.' No release note through Thrive POS 8.3.41 (2026-07-14) mentions punch queueing or duplicate-punch reconciliation on reconnect. Unresolved. || 325th: NEW MEASUREMENT on a CENSUS rather than the two uncertified corpora the earlier passes used, and deliberately still unknown. Across 884 articles 'offline' returns only 3 hits - two are card processing, and the third is a NEW article, 'ThrivePOS Network Requirements for Optimal Performance', which does confirm an offline mode exists without describing it: 'Slow or unstable internet can cause payment delays, syncing issues, or OFFLINE MODE ACTIVATION during peak business hours' and 'If you experience frequent disconnects, lag, or "POS Offline" messages, contact ThrivePOS Support'. 'store and forward' 2 hits (both card processing), 'reconnect' 0, 'lost connection' 0, 'no internet' 0. The one adjacent statement, in the 7.7.x release notes, scopes queueing to outbound integrations and names loyalty, not timekeeping: 'Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollment...'. Vocabulary check: 'punch' has 0 hits in the entire census - Thrive says 'clock in' (58) and 'time clock' (57) - and no clock-in article mentions connectivity at all. So the claim's documentation conjunct demonstrably fails, but nothing positively establishes that punches are lost, which is why this is held unknown and not a no. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. || 327th: NEW SURFACE (327th), cell unchanged, and it is worth recording because it is the closest Granbury comes to an outage statement and it is NOT about punches. The rebuilt integrations section publishes a dedicated connectivity-failover product page: 'PizzaCloud gives Thrive POS customers cellular backup for critical restaurant connectivity. If your internet or phone line drops, PizzaCloud can automatically switch over to cellular backup, helping your shop keep taking orders and processing payments instead of losing the night to a service outage ... Keep taking orders when your primary internet or phone line drops | Continue running cards during a connection outage | Switch to cellular backup automatically when a line fails' (https://www.thrivepos.com/integrations/pizzacloud). Time punches are not in that enumeration, and the product's whole premise is that continuity is bought by RESTORING the link, not by queueing locally - which is evidence about Granbury's outage posture but says nothing about whether a punch taken during the gap is preserved or deduplicated. The 7shifts page confirms punches leave the POS ('Sends clock-ins, clock-outs, and breaks over automatically ... Data moves in one direction, out of Thrive POS') but not what happens to them offline. Bound: the 254-URL HubSpot content-search census of www.thrivepos.com (49 terms, paged to exhaustion, includes unlinked pages) on top of the 884-article KB census. Retrieved 2026-09-18. || 329th: 329th: NEW SURFACE, cell still unknown, plus a POISON CORRECTION that matters for every future 'offline' control on this vendor. NEW SURFACE (329th): a COMPLETE anonymous census of THRIVE CONTROL CENTER, Granbury's own back-office/configuration app, which no prior pass touched. The public login page https://thrive-control-center.grs-tcc.com/ (1,310 bytes, Vue CLI) names /js/app.b3306bf3.js; that bundle carries the webpack chunk-name table ("js/"+({}[e]||e)+"."+{"chunk-0198d488":"68b133db",...}) with 121 entries. All 121 chunks AND all 121 matching .js.map files fetched: 121/121 HTTP 200, 0 misses, 1 round to a fixpoint (no chunk referenced a chunk outside the table). Plus app.b3306bf3.js.map. Soft-200 control: app.b3306bf3.js.NONSENSE.map = 404/135 bytes and the real maps begin {"version":3,; / = 200 but /zzz-nope-12345 = 404, so the host is not a catch-all. The maps carry sourcesContent: 6,783 source entries, 3,278 distinct sources, 2,763 of them the vendor's own (./src/** and ../shared-js/src/**), 19.9 MB of original source. Module census: menu 828, location-settings 473, common 278, shared-js 176, employment 58, user-management 54, locations 54, kiosk 53, user-roles 52, offers 42, ticket-finder 25. Grade B (production JS the vendor does not publish as documentation). THIS BOUNDS THE BACK-OFFICE APP ONLY, not the store-level POS binary. The app ships the COMPLETE time-clock configuration blob as its default - ./src/employment/employment-defaults.js: timeClock { enable, autoClockOffAfterTime 57600, autoLogOffAfterTime 300, requireReasonOnEditRecords, breaks { enabled, defaultLength, isPaid, excessIsNotPaid }, lunch { enabled, defaultLength, isPaid, excessIsNotPaid } } - and the TimeClock.vue settings screen renders exactly those fields and no others ('Enable Time Clock', 'POS Auto Log Off', 'Auto Clock Off After Time', 'Require a Reason When Editing Time Clock Records', 'Clock Out For Breaks', 'Clock Out For Lunch'). There is no offline, queue, sync, resume or duplicate-punch setting in the enumeration, and no such behaviour is described anywhere in the employment module (58 sources) or in 'Employees in TCC - Overview and FAQ' (KB, published 2026-09-08) or 'Preparing for Employment in TCC' (2026-08-31), both read in full today - the newest employment docs Granbury has, which cover import, merge, wages, POS Log On ID and 7shifts departments and never mention connectivity. POISON: the token 'offline' appears exactly ONCE in 19.9 MB of TCC source and it is NOT connectivity - it is a SALES CHANNEL id, new SalesChannelComplete('offline', 'Thrive at Location') in the ticket-finder search-criteria list (alongside 'online'/Thrive Online, 'letsget'/LetsGet, 'chowly'/Chowly). Any future 'offline' control on Thrive corpora must exclude that sense. 'punch' remains 0 across every corpus. Still unknown rather than no: the 326th merge rule stands - an unpublished offline statement does not carry a capability `no`, the POS is an on-premises binary this back-office census does not bound, and the newest release-note article ('Thrive POS Release notes 8.3.41 and up', re-fetched today, 1,708 chars) says nothing about punches or connectivity either way. 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

Security Settings Configuration documents six renameable security workgroups ('name them whatever you wish') with per-action grants spanning POS functions (void open/closed tickets, discount authorization with percentage limits, drawer access, gift-card and customer-point adjustments, kitchen-ticket reprint), delivery functions (edit promise times, override delivery restrictions, edit calculated mileage), manager functions (per-report access, view wage data, view Social Security, employee record editing) and configuration rights; PCI-restricted settings additionally require an owner-level administrative password. Structural limit worth noting: six workgroups maximum; configuration is per store. https://thrivepos.uservoice.com/knowledgebase/articles/720465-security-settings-configuration · retrieved 2026-08-03

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

The Void Details Report attributes each void to the employee who performed it and separately records 'who authorized the void', with reason, timestamps and amounts — an approver-attributed, queryable trail for the highest-risk override. Shortfall: this attribution is documented only for voids; discount overrides, register-assignment overrides ('Override register assignments' right) and schedule clock-on overrides are documented as prompts, but no article shows them written to a queryable audit log naming the approver. https://thrivepos.uservoice.com/knowledgebase/articles/439741-void-details-report · retrieved 2026-08-03

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

Native schedule builder inside the POS, documented end to end: Manager Home > Employees > Schedules, 'Add Schedule' creates a shift by job type, then an employee dropdown filtered to those eligible for that job type, day checkboxes, start/end times and a 'Next Day' flag for shifts crossing midnight. 'The Breaks will fill in automatically according to your configured break rules'; 'Use same schedule for all days' copies across the week; schedules save as reusable templates. Publication is explicit — 'press the Post Schedule button... This will make the schedule public to your employees', with email notification via the employee Communications tab. Also documented: daily 'As Scheduled' labor budget totals and availability/time-off conflict alerts. Corroborated downstream by Employee Schedule, Labor Schedule and Scheduled Vs Actual reports. https://thrivepos.uservoice.com/knowledgebase/articles/535726-create-labor-schedule-weekly · retrieved 2026-08-02 adversarially verified

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

Documented as history-driven, not a static template: 'The Thr!ve POS system can help you forecast your sales based on historical data,' via two configurable methods — 'forecast based on last year's same day sales PLUS or MINUS a %' (matched by day-of-week, not calendar date) or 'select the Last X weeks sales -- just enter a number to average,' combinable together. Create Labor Schedule - Daily (kb 938562) confirms the daily schedule view surfaces 'forecasted sales, your labor goal and budget, scheduled hours, schedule $ and schedule labor %,' with a per-day-of-week labor % budget set by the manager to guide staffing against the forecast. https://thrivepos.uservoice.com/knowledgebase/articles/938424 · retrieved 2026-08-04

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

KB: the manager home page hosts an 'Hourly Labor % graph' (its Set Goal button sets a labor % target per day of week) alongside the Weekly Sales & Forecast graph, and Config > Employees > Timeclock & Payroll offers 'Labor Performance Calculation - Labor %: Will show charts and graphs depicting the dollar amount of labor cost vs dollar amount of sales', with Additional Employer Labor Cost feeding 'the Labor Sales report, Store Summary and Manager Home'. The Labor Sales report is generated on demand and 'breaks out your labor costs vs. sales, by hour' with Sales $, Labor $, Salary $, Employer Costs and a Labor % column, so the running percentage is visible during service rather than only next morning. The Thrive Analytics app adds an off-premise view refreshed every 2-3 minutes. https://thrivepos.uservoice.com/knowledgebase/articles/938424-managing-sales-forecast-and-labor-budget · retrieved 2026-08-08 adversarially verified

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

Manage Overtime Settings documents a pre-emptive warning, not just after-the-fact reporting: 'Alert me of approaching overtime within X minutes per day' (daily-overtime states like California) or 'within X minutes per week,' configurable simultaneously; alerts 'appear on the Manager Home Alerts area if configured to do so there, and can be emailed to you.' The claim allows either warn or block, and this is a documented pre-crossing warning. (No clock-in block is documented — enforcement is notification-only.) https://thrivepos.uservoice.com/knowledgebase/articles/847875-manage-overtime-settings · retrieved 2026-08-04

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

Break rules are configurable as a rule set, but they are not jurisdiction-keyed and the vendor states they are not enforced at the terminal. Timeclock & Payroll (Config > Employees) documents a Break Enforcement table - 'Choose Break Enforcement to set up rules about what breaks are expected (will appear on schedules). Enter the rule by selecting the # of break minutes, choosing paid or unpaid, and entering the # of hours the employee should work before the break' - alongside 'Clock Out For Breaks', 'Default Break Length', 'Paid Breaks' and 'Dock For Long Breaks', and the same for lunches (kb 848598). So this is more than one break setting; it is a store-wide rule set keyed on hours worked. Named shortfalls: there is no per-state or jurisdiction rule library for breaks - by contrast the same screen IS jurisdiction-aware for overtime ('Overtime Pay When 8 Hours Exceeded Per Day', 'California Overtime', state minimum wage); release 8.1.3 limits the rules to planning, 'Restored the Break Rules functionality partially - so Thr!ve users can specify break rules for scheduling purposes. (Not yet enforced in frontend)'; the current 8.1+ timeclock walkthrough shows breaks taken as plain Break and Lunch buttons with no attestation prompt; and no missed-break premium-pay flagging is documented - the only monetary consequence documented runs the other way, 'Dock For Long Breaks', which docks the employee. https://thrivepos.uservoice.com/knowledgebase/articles/847869-timeclock-and-payroll-overview · retrieved 2026-08-08

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

CLAIM: supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes. VERDICT: no. EVIDENCE: `fair workweek`, `predictive scheduling`, `clopening`, `predictability pay` and `advance notice` return ZERO files each across the 372-article census. The scheduling documentation is present and is enforcement-only: 'TV - Timeclock Functions' documents schedule enforcement preventing clock-in outside the schedule (`clock in` = 5 files, 15 hits), and the labour partner in the seven-name integration enumeration is 7shifts, to which Thrive SENDS 'sales, labor punches, and employee records' - Thrive is the source system, not the ordinance engine. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.

labor-minor-labor-rules

Partial, and the shortfall is named by the vendor in the next sentence of the same article: 'They do not restrict clock on if scheduling is not enforced.' The mechanism is a per-employee availability record (max hours per day, max days per week, max hours per week, Not Available windows) that raises an ALERT during scheduling only. The claim's scheduling half is met advisorily and its clock-in half is not met at all; there is no age-derived or jurisdiction-derived rule table, and the Timeclock Functions article's list of clock-in refusal reasons has no age dimension. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/534571-availability · retrieved 2026-09-04

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

Same evidence as payments-tip-pooling: Close Register documents a lump 'Pay Tips (pays out generally, as to a tip pool)' disposition versus 'Pay Tips to Server' (per-employee attribution). Shortfall: no article documents automatic per-shift computation of pool distribution by configurable rule (percentage of sales, hours worked, points, or role) — the pooled path is a single payout, not a rules engine, so managers would still need a manual spreadsheet to divide it. https://thrivepos.uservoice.com/knowledgebase/articles/1132084-close-register-improved-in-v-7-7-0-with-video · retrieved 2026-08-04

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

Close Register documents three tip dispositions — 'Pay Tips (pays out generally, as to a tip pool), Pay Tips to Server (attributes tips specifically to the employee who took the order, and reports those tips on their server reports) or Retain Tips (do not pay out the tips)' — and positions set to 'Pay tips at payroll' get tips logged to their payroll records. A tips-vs-minimum-wage report also exists (kb 947427). Shortfall: the pooled 'Pay Tips' path has no documented per-shift, per-employee record of amounts contributed to or distributed from the pool — no pool-distribution ledger or export is described anywhere in the Learning Center. https://thrivepos.uservoice.com/knowledgebase/articles/1132084-close-register-improved-in-v-7-7-0-with-video · retrieved 2026-08-03

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

CLAIM: payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting W-2 Box 12 code TP and Box 14b reporting for tax year 2026. VERDICT: no. EVIDENCE: `qualified tips`, `W-2`, `w2`, `box 12`, `box 14`, `tipped occupation` and `payroll export` return ZERO files each across the 372-article census, and the census is current - it carries the 'Thrive POS Release notes 8.3.41 and up' stream with lastPublishedDate 2026-09-11 - so a 2026-tax-year change would be visible if it had shipped. The payroll surface that IS documented is the Employee Payroll Summary Report and a TimeClock message carrying driverFees; neither splits tips by qualification nor carries an occupation code. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

The vendor's own Timeclock & Payroll configuration enumerates what Thrive does with payroll: 'Payroll Export: If you are using a different payroll system this feature allows you to export your payroll to the company you use to pay your employees. For example; if you use ADP to run your payroll, you would select ADP from the drop down' and enter Company Code, Batch Description, Tips Code, Driver Fees Code and Server Sales Code. The companion article ends 'You can now import this file into your ADP payroll program.' The labor report set (Payroll, Payroll Details, Driver Payroll) produces the figures that feed that export. Neither doc host describes Thrive filing taxes or moving money by direct deposit. https://thrivepos.uservoice.com/knowledgebase/articles/847869-timeclock-and-payroll-overview · retrieved 2026-08-08 adversarially verified

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

One named payroll provider is fully documented: 'make payroll easy by exporting your payroll report in a format that can be easily imported into ADP payroll services' - add a six-digit ADP department code per job type, set Payroll Export to ADP, enter Company Code, Batch Description, Tips Code, Driver Fees Code and Server Sales Code, then 'navigate to Manager Home > Reports > Labor > Payroll and run it for the time period you wish to export ... notice the file name - this is formatted specifically for ADP and must remain as is.' The export carries timecards, wages, tips and driver fees. Shortfall, checked across BOTH published corpora rather than the Learning Center alone: ADP is the only provider named in either the 511-article UserVoice Learning Center or the 251-article Granbury KnowledgeBase - Gusto, Paychex and QuickBooks return zero hits on both hosts. The current-generation docs are vaguer still, not richer: the TCC Paid In / Paid Out settings article says only that 'the "Report on payroll" setting allows you to enter a payroll code, which can be used in some payroll exports', without naming any, and the Timeclock & Payroll config screen (kb 847869) describes the dropdown as 'if you are using a different payroll system this feature allows you to export your payroll ... for example; if you use ADP ... you would select ADP from the drop down' without listing its other options. What 8.2/8.3 added is Thrive Analytics payroll reporting ('Added Payroll Report for Thrive Analytics', 'Employee Payroll Detail Report', 'Employee Payroll Summary Report'), which is in-product reporting, not a documented provider format. The claim's two-provider bar is unmet. https://thrivepos.uservoice.com/knowledgebase/articles/947889-configuring-adp-payroll-export · retrieved 2026-08-08

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

Reachable, but not in Thrive and not in the base price. Thrive brokers a 7shifts integration that syncs 'employees, departments, and roles' out of the POS 'so a new hire is ready to schedule', and 7shifts is where self-service shift claiming and swap approval live. Shortfalls, all stated by Thrive itself: 7shifts 'is a separate subscription billed by 7shifts', not included; the integration counts against the tier-metered Third Party Integrations allowance, of which the Starter plan has none; and the data is one-way - 'Data flows from Thrive POS into 7shifts. Schedules are built and published in 7shifts, where your managers work' - so the approved schedule never returns to the POS and no overtime or role-eligibility rule is enforced at the Thrive clock-in. https://www.thrivepos.com/integrations/7shifts · retrieved 2026-09-04 adversarially verified

Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.

labor-digital-onboarding-i9

The new-hire flow is enumerated end to end and is three screens: 'first start by entering in the employee's general information ... click Save and Next ... you will be taken to the Job & Payroll screen. Enter the employee's wages and then select their authorized job types ... click Save and Next to proceed to System & Security. Here you will enter the employee's pass-code or finger print scan ... you will also select the employee's security level. Once you have saved this page the employee's profile will be complete and ready for use.' No tax-form step, no document upload, no signature capture. The nearest adjacent feature, Job Requirements (kb 534559, 747291), is a per-job-type list of dated credentials the manager keys in - 'for example if a employee is a driver you can enter their license and insurance expiration date' - with expiry alerts; it stores dates, not forms. 'I-9', 'W-4' and 'E-Verify' return zero hits across both the 511-article Learning Center and the 251-article Granbury KB, including every release stream through Thrive POS 8.3.41 (2026-07-14). The current product has moved further away from document collection, not toward it: the TCC release notes record 'TCC-1563 Remove DL, SS and birthdays from employee records' and 'TCC-1562 Remove DL, SS and birthdays from employee records from ETL process', and TCC's employee article asks only which employees need a TCC login. https://thrivepos.uservoice.com/knowledgebase/articles/534556-adding-an-employee · retrieved 2026-08-08

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

Server Performance Report documents per-employee Sales, Tickets, Tips, Tip Percentage, Average Check ('the total average dollar amount per employee ticket'), Average Amount Per Person, and a sales-by-order-type breakdown. Shortfall: no attachment-rate-for-named-categories column and no void/comp rate column are documented on this or any other server-level report — void/comp data is attributed by employee only on the separate Void Details Report (kb 439741), not joined into a per-server scorecard. https://thrivepos.uservoice.com/knowledgebase/articles/439841-server-performance-report · retrieved 2026-08-04

Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.

inventory-recipe-bom-costing

Native. Ingredients are configured per item and per size with a total food cost per size reported. https://thrivepos.uservoice.com/knowledgebase/articles/439853-item-ingredients-report · retrieved 2026-08-01 adversarially verified

Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.

inventory-unit-conversion-yields

Add An Ingredient documents the full unit chain: Purchase Unit ('the unit of measure in which you buy this ingredient (i.e. case, gallon, pound)'), Usage Unit for how the ingredient is used and sold, intermediate count units for multi-level conversion ('purchasing by the case, which yields 4 bottles, which yield 64 ounces each'), and an explicit Yield conversion ratio ('If you purchase by the pound, does 1 pound yield 16 ounces? Enter the conversion ratio here') with prep waste folded into the usage yield ('if you buy 8 ounces of green pepper, it may only yield 6 ounces of usable product'). Waste is expressed inside the yield ratio rather than as a separate percentage field. https://thrivepos.uservoice.com/knowledgebase/articles/886332-add-an-ingredient · retrieved 2026-08-04

Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator

inventory-theoretical-vs-actual

Documented variance model: 'The system will tell you what you should be using; your physical inventory will tell you what you ACTUALLY used.' That is theoretical-vs-actual by definition. https://thrivepos.uservoice.com/knowledgebase/articles/938940-physical-inventory · retrieved 2026-08-01 adversarially verified

Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator

inventory-realtime-depletion

Associate An Ingredient To A Menu Item confirms per-order, modifier-aware depletion: inclusions deplete automatically ('As long as the Pepperoni topping has its ingredients defined, the proper amount will be deducted whenever Pepperoni is included'), and requirement-driven customer choices (e.g. a dressing pick) deduct based on the item selected, with an explicit warning not to pre-configure optional add/remove modifiers as base ingredients. Shortfall: no article states the deduction timing explicitly — whether it posts at order-fire in near real time or in an end-of-day batch is not documented either way. https://thrivepos.uservoice.com/knowledgebase/articles/886365-associate-an-ingredient-to-a-menu-item · retrieved 2026-08-04

Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator

inventory-86-auto-sync

'TV - Out of Stock & Countdown (Version 8.1+)' documents automatic 86ing on depletion: 'Turn the Countdown feature ON, and enter the quantity of items you have on hand ... Each time an item is ordered, the quantity is reduced. When it reaches 0 the item will appear as out of stock (and Thrive Online will also be updated)'; manual out-of-stock marking likewise 'will automatically update its status in Thrive Online as well', can be applied to an individual size or style, and a modifier marked out of stock 'will make all items that contain that modifier as an inclusion also unavailable to order'. Shortfalls, all three material. (1) The countdown quantity is a per-item number the manager types on the Manage Item Stock screen, not the ingredient on-hand balance from the inventory module - no article on either host ties an ingredient falling to its Reorder Point or Par Level to an item being 86'd, and the current Granbury KB documents no inventory module at all beyond 'requires inventory module' toggles. (2) The only trigger is exactly zero, with no configurable threshold, and even the first-party channel is coarse: 'TOL - Item Countdown is not enforced' states 'The integration of the countdown feature with Thrive Online is somewhat limited. Orders placed online will reduce the countdown quantity available, and when it reaches 0, the item will be marked out-of-stock online. However, as long as some quantity remains, Thrive Online is not aware of specific quantities available.' (3) Propagation does not reach third-party marketplaces. Deliverect is the documented broker for DoorDash, Grubhub and the rest, and what it receives is a published menu, not a stock flag: 'Deliverect will receive all Menu Categories, Menu Items, Modifiers and Requirements ... Any changes and publish from the POS will update Deliverect just like we do for TOL', with the sync triggered by a TCC menu publish. Nothing in the Deliverect articles or its release stream describes an out-of-stock or countdown state reaching a channel. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Out-of-Stock-Countdown-Version-8-1 · retrieved 2026-08-08

Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.

inventory-count-modes

Physical Inventory counting is a documented first-party workflow launched from the Inventory main page. Partial/spot-count cadence and count sheets are not detailed, so scope beyond full counts remains unverified. https://thrivepos.uservoice.com/knowledgebase/articles/938940-physical-inventory · retrieved 2026-08-01 adversarially verified

Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.

inventory-mobile-count-offline

Physical Inventory Worksheet documents a mobile counting path: 'You can save this step by using a handheld tablet to enter as you go!' as an alternative to printing the worksheet and walking with paper. Shortfall: this single-sentence reference does not confirm barcode/QR scanning as part of the tablet flow, nor does it state the tablet continues to accept counts with no network connectivity and syncs on reconnect — no offline behavior is documented for it. https://thrivepos.uservoice.com/knowledgebase/articles/439854-physical-inventory-worksheet · retrieved 2026-08-04

Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator

inventory-vendor-catalogs-edi

Add An Ingredient documents a named electronic distributor integration: 'The PO Export format has one option - eSysco - which can be used with Sysco accounts.' Shortfall: only one broadline distributor (Sysco) is named — no US Foods or Performance Food Group integration is documented — and Create Purchase Order (kb 886341) states the alternative transmission is to 'E-mail it to the vendor or Print it,' with invoice receipt described elsewhere as entering 'the invoice # from your vendor... at time of receipt,' i.e. no electronic invoice-receiving path is documented even for the eSysco integration — only PO transmission out. https://thrivepos.uservoice.com/knowledgebase/articles/886332-add-an-ingredient · retrieved 2026-08-04

Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator

inventory-invoice-ocr

CLAIM: ingests supplier invoices from photo, PDF or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. VERDICT: no. EVIDENCE: across the census below, 'OCR' 0 hits, 'photo' 0, 'scanned' 0, 'extract' 0, 'EDI' 0, and every one of the 14 'invoice' hits is manual. 'Receiving Purchases' is the whole receive workflow and never leaves keyboard entry: 'Select the vendor from the drop down list ... Enter the vendor's invoice number at the top of the Receive screen ... you can double check the quantity received and edit the cost, if needed' (https://thrivepos.uservoice.com/knowledgebase/articles/938934-receiving-purchases). The 'Inventory Purchases' report confirms the only invoice datum Thrive holds is a number typed by a human: 'Invoice #: The invoice # from your vendor, ENTERED AT TIME OF RECEIPT' (https://thrivepos.uservoice.com/knowledgebase/articles/439850-inventory-purchases-report). The invoice DOCUMENT is never ingested anywhere in 884 articles. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. https://thrivepos.uservoice.com/knowledgebase/articles/938934-receiving-purchases · retrieved 2026-09-17 adversarially verified

Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator

inventory-price-change-alerts

The ingredient record carries two cost fields and the second is maintained by the system: 'Last cost: enter the last price paid per purchase unit' and 'Average Cost: this read-only field will automatically calculate', with the received price editable at receipt ('you can double check the quantity received and edit the cost, if needed', kb 938934) and per-invoice totals retrievable from the Inventory Purchases Report (kb 439850), whose Invoice # column links through to 'the order details'. Shortfalls: the Add An Ingredient article enumerates every field on the ingredient screen and those two scalars are the only price state kept - there is no per-item price-history view across invoices, no contracted or expected price to compare against, and no alert on price movement. The only thresholds in the module are quantity ones ('Reorder Point: enter the level at which you wish to be warned of reorder'; the Inventory Warning Report, kb 439848, is likewise quantity-based). Scope of that absence, stated honestly: Thrive's inventory module is documented only in the 8.0/8.1-era UserVoice Learning Center. The 251-article Granbury KnowledgeBase, where the current 8.2/8.3 product is documented, contains no inventory articles at all - its only inventory references are the receipt-printing option 'Print inventory weights (requires inventory module)' and a made/un-made void note - and the 8.2, 8.3 and TCC release-note streams add no price-variance alerting. So no price-variance threshold is documented in anything Thrive publishes, on evidence that is current for the release notes and several versions old for the module itself. https://thrivepos.uservoice.com/knowledgebase/articles/886332-add-an-ingredient · retrieved 2026-08-08

Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator

inventory-par-auto-suggest

Create Purchase Order documents per-item, per-location par levels driving suggested order quantities: a PO can be created 'from warning level, par level, all ingredients for that vendor, or copy a previous PO,' and 'Par Level... will order enough, based on your current on hand level, to bring your total up to par,' with a separate Typical Purchase Quantity default. Shortfall: every documented mode (warning level, par level, typical quantity) is a static threshold or default — no mode is described as driven by a sales forecast rather than a fixed par, which the claim requires at least one of. https://thrivepos.uservoice.com/knowledgebase/articles/886341-create-purchase-order · retrieved 2026-08-04

Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.

inventory-waste-logging

Inventory Adjustments explicitly exists to 'quickly record waste, spoilage, transfers, and other changes to your on hand quantity.' Reason-code granularity and reporting are not documented. https://thrivepos.uservoice.com/knowledgebase/articles/938937-inventory-adjustments · retrieved 2026-08-01 adversarially verified

Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.

inventory-transfers

Inter-location transfer is documented as a manual double-entry workaround using the generic Inventory Adjustments tool: 'For transfers to another store, you should record an adjustment in both locations' (select Adjust from the Inventory Main Page and complete the adjustment separately at each location). Shortfall: this is two independent single-sided adjustments the operator must remember to enter at both ends, not a linked two-sided transaction with an in-transit or approval state — nothing prevents or reconciles a transfer recorded at only one location. https://thrivepos.uservoice.com/knowledgebase/articles/938937-inventory-adjustments · retrieved 2026-08-04

Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.

inventory-commissary

The word 'transfers' does appear, and that is what makes this a no rather than a zero-hit: a transfer in Thrive is a one-sided on-hand adjustment - pick an ingredient, enter a new quantity or a plus/minus - with no counterparty location, no issue document and no computed transfer cost. The only production construct is the local, zero-priced 'Requisition items for production' permission. Across the 26 enumerated inventory articles of the P2 census there is no requisition, issue or inter-location stock movement; 'commissary' and 'central kitchen' are zero across all 875 documents. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. AUDIT (2026-09-04): Attacked as a P2 topic-count zero and it survived on better evidence than the note cited. 'Inventory Adjustments' (kb 938937) does not merely omit commissary transfers, it documents the WORKAROUND: 'Note: For Transfers to another store, record an adjustment in both locations', with cost recorded locally by FIFO on the negative side and last-purchase-cost on the positive side. A vendor telling operators to double-key a manual adjustment in each store is positive evidence that no issue document and no computed transfer cost exist. Residual risk: the Learning Center stops at 8.0.55 and the current KB carries no inventory articles, so an 8.3-era commissary module would be invisible. https://thrivepos.uservoice.com/knowledgebase/articles/938937-inventory-adjustments · retrieved 2026-09-04

Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.

inventory-lot-traceability

'Receiving Purchases' enumerates everything captured at receipt: vendor, optional PO, 'enter the vendor's invoice number at the top of the Receive screen', receive date, quantity received, cost, additional ingredients, and 'Other Costs' for delivery fees and taxes - then save. No lot, batch or serial field. 'Add An Ingredient' (kb 886332) enumerates the full ingredient master - name, item #, preferred vendor, vendor's number, typical purchase quantity, purchase unit, yield, up to four usage units, last cost, average cost, reorder point, par level, on hand, standard UPT, physical-inventory frequency, location, category - with no lot dimension either, and the recipe record (kb 886338) tracks only ingredient quantities and a calculated cost, so production is not lot-linked. 'Lot number' and 'batch number' return zero hits across the 511-article Learning Center, and none of the nine reports in the Reports - Inventory topic offers a lot trace. Neither backward nor forward recall tracing exists. https://thrivepos.uservoice.com/knowledgebase/articles/938934-receiving-purchases · retrieved 2026-08-08

Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.

inventory-shelf-life-expiry

Three enumerations, not a failed search. "Add An Ingredient" enumerates every field on the ingredient record - name, item #, preferred vendor and vendor's number, typical purchase quantity, purchase unit, yield, usage units, last cost, average cost, reorder point, par level, on hand, standard UPT, physical-inventory frequency, location, category - and there is no expiration, use-by or shelf-life field; the recipe record (kb 886338) adds only batch yield and a calculated cost. "Receiving Purchases" (kb 938934) enumerates what is captured at receipt - invoice number, receive date, quantity, cost, other costs, taxes - with no date-coded field, so an expiry date cannot be recorded in the first place. The delivered inventory report set is enumerated by the Reports - Inventory topic and is exactly nine: On Hand, Warning, Adjustments, Purchases, Ideal Usage, Category Target Usage, Ingredient Tracking, Item Ingredients and the Physical Inventory Worksheet - none an expiring-soon list, and the Inventory Warning Report is a reorder-quantity report. The vendor does build expiry alerting where it exists, but only for staff documents (Requirement Expiration Alerts, kb 793854 - driver licence, insurance). Scope note: the second vendor documentation host, granburysolutions.my.site.com/KnowledgeBase (~250 articles, current to 7/14/2026), publishes no inventory or ingredient articles at all, so it neither adds nor contradicts anything here. https://thrivepos.uservoice.com/knowledgebase/articles/886332-add-an-ingredient · retrieved 2026-08-08

Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.

inventory-bar-partial-bottle

Add An Ingredient documents a multi-level unit-conversion chain that reaches volume units below the whole bottle: 'purchasing by the case, which yields 4 bottles, which yield 64 ounces each,' with a Yield conversion ratio field. This lets a physical count be entered in ounces, i.e. by bottle fraction, for liquor counting. Shortfall: no scale/weight-integration hardware or workflow is documented — the fractional counting method is a manual volume-unit entry, not a weighed-bottle system. https://thrivepos.uservoice.com/knowledgebase/articles/886332-add-an-ingredient · retrieved 2026-08-04

Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.

inventory-cogs-gl-export

CLAIM: exports period COGS and accounts-payable invoice detail in a NAMED accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category. VERDICT: no - the prior pass withdrew its evidence as unverifiable and left this unknown; it can now be settled on a census rather than a floor. EVIDENCE: zero hits across all 884 articles for every named system and every accounting term: quickbooks 0, Sage 0, Intacct 0, NetSuite 0, Xero 0, Restaurant365 0, Compeat 0, 'general ledger' 0, 'chart of accounts' 0, 'journal entry' 0, GL 0, COGS 0, 'cost of goods' 0. This is not an unexamined corpus: 'export' and its forms return 142 hits, and enumerating them gives Thrive's ENTIRE named export surface - an ADP payroll export ('Improved ADP export options', 'Payroll Export button'), XML menu/price/tender exports to online-ordering integrators ('Export Items to XML', 'Configuration > XML Exports', 'The "XML Export" that is provided to your integrator', menu and coupon export 'and provide to Chowly'), an N2K order export, a Thr!ve Online export, report-to-Excel buttons on the individual reports, and a customer .csv ('Pressing Export will download a .csv file with customer details'). Accounting is absent from that enumeration, and there is no per-category GL mapping anywhere. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. https://thrivepos.uservoice.com/knowledgebase · retrieved 2026-09-17 adversarially verified

Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator

inventory-native-not-partner

This is the dossier's biggest error and it cascades through the entire inventory section. Thrive ships a native inventory module documented in its own KB: Inventory main page with Physical Inventory counts, Inventory Adjustments (waste, spoilage, transfers, on-hand changes), Inventory Purchases (purchase orders saved/received) and Item Ingredients reporting. The R365 integration is an additional back-office option, not the delivery mechanism for inventory. The researcher read one marketing bullet and inverted a whole capability area. https://thrivepos.uservoice.com/knowledgebase/articles/938940-physical-inventory · retrieved 2026-08-01 adversarially verified

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

Recipe-to-margin linkage is documented: 'Connecting the ingredients you buy to the items you sell is the best way to get an accurate picture of ideal food cost... total item cost and item margin information is calculated,' and the Item Ingredients Report shows 'total food cost per size.' Shortfall: no article documents joining that per-item cost to actual sales mix for a contribution-margin report, or an automatic flag when an item's margin falls below a configured threshold after an ingredient cost change — margin is shown per item, not proactively monitored. https://thrivepos.uservoice.com/knowledgebase/articles/439853-item-ingredients-report · retrieved 2026-08-04

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

Shortfall: the browser half is not minutes-fresh. KB: 'You can access reports from anywhere via web browser. No need to VPN to your location. Analytics reports are updated every 2-3 hours', and each dashboard shows 'when the data was most recently refreshed'; the scheduled-report article repeats 'data is compiled in Analytics every 2 hours or so'. The Thrive Analytics app is the piece that meets the claim - 'live updates - every 2 to 3 minutes - on the numbers that matter most: sales and labor', plus remote online-ordering toggles. Ticket Finder is separately described as compiling 'up-to-the-minute data from all your locations', so ticket lookup is current even when the dashboards are not. https://thrivepos.uservoice.com/knowledgebase/articles/1968360-thrive-analytics-overview · retrieved 2026-08-08 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

Documented close-out, replacing the denylisted review-site evidence entirely. Close Register: 'Count all the cash (only cash, not other tenders) in the drawer, including the starting balance, and enter it', which closes and reconciles the drawer in one step; a View Report button shows 'how much of each tender type is expected in the drawer, and what your sales are for that drawer'; after entry 'the system will confirm your close amount and let you know if you were over, right on, or short'; the operator gets 'a final chance to view / print the close register report'. Tip disposition is chosen at close (Pay Tips / Pay Tips to Server / Retain Tips). A separate End Of Day Checklist article covers unclosed tickets, driver close, server close, cash locations ('all registers must be closed and reconciled'), the End of Day Deposit, employees still on the clock, and credit batch settlement. CAVEAT worth recording: that article states 'Although there is no formal End of Day process in the Thr!ve system, this checklist is a good way to ensure that your closing manager has completed all tasks necessary for a successful close' — close-out is per-register plus an advisory checklist, not one enforced store-level day-close. https://thrivepos.uservoice.com/knowledgebase/articles/1132084-close-register-improved-in-v-7-7-0-with-video · retrieved 2026-08-02 adversarially verified

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

Item Sales Report shows per-item quantity, gross ('before any item specific discounts') and net sales and includes toppings/modifiers; Item Sales by Interval (kb 439722) adds time-of-day breakdown in buckets as short as 5 minutes, and a separate Sales By Day Part report exists. Shortfall: a modifier added to another item shows only a count with no sales value of its own — 'this count does not add to the total for the category, as it is not representative of a distinct separate item' — and no revenue-center or order-type filter is documented on the item-level reports. https://thrivepos.uservoice.com/knowledgebase/articles/439721-item-sales-report · retrieved 2026-08-03

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

Void Details Report attributes each void to the performing employee and 'who authorized the void,' with a mandatory-per-workgroup reason (Require Void Reasons, kb 1007758) and timestamps. Store Summary Report separately tracks aggregate 'discounts/comps/coupons/promos' amounts, and discount overrides are permission-gated with a password prompt (Apply A Discount, kb 711744). Shortfall: the employee+approver+reason-code audit trail with timestamps is documented for voids specifically — no article shows a comparable per-instance report for comps and discounts (Store Summary is an aggregate total, not a queryable per-transaction audit list with approver attribution). https://thrivepos.uservoice.com/knowledgebase/articles/439741-void-details-report · retrieved 2026-08-04

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

'Over / Short Report' (Manager Home > Reports > Cash > Over/Short): 'when a register, shift close or deposit is over or short; the system requires that a reason be given as to why the overage or shortage has occurred' - so drawer, shift and deposit are all captured - and each row carries the date, the time, 'the employee that recorded the overage or shortage', 'the cash location that the overage or shortage was recorded on', over vs short, the amount, the tender type, and the reason, with over/short totals at the top; printable and exportable to Excel. The comparison against expected cash is the reconcile step: 'the system may show you the correct amount to enter ... if you are over or short on the amount of cash the system is expecting the "Complete" button will be grayed out until you click the "Over/Short" button', and at register close 'the system will confirm your close amount and let you know if you were over, right on, or short' (kb 1132084). Expected cash accounts for paid-outs and transfers: the Registers Report (kb 439746) shows 'all of the Paid Ins, Paid Outs, Tips, Fees, Transfers, the Deposit and if the drawer was over or short' per cash location, and drawers are assigned per employee 'to hold employees accountable for drawer totals' (kb 817698). Reason codes are configured in Config > Tax/Tender/Cash > Cash Management (kb 821358). https://thrivepos.uservoice.com/knowledgebase/articles/439744-over-short-report · retrieved 2026-08-08

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

Labor reports were added to Thrive Analytics as a product update and labor costs appear as a dashboard metric; sales-per-labor-hour by hour/department/employee is not documented. https://www.thrivepos.com/en-us/thrive-product-news/labor-reports-now-in-thrive-analytics · retrieved 2026-08-01

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

Same evidence as labor-server-performance-metrics: Server Performance Report documents per-employee Sales, Tickets, Tips, Tip Percentage, Average Check, and Average Amount Per Person. Shortfall: no named-category attachment rate is a column on this or any report found, so 'items per check, attachment rate for named categories' is not documented; tips-as-%-of-sales IS documented (Tip Percentage). https://thrivepos.uservoice.com/knowledgebase/articles/439841-server-performance-report · retrieved 2026-08-04

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

Income Summary Report breaks revenue down by order type with Number of Orders, Order Total (gross), Discount Total, Tax Total, Fees Total, Tips Retained, Other Total, and a '% of Sales' split by order type. Shortfall: this is a dine-in/pickup/delivery order-type split, not a per-marketplace breakdown (DoorDash vs Uber Eats vs Grubhub reported separately), and nothing in the article nets out third-party marketplace commission — margin, not just gross revenue, by channel is not documented. https://thrivepos.uservoice.com/knowledgebase/articles/439719-income-summary-report · retrieved 2026-08-04

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

Shortfall: the location roll-up and the ticket view are separate tools, and no side-by-side store comparison table is documented. What is documented: Thrive Analytics is 'a powerful multi-store reporting tool', its Store Summary, Product Mix, Deliveries and Server Performance dashboards carry a location filter ('choose which locations to include, your time frame, order types... touch on the location names to turn them on or off') and 'the dark purple boxes are links to more detailed reports'; Ticket Finder 'compiles up-to-the-minute data from all your locations in one convenient spot', searchable by restaurant location, order type, tender, server, customer, item or ticket #, and 'click on the Ticket # hyperlink to jump to the Detailed view of that ticket' showing customer, timeline, driver and cash location. https://thrivepos.uservoice.com/knowledgebase/articles/1960267-ticket-finder-search-for-tickets · retrieved 2026-08-08 adversarially verified

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

reporting-custom-report-builder

Customisation of canned reports is documented in detail. Customize your Store Summary: 'Click the Customize Button. A window will popup where you can add and remove sections', and the operator can define reporting groups that cut across the menu - 'In addition to your pre-configured departments, you can add a group to combine items in any way you choose ... You can combine items from multiple departments, or limit the set of items in one department, even select just 1 item' - saved, then checked 'as active for the report', with Edit and Delete afterwards. A 'Customize' button likewise narrows other canned reports (Physical Inventory Worksheet, Customer Advanced Search) by status, job type, vendor or category. Thrive Analytics adds dashboard-level self-service: TV - Introduction to Thrive Analytics describes fixed dashboards (Store Summary, Product Mix, Deliveries, Server Performance, All Reports) with right-hand filters for locations, time frame and order types, click-to-filter widgets, drill-through to detail reports, and per-widget data download. Shortfall: every documented mechanism configures, filters or drills a pre-built fixed-shape report - the saved artefact is a section list or an item group inside the Store Summary, not a report the operator composed. No article on either doc host describes a non-developer choosing arbitrary dimensions AND measures from scratch and saving the result as a new report. Checked 2026-08-08 across both the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase: 'report builder', 'custom report', 'create a report', 'build a report', 'new widget' and 'create a dashboard' return nothing, and Sisense - the BI engine behind Thrive Analytics - surfaces only as back-end plumbing in TCC release notes (TCC-1721 credentials per Group, TCC-1818 PDF exports from the newer Sisense API calls, TCC-1647 fault tolerance for Sisense outages), never as an authoring surface exposed to operators. (Withdraws the earlier note's implication that the shortfall was established on the Learning Center alone.) https://thrivepos.uservoice.com/knowledgebase/articles/922542-customize-your-store-summary · retrieved 2026-08-08

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

Scheduling E-mail Reports in Thrive Analytics documents recurring automatic report delivery: configured per employee (Thrive Control Center > Employment > Employees > Scheduled Reports > Add New Scheduled Report), with a chosen report, time zone/DST handling, covered time frame, cadence ('Daily, Weekly or Monthly. Depending on this selection you can pick the time, day, etc.'), and a location filter ('Select the Locations to include... Select All'). Caveat: 'Not all dashboard reports are available, as e-mailed reports must be formatted differently to fit on a PDF page' — coverage is a subset of dashboard reports, not every report. https://thrivepos.uservoice.com/knowledgebase/articles/1963333-scheduling-e-mail-reports-in-thrive-analytics · retrieved 2026-08-04

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

Partial, and the shortfall is the destination. A real transaction-level extraction path exists and is customer-usable - TicketStream, authenticated by a Bearer Token issued one per company in Thrive Control Center under Location Settings > API Access plus a Location Code - and a third-party app demonstrably pulls it on a schedule, which is materially better than the manual-CSV-only the claim excludes. What is absent is any push to a destination the operator controls: 'S3', 'SFTP', 'Snowflake', 'BigQuery' and 'data warehouse' are zero across all 875 documents; every documented sink is Granbury's own cloud. Grade B on an archived vendor KB article; the live URL 302s. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://web.archive.org/web/20211204230248/https://thrivepos.uservoice.com/knowledgebase/articles/1896298-quickbooks-integration · retrieved 2026-09-04

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

An API exists and is first-party documented as shipped, contrary to the earlier reading. The DoorDash Drive article states the prerequisite plainly: 'your store must be on version 8.0.30 and configured to use TicketStream, our new data API. If you are unsure about your store's status, please contact support at 800-750-3947.' The release notes (kb 429421) describe it - 'TicketStream is our cloud-based reporting engine used for API access to POS data', 'Ticket Stream will also offer an API for 3rd party integrations' - and enumerate its coverage across versions: an order feed with item sections, category id/name and revenue centre, customer data and customer group, a timeclock feed with job-type department codes, paid in/out, end-of-day deposit, dispatch/return records, driver close, labor hours and overtime, and reconcile over/short. Shortfalls that keep this off yes: nothing is published - no endpoint, no base URL, no REST or GraphQL reference, no auth model, no schema, no rate limits, and no menu coverage; there is no developer portal or sandbox on any Granbury host; and credentials are not self-service, since the store must be configured for TicketStream by Granbury support. The vendor's own /api/v1/ on the knowledge-base host returns 401 without a client key and robots.txt disallows /api/. https://thrivepos.uservoice.com/knowledgebase/articles/1922671-doordash-drive-integration · retrieved 2026-08-08 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

The vendor defines its own integration surface as a pull API for reporting, and the one documented consumer polls it - the SyncThr!ve article tells operators the system fetches new data every two hours and offers a manual resync of a date range when data is missed. That is an enumerated alternative mechanism, not merely a gap. 'Webhook', 'HMAC', 'signature verification' and 'callback' return zero across all 875 documents, and there is no event catalogue, payload example, retry policy or customer-supplied endpoint anywhere in the P2 census. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. AUDIT (2026-09-04): Not a bare zero-hit: the vendor names its own integration surface a pull reporting engine, and the sole documented third-party consumer polls it - 'the system fetches new data every 2 hours' plus a 'Resync Selected Dates' manual backfill in the archived SyncThr!ve article. A documented alternative mechanism occupying exactly this function is the evidence-rules definition of `no`. The claim's own conjuncts (retry behaviour, payload signature verification) are publication questions, and no developer documentation is published on any host. https://thrivepos.uservoice.com/knowledgebase/articles/429421-version-7-8-x · retrieved 2026-09-04

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

Thrive's published plan matrix bundles the reporting/data product into the monthly price with no separate data fee or revenue share: Analytics Reporting is included in Delivery Plus ($149/mo), The Works ($199/mo) and Pizza Pro (custom), and there is no per-location or per-export data charge listed. Shortfalls: Analytics Reporting is explicitly excluded from the $99/mo Starter plan, so raw-data access is not in the entry-level standard subscription; third-party integrations are metered by tier rather than unlimited - 1 on Starter, 3 on Delivery Plus, 3 on The Works, 'Customized' on Pizza Pro - with the footnote 'integrations may incur additional costs with their providers'; Pizza Pro, the tier that carries 'access to best in class integrations for backoffice management', is custom-quoted; and the TicketStream data API itself has no published price at all and must be enabled by Granbury support (kb 1922671), so whether API access specifically is upcharged remains unstated. https://www.thrivepos.com/pricing · retrieved 2026-08-08

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

Starter ($99) includes only 'Basic Reporting'; Analytics Reporting requires the $149 Delivery Plus tier or above. Core analytics are behind an upgrade. https://www.thrivepos.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

CLAIM: 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. VERDICT: no - the claim is about what the vendor DOCUMENTS, and the census shows it documents nothing. EVIDENCE: `retention`, `purge`, `24 months` and `months of history` return ZERO files across the 372-article census. `archive` returns 4 files and every hit is the PCI housekeeping setting 'Archive data after X days - not really used' (TCC - Credit Card and Gift Configuration), i.e. card-data hygiene, not reporting history. The reporting articles that would state a window - TCC Ticket Finder, Thrive Analytics navigation, scheduled Analytics emails - say only that Ticket Finder data is 'up-to-the-minute' and that a date RANGE may be entered, with no stated floor. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

Partial because exactly one operator-configured threshold alert exists - the approaching-overtime alert, with a user-set X minutes per day and per week - so this is not a bare no. The shortfall: the employee Communications screen enumerates the complete set of alerts deliverable to a person (Daypart Sales, End of Day Deposit, Schedule notices) and every one is an unconditional scheduled send; the remaining alerts in the census are fixed conditions. No operator-defined metric, no threshold on voids, discounts or sales-versus-forecast, and 'anomaly' is zero across all 875 documents. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/847869-timeclock-and-payroll-overview · retrieved 2026-09-04

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

A marketing claim contradicted by the vendor's own documentation, which is why this lands at no rather than yes. Thrive's product-news post for TicketFinder says its 'natural language search options give you the flexibility to search through thousands of tickets' and offers questions like 'all the tickets at Location X that originated via Chowly, were paid with GrubHub, and included a Vegetarian Pizza'. The Customer Learning Center article the post itself links to describes something else: a faceted criteria picker. 'To search, just start typing anything in the search box... You can combine multiple criteria of different types... Selecting multiple criteria will narrow your results. You can not select multiple criteria from the same category (i.e. 2 different order types) in the same search.' Criteria are chosen from typed categories - location, order type, tender type, server, customer name, items, coupons, ticket number, date shortcuts - and the output is a ticket list, detail or table view. That is structured filtering, not a natural-language question, and it returns rows rather than the figure or chart the claim requires. No AI assistant over sales or labor data appears anywhere in the 511-article Learning Center or the 250-URL site. https://thrivepos.uservoice.com/knowledgebase/articles/1960267 · retrieved 2026-09-04 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

KB: the Customer Trend report lists, per identifiable customer, 'the date of their first order, how many orders have been placed in the last 30 days / 60 days / 90 days, the total amount of orders placed by the customer, the date of their last order', sorted by declining or increasing. 'How Many New Customers Have Returned?' documents the new-vs-returning measure: Advanced Search on First Order 'SINCE 120 Days Ago' gives the new-customer count, adding 'Total # of orders > 1' gives the returned count, 'Divide the 2nd number by the 1st number to get the % of customers who have returned'. Advanced Search also filters on loyalty membership, point balance, total spend, ticket average and whether the guest has ordered online, so cohorts tie to identifiable loyalty and online-ordering records. Caveat: the return rate is a two-search division rather than a single pre-built metric. https://thrivepos.uservoice.com/knowledgebase/articles/1178482-how-many-new-customers-have-returned · retrieved 2026-08-08 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

Same forecast engine as labor-demand-labor-forecast: 'The Thr!ve POS system can help you forecast your sales based on historical data,' via a configurable last-year-same-day-of-week +/- % method and/or a last-X-weeks trailing average, combinable together. Create Labor Schedule - Daily (kb 938562) confirms the forecast is exposed in the reporting/scheduling UI at hourly granularity ('gives you a detailed forecast of exactly what sales and deliveries you might have -- by hour') and is directly consumed by the labor-scheduling workflow via a per-day-of-week labor % budget. https://thrivepos.uservoice.com/knowledgebase/articles/938424 · retrieved 2026-08-04

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

Both halves are documented in the vendor's own knowledge base, on independent sources from the denylisted reviews that previously backed this cell. TAX: Manager Home > Reports > Sales > Tax Summary gives 'the break down of sales tax that's been collected during the day' over a date range — total taxable sales, non-taxable sales split by reason (marked non-taxable at sale, marked non-taxable in setup, non-taxable delivery fees), and per active tax type the Taxable Sales, Tax Collected, Tax Uncollected (open/unpaid tickets) and Tax Total, plus a Non-Tax Sale Details line list with ticket number, amount, reason, employee and customer; printable and exportable to Excel. TIPS: 'When Employee Tips Don't Make Minimum Wage' documents setting the local minimum hourly wage at Configuration > Employees > Timeclock Payroll, after which the Payroll report's Total Gross 'adds the shortfall to the wages and tips to make sure minimum wage is met' and Amount To Pay nets off tips already received; daily tip shortfall also surfaces on the Manager Home Sales report. Tips are attributed per server at Close Register via Pay Tips to Server, and an ADP payroll export is documented. https://thrivepos.uservoice.com/knowledgebase/articles/439739-tax-summary-report · retrieved 2026-08-02 adversarially verified

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

A third level exists. Thrive Control Center's documented context model is two-level - 'you have the choice to edit it at the "company" level, which means your changes will be published to all locations, or you can select an individual location to modify. This will create a location override' (TCC: Managing Context of Company and Location) - but the TCC release notes add a Group object between them and make it a first-class one. It was introduced as 'TCC-1527 Group Feature Structure Added' with 'TCC-1527 New Controls for displaying Company/Group/Location', shipped as a headline item ('Major items that are released with this version of TCC include Reseller Option, Group Options within Companies'), and is maintained since: 'TCC-1847 Fixed Adding Locations to Groups failing to add to Group', 'TCC-1827 [TCC Groups]: Fixed Timezone Becoming Null When a Location is Removed From a Group'. Configuration inherits down it - 'TCC-1736 Fixed Location Overrides to reflect to Group instead of Company', 'TCC-1731 Fixed Group level delivery hours populate to location', 'TCC-1778 Fixed Payment Overrides to display on location and group level', 'TCC-1887 Apply group overrides for employment blobs', 'TCC-1715 Diff viewer in the override indicator to get a list of changes vs next hierarchy' - and it is a publish target and a permission scope: 'TCC-1805 Fixed no publish option to a location when changes made to group level', 'TCC-1987 Fix NPE in staging workflow for groups which caused failures publishing to locations', 'TCC-1917 Fixed user permission to upload to image mananger for the group or locations', and 'TCC-1905 Ticket Finder filters by Company, even if employee logged in only has location / group access'. PLUs are namespaced by all three - 'TPOS-9769 Fixed a bug where Duplicate PLUs could be created between Company, Group and Location'. SHORTFALLS: (1) Granbury publishes no configuration article for Groups at all - every reference above is a release-note line, and the one narrative article on scoping (Managing Context) still describes only company and location; (2) it was introduced gated - 'Note that currently only GRS employees can see the Group option in the Company Settings ... it is not available for general use yet' - and no later article records the gate being lifted for operators; (3) analytics is not documented as group-scoped: the reporting filter is a location list, 'You can choose which locations to include, your time frame, order types, etc. Just touch on the location names to turn them on or off' (TV - Introduction to Thrive Analytics). (Withdraws the earlier rationale's claim that 511 articles are the complete corpus and that group vocabulary occurs zero times.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Release-Notes · retrieved 2026-08-08

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

multi-location-central-menu-publish

Thrive Control Center publishes a company-level menu to a chosen set of locations in one action: 'go to Menu > Menu Admin > Publish. On the publish screen, you'll see a list of locations and their status, including when they were last updated ... Select the location(s) to which you plan to publish, and click the Publish button.' Version identity is exposed - 'You can click the 3 dots next to the Last Update date to see the menu version the POS is currently using and the pending version' - and a published menu can be reverted ('it is possible to rollback to a previous version from TCC ... Use the Revert button'). Shortfalls: the history is a per-location last-updated timestamp plus current and pending version numbers, not an audit trail of what was pushed and by whom - no actor attribution is documented anywhere; and the payload cannot be scoped, 'Publishing will include all menu, configuration and hardware changes. There is not currently a way to separate these.' https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-Control-Center-Publish-changes-to-stores · 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

Thrive Control Center implements per-field location overrides on a shared company menu and configuration: 'you have the choice to edit it at the company level, which means your changes will be published to all locations, or you can select an individual location to modify. This will create a location override', with an override indicator shown next to each changed field and a one-click revert - 'you can easily revert the change at the location by clicking on the override indicator: If you revert, the location will be in sync with the company again.' The same inheritance model applies to menu items from category and department (TCC - Revert an item back to category default: 'Any section which has 2 circular arrows is in sync with the category and will be updated if you make changes at the category level'). Shortfall, and it is the half the claim turns on: there is no corporate LOCK. The documented behaviour runs the other way - 'Once a field is changed for a particular location, subsequent changes to that field at the company level will not affect this location' - so an overridden field detaches from corporate control rather than being protected from it, and no article documents making any field non-editable at store level. The only related control is coarse access security: owners can be limited 'to view and change just their location'. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Managing-Context-of-Company-and-Location-in-Thrive-Control-Center · retrieved 2026-08-08

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

Pricing schemes are Thrive's price-tier object and they cover two of the claim's three axes without duplicating the item. Location groups: 'This allows you to set groups of locations to default to different schemes, while still managing all pricing centrally.' Channel: 'You can also create a different scheme for 3rd party orders, which are often charged at a higher price ... If you turn 3rd party default on, it will use this scheme when exporting to your 3rd party online ordering solution', and TCC release note 1.1.8 adds 'Added Kiosk for default pricing scheme'. No duplication: 'navigate to your Items to set the prices for the new scheme. You can set the prices at the category and/or individual item level. In the pricing area, just pick the tab for the proper pricing scheme' - one item record with one price tab per scheme - and coupons can carry a different value per scheme. Future-dating is supported by convention ('just change them in a new scheme, then set that scheme as the default when the day comes'). Shortfall: the daypart axis is not served. TCC DayParts are defined as sections of the day used 'primarily for reporting purposes and to set different default promise times for your orders'; no article ties a pricing scheme to a daypart, and time-of-day price variation is documented only as auto-applying happy-hour OFFERS with time limits, i.e. a discount rather than a price tier. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Using-Pricing-Schemes-to-Manage-Different-Pricing-Levels · 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

Both halves are documented on the current doc host. Scheduling: 'If you wish to have an update take effect later, such as after close of business, you can press the Schedule button. Select the date and time for the publish.' Rollback after activation: 'If a menu is published in error, it is possible to rollback to a previous version from TCC. In the Publish screen, click on the Last Update information to see the menu versions. Use the Revert button to rollback to the most recent version the POS had.' Shortfalls: no per-location timezone interpretation is stated anywhere - the schedule is a single date and time, and nothing says it is resolved in each target location's own zone; the scheduled payload is not frozen, 'If you schedule a publish event, then make changes to the menu after, those changes will be included in the menu that is published'; and publishing cannot be scoped, 'Publishing will include all menu, configuration and hardware changes.' (Withdraws the earlier note's claim that no rollback of an already-published change is documented.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-Control-Center-Publish-changes-to-stores · retrieved 2026-08-08

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

A location is provisioned from company-level configuration rather than built from scratch. TCC's import article documents the payload: 'Below the POS Menu and Settings option you can turn on Default Configuration Settings. You should generally turn this on the first time you are importing for a company, as this will set all the configuration defaults at the company level, including hours, order types, printers, stations, cash management, etc.' Additional locations attach to an existing company menu - 'If you are importing a location's information to an existing menu, it will create overrides for that location for anything that differs' - and matching is by item name, not PLU. Tax structures are company-level objects modified per location (TCC - Tax Structure Set Up), tender types are configured under Payments, credit and gift carry company-level security and print defaults with only merchant credentials per location, and employment, job types and security now live in TCC and publish like other configuration. Shortfalls: (1) no expected time-to-open for a new location is published on thrivepos.com or in either doc corpus; (2) there is no named clone-a-template action - the documented route is an import from one existing typical location plus company defaults, and re-running it is discouraged ('Once you've imported these defaults it is not recommended that you do it again, as this may cause discrepancies in override calculations'). (Withdraws the earlier note's master-store PLU-broadcast evidence, which TCC's own documentation supersedes.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/Import-menus-in-Thrive-Control-Center · retrieved 2026-08-08

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

Granbury does document a franchise arrangement, and it is one tenant with scoped permissions rather than two tenants. TCC - How To Add A Company: 'Whenever possible, we want to group all franchisee locations for a particular brand under one company. This will make it much easier to share company menus, images, etc. and to provide consolidated reporting. Because security settings allow you to limit individual owners to view & change just their location, it is fine to group them under the company even if they operate fairly independently.' So the two halves the claim asks about are both present in outline - corporate gets consolidated reporting across franchisee locations and enforces configuration by publishing the company menu and settings down to them, while an individual franchisee owner is confined by security to view and change only their own location, with a Group level available between company and location ('TCC-1887 Apply group overrides for employment blobs', 'TCC-1905 Ticket Finder filters by Company, even if employee logged in only has location / group access'). SHORTFALLS: (1) there is no franchisor/franchisee tenant boundary - the article's whole point is that the franchisee's locations live inside the franchisor's company record, and it warns 'Think carefully and be sure you understand the implications before adding a new company for an existing brand'; (2) no article enumerates which data a franchisee owns exclusively - employment (employees, job types, security) is a TCC company-level object published downward, and the only per-location-only item documented is merchant credentials; (3) the separate 'Brand' construct that ties locations across different companies is incomplete by the vendor's own statement ('this is not yet fully developed in the menu management area'); (4) thrivepos.com's franchisor pillar page is still unpublished placeholder text. (Withdraws the earlier rationale's claim that 511 articles are the complete corpus and that 'franchise' never occurs.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-Control-Center-How-To-Add-A-Company-to-Thr-ve-Control-Center · retrieved 2026-08-08

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

CLAIM: automatic calculation of franchise royalty, ad-fund and marketing-fee amounts from POS net sales on a schedule, with a configurable royalty basis. VERDICT: no. EVIDENCE: the stem `royalt` returns ZERO files across the 372-article census, as do `ad fund`, `ad-fund`, `marketing fee` and `franchise fee`. The stem `franchis` returns exactly ONE hit and it is organisational, not financial: 'Whenever possible, we want to group all franchisee locations for a particular brand under one company' (TCC - How To Add A Company to Thr!ve Control Center). CONTROL TRAP WORTH RECORDING: a word-boundary `franchise` control returns zero and would have hidden that single real hit - only the stem found it. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

CLAIM: automated ACH/debit collection of calculated royalties from franchisee accounts, with a franchisee-visible statement of what was charged. VERDICT: no. EVIDENCE: `ACH` and the stem `royalt` both return ZERO files across the 372-article census, and there is nothing to collect because no royalty is calculated (see multi-location-royalty-calculation). The census's money-movement documentation is merchant-account and gift-card configuration (TCC - Credit Card and Gift Configuration) and cash-location transfers to and from the Main Safe; no franchisee debit appears in it. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 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

Shortfall: no documented store-vs-store ranking or variance flagging, and labor sits outside the web dashboards. KB: 'Thrive Analytics is a powerful multi-store reporting tool that lets you easily access your data for all your locations', with dashboards for Store Summary, Product Mix (item mix), Deliveries and Server Performance, a filter to 'choose which locations to include, your time frame, order types', click-to-filter widgets, per-widget data download and an All Reports dashboard listing everything available. Labor %, discounts and voids are covered by the on-premise POS report set rather than by the consolidated view; the Analytics app compares 'single locations or multiple' for sales and labor. Aggregation over a selected set of locations is documented; ranking and variance flags are not. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-Introduction-to-Thrive-Analytics · retrieved 2026-08-08 adversarially verified

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

Thrive Control Center holds one company menu with per-location overrides, and TCC's own import article states the matching rule: "Note: TCC does not rely on PLU#s to match items. Any item with an identical name will be considered the same item, any differences in name will create a new item as an override for that location", with a location imported into an existing menu producing "overrides for that location for anything that differs". Managing Context confirms the model - editing at the "company" level publishes to all locations, editing a location "will create a location override". An item a store has locally repriced therefore still reports under the one company item, and Thrive Analytics is "a powerful multi-store reporting tool that lets you easily access your data for all your locations" with a Product Mix dashboard and a filter to "choose which locations to include". Named shortfall: the renamed half of the claim fails outright - identity is the item NAME, so a store that renames an item gets a separate item rather than a mapping onto the corporate item, and there is no documented mapping layer for locally created or renamed items. (Withdraws the earlier note's PLU-based shortfall, which the current TCC documentation contradicts.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/Import-menus-in-Thrive-Control-Center · retrieved 2026-08-08

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

Partial with a two-part shortfall. Thrive does not hold gift balances at all: the article enumerates the processors that do (Vantiv/WorldPay Gift, Open Edge Gift, Cayan Gift, and gateway gift via Givex, Valuetec, Valulink and STS), and the current TCC setup binds those credentials per location, so whether a card sold at one store redeems at another is a property of the operator's processor account rather than a Thrive capability. The reporting half the claim also requires is documented absent: the Sales - Gift Certificates report is a daily sold-and-redeemed traffic listing, not an outstanding-liability balance. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/632905-supported-credit-and-gift-processors · retrieved 2026-09-04

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

Thr!ve Loyalty (SalesBuilder) holds one loyalty record across stores and the POS reconciles to it at customer selection: 'as you select the customer, the system will check to see if they have recently enrolled in loyalty online or via another store. The system will look for a matching email or phone # in the loyalty system. If it finds it, this customer will now be connected to that loyalty record.' Points and offer redemptions are written to and read from that external system ('The system will update SalesBuilder when the order is closed, and the offer will be marked redeemed'). Shortfalls: this is the separately-licensed SalesBuilder add-on rather than the base POS, and the link is a fuzzy match on email or mobile number rather than one identity - the same article documents fragmentation and the KB has a How To Merge Customer Accounts procedure. The built-in alternative, Using The Internal Loyalty Program (kb 1187437, v7.8.0+), tracks points against the store's own customer database and says nothing about sharing a balance across locations, and no article states that stored order history is shared brand-wide. https://thrivepos.uservoice.com/knowledgebase/articles/668170-using-the-external-salesbuilder-loyalty-program-v · retrieved 2026-08-08

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

CLAIM: a single location or terminal can operate two or more distinct brands or virtual brands with separate menus, branding and separately reportable revenue on the same hardware and drawer. VERDICT: no. EVIDENCE: `virtual brand` and `multi-brand` return ZERO files across the 372-article census. The only Brand construct Thrive documents points the OTHER WAY - many locations onto one brand, not many brands onto one location: 'The "Brand" concept is designed to allow you to tie locations that belong to different companies back to 1 brand, however this is not yet fully developed in the menu management area' (TCC - How To Add A Company to Thr!ve Control Center), in the same article that groups 'all franchisee locations for a particular brand under one company'. That is the inverse relation, not a part of the claim, so `partial` would be wrong. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · 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 a centrally managed, per-location-overridable object in Thrive Control Center: 'You may want to create a tax structure, such as sales tax, at the company level, but modify the tax rates per location.' Multiple simultaneous structures are supported ('You can add multiple tax structures if needed. Some items may use a different tax rate, or both structures') and attach at department, category or item level. Jurisdiction rules are covered: 'Rate varies by order type' with a default type used before a type is selected; inclusive versus exclusive via 'Display tax in item price'; 'Applies for Discounts Before / After'; and separate toggles for auto gratuity, misc charges, delivery fee and gift-card sales. Since POS 8.3.40 there is explicit multi-jurisdiction delivery handling - Tax Rates by Zone - where a structure flagged 'Valid by Zone' is designated the default ('Setting this tax structure as default applies it to in-store orders and deliveries outside any zone') and additional zone-specific structures apply only to deliveries inside the zones selected, so a restaurant delivering into 'a neighboring county or city' can 'make sure each order is taxed correctly without any manual adjustments'. Shortfall: exemption is not per location. The documented mechanisms are a customer-level Non Taxable toggle with a non-taxable ID, and a per-order Non-Tax Sale option; no article documents exempting a location or applying a location-specific exemption certificate. (Withdraws the earlier note's shortfall that multi-store tax structures are aligned by hand through matching PLUs - that describes the pre-TCC model, which TCC's own documentation supersedes.) https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Tax-Structure-Set-Up-in-Thrive-Control-Center · retrieved 2026-08-08

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

CLAIM: an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. VERDICT: no. EVIDENCE: `audit log`, `change log` and `who changed` return ZERO files across the 372-article census. The TCC configuration articles that would host such a feature are all present and read as write-only screens - Menus Admin, Pricing Schemes, Tax Structure, Credit & Gift, Employment / Job Types, Printer Options and Print Routing. The one corporate-visibility tool that IS documented, 'TCC - Ticket Finder Search Tool', is a TICKET search over 'items ordered, coupons used, order source, customer information, tender type used, employee, order type' with a per-ticket history timeline - transaction history, not configuration history. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

multi-location-enterprise-api

Shortfall: the API exists but is undocumented for consumers and provisioned by the vendor. TCC's Add A Company screen carries a company-level switch - 'Turn on the TicketStream API only if any 3rd party integrations will be used. Turn it OFF for most customers, this will not impact the ability to get Analytics' - and the DoorDash Drive article requires a store 'configured to use TicketStream, our new data API'. Release notes show its shape: order feed carrying customer data and Customer Group, dispatch and driver-close and return records, a No Sale report, localized business date and timezone offset, historical data sync. No public reference, endpoint list, authentication model or statement that one authenticated call returns all locations exists on either doc host. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Thrive-Control-Center-How-To-Add-A-Company-to-Thr-ve-Control-Center · retrieved 2026-08-08 adversarially verified

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

multi-location-central-labor-policy

The rules exist and are enforced at the terminal, not merely reported. Config > Employees > Timeclock and Payroll 'allows you to manage specific features concerning timeclock functions, how you manage overtime, break and lunch enforcement': overtime after 8 hours per day, after 40 per week, and a 'California Overtime' option for more than 12 hours per day or 7 consecutive work days; 'Alert Me Of Approaching Overtime Within X Mins Per Day' or per week; 'Clock Out For Breaks' and 'Clock Out For Lunch' make clocking out mandatory and with a Default Break Length 'they will not be able to clock in until that time has expired'; 'Dock For Long Breaks' and 'Dock For Long Lunches'; and a Break Enforcement rule builder taking break minutes, paid or unpaid, and the hours worked before the break is due, whose rules also drive the schedule. Since 8.1 this configuration is no longer store-only: employment lives in Thrive Control Center (Employment > Employees, Job Types, and Employment > Security > System Configuration), is published to locations like other configuration, and TCC note TCC-1887 records 'Apply group overrides for employment blobs' - so a chain can set policy at company or location-group level and override per location. Shortfalls: (1) no predictive-scheduling or fair-workweek compliance option exists on the screen and 'predictive scheduling' appears nowhere in either corpus; (2) schedule enforcement at clock-in is delivered by a third-party integration rather than natively - the 8.3.35 notes record fixes to 'Legacy Employment Schedule Verification' and to '7Shifts Schedule Verification preventing users from clocking in and overriding schedule enforcement', with 7shifts registered per location in TCC (TCC-2003 'Register 7shifts Location to Location in TCC'; TPOS-8706 '7Shifts Integration Live'). https://thrivepos.uservoice.com/knowledgebase/articles/847869-timeclock-and-payroll-overview · retrieved 2026-08-08

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

Hardware store stocks generic Computers, Tablets, Touch Screen terminals and Display Kits rather than a proprietary vendor terminal line, suggesting commodity PC/tablet hardware; no explicit statement that operator-sourced hardware is supported. https://thrivehardware.com/ · 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

Hardware Requirements (Support / Hardware topic) names the client platforms and states minimums. Vendor-offered workstations: a 15.6-inch Android unit ('Android 8.1 OS, 4GB DDRIII RAM, with one year warranty'), a 14-inch Android unit ('Android Pie 9.0 OS, 3GB RAM, 32GB storage, with one year warranty'), a 10.2-inch iPad with enclosure and base, and a 14-inch all-in-one Intel Dual Core i3-6100 2.3GHz Skylake Linux workstation, each paired with 'our recommended Intel Nuc Computer i7 16G RAM SSD (Linux) as a dedicated server'. For bring-your-own hardware the article gives a minimum-requirements table: 'Workstations can be Android or iPad tablets, or PC-based Linux or Windows', workstation minimums Intel i5 or i3 3.1GHz, 8GB DDR3, 256GB disk, operating system 'Linux CentOS 6.7+, Windows 10 Pro'; server minimums Intel i7-2600 or i7-6700, 16GB DDR3, 320GB 7200 or SSD, 'Linux CentOS 6.7+', with port, NIC and video requirements listed. Also specified: touch screens '15" or greater, 1024 x 768 native resolution, ELO Touch compatible - USB', printers that 'can run EPSON Emulation Mode', an iPad mini or Android tablet as customer display, and Firefox 'with specific configuration changes made to operate securely and in kiosk mode'. Gap: no minimum Android or iOS version is stated for customer-supplied tablets. https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements · retrieved 2026-08-08

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

Rests on P4, retested: the /products index names 46 products under 15 categories and the corpus holds 47 product paths of which only android-tabletworkstation is a real 404 - two enumerations agreeing on 46. Thrive's own hardware store sells no purpose-built handheld: the only mobile device in the closed census is a consumer 9th-generation iPad, alongside strap-on MSR swipes. 'rugged' occurs once in the whole store and it describes the KDS bump bar, not a terminal. AUDIT (2026-09-04): P4 IS BROKEN, but this verdict survives without it. 'Hardware Requirements' (kb 423702) opens 'Thrive Recommended Hardware / We offer a variety of hardware solutions to meet your needs!' and enumerates four device families - 15.6in Android, 14in Android with foldable or printer base, enclosed 10.2in iPad, Linux all-in-one - every one a counter or wall-mounted unit. That is a second independent enumeration agreeing with the storefront. Decisively, the claim requires a PUBLISHED drop rating and IP ingress rating, and neither exists anywhere in the 875 documents. https://www.thrivehardware.com/products/ipad-pdc88 · retrieved 2026-09-04

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

Rests on P4 (the closed 46-product census). There is no purpose-built handheld in the catalogue to carry a swappable battery, and the tablet SKUs publish warranty terms only - no battery capacity, runtime, or replaceability. 'hot-swap', 'hot swap' and 'swappable' return zero across the whole 2.19 MB corpus; the only battery products sold are UPS units. AUDIT (2026-09-04): The cited warranty page is part of what breaks P4 (it extends warranty on 'any Android tablet' while the catalogue lists none), but the verdict does not need P4. There is no purpose-built handheld in either enumeration to carry a swappable battery, and the claim's disjunct - that the vendor publishes a rated battery life for a full shift - fails outright: every 'battery' occurrence is a UPS or in-store backup, and the published tablet specifications stop at screen size, OS, RAM and a one-year warranty. https://www.thrivehardware.com/products/android-tablet-warranty-extension · retrieved 2026-09-04

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

Rests on P4. The one tablet Thrive sells is explicitly the Wi-Fi-only iPad variant, not the cellular model, and the closed 46-product census carries Router, WiFi and Switch categories with no cellular or LTE product of any kind. Word-boundary greps for 'LTE', 'cellular' and '4G' return ZERO across all 875 documents, including the P2 Learning Center census. AUDIT (2026-09-04): Held only after correcting the note's overstatement: the 'ZERO across all 875 documents' is a zero over a corpus that excludes www.thrivepos.com's blog, where prior research found a page on cellular backup during internet outages. That page does not rescue the claim - it is a purchasing recommendation to the operator, not a documented device radio or vendor-supplied failover - and the positive evidence stands: the one tablet Thrive sells is the Wi-Fi-only iPad variant, and the Router, WiFi and Switch categories carry no cellular SKU. https://www.thrivehardware.com/products/ipad-pdc88 · retrieved 2026-09-04

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

Thrive runs on an in-store Linux server, and the Version 8.0 release notes publish an explicit degradation list under 'Improved Tools for Internet Connectivity Problems': active network monitoring of Google Maps, SalesBuilder, Thr!ve Online and Dr!ve, with notification in the POS Instant Messaging section 'if a site is unreachable, or if your internet is down'; 'Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollments, transactions and redemptions, Thr!ve Online or Let's Get menu updates, Dr!ve status updates, E-mail notifications are all sent as soon as [we] have a connection'; 'Other actions that can't be saved for later - such as mapping or driving directions, will time out quickly so as not to interfere with your POS processes'; and 'Credit card processing will still attempt to connect, and give you an authorize later option if a connection is not available.' The card path is documented end to end at the batch: 'At the bottom of the screen, you may see information about unauthorized charges. This can occur if you had an internet outage and the system was unable to reach the processor at the time of the transaction. You must authorize these transactions before closing the batch' (Credit Batch - WorldPay Element / EMV, kb 1857904). Store Setup Overview additionally offers 'Enable Internet Functions... Turn this off if your internet is temporarily down', confirming order entry, LAN printing and cash continue locally. Not covered: behaviour when the in-store server itself fails, beyond the recommendation that 'All systems should have a backup server/workstations to use if primary fails'. https://thrivepos.uservoice.com/knowledgebase/articles/1867636-version-8-0-legacy · 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

ChefTab is a third-party product line from Select Electronics Corp, distributed by MicroPlus Inc., with its own storefront and hardware SKUs. Thrive markets ChefTabX as 'now part of the Thrive POS family' — a phrase consistent with an acquisition or a Jonas-sibling relationship but not evidence Thrive built or owns it. Compounding this: KDS is bundled only in the quote-only Pizza Pro tier, so it is neither priced nor guaranteed to any published-plan buyer. 'First-party' is unproven. https://micropluskds.com/ · retrieved 2026-08-01 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

Thrive ships its own self-order kiosk, evidenced by a dated first-party release stream on the current doc host: 'Release notes - FireFly Thr!ve P O S - Kiosk 0.1.31, 1/14/2026'. It runs the POS menu and modifier engine rather than a separate catalogue - release items cover sized items auto-advancing to toppings 'Once Size/Style requirements are fulfilled', nested requirement minimum and maximum topping pop-ups, topping limits with item-based overrides, inclusions carrying a quantity, offers and time-based offers, and 'half toppings ... submitted as half toppings from Kiosk' - and it is configured from Thrive Control Center ('Unhide Kiosk, Kiosk Menu and Kiosk Design', modifier sort order following 'TCC>Kiosk Menu', 'Added Active Kiosk options to Order Types for use on Kiosk', 'Added Kiosk for default pricing scheme', 'Added Flag on payment types to toggle on or off for KIOSK', and kiosk locations disabled 'when the subscription is inactive in TCC'). Payment is integrated: card and cash tenders where 'selecting a tender prompts payment, no Submit required', customer receipt and credit slip printing on payment, EMV handling ('Do not allow partial approval on Kiosk EMV transactions'), and cash-discount pricing. Several entries are filed against Thrive Online, so the kiosk is Thrive's own product built on TOL, not a resold third-party kiosk. Shortfalls: (1) no hardware is documented - neither a countertop nor a freestanding form factor is named in either doc corpus, thrivehardware.com lists no kiosk line, and thrivepos.com/kiosk-ordering carries no model, availability or price; (2) no ADA or accessibility statement exists for the kiosk - the only accessibility article on either host covers the Thrive Online website ('Thrive Online, in its base configuration, has passed these scans at a level AA compliance'), which is the ordering site, not the in-store terminal. https://granburysolutions.my.site.com/KnowledgeBase/s/article/KIOSK-RELEASE-NOTES-0-1-26-and-Up · retrieved 2026-08-08

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

The claim needs menu boards, confirmation displays, headsets AND a timer; none exists. The article walks the COMPLETE Drive Thru option list with no timing or speed-of-service option, so the timer absence is a within-document enumeration. The hardware absence rests on P4: the closed 46-product catalogue has no outdoor menu board, confirmation display or speaker/headset SKU, and 'menu board', 'headset' and 'confirmation display' return zero corpus-wide. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. AUDIT (2026-09-04): A four-way conjunction that fails on a leg not needing the broken P4: 'Hardware Requirements' enumerates the supported peripheral CLASSES - touch screens, printers, customer displays, magnetic stripe readers - with no outdoor menu board, order confirmation display, speaker or headset, and 'menu board' and 'headset' are zero corpus-wide. The timer leg is weaker than the note implies, but the hardware legs alone defeat the conjunction. https://thrivepos.uservoice.com/knowledgebase/articles/850887-in-house-orders-drive-thru · retrieved 2026-09-04

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

Hardware catalog carries a general Printers category rather than a vendor-branded-only line, implying standard thermal printer support; no manufacturer compatibility list is published. https://thrivehardware.com/ · 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

CORRECTED 2026-09-04 (203rd) - the prior note said 'No scales or customer-facing displays listed', and the display half is FALSE. The catalogue (46 live products, read in full for the first time this session) sells 'Thrive Customer Display Kit - Kit includes Customer Display Tablet and Stand, for use with Thrive Android, iPad or Computer stations as a rear display for customer signature / tip / email capture.' The 15 published categories are Backup Power, CallerID, Cash Drawer, Computer, Credit Card Device, Display Kits, Kitchen, Printers, Router, Services, Supplies, Switch, Tablets, Touch Screen and WiFi, with named third-party makes and models throughout: Epson TM-T20IV / TM-U220B / TM-M30II, Star SP700, Ingenico Lane 3600 and Lane 7000, Mikrotik hEX RB750Gr3, Ubiquiti U6+, Cognitive TPG DLXI, MagTek iDynamo5 and Dynamag, and a ChefTab X KDS controller with a metal USB bump bar. Scales remain genuinely absent from the catalogue - that half of the old note stands. IMPORTANT LIMIT, established on audit this session: the storefront is a census of what Thrive SELLS ONLINE, not of what it supports - the KB's own 'Supported EMV Devices' article names six pinpads of which the store lists only two, and 'Hardware Requirements' describes 15.6-inch and 14-inch Android touchscreens the store does not carry. https://www.thrivehardware.com/products · retrieved 2026-09-04

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 happens on a separate networked PIN entry device rather than in the POS: 'Press the Pin Pad button... The EMV Device will instruct the customer to insert chip card or swipe a non-chip card. At this point the customer could also tap any NFC payment card or device to pay with Apple Pay or Google Pay.' The 8.0 release notes name the device - 'EMV integration with the Ingenico IPP320 device. This is an ethernet device' - and Granbury states the scope benefit: 'Using an EMV/chip card... removes credit card data from your POS system, helping you with PCI compliance. EMV is available on the Worldpay platform as of version 8.0.' Supported Credit and Gift Processors (kb 632905) describes the integrations as '100% encrypted, tokenized direct integration'. Shortfalls: (1) no validated P2PE solution is claimed - 'P2PE' occurs zero times in all 511 Customer Learning Center articles, and no PCI PTS or P2PE listing number is cited; (2) the merchant's SAQ type is never stated - 'SAQ' also occurs zero times, and the only PCI language in the corpus concerns administrative passwords and PA-DSS password rules; (3) Credit Configuration documents 'Allow Bypass of PIN Pad', which lets staff 'select Credit on the tender screen to enter credit card data directly into the POS system' for phone orders, so the application is not unconditionally out of scope. https://thrivepos.uservoice.com/knowledgebase/articles/1887319-paying-with-an-emv-device · 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

'Supported EMV Devices - WP and WP Gateway' on the current-product KnowledgeBase is a per-processor enumeration of the card-acceptance hardware Thrive certifies, and it contains no commodity-phone or tablet-NFC path. Under Worldpay EMV it lists Verifone Mx915, Ingenico iPP320 (deprecated), Lane 3000, Link 2500, Lane 7000 and Lane 3600; it then enumerates the gateway processors separately - Fiserv, Chase Paymentech, Global Payments and TSYS - each with its own Verifone/Ingenico device list, noting 'Gatway accounts will purchase their own EMV device from the list below'. The article states that the list is the maintained current set: 'As newer devices are added and certified through Thrive POS, we will will add to the list.' Every entry is a separate reader. Corroborating: 'Tap to Pay', 'tap to phone' and 'softPOS' occur zero times across both published corpora (511 UserVoice articles and 251 Granbury KnowledgeBase articles, including the 8.2/8.3.x and kiosk release-note streams through 2026); contactless is documented only as a pinpad capability - 'Retail Base Version 23 or higher is required to use QuickChip / Pre-Read / Contactless features' on the EMV device - and the workstation card-entry paths are the Pin Pad button, keyed entry via 'Allow Bypass of Pin Pad' and an attached encrypted MSR. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Support-EMV-Devices-WP-and-WP-Gateway · retrieved 2026-08-08

Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator

hardware-pricing-transparency

CORRECTED 2026-09-04 (203rd). The prior verdict was 'no', on the note 'thrivehardware.com exposes category navigation only; no SKU-level prices are published on the public site.' That is false and was contradicted inside this same file, which already cited 'Additional Onsite Day, $800.00'. Every product page publishes a price: 92 price strings across the catalogue, e.g. Star Printer Ribbon $4.00, iPad Credit Card Swipe, Thrive Server 2026 $1,161.00, Equus i3 Workstation/Backup Server $939.00. The catalogue was never read before because the record's host note wrongly treated thrivehardware.com as barring ClaudeBot; its Squarespace robots.txt stacks ~29 AI user-agent tokens into ONE group ending in 'User-agent: *' whose only rules are /config, /search, /account, /api/, /static/ and query patterns, so /products is permitted (confirmed with scripts/lib/robots.mjs: blanketBar null, refusedForUs('/products/...') null). Shortfall keeping this off a stronger reading: hardware pricing is published, software pricing tiers are published, but installation, training and menu-build services are priced per hour or per day 'subject to availability' and the processing rate remains quote-only. https://www.thrivehardware.com/products · retrieved 2026-09-04

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

A dedicated hardware storefront implies outright purchase, but no ownership-vs-lease statement is published. Vendor's own blog warns operators about 'free' hardware deals, implying financed/bundled arrangements are common in the market and possibly in their own quotes. https://thrivehardware.com/ · retrieved 2026-08-01

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

CLAIM: vendor DOCUMENTATION confirms whether hardware purchased from the vendor remains usable with other software after cancellation. VERDICT: no - the prior passes held this unknown because their corpora were floors; it is now bounded by a COMPLETE enumeration of every public surface Granbury publishes, and no such document exists anywhere on any of them. NEW SURFACE (327th): www.thrivepos.com is a HubSpot CMS site (hs-scripts.com/29066.js, /hs-fs/, _hcms), so it answers the HubSpot content-search API, a route no prior pass used: https://www.thrivepos.com/_hcms/search?term=<t>&limit=100&offset=<n>, swept with 49 terms and paged to exhaustion -> 254 distinct URLs (202 BLOG_POST, 50 SITE_PAGE, 2 LISTING_PAGE). That search index is the CMS's own content store, not a sitemap, and it returns UNLINKED pages. The complete 50-page SITE_PAGE list contains NO terms of service, MSA, EULA, sales agreement, warranty or equipment-ownership page; the only legal documents on the whole site are the two in the footer, 'Privacy Policy' and 'SMS Service Terms'. Guessed legal paths all return the SAME 51,188-byte body as a nonsense control (/terms, /terms-and-conditions/, /msa, /eula, /legal, /merchant-agreement vs /zzz-nonsense-control - identical length, so they are catch-all 404s, not documents). SECOND HOST: www.thrivehardware.com/sitemap.xml is a complete 52-URL census (2 pages, /returns, /contact, /computers, /products and 47 /products/* SKUs) with no terms, policies or legal page; /terms, /terms-of-service and /policies/terms-of-service all return the same 88,196-byte body as /zzz-nonsense-ctl. THIRD HOST: www.granburysolutions.com no longer exists as a site - every path (/, /terms, /legal) 301s to https://www.thrivepos.com/granbury-solutions, so there is no separate corporate legal surface. FOURTH: the 884-article two-corpus KB census (thrivepos.uservoice.com 511 + granburysolutions.my.site.com/KnowledgeBase 372, built 2026-09-17) returns 'terminate' 0, 'termination' 0, 'cancel service' 0. That is now four enumerated surfaces, not a sample. The nearest positive evidence remains non-contractual and cannot carry a yes: Thrive supports bring-your-own commodity kit ('Using your own hardware? Check below for minimum requirements', thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements) and thrivehardware.com sells ordinary Epson/Star printers, Equus/i3 workstations and Android tablets, but the claim asks for DOCUMENTED confirmation and Granbury publishes none. Retrieved 2026-09-18. https://www.thrivehardware.com/sitemap.xml · retrieved 2026-09-18 adversarially verified

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

A warranty term is published: 'Granbury Solutions offers a 60 day warranty on all hardware', with many items also carrying manufacturer warranties of up to 3 years from purchase, and the KB's Hardware Requirements article states 'one year warranty' on each of the two Thrive Android tablet options. A formal returns process exists - 'NO RETURNS WILL BE ACCEPTED WITHOUT AN RMA NUMBER', obtained from rma@thrivepos.com - and 'Any new, in original packing, equipment may be exchanged for another item for up to 60 days after the date of purchase', or refunded within 60 days 'less a 15% restocking fee, provided the item is returned at customer expense'. Shortfall: that 60-day window is a buyer's-remorse exchange, not a failure-replacement SLA. For defective equipment the page only directs the merchant to call support or the Customer Care Portal for troubleshooting, with next steps depending on purchase date and equipment type; no advance-exchange or cross-ship programme is offered and no turnaround commitment (next-business-day depot swap or otherwise) is published on thrivehardware.com, thrivepos.com or in the 511-article Customer Learning Center. https://www.thrivehardware.com/returns · 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

Driver app is explicitly designed to run on drivers' own phones ('everything they need on their phone'), but no documented BYOD permission or security model. https://www.thrivepos.com/en-us/features · retrieved 2026-08-01

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

CLAIM: 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. VERDICT: no, on every conjunct. EVIDENCE: `remote reboot`, `staged rollout`, `terminal status`, `device management`, `remote management` and `MDM` return ZERO files across the 372-article census. `reboot` occurs once and it is manual and physical: 'hold down the yellow button and the # button on the EMV device and the device will reboot' (Support - EMV Devices WP and WP Gateway). The TCC Hardware articles present in the census - 'Stations and Cash Drawer Configuration in Thrive Control Center' and 'TCC - Printer Options and Print Routing by Station and Order Type' - configure devices and never report their state. The only liveness surface Thrive publishes is the separate UptimeRobot page status.thrivepos.com, which monitors Thrive's own online SERVICES, not a merchant's terminals. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. https://granburysolutions.my.site.com/KnowledgeBase · retrieved 2026-09-17 adversarially verified

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

Caller ID units are a stocked category in the first-party hardware store — a deliberate pizza phone-order capability most cloud POS vendors have abandoned. A reviewer separately references a billable 'call center feature'. https://thrivehardware.com/ · retrieved 2026-08-01

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

extensibility-public-api-docs

Corrected: the earlier claim that the public Learning Center holds "zero API, webhook, or developer material" is wrong. Thrive names and describes a data API in its own release notes - "TicketStream is our cloud-based reporting engine used for API access to POS data" (Version 7.8.x, re-fetched 2026-08-08) - and itemises its surface release by release: "Add the 'return' report to the API", "Enhanced TicketStream: Add Customer Group to customer data on order feed", "Resolved order date issues with TicketStream Orders API" (Version 8.0 Legacy, kb 1867636). What does not exist is a public, self-serve API REFERENCE. Across thrivepos.uservoice.com (511 articles), granburysolutions.my.site.com/KnowledgeBase (251) and the grsalesbuilder.uservoice.com mirror (39) there is no endpoint list, request or response schema, authentication scheme or sandbox: "api reference" and "sandbox" return zero hits on all three, "swagger" returns one hit and it is an internal Jira item ("Make Altura swagger documentation accessible again"), "api key" returns only Google Maps client-id migration tickets, and every "endpoint" hit is an internal TCC or TPOS ticket. Access is positively gated rather than merely undocumented: TicketStream is a per-company switch only a Granbury administrator sets in Thrive Control Center - "Turn on the TicketStream API only if any 3rd party integrations will be used. Turn it OFF for most customers" - and operators are told "Your store must be on version 8.0.30 and configured to use TicketStream, our new data API... please contact support". developer.thrivepos.com does not resolve (curl, 2026-08-08). None of these corpora is certified complete, but the gating statement is first-party positive evidence, not an absence argument. https://thrivepos.uservoice.com/knowledgebase/articles/429421-version-7-8-x · retrieved 2026-08-08 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

The tier matrix is the vendor's own complete statement of what each subscription includes, and integration access is metered rather than included: Third Party Integrations are absent from the Starter plan, capped at 'Includes 1 Integration' on Delivery Plus, 'Includes 3 Integrations' on The Works, and 'Customized' on Pizza Pro, with the standing footnote 'Integrations may incur additional costs with their providers'. No API line appears in any tier. Connecting anything therefore requires both an upgraded plan and, on Thrive's own account, a further payment to the partner - which is what the claim excludes. Corroborated at the partner level: the 7shifts integration page states 'No. 7shifts is a separate subscription billed by 7shifts.' https://www.thrivepos.com/pricing · retrieved 2026-09-04 adversarially verified

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

extensibility-partner-revshare

Positive absence on a publication claim. The Software Integrations page is Thrive's whole public account of its partner programme - it describes the categories it brokers (loyalty, gift cards, inventory and back-office, phone services, staff scheduling, third-party ordering through Deliverect) and says only 'Integrations may incur additional costs with their providers', which is a warning rather than a term. No referral fee, revenue-share percentage or per-location partner fee is stated there, on the pricing page's integration rows, or anywhere in the 250-URL sitemap, and Thrive publishes no partner agreement - its complete legal set is a privacy policy and SMS terms. https://www.thrivepos.com/en-us/thrive-pos-third-party-integrations · retrieved 2026-09-04 adversarially verified

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

extensibility-free-sandbox

The claim asks whether a developer without a paid production account can get a test environment, and Thrive publishes no developer entry point at all: no developer or API page in the 250-URL sitemap, no api./developer./docs. host in DNS, and no API or developer category among the 43 in the 511-article Customer Learning Center. Integration is a brokered, account-holder path by design - the 7shifts page says 'Thrive POS handles setup and configuration' and directs existing customers to 'Contact support to get 7shifts connected' - so there is no signup, no seeded data and no sandbox to be had without an account. https://www.thrivepos.com/pricing · retrieved 2026-09-04 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

RE-VERIFICATION (330th) - THE `no` IS FALSIFIED IN PART BY SHIPPED VENDOR CODE. New surface: the Thrive Control Center (TCC) production client's own public source maps, already on disk at .cache/q329/thrive-pos/tcc/ (app.b3306bf3.js.map + 242 chunk maps; nonsense-sibling control tcc/app.b3306bf3.js.NONSENSE.map was NOT a map, so the maps are real). chunk-0956b833.a02b0604.js.map carries the full unminified sources src/authorize/Authorize.vue and src/authorize/authorize-service.js, and app.b3306bf3.js.map carries the router. TCC ships a real OAuth-style AUTHORIZATION-CODE endpoint at /auth: `{path: '/auth', name: 'auth', props: route => ({redirectUri: route.query.redirect_uri, source: route.query.source, state: route.query.state}), component: () => import('./authorize/Authorize.vue')}`. The screen is a delegated-consent screen, not a shared secret: 'Authorization Request from: {{ source | upperCase }}' / '{{ source | titleCase }} is requesting access to menu settings for the following tenants:' over a list of `user.accessibleTenants`, then 'If you trust this application click ''Authorize'' to grant access, otherwise log out or navigate away from this screen.' It is OPERATOR-GRANTED and permission-gated: 'Permission Required: Your account does not have the "Integrations Setup" permission needed to authorize this integration. Please contact your administrator.' (hasIntegrationsSetup = hasFeature(appFeatures.integrationsSetup), 'INTEGRATIONS_SETUP'), and the Authorize button is disabled unless `valid && tokenUrl && hasIntegrationsSetup`. On click it fetches `${tokenUrl}/thirdparty/tcc/auth?userId=..&companyId=..` (tokenUrl from GET /api/companies/thirdPartyIntegrationUrl/{companyId}) and redirects `uri += 'code=' + response.auth_code`, or for thrive-sync POSTs /api/thrive-sync/auth/code and redirects `code=<code>&state=<state>` - i.e. a redirect_uri + state + one-time code exchange, and it calls logout() before the redirect. That directly contradicts the prior note's 'not a delegated grant with scopes, consent or per-app revocation': consent, an operator permission gate, a per-tenant listing and a scope statement ('menu settings') demonstrably exist in the shipping app. WHY ONLY PARTIAL, NOT YES: (a) the client list is a HARDCODED ALLOWLIST OF TWO - `validSources: ['stream', 'thrive-sync']` - both Granbury's own services (stream = TicketStream, the API named in the 7.8.x release notes; thrive-sync is first-party), and an arbitrary third-party app cannot be a source; (b) there is no client registration, no published token/authorize endpoint, no scope parameter (the scope is fixed prose) and NO revocation surface anywhere in the 20.4 MB TCC source corpus; (c) the source still shows an unfinished limb ('PLACE CALL HERE WHEN WE KNOW WHAT IT IS'); (d) this is production JS the vendor does not publish as documentation = grade B, and the static per-company TicketStream bearer token documented in TCC > Location Settings > API Access is not retired by it. Table-stakes weight, so partial is the right landing. Retrieved 2026-09-18. https://tcc.thrivepos.com/ · retrieved 2026-09-18 adversarially verified

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

extensibility-webhooks-push

The claim asks for pushed webhooks 'rather than requiring polling'. The one documented third-party consumer of the Thrive API, SyncThr!ve on the QuickBooks store, is set up by entering a bearer token, a Location Code and a start date and then PRESSING FETCH - an explicitly pulled sync. 'webhook' returns ZERO corpus-wide including the 513-article P2 census. The only push-shaped transport documented anywhere is Deliverect's private AWS SQS/SNS queue, a bilateral arrangement with one named broker, not a URL a partner registers. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. AUDIT (2026-09-04): The quote is sufficient and there is more of it: the only documented third-party consumer is configured with a token, a Location Code and a start date, then 'Press Fetch', and the article tells operators 'the system fetches new data every 2 hours' with a manual 'Resync Selected Dates'. That is an explicitly polled channel in the vendor's own material. The Deliverect SQS/SNS push is correctly excluded - a private bilateral queue with one named broker is not a partner-registrable endpoint. https://web.archive.org/web/20211204230248/https://thrivepos.uservoice.com/knowledgebase/articles/1896298-quickbooks-integration · retrieved 2026-09-04

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

This claim is explicitly about documentation - signing, retry-with-backoff and a replayable event log must all be documented - and Thrive publishes no API or event documentation of any kind against which those properties could be stated. Verified by the same three enumerations: no developer or API page among the 250 sitemap URLs, no api./developer./docs. host resolving in DNS, and no API, developer or webhook category among the 43 categories and 511 articles of the Customer Learning Center. Whether an unpublished partner interface exists is a separate question and is left open on the webhooks-push cell; the documented-reliability requirements here cannot be met either way. https://www.thrivepos.com/pricing · retrieved 2026-09-04 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

An order-injection endpoint demonstrably exists: the vendor's own release notes quote a failed submission against it verbatim - "Deliverect : Invalid HTTP result from POS THRIVEPOS: 500 - {\"timestamp\":\"2023-02-15T05:02:31.004Z\",\"status\":500,\"error\":\"Internal Server Error\",\"path\":\"/pos/order\"} caused by mapping request failure" - and orders posted through it become first-class tickets: they print "directly onto your tickets or KPS", carry the channel and channel order id, honour the 3rd-party default pricing scheme, accept zone information for delivery, support channel-side cancellation (TPOS-7473) and close via Quick Close. Named shortfall: it is not a public write API. The switch is operator-invisible and vendor-gated - "Turn on the TicketStream API only if any 3rd party integrations will be used. Turn it OFF for most customers" (TCC company setup) - the partner is registered by an Account ID / Location ID exchange arranged through Granbury and Deliverect, and no endpoint reference, request schema, authentication scheme or developer documentation is published for an arbitrary developer to call /pos/order. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Integration-Releases · retrieved 2026-08-08

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

extensibility-menu-write-api

RE-VERIFICATION (330th), NEW SURFACE, VALUE HELD: the TCC production source maps (.cache/q329/thrive-pos/tcc/, chunk-0956b833) contain a consent screen whose scope sentence is '{{ source | titleCase }} is requesting access to menu settings for the following tenants:' (src/authorize/Authorize.vue). That is a delegated grant whose OBJECT is menu settings, which is the object of this claim - so the residual risk here is now named rather than hypothetical. It does not move the cell: the sentence states access, never direction, no write endpoint, field list or method appears anywhere in the 20.4 MB TCC source corpus (tokenised, case-insensitive: 'menu' + 'POST'/'PUT'/'PATCH' co-occurrences are all TCC's own internal /api/menu calls from the back office, not a partner API), and the grantable sources are a hardcoded allowlist of Granbury's own two services ['stream','thrive-sync']. Unstated direction carries at most a residual risk, not a partial. Retrieved 2026-09-18. https://www.thrivepos.com/thrive-connect · retrieved 2026-09-18 adversarially verified

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

CLAIM: every core object the API can read (orders, menu, customers, employees, inventory) can also be WRITTEN or updated via the same API. VERDICT: no - Granbury's own published integration pages now state the asymmetry in so many words, on the vendor's own site, for its own product. NEW SURFACE (327th): the rebuilt www.thrivepos.com/integrations section, enumerated by the HubSpot content-search API (https://www.thrivepos.com/_hcms/search, 49 terms paged to exhaustion, 254 URLs; the complete /integrations/* set is 7shifts, deliverect, doordash-drive, pizzacloud, restaurant-365, valutec, wookai, plus the first-party thrive-connect). Each page carries a direction table. 7shifts: 'What syncs Thrive POS -> 7shifts: Sales ... Time punches ... People (Employees, departments, and roles)' followed by the flat statement 'DATA MOVES IN ONE DIRECTION, OUT OF THRIVE POS. Schedules are built and published in 7shifts' - so employees, labour and sales are read-out-only, and the schedule object never comes back. Restaurant365: 'Thrive POS remains the source of record for restaurant sales and labor activity. Restaurant365 RECEIVES POS data' - again out-only. Thrive Connect (first-party): 'Menu, pricing, and availability publish OUT to every connected channel' and 'Orders come INTO Thrive POS' - i.e. exactly one object writes inbound (orders) and the menu writes only outbound. Combined with the standing measurement that reads run through TicketStream feeds (order, item, timeclock, dispatch, deposit) while the only inbound endpoint Granbury has ever named is '"path":"/pos/order"', every core object except the order is read-only to a third party. BOUND: the 884-article two-corpus KB census (2026-09-17) - 'webhook' 0, 'callback' 0, 'openapi' 0, 'REST API' 0, 'swagger' 1 (internal ticket TOL-5408) - plus the 254-URL HubSpot site census, which contains no developer or API page, plus the 49-name CT set with no api/developer/docs/altura host, plus the 325th's exhausted anonymous-spec probes against same-host nonsense controls. GRADE NOTE: the direction statements are marketing pages (grade C on their own); the verdict rests on the KB census and the absence of any published API, hence B. Retrieved 2026-09-18. MERGE: graded C, the direction statements are marketing pages. https://www.thrivepos.com/integrations/7shifts · retrieved 2026-09-18 adversarially verified

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

extensibility-published-rate-limits

Nothing about an API is published, so no quota can be. Three independent enumerations agree: the 250-URL sitemap of www.thrivepos.com contains no developer, API or integration-reference page and /api, /developer and /developers all 404; api., developer. and docs.thrivepos.com do not resolve in DNS; and the Customer Learning Center's own category index lists 43 categories and 511 articles covering menu, orders, reporting, configuration and hardware with no API or developer category among them. What Thrive does publish about connecting systems is vendor-brokered rather than self-serve - 'Thrive POS handles setup and configuration' - so no numeric quota, throttling behaviour or rate-limit header is documented for an operator or a partner to rely on. https://www.thrivepos.com/pricing · retrieved 2026-09-04 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

Vendor claims direct integration with DoorDash, Uber Eats and GrubHub plus native DoorDash Drive. Whether these are vendor-owned certifications or resold middleware is not disclosed, and DPIP status is absent. https://www.thrivepos.com/delivery · 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

Two middleware endpoints, both documented by the vendor itself. Deliverect: "Deliverect is a 3rd party order aggregator that Thrive POS will sync menu's to and recieve orders from. The entire development was from Thrive POS and TCC to the Deliverect api interface. Communication between the two products will be conducted through SQS/SNS in AWS so that no additional networking or interface steps are necessary", with a documented registration handshake (TCC Account ID at company level, Deliverect Location ID on the location Integrations tab), a minimum POS version of 8.1.60, its own release stream (Deliverect Integration Releases) and continuing fixes in the POS release notes through 8.3.x. Chowly: "We work with a partner, Chowly, to integrate orders from a wide variety of 3rd party sites", set up by per-site tender types with Granbury authorising the link (kb 1887514). Otter and Checkmate/ItsaCheckmate were searched for across both documentation hosts and are not documented for Thrive. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Overview · 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

Restaurant365 integration covers back-office/accounting functions. No QuickBooks Online connector is documented, so the two-system bar is not met from public sources. https://www.thrivepos.com/en-us/features · 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

Configuring ADP Payroll Export (kb 947889) documents the full flow: enter the six-digit ADP department code on each job type, then in Config > Employees > Timeclock & Payroll set "Payroll Export: Select ADP from the drop down" with Company Code, Batch Description, Tips Code, Driver Fees Code and Server Sales Code as supplied by ADP; then "navigate to Manager Home > Reports > Labor > Payroll and run it for the time period you wish to export", producing a file "formatted specifically for ADP" whose name "must remain as is" - "You can now import this file into your ADP payroll program." A second named provider is in the release notes: 7.6.3 "Added a new PayCom payroll integration", revised at 7.6.7 to "use employee_number instead of ID" (kb 1141255). Payroll Export is a dropdown, so the list is longer than two, but two are named first-party. Hours, tips and driver fees move as a file import with no re-keying. https://thrivepos.uservoice.com/knowledgebase/articles/947889-configuring-adp-payroll-export · retrieved 2026-08-08

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

Partial because a transaction-level feed genuinely exists and can be switched on for outside consumers - TicketStream, enabled per company in TCC with the stated purpose 'only if any 3rd party integrations will be used'. Named shortfall: the only SCHEDULED delivery Thrive documents is a rendered PDF report e-mailed to a named employee, not rows to a destination the customer controls; 'Snowflake', 'SFTP' and 'data warehouse' return ZERO corpus-wide, no schema or file format is published, and enabling TicketStream requires Granbury rather than the operator. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/1963333-scheduling-e-mail-reports-in-thrive-analytics · retrieved 2026-09-04

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

extensibility-app-marketplace

No public integrations marketplace exists on thrivepos.com; integrations are sold as a metered allotment ('includes 3 integrations') negotiated through sales, which is structurally the opposite of a self-install marketplace. https://www.thrivepos.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

Re-evidenced to the current product. 'TCC Marketing - User defined fields and groups' documents the feature in Thrive Control Center, the shipping admin tool: 'Thrive allows you to define 3 user fields to collect any extra information about your customers. You might use this for gate codes, special instructions, etc. If you wish to use a field, give it a label, and set it to active. If you turn on the "print" option, it will print with the customer address on the ticket.' It is self-serve at Configuration > Marketing, settable at company or location context, with no vendor engineering engagement. Named shortfall: it is exactly three pre-provisioned slots on the customer record only - not custom fields on menu items, orders, employees or any other POS object - and no vendor-hosted scripting, rules engine or custom logic against POS objects is documented on either published host (the 511-article UserVoice Learning Center or the 251-article Granbury KnowledgeBase, including the TCC 1.1.x and POS 8.3.x release-note streams). https://granburysolutions.my.site.com/KnowledgeBase/s/article/TCC-Marketing-User-defined-fields-and-groups · retrieved 2026-08-08

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

The claim needs a third-party UI driving the POS transaction engine via API. Every front end Thrive documents is first-party - the Kiosk and Thrive Online release streams, the Dr!ve driver app, the rear customer display - and the single third-party channel is scoped, in Granbury's own words, to menu sync out and finished order receipt in, not to item selection, pricing or tender. The absence of any engine-level API rests on P2. AUDIT (2026-09-04): Unlike the two extensibility cells downgraded, this asks about a MODE the vendor would have to offer and announce, not whether a particular endpoint exists. Thrive's documented front ends are enumerable and all first-party, and the single third-party channel is scoped by Granbury's own words to menu sync out and finished-order receipt in, with the POS running as a locked-down Firefox kiosk on an in-store server. Residual risk: an unpublished enterprise embedding programme would not appear here. https://granburysolutions.my.site.com/KnowledgeBase/s/article/Deliverect-Overview · retrieved 2026-09-04

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

extensibility-api-versioning-deprecation

Correction: the earlier rationale said "there is no published API to version". There is. TicketStream is named first-party as "our new data API" and "our cloud-based reporting engine used for API access to POS data", and its changes are published as a dated per-release changelog - the 7.8.x notes carry a dedicated "TicketStream Enhancements" section ("Added Category ID and Name to Order Feed Item Section", "Added a data feed event when a ticket is Assigned / Dispatched", "Added job type department code to timeclock feed") and the 8.0 notes itemise the surface release by release across 8.0.9 to 8.0.12 ("Add Customer Group to customer data on order feed", "Add the 'return' report to the API", "Resolved order date issues with TicketStream Orders API"). Additive and behavioural changes to named feeds are therefore logged against a version number, publicly and anonymously readable. Named shortfalls: no stated deprecation or breaking-change notice policy exists for the interface - no notice window, no sunset schedule, no versioned endpoint, and feeds are altered in place (8.0.12's "change date & timestamp formats for item add time / offer time / void time" is a breaking format change shipped with no notice period); and there is no separate API changelog, so a consumer must read the whole product release notes to find it. The deprecation notices Thrive does publish are product-level, not interface-level: 8.1's "Important Feature Exclusions" and "Let's Get Online will not be compatible with this version. Please upgrade to Thrive Online". https://thrivepos.uservoice.com/knowledgebase/articles/1867636-version-8-0-legacy · retrieved 2026-08-08 adversarially verified

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

Partial: real self-service export exists but only object-by-object - a customer .csv from Advanced Search, a per-report Excel button on essentially every report, and the TicketStream transaction feed. Named shortfall: there is no single complete historical extract of orders, menu, customers and payments metadata on demand, and no contractual data-return obligation at exit. The latter rests on P5, retested and confirmed - every contract phrase returns ZERO across the entire 2.19 MB corpus. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/1960300-customer-advanced-search-marketing-version-8-1 · retrieved 2026-09-04

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

reliability-offline-order-entry

Version 7.7 release notes, "Improved Tools for Internet Connectivity Problems": the POS keeps running and only cloud-bound work is deferred - "Whenever possible, actions & updates are queued so that they will still be sent when connectivity returns. For example, SalesBuilder loyalty enrollments, transactions and redemptions, Thr!ve Online or Let's Get menu updates, Dr!ve status updates, E-mail notifications are all sent as soon as [we] have a connection", "Other actions that can't be saved for later - such as mapping or driving directions, will time out quickly so as not to interfere with your POS processes", and "Credit card processing will still attempt to connect, and give you an 'authorize later' option if a connection is not available"; an unreachable site is flagged in the POS Instant Messaging panel. Credit Cards - Batch (kb 819000) confirms orders were taken and tendered through the outage: "Cards may have been 'Not Authorized' if you lost internet connectivity during the day." The architecture supports it - Hardware Requirements (kb 423702): "The server is the workhorse of the system which powers your operation and stores data. All systems require at least one server", with workstations and Ethernet printers on the store LAN. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · 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

Credit Batch - WorldPay Element / EMV (kb 1857904): "At the bottom of the screen, you may see information about unauthorized charges. This can occur if you had an internet outage and the system was unable to reach the processor at the time of the transaction. You must authorize these transactions before closing the batch, so click the button to authorize", followed by "the system is contacting the processor to update the transaction amount and status". Credit Cards - Batch (kb 819000) says the same for the legacy path: "Cards may have been 'Not Authorized' if you lost internet connectivity during the day", and the Daily Close button unlocks only once they are authorized. Version 7.7 states the terminal behaviour: "Credit card processing will still attempt to connect, and give you an 'authorize later' option if a connection is not available." So the card is captured at the terminal while offline and post-authorized at batch close - store-and-forward, not a cash-only fallback. Two caveats worth knowing: authorization is deferred, so declines surface at batch time, and release 8.0.73 records "Blocking store and forward MSR transactions with Cayan", so behaviour is processor-dependent. https://thrivepos.uservoice.com/knowledgebase/articles/1857904-credit-batch-worldpay-element-emv · 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

The claim tests whether the vendor PUBLISHES a liability allocation, so it is answered by enumerating what is published. Read live 2026-08-08: thrivepos.com's sitemap lists 246 pages and exactly two legal instruments, /en-us/privacy-policy and /en-us/sms-messaging-tos - there is no merchant agreement, processing agreement or terms of service on the site at all, so no published instrument allocates a post-reconnect store-and-forward decline. Both documentation hosts were then searched: across the 511-article UserVoice Learning Center and the 251-article Granbury KnowledgeBase (including the 8.2, 8.3 and TCC release streams), store-and-forward appears only as engineering work - 'Save Thrive Payments key rotations and store-and-forward requests to Mysql so that RabbitMQ can be removed' (8.1.3) and 'TPOS-7448 Fixed Failed/declined store and forward TP transaction fail to clear' (8.2) - which confirms declines after reconnect happen and are treated as a defect, never as a commercial allocation. No per-transaction or cumulative offline cap is stated anywhere either. Withdrawn from the earlier note: the claim that the UserVoice knowledgebase is Thrive's corpus, and the citation to its index page. https://www.thrivepos.com/sitemap.xml · 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

Hardware Requirements (kb 423702) describes a single in-store server holding all state: "The server is the workhorse of the system which powers your operation and stores data - All systems require at least one server which can be used as a workstation; A dedicated server is recommended for >5 terminals", with Android, iPad, Linux and Windows workstations each attached by "NIC 1-1000Mbps (Gigabit)" through a Granbury-supplied switch (Installing Your Switch, kb 871005) - the tablet entries all read "Use with our recommended Intel Nuc Computer i7 16G RAM SSD (Linux) as a dedicated server." Ticket and table state therefore lives on the LAN server, not in the cloud, and version 7.7 confirms that when the internet drops only cloud-bound actions queue while POS processes continue. Recall, Split, table layout and driver screens are all served from that local server, so terminals keep sharing one check state WAN-down rather than becoming islands. https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements · retrieved 2026-08-08

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

Product lineage is on-premise Windows pizza POS with a 'cloud-based Control Center' layered above, and KDS screens are described as independently operating to avoid single points of failure — consistent with an on-site engine, but never documented as such. https://www.thrivepos.com/k-d-s · retrieved 2026-08-01

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

reliability-offline-kds-printing

Kitchen routing is a LAN function of the in-store server. KPS Configuration (kb 408232) sets up KPS screens from the same printer-configuration screen that routes items to kitchen printers ("KPS (Kitchen Production System) allows you to send orders to various KPS screens in addition to or instead of printers"), and Hardware Requirements (kb 423702) lists those printers as "Thermal, Inkjet or Impact POS printers ... Ethernet (preferred), serial or USB" hanging off the store network behind the server that "powers your operation and stores data". Version 7.7's connectivity notes confirm an internet outage suspends only cloud-bound actions, which are queued, while POS processes continue - and kb 819000 shows orders being taken and tendered through such an outage. Worth recording: the KDS itself is version-gated - "Version 8.1 - Current Release" (kb 1936528) lists Kitchen Display among the "Important Feature Exclusions" not yet compatible with 8.1, so 8.1 sites route to kitchen printers only. https://thrivepos.uservoice.com/knowledgebase/articles/408232-kps-configuration · retrieved 2026-08-08

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

Partial: two fallback paths are documented, and both are operator-driven. The 7.7 note gives an on-demand local-printer path when no receipt printer is configured, and Security Settings Configuration grants an employee permission to 'activate an alternate printer setting'. Named shortfall: neither is automatic and neither is triggered by failure - the first fires on a MISSING configuration, not an unreachable device, and the second is a manual toggle. No automatic rerouting to a backup printer and no print-failure alert is documented. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · retrieved 2026-09-04

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

reliability-sync-conflict-handling

Corrected: the earlier note rested on the Learning Center being "the full" corpus, which it is not - Thrive has at least three first-party doc hosts. Re-searched 2026-08-08 across all of them (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, 251, current to POS 8.3.41; the grsalesbuilder.uservoice.com mirror, 39): no article describes conflict resolution, network-partition behaviour, or what happens when the same record is edited on two devices. "Conflict" occurs nine times in total and every occurrence is unrelated - an offer that conflicts with another offer, two menu buttons overlapping in the TCC layout grid, conflicting scheduled times, a CSS style note - while "last-write", "last write" and "partition" occur zero times. The only sync-behaviour statement located is a corporate-push warning on the Send To Stores screen: "Stores must be configured and synced with identical PLU#s. Do not send data to stores without confirming that they are properly synced or you could overwrite their menu incorrectly!" - an unguarded overwrite hazard, not a resolution rule - and the release notes show such conflicts handled silently in code ("TPOS-9971 Fixed 409 PLU version conflict bug") with nothing operator-facing. The claim tests whether the vendor DOCUMENTS this behaviour; three first-party corpora and the vendor's own site show it does not. https://thrivepos.uservoice.com/knowledgebase · retrieved 2026-08-08 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

There is no maintained offline feature matrix, but the vendor does publish a partial enumeration. Version 7.7.x, 'Improved Tools for Internet Connectivity Problems' (retrieved live 2026-08-08), splits functions three ways: queued and sent on reconnect - 'SalesBuilder loyalty enrollments, transactions and redemptions, Thr!ve Online or Let's Get menu updates, Dr!ve status updates, E-mail notifications are all sent as soon as [we] have a connection'; unavailable and fast-failing - 'Other actions that can't be saved for later - such as mapping or driving directions, will time out quickly so as not to interfere with your POS processes'; and degraded - 'Credit card processing will still attempt to connect, and give you an "authorize later" option if a connection is not available', with unreachable sites flagged in the POS Instant Messaging panel. Shortfall: this is a single release note from the 7.7 stream, not a current reference; it is silent on the specific functions the claim asks about apart from loyalty and card entry - no statement covers gift cards, refunds, manual card entry or text-to-pay - and nothing in the 8.1/8.2/8.3 streams through 8.3.41 (2026-07-14) or in the Thrive Control Center notes restates it, even though 8.1 moved menu, pricing and configuration into the cloud. Searched for a replacement across the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase; 'offline'/'off-line' appear only as payment engineering ('Save Thrive Payments key rotations and store-and-forward requests to Mysql', 8.1.3; 'Fixed Failed/declined store and forward TP transaction fail to clear', 8.2.21; 'Blocking store and forward MSR transactions with Cayan', 8.0.73), never as an operator-facing matrix. Withdrawn: the earlier note's sole basis, thrivepos.com's cellular-backup blog post - it is a marketing article and its absence of an enumeration was never evidence that none is published elsewhere. https://thrivepos.uservoice.com/knowledgebase/articles/1132123-version-7-7-x · retrieved 2026-08-08 adversarially verified

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

reliability-public-status-page

status.thrivepos.com is a live public status page - no login, titled "Thrive POS - Online Services", and linked as "Status" from the customer support portal. It is per-component: its monitor feed (/api/getMonitorList/O8YLDSAr48, read 2026-08-08) returns seven separately tracked services - Support Portal, Thrive Analytics, Thrive Console, Thrive Control Center / TicketStream, Thrive Online, Thrive POS corporate site and Thrive POS Salesbuilder (monitors created 2018) - each carrying 90 days of daily uptime ratios, alongside page sections "Service status", "Uptime Last 90 days", "Overall Uptime" and "Status update history" and an event feed. All seven read operational on 2026-08-08 and the event feed was empty for the trailing seven days. Scope note: it covers Thrive's cloud services; the in-store POS is on-premise and not monitored here. https://status.thrivepos.com · retrieved 2026-08-08

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

Positive absence in the two places the commitment would live. Thrive runs a public status page that publishes measured uptime over 24 hours, 7, 30 and 90 days and an incident history - so availability is reported - but it states no target percentage and no service credit, and its own footer links only to a privacy policy and the status-tool vendor's terms of service. On the contract side there is nothing to hold the SLA: the only agreements Thrive publishes are its privacy policy and its SMS business-notification terms, and /sla, /terms, /msa and /legal all 404. https://status.thrivepos.com/ · retrieved 2026-09-04 adversarially verified

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

reliability-incident-postmortems

Thrive publishes root-cause summaries inside its Statuspage incident timelines, but no formal post-incident reports. The record looked only at status.thrivepos.com (an UptimeRobot monitor page); Granbury Solutions also runs an Atlassian Statuspage at status.granburysolutions.com, titled "Thrive POS Status", whose components include Thr!ve Online, Thrive Analytics, Thr!ve Control Center, SalesBuilder and Thrive POS Phone System. That host's robots.txt disallows /api/ and /embed/, so this rests only on its permitted surfaces: history.atom (25 entries, 2021-07-10 to 2026-08-18, 6 of them scheduled maintenances) and individual /incidents/ pages. The /history page is script-rendered and names no incident in its HTML. Several outages close with a written cause: 2024-06-06 "Salesbuilder failing to authenticate" - "We have identified a certificate on the Salesbuilder server that was incorrectly auto updated through LetsEncrypt. Our engeineers have properly reinstalled the certificate and traffic is now being validated with SSL/TSL connection."; 2022-08-26 "Thrive Online currently experiencing degraded performance" - "We have identified an issue with one of our Application Load Balancers causing routing issues with Thrive Online."; 2023-02-15 "Publishing from TCC Intermittent" - "We have confirmed that an intrusion detection system that does penetration testing was the root cause of the degradation of service."; 2024-03-16 "Thrive Online Outage" - "We have identified that the error is from a corrupt certificate authority."; 2023-04-24 "Thrive Control Center Login Unavailable" - "We have identified an update to an underlying subsystem in AWS has caused issues for all users logging into Thrive Control Center." Shortfalls: none of these incident pages and no history.atom entry carries a postmortem section; the cause statements are one or two sentences, and are often proximate or missing. 2024-10-11 "TOL slow to respond or unresponsive" says "The main cache memory utilized for menu presentation had one of the underlying servers become non responsive causing the outage" but adds "we are still investigating the root cause of why the server went down", with no follow-up. Several Thrive Online outages close with no cause: 2023-06-13 "Thrive Online Major Outage" ("We have identified the issue and fix has been applied") and 2024-08-28 "Thrive Online not fully loading restaurants" ("We have identified the cause and resolved the issue"). 2023-05-12 promised "root analysis will be conducted" and no analysis was ever added. The on-premises POS itself is not a monitored component. https://status.granburysolutions.com/incidents/glbvp6sczwyz · retrieved 2026-09-12 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

OVERTURNED by the no-audit on 2026-09-04. I had written no because Thrive's four-tier pricing matrix names support once, as 'U.S. Based Support' at every tier, with no hours and no 24/7 designation, and because no page in the 250-URL sitemap publishes support hours. That is the absence of a marketing adjective, not positive evidence: a vendor can staff an overnight line and describe it by geography rather than by clock, and Thrive routes support to a customer portal at support.portal.granburysolutions.com whose hours were not retrieved. The measurement stands - support hours are nowhere published on the public site - but it cannot carry the verdict. || 324th: NEW SURFACE (324th), cell deliberately left unresolved. The 372-article Salesforce Knowledge REST census returns ZERO files for `support hours`, `24/7`, `24 hours a day`, `after hours` and `on call`; the newest support article, 'ThrivePOS Network Requirements for Optimal Performance', ends with a bare 'Need Help? ... Email: support@thrivepos.com Phone: (817) 750-3947' and no hours. The rebuilt www.thrivepos.com (255 pages crawled today) still names support only as 'U.S. Based Support' at all four tiers and 'White Glove Customer Support ... over a 98% customer support satisfaction rate'. This is now a CENSUS-bounded silence rather than a partial one, but it remains the absence of a marketing adjective, which the 2026-09-04 no-audit already ruled insufficient - a vendor may staff an overnight line and describe it by geography. Unknown, not no. BOUND: a validated CENSUS of the vendor's current help centre, obtained today by a route no prior pass used - the anonymous Salesforce Knowledge REST API on the Experience Cloud site: https://granburysolutions.my.site.com/KnowledgeBase/services/data/v59.0/support/knowledgeArticles?pageSize=100 (4 pages via nextPageUrl, 372 unique articles; each body then fetched from its own /knowledgeArticles/<id> url, layoutItems Question__c + Answer__c; 372/372 bodies retrieved, 783,586 chars of stripped text). CENSUS VALIDATION: all 71 distinct my.site.com/KnowledgeBase/s/article/ slugs already cited anywhere in data/vendors/thrive-pos/*.jsonl are present in the pull (71/71); the site's own manifest sitemap-topicarticle-1.xml lists only 197 articles, a strict subset, and the prior pass's 264-article dump is also a subset - 110 of these 372 articles were never held before. The API 401s at the org root (/services/...) and 200s only under /KnowledgeBase, so this is the community's published set, not an auth bypass. SECOND CORPUS: a fresh full crawl of www.thrivepos.com today - sitemap.xml 256 urls, 255 pages fetched and stripped - a REBUILT site (2 pages new since the last pass: /thrive-connect and /integrations/wookai). THIRD CORPUS: the site's closed partner enumeration 'OUR SOFTWARE INTEGRATION PARTNERS' at https://www.thrivepos.com/integrations - exactly seven: 7shifts, Deliverect, DoorDash Drive, PizzaCloud, Restaurant365, Valutec, WookAI. CONTROL POISON FOUND AND TOKENISED AWAY: `course` matches only 'of course' (2/2); `fire` is Google Tag Manager 'failed to fire', a fire-extinguisher table-design icon and the idiom 'putting out fires' (5/5); `hold` is caller-ID hold time, press-and-hold gestures and 'the Main Safe holds extra money' (4/4); a word-boundary `franchise` control returns ZERO while the stem `franchis` returns one real hit ('franchisee locations'), so the stem was required; `archive` is only the PCI setting 'Archive data after X days'. Positive controls prove the corpus and the extractor are live: api 21 files, pre-auth 13 files / 32 hits, DoorDash 7 files / 78 hits, Deliverect 12 files / 133 hits, curbside 4 files, offline 2 files, clock in 5 files / 15 hits. Retrieved 2026-09-17. || 325th: NEW MEASUREMENT, cell deliberately still unknown. The 2026-09-04 audit's finding - that support hours are nowhere published - was bound to a 250-URL sitemap; it now holds against the two-corpus CENSUS below. '24/7' occurs exactly ONCE in 1,777,847 characters and it is the poison, a menu active-time tip ('Active Time: Designate certain times of the day that you want this menu to be active. Tip: If left blank it will be active 24/7'); '24x7' 0 hits, 'around the clock' 0, 'hours of operation' 2 hits both in the Daypart Hours configuration article, 'business hours' 23 hits none of them Thrive's own. 'support' returns 170 hits and the only contact detail published is a channel, not a clock: 'contact ThrivePOS Support for help ... Email: support@thrivepos.com Phone: (817) 750-3947'. So the absence is now measured over a census, and it remains the absence of a published hours statement - not evidence that overnight phone support is unavailable. Unknown stands. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. || 327th: NEW MEASUREMENT (327th) on a stronger bound, cell still held per the 2026-09-04 no-audit. www.thrivepos.com runs on HubSpot CMS, so its content store can be enumerated directly rather than crawled: https://www.thrivepos.com/_hcms/search?term=<t>&limit=100&offset=<n>, swept with 49 terms and paged to exhaustion, returns 254 distinct URLs (202 BLOG_POST, 50 SITE_PAGE, 2 LISTING_PAGE) INCLUDING pages nothing links to. Across that whole set the token '24/7' returns 0 results and 'hours' returns only labour-and-scheduling prose (7shifts 'hours worked', WookAI 'Hours saved per week'). The contact page publishes a phone number and an address and no hours at all - 'Send an inquiry or comment, but be sure to use our Customer Support Portal for Technical Support issues! ADDRESS: 8150 Springwood Drive Suite 150 Irving, TX 75063 PHONE: +1.817.750.3947' - and the footer's support links are 'Thrive Control Center | Customer Support Portal | Thrive Hardware | System Status'. The Customer Support Portal itself cannot be read: https://support.portal.granburysolutions.com/ 302s to /User/Login?ReturnUrl=%2faspx%2fHome (11,571 bytes), a login wall, which is a gate and not an absence. So the silence is now census-bounded on the marketing site as well as on the 884-article KB, but it remains the absence of a marketing adjective, which the 2026-09-04 no-audit already ruled cannot carry the verdict. Retrieved 2026-09-18. || 329th: 329th: TWO NEW SURFACES, both silent on hours, so the 2026-09-04 no-audit still governs. (a) Granbury's Atlassian STATUSPAGE, which no prior pass opened: https://status.granburysolutions.com ('Thrive POS Status') exposes api/v2/components.json (41 components, 14.1 KB) and api/v2/incidents.json (43 incidents, 27,088 chars of update prose). One component IS the support line - 'Thrive POS Phone System | This is a status page for the phone systems for Thrive POS , including sales and support' - and the component set otherwise enumerates Thr!ve Online, Ticket-Stream, Thrive Analytics, SalesBuilder, Thr!ve Control Center, Thr!ve Console, DoorDash Drive API, three credit processors and the Twilio/SendGrid estate. Across all 43 incidents, tokenised controls: '24/7' 0, '24x7' 0, 'support hours' 0, 'after hours' 0, 'on call' 0, 'business hours' 0, 'weekend' 0, 'holiday' 0, 'emergency' 0; 'overnight' 1 hit and it is poison ('The service will be unavailable overnight while we take action to mitigate', 2019). A vendor that runs a public status component for its own phone system publishes no coverage window for it. (b) an UNREAD legal page, 'SMS / RCS MESSAGING TERMS' effective 03/05/2026, last updated 6/23/2026 (https://www.thrivepos.com/en-us/sms-messaging-tos), which names the contracting entity 'Thrive POS / Diamond Touch, Inc.' and a support number the marketing site never shows - 'Reply HELP for support information or contact us at support@thrivepos.com or 800-750-3947' - again with no hours and no service commitment. The same 800 number appears in 'Employees in TCC - Overview and FAQ' ('open a support case through the support portal or by calling 800-750-3947'), and 'Preparing for Employment in TCC' shows Granbury staff working off-hours by arrangement rather than a published window: 'we'll schedule a second call outside of business hours to publish the data'. POISON CLEARED: the 255-page site crawl's two '24/7' hits are both blog prose, not support ('you would love to be at the restaurant 24/7', 'keep their smartphones handy 24/7'), and UserVoice's one 'after hours' hit is a daypart explanation. Still no hours statement on any surface; unknown stands. Retrieved 2026-09-18. adversarially verified

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

reliability-onsite-install

Granbury's own hardware store sells on-site installer time: "Additional Onsite Day", $800.00, "Additional onsite day with your Thrive installer. **Subject to availability, does not include airfare changes" - the wording presupposes a first-party installer who travels to the site, and the catalogue also carries "Thrive 8.1 Training, 1st Store" ($500, "4 hours of training on Thrive 8.1 features"), a per-hour professional services SKU and a per-hour menu work and additional training SKU. Named shortfall: on-site days are a priced add-on "subject to availability" with travel billed separately rather than an included go-live programme; no on-site installation or go-live offering is described on thrivepos.com or in the Learning Center, whose own installation content is a set of self-install videos (router, switch, POS terminal, all-in-one terminal, printer, cash drawer, CallerID). The evidence is a storefront SKU, grade C, which cannot carry a yes on a differentiator claim. https://www.thrivehardware.com/products/additional-onsite-day · retrieved 2026-08-08

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

reliability-menu-build-service

Vendor sells discrete paid configuration services ($100 for suggestive-selling setup), and reviewers describe an assigned trainer during onboarding — implying paid setup assistance rather than an included full menu build. https://www.thrivepos.com/en-us/thrive-product-news/boost-your-ticket-average-with-suggestive-selling · retrieved 2026-08-01

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

reliability-hardware-replacement-sla

thrivehardware.com/returns documents a warranty program: 'Granbury Solutions offers a 60 day warranty on all hardware' plus pass-through manufacturer warranties 'up to 3 years from the date of purchase,' with a defined process for defective items (contact support or the Customer Care Portal, RMA number required — 'NO RETURNS WILL BE ACCEPTED WITHOUT AN RMA NUMBER'). Shortfall: 'the next steps will be determined by date of purchase and the type of equipment in question' — no advance-exchange program and no stated turnaround time are published; the process is warranty repair/replacement with an unstated timeline, not the SLA-backed advance exchange the claim describes. https://www.thrivehardware.com/returns · retrieved 2026-08-04

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

reliability-backup-restore

Operator-triggered backup is documented in dated first-party release notes. Release 7.3.0 (kb 553194): 'the offsite backup process has changed. It will still run automatically, but you can initiate a backup manually by clicking on the link from Manager Home.' Release 7.4.x (kb 849330) adds '1404 Online Backups: Perform automated system backups right from the Manager Home screen', and 7.7 adds 'Onsite Backups: Enhanced the back up function to enable automatic back up the database nightly to another station on the network (in addition to cloud backups)' (kb 1132123); later notes reference 'workstation permissions for onsite backups' and 'Offsite backups sometimes hanging'. Named shortfall, now tested against everything Thrive publishes rather than one host: no article on either documentation host describes an operator retrieving or restoring a backup themselves - restores are not described at all - and no RPO or RTO figure appears in the 511-article UserVoice Learning Center, the 251-article Granbury KnowledgeBase, or the 246 pages of www.thrivepos.com (sitemap read live 2026-08-08). Worth stating plainly: 'backup' returns zero hits across the entire current-generation Granbury KnowledgeBase, including the 8.2, 8.3 and TCC release streams, so the trigger-side evidence above is 7.x-era and nothing more recent restates it. https://thrivepos.uservoice.com/knowledgebase/articles/553194-7-3-0 · retrieved 2026-08-08

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

Positive evidence, not a P3 zero-hit: this article is the vendor's OWN designated answer to 'how do I validate Thrive's PCI compliance', and the answer it gives is to search the PCI SSC's payment-applications listing for Granbury Restaurant Solutions. That is PA-DSS - a retired payment-application programme superseded by the Software Security Framework - and it is neither a PCI DSS v4.0/4.0.1 Attestation of Compliance for the vendor's own environment nor a validated P2PE listing. When the vendor is asked directly and names something else, no v4 AoC is published. AUDIT (2026-09-04): This is the vendor's own designated answer to the exact question the claim asks, and the answer names something else: Granbury points merchants at the PCI SSC's payment-applications listing. PA-DSS is a retired programme superseded by the Software Security Framework and is neither a PCI DSS v4.0/4.0.1 AoC for the vendor's own environment nor a validated P2PE listing. The claim is a publication claim, and no trust, security or compliance page exists on any Granbury host. Caveat: the article is dated Jun 11 2021 and nothing more recent replaces it - which is itself the finding. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-How-can-I-validate-that-Thrive-is-a-PA-DSS-Certified-application-for-PCI-Compliance · retrieved 2026-09-04

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

reliability-mfa-role-based-access

Role-based permissions are strongly documented (Security Settings Configuration: six renameable workgroups with granular per-action grants, already scored yes on labor-granular-rbac). A Version 8.0-era release note adds a second credential for sensitive areas: 'a new Administrative password is now necessary to access certain backend areas such as credit card settings... a secure password that meets PCI requirements.' Shortfall: this is a second static password, not a documented second authentication factor (SMS/authenticator app/hardware key) — no article uses MFA/two-factor language for POS or back-office logins. https://thrivepos.uservoice.com/knowledgebase/articles/720465-security-settings-configuration · retrieved 2026-08-04

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

reliability-self-serve-training

There is a free public training library: the Customer Learning Center hosts 'Thrive Academy' course tracks for cashiers, servers, drivers and managers, plus setup videos (e.g. 'Fractions Setup - Video') and downloadable documentation and release notes, all viewable without signing in. https://thrivepos.uservoice.com/knowledgebase · retrieved 2026-08-01 adversarially verified

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

reliability-failover-terminal-role

CLAIM: any terminal can assume the master/server role AUTOMATICALLY if the designated primary terminal or local server fails. VERDICT: no. EVIDENCE: Thrive's own 'Thrive Recommended Hardware' article states the architecture and the remedy in the same breath: 'The server is the workhorse of the system which powers your operation and stores data. All systems require at least one server which can be used as a workstation. A dedicated server is recommended for >5 terminals. ALL SYSTEMS SHOULD HAVE A BACKUP SERVER/WORKSTATIONS TO USE IF PRIMARY FAILS' (https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements). The documented answer to a dead primary is therefore a spare machine the operator buys and puts into use - an instruction to the purchaser, not an automatic role handover. Controls across all 884 articles: 'fail over' 0 hits, 'take over' 0, 'designated server' 0, 'promote' 21 hits all in the marketing sense ('promote specials'), 'backup server' 1 hit (the sentence quoted), 'failover' 2 hits in one unrelated legacy-online-ordering article. Corroborating, from the Salesforce KB's station article: 'Stations will be added as the "Server", "Manager Station", "Station 1", "Station 2" etc. with a "Remote" and "Support" station also added automatically ... we recommend that you leave them usin[g the defaults]' - fixed named roles, no role-election setting anywhere in its per-station options. BOUND - a TWO-CORPUS CENSUS built 2026-09-17, not a floor. (a) thrivepos.uservoice.com Customer Learning Center: all 45 topic pages fetched (the 43 linked from /knowledgebase plus topics 59050 and 116220, which are referenced only from inside other pages and added zero new articles), yielding 511 distinct article URLs; all 511 fetched, none under 3 KB; ?page=1/2/3 return the identical 511, so the listing is unpaginated and complete. The href fixpoint over all 511 bodies references 12 further article ids: 1860970 is live and was added to the corpus, and 420225, 442564, 442566, 442569, 455566, 663439, 663547, 789585, 822090, 824439 and 824442 all 302 to /knowledgebase, which is UserVoice's soft-404 for a deleted article - so nothing is gated, 401ed or withheld. (b) the granburysolutions.my.site.com Salesforce Knowledge REST census of 372 articles. TOTAL 884 articles, 1,777,847 characters of stripped text. CONTROLS are tokenised, case-insensitive and word-boundary ((?<![A-Za-z0-9])term(?![A-Za-z0-9])), so no substring poison. POSITIVE controls all pass on this corpus: printer 338, printers 141, print routing 8, export 128 / exports 9 / exported 5, ingredient 87, receive 68, clock in 58, time clock 57, vendor 34, support 170, hours 337, invoice 14. POISON FOUND AND EXCLUDED: 'punch' returns 0 - Thrive's own vocabulary is 'clock in'/'clock out', never 'punch'; '24/7' has exactly ONE hit and it is a menu active-time tip ('If left blank it will be active 24/7'), not support hours; 'promote' 21 hits are all the marketing sense ('promote specials'), never role promotion; 'prep time' 1 hit is a DoorDash Drive support-contact line; 'redirect' 12 hits are URL and report redirects, never ticket rerouting. Retrieved 2026-09-17. https://thrivepos.uservoice.com/knowledgebase/articles/423702-hardware-requirements · retrieved 2026-09-17 adversarially verified

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

reliability-cellular-backup

Vendor actively recommends and points operators to internet cellular backup services for outage protection, but this is third-party connectivity guidance rather than documented first-party automatic LTE failover in the terminal. https://www.thrivepos.com/en-us/thrive-product-news/dont-let-internet-outages-take-a-slice-out-of-your-profits · retrieved 2026-08-01

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

Monthly pricing is genuinely published and unqualified by a stated term: four tiers priced as Starter $99/mo (1 terminal), Delivery Plus $149/mo (up to 3), The Works $199/mo (up to 5) and Pizza Pro at custom pricing (unlimited), with a per-tier feature matrix. Shortfalls, both material: no terms of service or MSA is published anywhere on the site, so nothing states that a monthly plan carries no minimum multi-year commitment - the absence of a stated term on a price card is not a published absence of a term - and the same page makes processing compulsory ('All monthly plans require payment processing with ThrivePay'), which attaches a second, unpublished agreement to every monthly subscription. https://www.thrivepos.com/pricing · retrieved 2026-09-04 adversarially verified

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

commercial-no-early-termination-fee

The claim turns on what the published terms say, and Thrive publishes no terms. Its own footer names the complete Company legal set on every page of the site - Privacy Policy and SMS Service Terms, nothing else - and every conventional path was probed: /terms, /terms-of-service, /terms-and-conditions, /legal, /msa, /eula and /sla all return 404 on www.thrivepos.com, while the same paths on the parent brand granburysolutions.com 301 to a Thrive marketing page rather than to a document. The 250-URL sitemap contains no agreement of any kind, and the 511-article Customer Learning Center has no contracts category. A statement that there is no early termination fee therefore does not exist to be relied on; the pricing page publishes monthly rates and links to no agreement. https://www.thrivepos.com/en-us/privacy-policy · retrieved 2026-09-04 adversarially verified

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

The vendor's own sitemap.xml enumerates its entire published site: 75 non-blog URLs, of which exactly two are policy documents - /en-us/privacy-policy ('LAST UPDATED: January 11, 2024') and /en-us/sms-messaging-tos. Neither addresses the software subscription. /pricing lists Starter $99/mo, Delivery Plus $149/mo, The Works $199/mo and Pizza Pro custom, with the single condition 'All monthly plans require payment processing with ThrivePay' and no renewal term, no notice window and no cancellation clause. No terms-of-service, MSA or subscription-agreement page is published; trust./legal./security.thrivepos.com and trust.granburysolutions.com do not resolve, and granburysolutions.com/terms-of-service redirects to a marketing page. Renewal and cancellation-notice terms are therefore not publicly accessible - they exist only in the signed quote. https://www.thrivepos.com/sitemap.xml · 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

Re-read verbatim 2026-08-11: "All monthly plans require payment processing with ThrivePay." (The wording previously recorded here, "All plans require ThrivePay payment processing.", was a paraphrase in quotation marks.) Hard processing lock across every published MONTHLY tier — Starter, Delivery Plus and The Works; the page also carries an enterprise row at "custom pricing" which that sentence does not reach, so the lock is not established for it. Value unchanged: processing is bundled on every tier whose price is published. https://www.thrivepos.com/pricing · 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

No rate of any kind is published — neither flat nor interchange-plus. Only qualitative 'competitive rates' language. https://www.thrivepos.com/payment-processing · 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

Same measurement, applied to the processing side, where the exposure is larger because processing is compulsory: the pricing page states 'All monthly plans require payment processing with ThrivePay.' No processing agreement, merchant application or fee schedule is published anywhere - the only two legal documents Thrive publishes are the privacy policy and the SMS business-notification terms, and every /terms, /msa, /legal and /sla path 404s. There is consequently no published cap on vendor-initiated rate increases, no prohibition, and no penalty-free-exit right on an increase. https://www.thrivepos.com/en-us/privacy-policy · retrieved 2026-09-04 adversarially verified

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

Software tiers published with specific dollars and terminal counts: $99 (1 terminal), $149 (3), $199 (5), custom (unlimited). Caveat: the features page contradicts this by advertising unlimited terminals for one flat rate. https://www.thrivepos.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

Modules are bundled into ascending tiers, not sold a la carte — loyalty and marketing require the $199 tier; KDS, driver app and table service require the quote-only Pizza Pro tier. Cancelling a module means repricing the base subscription. https://www.thrivepos.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

A dedicated hardware storefront implies outright purchase, but no prices are published and no statement rules out a mandatory lease. https://thrivehardware.com/ · retrieved 2026-08-01

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

Catalog is generic (Computers, Tablets, Printers, Cash Drawers, EMV Pinpads) rather than proprietary vendor-only devices, but no third-party hardware model is named as supported. https://thrivehardware.com/ · retrieved 2026-08-01

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

commercial-implementation-fee-published

No implementation, onboarding, menu-build or training fee is published, and it is not stated as $0. The only published one-time fee is $100 for suggestive-selling configuration. https://www.thrivepos.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 manual export is documented throughout the Learning Center and needs no support ticket: Customer Advanced Search's Output List "Export detailed info to .csv", the Tax Summary Report "printable and exportable to Excel", an "Excel" button at the foot of reports generally (kb 943822 troubleshoots opening those files in Excel 2013), and the QuickBooks integration's ".csv download function to get detail transactions behind each total" (kb 1896298). Corrected shortfall: the earlier note said "no API export path is documented", which is wrong - TicketStream is named first-party as "our new data API" and "our cloud-based reporting engine used for API access to POS data", and it carries transaction-level order, item, timeclock, dispatch, driver-close and deposit feeds. What keeps this at partial is that the API path is not self-serve: it is a per-company switch only a Granbury administrator sets in Thrive Control Center ("Turn on the TicketStream API only if any 3rd party integrations will be used. Turn it OFF for most customers"), operators are told their store "must be... configured to use TicketStream, our new data API... please contact support", and no endpoint or schema reference is published for it. So the remaining shortfalls are: in-product export is per-report and manual rather than one full-history extract covering orders, line items, payments AND labor together, and the API path that would cover all four requires contacting the vendor to be switched on. https://thrivepos.uservoice.com/knowledgebase/articles/952507-customer-advanced-search · retrieved 2026-08-08 adversarially verified

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

commercial-export-customer-and-loyalty

Same evidence as guest-loyalty-data-export-portability: Customer Advanced Search documents 'Export detailed info to .csv' (all fields) and 'Export e-mail addresses' as an operator-run, in-product action. Shortfall: whether loyalty point balances specifically are included in the 'detailed info' export is not stated, and no gift-card outstanding-liability export is documented anywhere in the record. https://thrivepos.uservoice.com/knowledgebase/articles/952507-customer-advanced-search · retrieved 2026-08-04

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

Checked both halves of 'contract or documentation'. There is no contract: the published legal set is the privacy policy and the SMS terms, and every agreement path 404s. The privacy policy does carry a portability clause, but it is a GDPR/CCPA personal-data right about the data subject's own information - 'we will, to the extent required by applicable law, provide to you, or a third party you have chosen, your personal data in a structured, commonly used, machine-readable format' - not an operator's right to extract order, menu and payment history at contract end. The 511-article Customer Learning Center's 43 categories include reporting and configuration but no offboarding, data-export-at-termination or account-closure topic. No number of days is specified anywhere. https://www.thrivepos.com/en-us/privacy-policy · retrieved 2026-09-04 adversarially verified

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

commercial-data-ownership-clause

The published privacy policy (LAST UPDATED: January 11, 2024) has a 'Company as Data Processor' section: 'our business customers remain the data controller in respect of personal data they provide to us... we act in accordance with the instructions of such customers regarding the collection, processing, storage, deletion and transfer of customer data... We will only use such personal data for the purposes of providing the services and products for which our business customers have engaged us.' That is a controller designation plus a purpose limitation. Shortfalls: it never uses ownership language and never mentions transaction data - only personal data; it is a website privacy policy, not an MSA or DPA the operator executes (no terms-of-service page exists in https://www.thrivepos.com/sitemap.xml); it says nothing about aggregated or de-identified use; and it reserves sharing 'within the Jonas Group' across borders and on 'a merger, or other similar transaction that results in a change of control'. https://www.thrivepos.com/en-us/privacy-policy · retrieved 2026-08-08

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

Proprietary commercial software owned by Constellation Software via Jonas Software. No source availability or self-hosting option. https://www.thrivepos.com/about-us · retrieved 2026-08-01

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

Tokenization is documented directly and currently. 'TV - PASS Tokenization required for WorldPay tri-Pos Accounts' (fetched 2026-08-08): 'PASS tokenization is a WorldPay service that can be activated on a merchant processing account. It is REQUIRED for Thrive processing ... allows the POS or Online system to submit a credit card to WorldPay and receive back a "token" that represents that card and can be used for future transactions. This ensures that no actual card data is saved on the POS system.' The older Learning Center agrees - 'Supported Credit and Gift Processors' (kb 632905) describes Vantiv/WorldPay, Open Edge and Cayan/TSYS each as a '100% encrypted, tokenized direct integration', the hardware article requires 'tokenized and encrypted swipes', and the credit-settings article says 'all card data is tokenized (so card #s are never stored in your system)'. On compliance, the vendor points to an external listing rather than making a scope claim: 'The PCI Security Standards organization certifies payment processing applications for PCI compliance. Visit their site ... Search for Granbury Restaurant Solutions as the company' - PA-DSS application validation, which is not P2PE. Shortfalls: no PCI-listed validated P2PE solution is named, and 'P2PE' and 'SAQ' return zero hits across BOTH documentation corpora (511-article UserVoice Learning Center plus 251-article Granbury KnowledgeBase, including the 8.2/8.3/TCC/TOL streams) and across the 246 pages of www.thrivepos.com, so no SAQ type (A or P2PE-HW) is claimed anywhere. Encryption remains a property of the merchant's chosen processor - PASS must be activated on the merchant's WorldPay account - and the current docs describe scope moving the wrong way when pin-pad bypass is enabled: 'allowing users to enter credit card data on your workstations, rather than in your EMV device, may have PCI implications.' https://granburysolutions.my.site.com/KnowledgeBase/s/article/TV-PASS-Tokenization-required-for-WorldPay-tri-Pos-Accounts · retrieved 2026-08-08

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

Partial: a documented, explicitly PCI-motivated access-control regime exists - complexity rules, no reuse of the previous four passwords, 90-day expiry, and a 30-minute lockout after six failed attempts, which the article says are 'required by PCI guidelines' - backed by 8.0-era encrypted passcode storage and an input filter that strips card data from notes. Named shortfall: the regime is single-factor by construction. 'multi-factor', 'two-factor' and 'MFA' return ZERO across all 875 documents, and nothing addresses v4's future-dated payment-page script-integrity requirements (6.4.3 / 11.6.1) for Thrive Online or the kiosk. SOURCE-DATE CAVEAT (203rd): thrivepos.uservoice.com is a FROZEN 2020 doc site - zero content dated after 2020, and its own 8.1 release article lists Inventory and Kitchen Display as not carried forward. The shipping product is 8.3.41+ (2026), documented only on granburysolutions.my.site.com, which is not enumerable. This citation is presence evidence for the 7.x/8.0 product. https://thrivepos.uservoice.com/knowledgebase/articles/1852249-administrative-password-privileges · retrieved 2026-09-04

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

Thrive POS makes no public attestation statement. Its own sitemap.xml enumerates every published page (75 non-blog URLs including /about-us, /payment-processing, /pricing and all product pages) and contains no trust centre, security or compliance page; the only policy documents are /en-us/privacy-policy and /en-us/sms-messaging-tos. The privacy policy's 'Security of Your Personal Data' section offers only 'We use commercially reasonable measures to safeguard personal data' and names no framework. The strings 'SOC 2' and 'ISO 27001' appear zero times across the complete 511-article UserVoice Customer Learning Center. trust.thrivepos.com, security.thrivepos.com, legal.thrivepos.com and trust.granburysolutions.com do not resolve in DNS. No statement that a report is available under NDA or on request exists on any public page. https://www.thrivepos.com/sitemap.xml · retrieved 2026-08-08

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

The operator can service the three mechanical parts of a request in-app. 'Customer Overview' (Manager Home > Customers) documents search on 'any personal information', 'Cust Details' to open the profile, and 'Delete: If a customer is selected in the results screen, clicking this button will initiate deleting the customer profile. (If you want to delete the whole list, click on Output List and select Delete All)'. The Output List screen (952507-customer-advanced-search) offers 'Export detailed info to .csv: Creates a file with all fields'. On the policy side, https://www.thrivepos.com/en-us/privacy-policy publishes a request channel (privacy@granburyrs.com, 1-800-750-3947), GDPR access/erasure/portability rights, CCPA disclosure and deletion rights with a 45-day response, and 'We try to respond to all legitimate requests within one month'. Shortfalls: no DPA is published or offered for execution anywhere in https://www.thrivepos.com/sitemap.xml, and where Thrive acts as processor the policy explicitly pushes the request back to the operator - 'we will refer any request from an individual for access to personal data which we hold about them to our customer. We will not usually respond directly to the request'; nothing in the 511-article Learning Center is framed as CCPA/CPRA or GDPR tooling, there is no requester-verification step, consent log or audit trail, and the documented delete acts on the customer profile with no statement about order history, loyalty points or house-account records. https://thrivepos.uservoice.com/knowledgebase/articles/794877-customer-overview · retrieved 2026-08-08

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

'TOL: Accessiblity for disabled users' is a first-party conformance statement for the consumer web-ordering surface: 'The Web Content Accessibility Guideline (WCAG 2.0) is the standard widely used to ensure a website is accessible. WCAG 2.1 sets forward 14 guidelines to follow... Thrive Online, in its base configuration, has passed these scans at a level "AA" compliance.' It qualifies itself in three ways the claim cares about: conformance is asserted from automated scans rather than an audit ('While there is no central authority that certifies sites as compliant with WCAG 2.1, various technology tools are available to scan the site and report on compliance'); it is void on customisation ('selecting a color palette with insufficient contrast, or adding custom CSS has the potential to put elements out of compliance'); and remediation is a paid service ('We offer a service to scan your site and assist with compliance updates'), under the disclaimer that 'meeting this standard does not guarantee legal protection'. Named shortfalls: no VPAT or ACR is published - 'VPAT' and 'ACR' occur zero times across both corpora (511 UserVoice articles, 251 Granbury KnowledgeBase articles) and thrivepos.com's roughly 75-page sitemap has no accessibility page - and the self-order KIOSK is not covered at all. The kiosk is Thrive's own product with its own release stream (KIOSK RELEASE NOTES 0.1.21-0.1.31, latest 14 Jan 2026) and neither those notes nor its hardware spec ('FireFox browser with specific configuration changes made to operate securely and in kiosk mode' on a '15" or greater, 1024 x 768 native resolution, ELO Touch compatible' screen) mentions a tactile keypad, audio jack, headphone port or any non-visual access mode; 'screen reader' and 'tactile' return zero on both hosts. https://granburysolutions.my.site.com/KnowledgeBase/s/article/TOL-Accessiblity-for-disabled-users · retrieved 2026-08-08

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

Surcharge program documents the 3%/cost-of-acceptance cap, the 30-day card-brand notice filed on the merchant's behalf, and signage at entry, terminal and receipt. Automatic debit/prepaid exclusion is not stated, which is the load-bearing compliance control. https://www.thrivepos.com/payment-processing · retrieved 2026-08-01