Thrive POS

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-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

order-capture-coursing-hold-fire

Checked 2026-08-08 against both published corpora - the 511-article thrivepos.uservoice.com Learning Center and the 251-article Granbury KB (granburysolutions.my.site.com/KnowledgeBase), which is where the current 8.3.x product is documented. Neither contains the word coursing, a hold-and-fire action, or a fire-next-course button. The current table-service articles are the closest thing and they describe a different model: TV - Working with Tables from the Table Screen ends the order flow at 'it may bypass the tender screen and simply save the order (and print in the kitchen)', and TV - Table Service Status and Alerts covers only three service-stage timers ('seated, but has not had an order yet', order not settled, settled not cleared). Neither article warrants that it enumerates every per-order action, so this is a documentation gap, not positive evidence of absence.

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

order-capture-bar-tab-preauth differentiator

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

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

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

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

order-capture-qr-same-check differentiator

Checked 2026-08-08 across both documentation hosts. The earlier reasoning that the documentation is frozen in the v8.0 / v8.1-beta era is withdrawn: granburysolutions.my.site.com/KnowledgeBase publishes ~250 further articles, current to POS 8.3.41 dated 7/14/2026, covering the products the older corpus lacked - Thrive Control Center, the Kiosk, Deliverect, SMS Order Updates and the Analytics app - as well as table service (Table Design, Working with Tables from the Table Screen, Table Service Status and Alerts). Across that current corpus "QR" occurs zero times in a guest-ordering sense, and no article describes a guest-facing at-table ordering surface, on the same check or otherwise; the only self-service front end documented is the staffless Kiosk, which opens its own order. That is still a search returning nothing rather than an enumeration or a stated limitation, and thrivepos.com's product menu is a marketing roundup, so there is no positive evidence either way.

order-capture-kiosk-first-party differentiator

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

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

order-capture-drive-thru-timers

Checked 2026-08-08 against both published corpora. The current 251-article Granbury KB - which carries the 8.2/8.3 release streams, Thrive Analytics articles and the TCC configuration set - contains no occurrence of 'drive thru' or 'drive through' at all, so nothing there either documents or rules out segment timers. In the older Learning Center the only drive-thru document is In House Orders - Drive Thru (kb 850887), a Config > Order Types settings list whose own preamble is explicitly non-exhaustive ('The Orders Configuration function allows you to specify details for each order type, including how you would like to identify customers, delivery requirements and fees, driver and server management, etc.') and which lists no timing capture. Thrive's reporting has moved to Thrive Analytics, whose report catalogue is not published, so no report enumeration is available to argue from either. Documentation gap, not proven absence.

order-capture-voice-ai differentiator

Checked 2026-08-08 across both documentation hosts. The earlier "documentation frozen in 2021" reasoning is withdrawn - granburysolutions.my.site.com/KnowledgeBase publishes ~250 further articles with POS release notes running to 8.3.41 on 7/14/2026, plus TCC, Kiosk, Deliverect and SMS Order Update articles - and a search of that current corpus for AI, voice ordering, IVR, speech recognition and transcription returns nothing. Thrive's one telephony partnership, Kanekt 365 (announced 22 May 2021), is a human call centre - "expertly trained call center staff", with orders "transmitted directly to your Thrive POS system where they will print in the kitchen just like an online order" - so there is no evidence of an AI agent. On the second limb, the order-injection interface that a voice-AI partner would use is real but unpublished: it is reached over a company-level TicketStream API switch in TCC and a vendor-arranged registration, with no public endpoint reference or partner-program page. Neither limb has an enumerative source, so this is undetermined rather than a positive absence.

order-capture-throttling differentiator

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

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

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

order-capture-order-ready-signal differentiator

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.

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

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

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

menu-pricing-fractional-placement differentiator

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

menu-pricing-half-and-half-rule differentiator

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

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

menu-pricing-size-style-matrix differentiator

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

menu-pricing-included-allowance differentiator

'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

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

menu-pricing-upsell-prompts differentiator

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

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

menu-pricing-countdown-auto-86 differentiator

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

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

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

menu-pricing-dual-pricing differentiator

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-pricing-versioning-effective-dates differentiator

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

menu-pricing-franchise-hierarchy differentiator

'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

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-pricing-recipe-linkage differentiator

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

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

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

payments-processor-choice differentiator

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

payments-published-rates differentiator

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

payments-dual-pricing differentiator

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

payments-surcharge-guardrails differentiator

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

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

payments-softpos-tap-to-pay differentiator

Checked 2026-08-08 against a complete local dump of all 511 articles on thrivepos.uservoice.com (the Thrive POS Customer Learning Center, the vendor's only doc host - support./help./docs./kb./learn.thrivepos.com do not resolve) plus thrivepos.com/en-us/features and thrivepos.com/payment-processing. Contactless acceptance is documented only through a tethered terminal: Paying with an EMV device says 'the customer could also tap any NFC payment card or device to pay with Apple Pay or Google Pay, for instance', and the 8.0 release notes name the device - 'EMV integration with the Ingenico IPP320 device. This is an ethernet device. This device also supports Google Pay / Apple Pay'. The marketing page goes no further than 'Hardware with NFC and EMV technology'. No article, release note (7.5 through 8.1.6) or marketing page anywhere names Tap to Pay on iPhone, Android tap-to-pay, or acceptance on a phone without a reader. The obvious enumeration - Hardware Requirements, which lists every peripheral class Thrive supports (touch screens, printers, customer displays, magnetic strip reader, cash drawer, biometric, router/switch, WiFi, caller ID) - carries the footer 'Updated 12/4/2020', which predates phone-as-terminal acceptance existing, so its silence cannot be read as exhaustive for this claim. Release notes after 8.1.6 are redirected off the Learning Center to granburysolutions.lightning.force.com/lightning/r/Knowledge__kav/..., which requires a Salesforce login and could not be read. Unresolved for want of a current hardware or payment-methods enumeration.

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

payments-qr-guest-pay differentiator

Checked 2026-08-08 against both published corpora and the live marketing site. In the 251-article Granbury KB - the current documentation set - the single occurrence of 'QR' is a loyalty marketing 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' (SB - What is the URL for customers to sign up for loyalty), which is enrolment, not payment. No article documents a guest scanning a check to view or settle it; the guest-facing payment surfaces that are documented are the Thrive Online hosted payment form, the kiosk, and the rear customer display for tip/EMV entry. The older Tender Configuration screen the prior 'no' rested on enumerates tender types, not payment-initiation channels, so it cannot rule this out. thrivepos.com's product menu and pricing matrix do not mention scan-to-pay either. This is absence of evidence in both corpora, not a stated limitation.

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

payments-tip-pooling differentiator

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

payments-offline-store-and-forward differentiator

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

payments-offline-decline-liability differentiator

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

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

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

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

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

payments-chargeback-tooling differentiator

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

payments-card-on-file differentiator

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

payments-payout-timing differentiator

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

payments-multi-entity-routing differentiator

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

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

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

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

kitchen-course-firing differentiator

Checked 2026-08-08 against a complete local dump of all 511 articles of the Thrive POS Customer Learning Center 8.0 (thrivepos.uservoice.com/knowledgebase). The token 'coursing' appears nowhere; every hit on 'course' is a Thrive Academy training course (Cashier/Server/Driver/Manager 101). 'Fire' appears only as a fire-extinguisher table-design icon. The two mechanisms that come closest are both something else: Subtotal Tickets (kb 898755) groups items into named subtotals within one ticket for separate payment on large group orders, not for staged kitchen release, and Phone Orders - Delivery (kb 428690) 'Deferred Order Defaults - Lead Time' plus 'Active Serving Time' schedule when a whole deferred order prints, not individual courses. The 19-article Table Service topic, the 33-article Menu / Ordering topic and both KPS articles (408232, 1139926) contain no hold-and-fire action from a terminal, handheld or expo screen. The Learning Center is a complete published surface but asserts no completeness about the product, so this is undocumented rather than absent.

kitchen-prep-time-pacing differentiator

Checked 2026-08-08 against both corpora. In the current 251-article Granbury KB, 'cook time', 'prep time' and 'make time' return nothing about item-level timing (the sole hit is a DoorDash Drive support-contact line about a store adjusting its prep time). The TCC menu articles do enumerate the per-department and per-category kitchen-display settings - 'Department KPS... Settings include: Display Bold, Display Red, Display Included items, Exclude Sizes' - and no timing field appears among them. Thrive measures production time rather than configuring it: KPS Configuration says 'KPS can help you track your production times', the Production Time report shows 'how long it took to bump that order' after the fact, and the only forward-looking timing controls are order-level promise times per daypart and order type. Nothing staggers item start or display times so that an order's items finish together. Neither corpus is certified complete and no page states the limitation, so this is a documentation gap rather than proven absence.

kitchen-order-throttling differentiator

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

kitchen-channel-pause-propagation differentiator

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

kitchen-order-ready-callback differentiator

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

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

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

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

kitchen-printer-fallback differentiator

Checked 2026-08-08 against both corpora, including the current TCC printer documentation. TCC - Printer Options and Print Routing by Station and Order Type sets which printers are active per station and order type, adds credit/local/dispatch printer selections, and offers named print settings that an operator can switch between ('you can add different settings and switch the system to use these settings as needed, so if you have more kitchen stations on a busy weekend'); Configuration in TCC - Menu Printers defines the Designated Items / Production Items / All Items routing behaviours; the Other Options block covers reprint-on-void and reprint-on-change. None exposes a backup printer, a reroute-on-failure option, or any behaviour for a dead printer or dead KPS screen, and the manual switch of print settings is an operator action, not failover. A search of both corpora for failover, fail over and redundan returns nothing relevant. Since none of these pages warrants that it enumerates the whole print subsystem and no support page states the limitation, this is a documentation gap rather than positive evidence of absence.

kitchen-offline-operation differentiator

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

kitchen-item-build-screens differentiator

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

kitchen-pizza-fractional-display differentiator

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

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

kitchen-order-modification-alerts differentiator

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

kitchen-guest-ready-notification differentiator

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

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

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

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

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

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

delivery-route-map differentiator

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

delivery-driver-tracking differentiator

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-zones-polygon differentiator

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

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

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

delivery-driver-comp differentiator

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

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

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

delivery-daas-fallback differentiator

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

delivery-3p-direct-integration differentiator

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

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

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

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

delivery-store-pause

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles current to POS 8.3.41 on 7/14/2026). A pause control does exist, but for first-party ordering only: the Thrive Analytics App "lets you toggle online ordering on or off instantly" and lets you "turn each on or off" by order type, and Online Ordering Control for the Analytics App documents the scoping (company-wide or per location, "this will take affect almost immediately for the online ordering", order-type toggles "can take up to 10 minutes to affect a particular location") - with no timer and no auto-reactivation. Out-of-stock likewise propagates only to Thrive Online: "Saving an item as 'Out of Stock' will automatically update its status in Thrive Online as well". The marketplace channels run through Deliverect, whose documented operator surface in the Thrive docs is location registration, menu publish and channel-to-payment-method matching, with channel management explicitly Deliverect's own console and Deliverect's responsibility. Nothing on either host states whether a DoorDash, Uber Eats or Grubhub storefront can be paused from inside the POS, so this remains a documentation gap rather than proven absence.

delivery-3p-reconciliation differentiator

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

delivery-injection-error-visibility differentiator

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

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

delivery-promise-time differentiator

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

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

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

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

digital-native-app differentiator

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

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-upsell-engine differentiator

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

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

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

digital-qr-table

Checked 2026-08-08 across both first-party corpora: the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com/KnowledgeBase, neither certified complete. On the Learning Center 'QR' occurs once, in Printer Ticket Configuration (kb 408231), as a header/footer field 'QR Code: Can add custom QR code' with no stated destination. On the Granbury KB it occurs once, in 'SB - What is the URL for customers to sign up for loyalty': '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, or other marketing materials!' - a loyalty sign-up link, not a check. The current table-service articles there (TV - Working with Tables from the Table Screen, TV - Table Service Status and Alerts, TCC Table Settings, TV - Split Ticket v8.1, TV - Customer Subtotals) all settle at the POS or server screen and none describes a guest-scanned flow; Thrive Online is a separate ordering site whose checkout is documented only for its hosted payment form. A custom QR could in principle be pointed at Thrive Online without that being documented as attaching to the open check, so this is a documentation gap, not proven absence.

digital-kiosk differentiator

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

digital-group-ordering

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. The closest documented capability is staff-entered, not guest-facing: Subtotal Tickets (kb 898755, republished on the current host as 'TV - Customer Subtotals / Order by Seat (v. 8.1+)') - 'If you ever take large group delivery orders, Subtotals are a great way to organize your tickets, make it easy for people to pay individually, while retaining one master delivery order', with the caveat 'You must pay for all subtotals at once.' That is one cashier building one ticket, with no shareable link, no participant self-service and no per-person or total spend cap. 'Group order' returns zero hits on the Granbury KB; the only 'Group' features there are TCC Marketing Customer Settings User Groups (customer segmentation) and an unreleased company Group structure in the TCC release notes. No TOL release note through 5.0.36 (2026-04-22) and no Thrive POS release note through 8.3.41 (2026-07-14) introduces a shared cart or invite link. Absence across two incomplete corpora is evidence about the documentation, not proof the ordering product lacks it, so this stays unknown.

digital-catering-portal differentiator

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

digital-voice-ai-phone differentiator

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles including release-note streams for POS 8.1.57 through 8.3.41 dated 7/14/2026, TCC, Thrive Online and the Kiosk). Searched both for AI, voice ordering, IVR, speech, transcription and answering service. The documented telephony is still caller-ID assisted human answering: the customer search screen shows incoming calls - "Up to 8 lines are shown, with the customer name and phone # and hold time... Touch one of these customers if you are answering the phone" - and the Phone Calls Report (kb 439838) states "This report requires the integration of a CallerID box." The newer host adds SMS Order Updates, a Kiosk, Deliverect and the Analytics app, but names no AI voice agent, speech-to-order or certified AI-answering partner; the named order-injection partners remain Deliverect, Chowly and DoorDash. No source enumerates the vendor's telephony or partner surface, so this is a documentation gap rather than positive absence.

digital-drivethru-ai

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. On the Learning Center, drive-thru appears in exactly three places: In House Orders - Drive Thru (kb 850887), a Config > Order Types > Drive Thru preferences page; a release note recording that article's addition; and a list of order types in the printing configuration. On the current Granbury KB, 'drive thru' and 'drive-thru' return zero hits - including in Thrive Control Center Active Order Types and Order Type Settings, and in every release stream through Thrive POS 8.3.41 (2026-07-14), TCC 1.1.40, TOL 5.0.36 and KIOSK 0.1.31. There is no lane hardware, speaker or headset integration, no voice ordering, no escalation-to-human handoff and no drive-thru timer anywhere in either corpus, and the only machine-learning feature documented is offer-stacking optimisation. Thrive's addressable market is pizza and delivery independents, which is consistent with the silence but is not evidence, so this remains unknown rather than no.

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

digital-google-order differentiator

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

digital-apple-business-connect

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. 'Apple Business', 'Apple Maps', 'place card' and 'Order Food' return zero hits in both. The only Apple references are Apple Pay acceptance at the EMV terminal and the instruction to download the Dr!ve driver app from the Apple store. The current Granbury KB does document one place-listing integration, and it is the other platform: 'TOL - How can I get my TOL website listed on my Google business listing', alongside Google Tag Manager articles and TCC Marketing Social Media, which collects Facebook, Yelp, Twitter and Instagram page names for the online-ordering confirmation page. Thrive Online's own merchant configuration surface is only partly published, so an Apple Business Connect listing could exist without appearing in either corpus; unknown rather than no.

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

digital-subscriptions

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. Every occurrence of 'subscription' in both refers to Thrive billing the operator: 'CMM is an optional feature with a monthly subscription fee' and the Dr!ve driver app as a 'subscription product' on the Learning Center; on the current Granbury KB, 'navigate to the Accounts > Location section and edit the location ... Scroll to the Subscriptions section', 'TOL-5110 Disable Kiosk locations when the subscription is inactive in TCC', and 'TPOS-8985 Added Order Progress SMS Messaging Subscription and Cheftab to SalesForce'. 'Membership' returns nothing in either. The guest-facing programs that exist are not recurring: Thrive Basic Loyalty is points earned and redeemed for dollars off, Thrive Advanced Loyalty / SalesBuilder is trigger-issued offers, Customer Groups is segmentation and special pricing, and House Accounts is post-pay invoicing. Nothing charges a guest a periodic fee for a delivery-fee waiver, a per-period entitlement or a paid loyalty tier, and nothing states such a program cannot be built. Unknown.

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

digital-guest-data-ownership differentiator

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-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-surcharge-transparency differentiator

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

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

guest-loyalty-thirdparty-identity-attach differentiator

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

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

guest-loyalty-tiers differentiator

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

guest-loyalty-offline-behavior differentiator

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

guest-loyalty-offer-stacking-rules differentiator

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

guest-loyalty-targeted-offers differentiator

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

guest-loyalty-rfm-segmentation differentiator

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

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

guest-loyalty-native-email-sms differentiator

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

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

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

guest-loyalty-campaign-attribution differentiator

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

guest-loyalty-data-export-portability differentiator

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

guest-loyalty-cdp-event-api differentiator

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

guest-loyalty-review-capture-routing differentiator

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

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

guest-loyalty-wallet-pass differentiator

Checked 2026-08-08 on both first-party doc sets. The 511-article Thrive POS Customer Learning Center (thrivepos.uservoice.com) has zero occurrences of 'wallet', 'Apple Wallet', 'Google Wallet' or 'pass'; the documented guest credentials are a magstripe loyalty swipe card with configurable leading/end characters (kb 439050), lookup by phone or email, and the branded mobile app / Thrive Online account. On the loyalty module's own knowledge base (grsalesbuilder.uservoice.com), 'Setting Up the Rewards App' (kb 419742) describes the alternatives explicitly - 'Download the app for iPad or iPhone. Look for "Granbury Rewards" in the app store. If you are using an Android device or just a computer, no worries. Just bookmark a shortcut to your reward program URL' - and that is a staff-side posting app, with no wallet pass anywhere. 'Customize Your Sign Up Page' and 'Customer Log In / Register Card' were also checked. Neither article presents its list as the complete set of guest credential formats, so absence stays unresolved.

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

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

guest-loyalty-ai-offer-recommendation differentiator

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, plus grsalesbuilder.uservoice.com. Thrive does document one machine-learning feature, and it is not this claim: 'Offer Interactions in Thrive Control Center' states 'The Thrive POS system uses advanced machine learning to optimize application of available offers based on those set to auto apply and those you have manually applied, while minimizing the value discounted ... If multiple items on the order fulfill criteria for multiple different offers, the system will choose to apply offers in a way that maximizes the number of offers it can apply.' That resolves which existing offers stack on a live ticket; it recommends nothing about offer content, target audience or send timing. The send-automation surface remains deterministic: every SalesBuilder campaign trigger is a rule parameterised by three variables - 'each trigger has up to 3 variables, titled X, Y and Z. These control how the trigger behaves' - covering Welcome, Birthday, Anniversary, Lost Customer, Point Certificate, spending, visits, transaction value and buckets; TCC's own loyalty and offer articles (Basic Loyalty point bonuses, How to add a basic offer, Complex Offers, Offers Advanced Settings) are all manually authored. No article in either corpus describes a generated or recommended offer, audience or send time, but neither corpus is exhaustive, so this stays unresolved rather than scored absent.

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

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

labor-photo-punch-verification differentiator

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

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

labor-offline-time-punch differentiator

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. adversarially verified

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

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

labor-native-scheduling differentiator

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

labor-demand-labor-forecast differentiator

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

labor-realtime-labor-percent differentiator

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

labor-overtime-prevention differentiator

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

labor-break-compliance-by-state differentiator

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

labor-fair-workweek-support

Re-checked 2026-08-08 against both published corpora. Withdrawn: the earlier claim that Thrive's only scheduling documentation is v8.0-era. The 251-article Granbury KnowledgeBase carries current labor articles - 'TV - Timeclock Functions: Clock In / Out / Breaks / Review Timeclock Records (8.1+)', which documents schedule enforcement ('If you are using schedule enforcement, the system will prevent clock in if the employee is not on the schedule'), and 'TV - Request Time Off (v. 8.1+)' ('Employees can easily enter time off requests from the POS system ... These requests will also be noted in the scheduling function') - and the release-note streams show shift scheduling being handed to a partner: 'TPOS-8706 7Shifts Integration Live' (TCC 1.1.14+), 'Add Sync All Button to TCC>Locations>Integrations>7Shifts', 'Added a toggle to Employee Record to "View 7Shifts Schedules"', and an 8.3.35+ fix to '7Shifts Schedule Verification'. What is still absent everywhere: any advance-notice or posting-deadline clock, any good-faith-estimate document, and any predictability-pay calculation on the payroll side. The only scheduling-rule work in the notes is 'Restored the Break Rules functionality partially - so Thr!ve users can specify break rules for scheduling purposes. (Not yet enforced in frontend)' (8.1.3). Thrive's documented integration surface with 7Shifts is schedule verification and viewing, not compliance calculation, and no first-party statement claims predictive-scheduling support either way.

labor-minor-labor-rules

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. 'Minor' returns zero hits on the current Granbury KB. What that host does enumerate is the clock-in gate: 'TV - Timeclock Functions (8.1+)' lists the reasons an employee cannot clock in - required messages, inactive employee, no security workgroup assigned, no job types authorised, expired employee requirements such as food handlers or driver's licence, and 'Employee is not scheduled to work. If you are using schedule enforcement, the system will prevent clock in if the employee is not on the schedule' - with no age dimension. On the Learning Center, 'Configuring Schedule Overview' (kb 561588) enumerates four schedule settings (minimum shift length, verify schedule for clock on, record late after, allow early clock in), the break and lunch rules are keyed to hours worked rather than age, and Job/Employee Requirements track document expiry. Against that, the v7.8.x release notes record 'resolved issue with adding employees, with birthday defined, complains about being a minor' - so an age check exists in the product that no article on either host describes - and TCC's own release notes record 'TCC-1563 Remove DL, SS and birthdays from employee records', which changes what age data the current product even holds. No article in either corpus states an age-based hour cap, prohibited time window or school-day limit at scheduling or clock-in, and the scheduling module itself is undocumented on the current host, so this stays unresolved rather than scored absent.

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

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

labor-qualified-tips-w2-reporting differentiator

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. The earlier reasoning - that the documentation predates the requirement - is withdrawn: the Granbury KB carries dated first-party release streams through Thrive POS 8.3.41 (2026-07-14), so a current statement would be visible if one existed. It does not. 'W-2', 'Box 12', 'tipped occupation' and 'qualified tip' return zero hits on that host, as do ADP, Gusto, Paychex and QuickBooks; the only payroll-export material published there is a per-job-type setting described as 'a payroll code, which can be used in some payroll exports', plus tip-declaration and tips-on-payroll settings ('Declare tips at clock off', paying driver fees on payroll). On the Learning Center, 'Configuring ADP Payroll Export' (kb 947889) enumerates the configurable payload - Company Code, Batch Description, a single Tips Code, Driver Fees Code, Server Sales Code - and the Payroll Report (kb 439799) shows a single tips column, with no cash-versus-charged split and no occupation code. That is an enumeration of one provider's export as documented, not a vendor statement about tax-year 2026 W-2 handling, and thrivepos.com says nothing about payroll tax reporting either. Unresolved.

labor-native-payroll differentiator

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

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

labor-shift-swap-workflow differentiator

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

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

labor-server-performance-metrics differentiator

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

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

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

inventory-theoretical-vs-actual differentiator

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

inventory-realtime-depletion differentiator

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

inventory-86-auto-sync differentiator

'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

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

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

inventory-vendor-catalogs-edi differentiator

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

inventory-invoice-ocr differentiator

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. On the Learning Center, 'Receiving Purchases' (kb 938934) is the whole receive workflow and is manual throughout: select the vendor, optionally receive against an open PO, 'enter the vendor's invoice number at the top of the Receive screen', edit the receive date, 'double check the quantity received and edit the cost, if needed', add ingredients, record delivery fees and taxes under Other Costs, save. 'Create Purchase Order' (kb 886341) is outbound only and the sole file format documented in the module is a PO export - 'the PO Export format has one option - eSysco - which can be used with Sysco accounts' - which sends orders to the vendor rather than ingesting invoices. 'OCR', 'scan invoice', photo capture and e-mail ingestion return zero hits in both corpora, and no release note through Thrive POS 8.3.41 (2026-07-14) introduces invoice ingestion. The current Granbury KB does not republish the inventory module at all - inventory appears there only as 'requires inventory module' on ticket-weight settings, a voided-item deduction note and a 'Disable Made/Un-Made being required if Inventory is disabled' fix - so the module's current surface is largely unpublished. A step-by-step of the manual path plus an unpublished module is not an assertion that no import path exists, so this stays unresolved rather than scored absent.

inventory-price-change-alerts differentiator

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

inventory-par-auto-suggest differentiator

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

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

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

inventory-commissary

Checked 2026-08-08 against BOTH published corpora - the 511-article thrivepos.uservoice.com Learning Center (which stops at release 8.1.6) and the 251-article granburysolutions.my.site.com KnowledgeBase, where the current 8.3 product is documented. Neither is certified complete. 'Commissary', 'central kitchen' and 'transfer cost' return zero hits in either. The building blocks half-exist in the older corpus: 'Add A Inventory Ingredient Recipe' (kb 886338) covers items made in advance from other ingredients and computes their cost ('Calculated Cost: this is a read only field which will display the cost of the recipe based on the ingredients you've selected'), and multi-store apparatus exists elsewhere - a 'Master Store' flag, and now Thrive Control Center's company/location model. The 17-article Manager - Inventory topic documents only ingredients, recipes, item association, PO creation, receiving, adjustments, physical inventory and usage reporting; there is no issue, requisition or inter-location stock transfer function in it, and 'Transfer' in the cash module (kb 818370) moves money between cash locations, not stock between stores. Critically, the current-generation KnowledgeBase contains NO inventory articles at all - inventory was not carried into the Thrive Control Center documentation set - so what the 8.3 inventory module does today is undocumented in either direction. Unresolved.

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

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

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

inventory-cogs-gl-export

The prior evidence has been withdrawn as unverifiable. The cited article (thrivepos.uservoice.com/knowledgebase/articles/1896298-quickbooks-integration) now redirects to the knowledgebase index, the Learning Center's own search returns zero articles for 'quickbooks', and the phrases it was quoted for appear in neither the 511-article Learning Center dump nor the 251-article Granbury KnowledgeBase dump; 'QuickBooks', 'chart of accounts', 'general ledger', 'Sage', 'Intacct', 'NetSuite' and 'Xero' return zero hits across both corpora. A same-named but unrelated product (Thrive by Shopventory / Thrive Metrics) does publish QuickBooks chart-of-accounts mapping documentation, which makes the withdrawn quotation a probable conflation, so it was not re-pointed. The only surviving accounting signal is an unlabelled 'R365' partner logo in the image list of www.thrivepos.com/en-us/thrive-pos-third-party-integrations, whose body text names only Deliverect and describes 'back-office management tools' generically - grade D, and silent on period COGS, accounts-payable invoice detail and GL mapping per item category. Checked 2026-08-08. Not established either way.

inventory-native-not-partner differentiator

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

inventory-menu-margin-linkage differentiator

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

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

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

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

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

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

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

reporting-server-scorecards differentiator

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

reporting-channel-profitability differentiator

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

reporting-multiloc-drilldown differentiator

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

reporting-custom-report-builder differentiator

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

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

reporting-raw-warehouse-export differentiator

Checked 2026-08-08 across BOTH published corpora (511-article thrivepos.uservoice.com Learning Center, which stops at 8.1.6, and the 251-article granburysolutions.my.site.com KnowledgeBase covering the current 8.3 product); neither is certified complete. 'S3', 'SFTP', 'Snowflake', 'BigQuery' and 'data warehouse' return zero hits in either. Two mechanisms come close and neither matches. Scheduled Analytics e-mail (TCC - E-mail reports on schedule from Thrive Analytics) does automate recurrence per employee, time zone and location set, but the payload is a formatted report, not transaction-level raw data, and it lands in an inbox rather than a destination the operator owns. TicketStream is a genuine transaction-level feed - orders, timeclock events, paid in/out, end-of-day deposit, dispatch and return records - and TCC exposes it as a company-level switch, 'Turn on the TicketStream API only if any 3rd party integrations will be used', but every documented destination is Granbury's own cloud, and TCC release note 1.1.39 (5/11/2026) says only that 'Thrive Sync infrastructure needed to be released for Integrations to begin Alpha'. Ad-hoc extraction remains manual: Analytics widgets offer data download behind a three-dot menu, Ticket Finder exports a table view, back-office reports export to Excel. No operator-configurable sink is documented in either corpus. Unresolved.

reporting-public-api differentiator

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

reporting-webhooks differentiator

Checked 2026-08-08 against BOTH published corpora (511-article Learning Center, stopping at 8.1.6; 251-article Granbury KnowledgeBase for the current 8.3 product), neither certified complete. 'Webhook', 'HMAC', 'signature verification' and 'retry' return zero hits in either. The nearest real mechanism is TicketStream, which is genuinely event-driven - the v7.8.2 notes record 'added a data feed event when a ticket is Assigned / Dispatched', later notes cover order-status updates at driver and server close, tip updates, and a 'refactored Ticketstream message queue process for better reliability' - and Thrive Control Center now exposes it as a company-level switch, 'Turn on the TicketStream API only if any 3rd party integrations will be used'. But every documented destination is Granbury's own cloud reporting platform; there is no operator-configurable callback URL, no event catalogue, no payload example, no signing scheme and no documented retry or replay behaviour, and enablement remains a support request. TCC 1.1.39 (5/11/2026) notes only that 'Thrive Sync infrastructure needed to be released for Integrations to begin Alpha'. Whether Granbury will emit TicketStream events to a partner endpoint under contract is not published on either host. Unresolved rather than absent.

reporting-api-not-upcharged differentiator

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

reporting-tier-paywall differentiator

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

reporting-history-retention differentiator

Checked 2026-08-08 against BOTH published corpora (511-article Learning Center; 251-article Granbury KnowledgeBase), neither certified complete. 'Retention' and 'purge' return zero hits; 'archive' returns only card-data housekeeping - the Credit and Gift configuration setting 'Archive data after X days - not really used' (TCC - Credit Card and Gift Configuration) - which is PCI hygiene, not reporting history. The current Analytics documentation still states no window: 'TV - Introduction to Thrive Analytics' gives refresh cadence ('Analytics reports are updated every 2-3 hours') and a filter where you 'choose a time frame or pick dates from a calendar'; Ticket Finder offers date shortcuts (yesterday, this month, last week) and an 'Add Date' picker with no stated earliest date; scheduled e-mail reports cover forward periods only. No article on either host commits to 24 months of transaction detail being queryable, and none documents truncation or an archive-retrieval fee. Because Thrive is an on-premises system with a local database plus a separate cloud store, the answer may differ between the two and neither is published. Unresolved.

reporting-anomaly-alerts differentiator

Checked 2026-08-08 against BOTH published corpora (511-article Learning Center; 251-article Granbury KnowledgeBase), neither certified complete. Every alert documented on either host is a fixed configured condition, not a deviation from a historical pattern: overtime-approaching alerts, Requirement Expiration Alerts, End Of Day Deposit Alerts, table-service and restroom-service status alerts, driver alerts, the Manager Alerts widget for time-off requests and out-of-stock, and the Large Tip Alert added in v7.8. On the cloud side, 'TCC - E-mail reports on schedule from Thrive Analytics' delivers a chosen report on a timetable (time zone, report, time frame, schedule, locations) with no conditional or threshold option, and the current mobile Thrive Analytics App (documented 14 Jul 2025) offers 'live updates - every 2 to 3 minutes - on the numbers that matter most: sales and labor' plus online-ordering toggles, but describes no alerting at all. 'Anomaly' returns zero hits. Analytics remains thinly documented - a handful of articles for a whole BI product - so its alerting surface is not established well enough to assert absence. Unresolved.

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

reporting-guest-cohorts differentiator

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

reporting-sales-forecast differentiator

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

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

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

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

multi-location-local-override-policy differentiator

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

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

multi-location-scheduled-publish differentiator

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

multi-location-new-store-template differentiator

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

multi-location-corp-vs-franchisee-roles differentiator

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

multi-location-royalty-calculation differentiator

Re-checked 2026-08-08 against BOTH local dumps - 511 Customer Learning Center articles (thrivepos.uservoice.com) and 251 Granbury KnowledgeBase articles (granburysolutions.my.site.com), neither certified complete. The earlier rationale's claim that 'royalty', 'franchise' and 'ad fund' occur zero times was run only on the UserVoice corpus and is withdrawn: 'TCC - How To Add A Company' says '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.' That is franchise-aware tenancy, not a royalty engine. Across both corpora 'royalty' and 'ad fund' still occur zero times; the enumerated Analytics dashboards (Store Summary, Product Mix, Deliveries, Server Performance, All Reports) and the seven POS reports topics contain no royalty, ad-fund or franchise-fee report, and no configuration screen offers a royalty basis. Because neither dump is certified complete and TCC's full screen inventory is unpublished, this remains unknown rather than no. adversarially verified

multi-location-royalty-collection

Checked 2026-08-08 against BOTH published corpora (511-article Learning Center; 251-article Granbury KnowledgeBase covering the current 8.3 product), neither certified complete. 'Royalty' and 'ACH' occur zero times in either. The only occurrence of 'franchise' across the current KnowledgeBase is organisational rather than financial: '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 and change just their location, it is fine to group them under the company even if they operate fairly independently' (TCC - How To Add A Company). So the franchisor structure exists for menu and reporting purposes with no money movement attached. The money movement Thrive does document runs the other way - card and gift acceptance through third-party processors whose merchant credentials are per location, house-account billing to customers, and a payroll export to ADP - with no debit-from-a-store mechanism of any kind and no franchisee-visible statement of charges. Nothing on www.thrivepos.com addresses it either. Not documented in either direction.

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

multi-location-normalized-item-rollup differentiator

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

multi-location-cross-location-giftcard

Checked 2026-08-08 against BOTH published corpora, neither certified complete. Gift balances are not held by Thrive. For current releases the setup lives in Thrive Control Center and it is explicitly split: general security and print settings 'can be configured at the company level, which will default for all locations in your Company or Group', but 'Specific credentials for credit card processing and gift card setup will ONLY be available for the individual location' (TCC - Credit Card and Gift Configuration, updated Dec 2023). The gift processor is chosen per location from WorldPay/Element, Standalone Stored Card, Valutec/Express, OpenEdge, Mercury or Cayan, and for Cayan the article says 'we get the end credentials for their platform and are not involved with the setup of the Gift Card itself'. Whether a card sold at one store is redeemable at another is therefore a property of the merchant account the operator holds with that processor, and no Granbury article addresses it. Nor is there an outstanding-liability report: the only liability treatment documented is the end-of-day line 'Gift C. Sold - Gift Certificates or Cards sold. These are not included in your sales figures, as they are really liabilities for your business', which is a day-part exclusion, and no inter-store settlement or redemption reconciliation article exists on either host. Unresolved in both directions.

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

multi-location-multi-brand differentiator

Checked 2026-08-08 against BOTH published corpora, neither certified complete. 'Virtual brand' never appears. Thrive Control Center does have a Brand construct, and the vendor's own description limits it: '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) - a cross-company grouping of whole locations, not two brands inside one. Companies can hold multiple menus, but assignment is one menu per location: 'The Location has a menu assigned to it, which allows us to pick the Menu Tab you want to default to, where the Company is valid for all Menus' (TCC - Set Default Menu Tab Per Station); the per-station control chooses a starting menu TAB within that one menu, for example a bar tab for a bar station. Against the claim, a store record still carries one Store Name and one Logo which 'will appear on the POS screen and printed reports', and revenue is reportable by order type, department, item and pricing scheme but not by brand; no article describes separate receipt branding on one station or a second concept sharing a drawer. Suggestive of absence, but a single-menu, single-logo store record is not a statement about co-branding, so this stays unresolved.

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

multi-location-config-audit-log differentiator

Checked 2026-08-08 across BOTH first-party corpora, neither certified complete: the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase. On the newer host 'audit' occurs twice and neither is configuration-level - a web-accessibility page recommending 'a professional compliance auditor', and time-off requests providing 'a clear record of requests and an audit trail for approving or rejecting requests'; 'change log' and 'change history' occur zero times on either host. What TCC does document about change tracking is version-level, not actor-level: the publish screen lets you '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 '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', and an override indicator shows that a location differs from its parent - but none of these names the user who made the change or produces an exportable history. The older corpus's change-tracking features are transactional rather than configuration-level ('Track Adds & Edits to Tickets on the Full Review Screen'; an edited deposit 'will show the user who made the edit, the time and date'; 'Required Reason When Editing Time Record'). So nothing on either host shows who changed a price, tax, permission or discount at which location and when, and nothing is exportable to corporate - but neither host publishes a complete TCC screen inventory, so this remains absence of documentation rather than documented absence. (Withdraws the earlier rationale's premise that the 511-article Learning Center is the complete corpus.)

multi-location-enterprise-api differentiator

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

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

hardware-commodity-devices differentiator

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

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

hardware-handheld-purpose-built

Checked 2026-08-08. Hardware Requirements (thrivepos.uservoice.com/knowledgebase/articles/423702, Support/Hardware topic) lists the offered devices and every one is a fixed or enclosed unit: 15.6-inch and 14-inch Android touchscreens with foldable or printer bases and wall-mount capability, a 10.2-inch iPad 'designed for retail environments. Comes with a secure enclosure & base', and an all-in-one Linux workstation; the minimum-requirements table adds touch screens '15" or greater' and a separate Magnetic Strip Reader, and the Thrive T2 Android Tablet article (kb 1910761) describes a tablet with a printer base and customer-facing screen, i.e. a counter station. Card entry is on a separately networked EMV pinpad reached with the Pin Pad button, not a reader in the device. www.thrivehardware.com's categories are Computers, Display Kits, Tablets, EMV Pinpads, Credit Card Devices, Touch Screen, Printers, Cash Drawer, Router, WiFi Hardware, Switch, Caller ID, Backup Power, Supplies and Services - no handheld line. Across all 511 KB articles 'handheld' appears once, as an aside about counting inventory, and 'tableside', 'rugged', 'drop rating' and 'IP54' appear zero times, so no drop or ingress rating is published for any device. This leans strongly toward absence, but neither the hardware page nor the store asserts completeness, so it stays unknown.

hardware-handheld-battery-swap differentiator

Checked 2026-08-08. There is no purpose-built handheld to rate: Hardware Requirements (kb 423702) and the Thrive T2 Android Tablet article (kb 1910761) describe counter-mounted or enclosed tablets, and www.thrivehardware.com sells no handheld category. Even for the tablets that are offered, the published specification is limited to screen size, OS ('Android 8.1 OS, 4GB DDRIII RAM', 'Android Pie 9.0 OS, 3GB RAM, 32GB storage'), mounting options and 'one year warranty' - no battery capacity, no rated runtime and no statement about replaceable or hot-swappable batteries. The word 'battery' occurs 9 times across all 511 articles and every occurrence is about the store's UPS battery backup for the router, modem and switch. Nothing to resolve this in either direction.

hardware-handheld-lte

Checked 2026-08-08 against BOTH published corpora (511-article Learning Center; 251-article Granbury KnowledgeBase), neither certified complete: 'cellular', 'LTE' and '4G' occur zero times in either. The current release notes do establish mobile stations - 8.2 'Added support for IOS and workstation Desktop ability to exit the launched support page' and 8.3.31 'Fixed bug where MSRs were not swiping in iOS on 8.3' - so tablet stations exist, but nothing documents a radio in them or a failover path. The connectivity articles cover installing the Granbury-supplied router, switch and wireless access point and a UPS for them; www.thrivehardware.com categories run Computers, Display Kits, Tablets, EMV Pinpads, Credit Card Devices, Touch Screen, Printers, Cash Drawer, Router, WiFi Hardware, Switch, Caller ID, Backup Power, Supplies, Services, with no cellular product. Store-level cellular backup appears only on the marketing blog (thrivepos.com/en-us/thrive-product-news/dont-let-internet-outages-take-a-slice-out-of-your-profits), which is a purchasing recommendation to the operator, not a documented device failover feature. Unresolved.

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

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

hardware-kiosk differentiator

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

hardware-drive-thru

Re-checked 2026-08-08 across both published corpora - the 511-article thrivepos.uservoice.com Learning Center and the 251-article granburysolutions.my.site.com KnowledgeBase where the current 8.3.x product is documented - plus www.thrivehardware.com. Neither dump is certified complete, so this finding is scoped to them. 'menu board', 'headset' and 'confirmation display' occur zero times in both, and the Granbury KnowledgeBase carries no drive-thru article at all - the term does not occur in any spelling, including in the POS 8.2/8.3.x, TCC 1.1.x and kiosk release-note streams. The software side is one order type: In House Orders - Drive Thru (kb 850887, Config - Order Types) enumerates its whole option set - prompt for customer name, tent number, table number, customer lookup; allow save of open tickets; show in server details - with no timer, no speed-of-service target and no measurement, and no drive-thru timing report appears in either host's reporting topic. On hardware, Hardware Requirements (kb 423702) lists the supported peripheral classes as touch screens, printers, customer displays and magnetic stripe readers, and the Thrive Hardware store's categories carry no outdoor menu board, confirmation display or speaker/headset line. A recommended-hardware page and a store catalogue are not exhaustive statements, so this is 'not documented in either published corpus', which is unknown, not no.

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

hardware-peripherals

Catalog carries Cash Drawers, EMV Pinpads, Credit Card Devices, Routers, WiFi Hardware, Switches, Backup Power and Caller ID units. No scales or customer-facing displays listed; no formal compatibility list. https://thrivehardware.com/ · retrieved 2026-08-01

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

hardware-tap-to-phone differentiator

'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-pricing-transparency differentiator

thrivehardware.com exposes category navigation only; no SKU-level prices are published on the public site. https://thrivehardware.com/ · retrieved 2026-08-01

hardware-ownership-vs-lease differentiator

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

hardware-usable-after-churn differentiator

Checked 2026-08-08 on all three Granbury hosts. www.thrivepos.com publishes no master service agreement or terms of service - the footer's only legal links are a Privacy Policy and SMS Service Terms, and www.thrivepos.com/terms-of-service returns 404 - so there is no contract language to read on hardware ownership or post-termination use. www.thrivehardware.com/returns covers the 60-day warranty, the RMA requirement and restocking fees but says nothing about whether equipment keeps working after cancellation. The complete 511-article Customer Learning Center contains no article on cancellation, deactivation or repurposing hardware; the closest thing is Store Setup Overview's 'Station License: this is where the system will indicate how many active licenses you have with Granbury for this POS', which shows licensing is enforced per station but not what happens to the device when the licence lapses. Genuinely unresolvable from published material.

hardware-rma-sla differentiator

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

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

hardware-remote-device-management differentiator

Re-checked 2026-08-08 across both corpora. Correction to the earlier reasoning: Thrive Control Center's Hardware section IS published, on the 251-article granburysolutions.my.site.com KnowledgeBase - 'Stations and Cash Drawer Configuration in Thrive Control Center' (Hardware > Stations) and 'TCC - Printer Options and Print Routing by Station and Order Type'. What those screens do is configure, not monitor: a station carries a name, a fixed IP address or 'Allow IP to change', on-screen signature, fingerprint login, restricted order types and a default order type and screen, and changes reach the store only through a separate publish step. No status field, no online/offline indicator, no remote reboot and no staged rollout appears; 'station status', 'printer status', 'online/offline', 'heartbeat' and remote-reboot vocabulary return zero across all 251 Granbury articles and all 511 UserVoice articles, including the TCC 1.1.x, POS 8.2/8.3.x and kiosk release-note streams. Updating is still documented as local (Update Your POS System, kb 507549: run from that store's own Manager Home, only in a 'Sunday 9pm - Thursday 6am' window, then 'reboot each station' by hand), and version visibility is per store. Because neither dump is certified complete and TCC's screen inventory is only partly published, this is absence of documentation rather than documented absence.

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

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

extensibility-api-access-cost differentiator

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

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

extensibility-free-sandbox differentiator

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

extensibility-oauth-partner-apps

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles current to 7/14/2026). "OAuth" appears zero times on either, and no article describes API keys, tokens, scopes, or an operator screen to grant or revoke an individual third-party app. What the newer host does document points the other way without enumerating it: API access is a single company-wide switch - "Turn on the TicketStream API only if any 3rd party integrations will be used. Turn it OFF for most customers" (TCC company setup) - and each integration is onboarded by exchanging identifiers rather than by a delegated grant: Deliverect is registered by putting its Account ID on the TCC company Integrations tab and reading back a Location ID ("Deliverect will be provided the TCC Location ID and then Register their system to TCC automatically"), transport is AWS SQS/SNS, Chowly is authorised by a Granbury account manager, and DoorDash Drive has the operator paste a Business Name and Account ID. Three worked examples are not an enumeration of the authentication model, and no developer documentation is published (developer.thrivepos.com does not resolve), so this remains undetermined rather than a positive no.

extensibility-webhooks-push

Re-checked 2026-08-08 across both published corpora - the 511-article UserVoice Learning Center and the 251-article Granbury KnowledgeBase including the 8.2, 8.3, TCC, TOL, KIOSK and Deliverect release streams. 'Webhook' returns zero hits on both hosts. The outbound mechanisms that are documented are internal rather than partner-facing: TicketStream, introduced in the 7.5 notes ('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') and called 'our new data API' in the current DoorDash Drive article, is store-to-Thrive-cloud telemetry enabled by a Granbury administrator; and the Deliverect Overview states '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' - a private queue between Thrive and one named broker, not a subscribable endpoint. The TCC release notes list individual REST endpoints ('TCC API endpoint to get tenant details based off deliverect credentials', 'Expose Company's mobile app version and bundle id thru API'), which are request/response calls, not events. No article anywhere describes a partner registering a callback URL, an event catalogue for created/modified/paid/voided/refunded, payload shapes or delivery semantics, so whether the partner channel pushes or is polled is not published.

extensibility-webhook-reliability differentiator

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

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

extensibility-menu-write-api differentiator

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles current to POS 8.3.41 on 7/14/2026). Correction to the earlier reading: the menu-integration path is no longer a file hand-off. Granbury documents an automatic outbound API sync - "The entire development was from Thrive POS and TCC to the Deliverect api interface... 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" (Deliverect Overview / Q and A). That is still a write FROM Thrive, not INTO it. Inbound menu authoring remains a UI function: version 8.1 moved "all of the menu, item, price and coupon controls" into Thrive Control Center, and TCC's own Import Menu is a one-time POS-to-TCC migration driven from the Menus Admin screen, not an endpoint. No article on either host describes a menu, item, modifier or price write endpoint, and no API surface is enumerated anywhere, so this is absence of evidence rather than evidence of absence.

extensibility-data-symmetry differentiator

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles current to 7/14/2026). There is still no published API reference against which symmetry could be tested - developer.thrivepos.com does not resolve and thrivepos.com's sitemap has no API page. What is now visible is that read and write are separate purpose-built channels rather than one object model: reads run through TicketStream (order, item, timeclock, dispatch and deposit feeds; enabled by a company-level switch in TCC), order writes run through an HTTP endpoint the release notes name only in passing as "path":"/pos/order" when a Deliverect submission failed, and menu writes run outward only, as an automatic push from Thrive Control Center to Deliverect on publish. Employee and customer objects appear in internal endpoints mentioned in TCC release notes ("Added endpoint to return employee details given company id and employee phone number for Drive app") that are not offered to third parties. No object list is published for either direction, so read/write symmetry is undetermined rather than absent.

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

extensibility-doordash-preferred differentiator

Thrive is absent from DoorDash's 2026 Preferred Integration Partner cohort. DoorDash's own newsroom post of May 18, 2026 enumerates the cohort in full - 'Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, and UrbanPiper' - and states the roster 'was generated based on performance and feature sets as of May 8, 2026'. Affirmative absence from a closed, operator-published list, not merely undocumented. The DPIP criteria a partner must meet (order failure rate below 1%, merchant cancel rate below 1%, 250+ DoorDash stores, eight named features) are documented separately at developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/, which publishes no roster. Citation moved 2026-08-09: the previously cited get.doordash.com blog post redirects to merchants.doordash.com and now 404s. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-09

extensibility-first-party-delivery-integrations differentiator

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

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

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

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

extensibility-bi-data-warehouse differentiator

Re-checked 2026-08-08 across thrivepos.uservoice.com (511 articles) and granburysolutions.my.site.com/KnowledgeBase (251), neither certified complete. Every documented export remains pull- or e-mail-based: a per-report "Excel" button (kb 943822 troubleshoots opening those files), a manual QuickBooks .csv of the detail transactions behind each total (kb 1896298), and Thrive Analytics scheduled e-mail delivery of reports (kb 1963333) - a rendered report to an inbox, not raw rows to a destination the customer controls. Correction to the earlier reading: TicketStream is more than an internal reporting pipe. It is described first-party as "our new data API" and "our cloud-based reporting engine used for API access to POS data", it carries transaction-level order, item, timeclock, dispatch, driver-close, return and deposit feeds, and it is exposed by an explicit per-company switch whose stated purpose is third-party access - "Turn on the TicketStream API only if any 3rd party integrations will be used" (TCC add-company). So a transaction-level feed can be turned on for an outside consumer, which the earlier rationale said was unstated. What is still unpublished is everything this claim actually tests: no schedule, no delivery mechanism, no customer-controlled destination (no S3, SFTP, warehouse or Snowflake share is named on either host), no format or schema, and no way for an operator to enable it without Granbury. Undetermined rather than absent.

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

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

extensibility-headless-embedded

Checked 2026-08-08 across both documentation hosts (thrivepos.uservoice.com, 511 articles; granburysolutions.my.site.com/KnowledgeBase, ~250 articles current to 7/14/2026). The kiosk that post-dates the older corpus is first-party, not a third-party UI on an open engine: its release notes are published as "Thr!ve On Line - Kiosk" versions built on Thrive's own order service and TOL rules ("Kiosk now follows TOL rules for available modifiers and adheres to EX OL rules set on items/modifiers"), and the one API surface named in them - "Make Altura swagger documentation accessible again" - is an internal Jira item with no public reference. Every other front end is first-party too: Thrive Online, the Dr!ve driver app, the rear customer display. The one third-party channel, Deliverect, submits an already-priced and already-paid order to /pos/order rather than driving item selection, pricing or tender. The POS itself runs as a browser application on an in-store server ("FireFox browser with specific configuration changes made to operate securely and in kiosk mode", kb 423702), which is an implementation detail, not a documented embedding surface. Whether the partner-gated interface could be driven headlessly is not published.

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

extensibility-data-portability-exit differentiator

Checked 2026-08-08. The only agreements Thrive publishes are the customer-portal Terms and Conditions and Privacy Statement at support.portal.granburysolutions.com/home/terms/ and /home/privacy/ - both read in full, and both are website terms of use (acceptance, modification, linked sites, prohibited use, data collection) with no service, termination or data-return clause - plus thrivepos.com/en-us/privacy-policy and /en-us/sms-messaging-tos. thrivepos.com's sitemap contains no MSA, subscription agreement or contract page. The Learning Center documents per-report Excel export, a QuickBooks .csv of detail transactions (kb 1896298) and a customer-list export from the POS customer search, but no complete historical extract of orders, customers, menu and payments metadata on demand, and nothing about what happens at contract end. Not published either way.

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

reliability-offline-card-auth differentiator

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

reliability-offline-decline-liability differentiator

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

reliability-lan-degraded-multi-terminal differentiator

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

reliability-local-transaction-engine differentiator

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

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

reliability-printer-fallback

Checked 2026-08-08 against the complete dump rather than the topic listing: re-read the 13-article Config - Printing topic (general printer setup, printer station configuration, print settings, printer ticket configuration, Other Printing Options kb 410417, KPS configuration, item printing, ticket sort order, promo messages) plus Security Settings Configuration (kb 720465) and Hardware Requirements (kb 423702). Nothing describes a backup printer, automatic rerouting when a station is unreachable, or a staff alert on print failure. The nearest documented behaviours are all operator-driven: the employee permission "Toggle print setting: Authorize this employee to activate an alternate printer setting" (kb 720465), the "Print customer receipt on demand ... If no receipt printer is defined for the station / order type, a Print Receipt button will appear on the tender screen to print an individual order to the local printer" fallback added in 7.7, and "Print 'nothing to prepare' tickets". Those are configuration screens, not a stated enumeration of failure behaviour, so absence here is not proof of absence.

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

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

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

reliability-contractual-uptime-sla differentiator

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

reliability-incident-postmortems

Checked 2026-08-08. Thrive does operate a public status page - status.thrivepos.com, seven monitored components - but it is an UptimeRobot deployment whose surfaces are automated monitor logs, 90-day uptime bars and short "status updates"; its event feed (/api/getEventFeed/O8YLDSAr48) returned zero events for the trailing seven days, and it has no facility for a written root-cause narrative. Enumerated thrivepos.com's sitemap: the roughly 60 non-blog pages include a "Thrive Product News" series and case studies but no incident, trust or security page, and the Release Notes topic in the Learning Center records defect fixes without outage narratives. No post-incident report was found - and no major outage that would have occasioned one is documented either, so this is not evidence that the vendor withholds them.

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. adversarially verified

reliability-onsite-install differentiator

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

reliability-menu-build-service differentiator

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

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

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

reliability-pci-dss-4-attestation

Re-checked 2026-08-08. Correction to the earlier reasoning: the vendor does point merchants at a certification, on the current-product KnowledgeBase. 'TV - How can I validate that Thrive is a PA-DSS Certified application for PCI Compliance?' answers: '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. You'll see the certification results.' That is a PA-DSS payment-application validation, which is not what this claim asks for: PA-DSS was retired by the Council in favour of the Software Security Framework, and a PA-DSS listing is neither a PCI DSS v4.0/4.0.1 Attestation of Compliance for the vendor's own environment nor a validated P2PE listing, and it says nothing about the post-March-2025 future-dated requirements. Nothing else exists: trust.thrivepos.com does not resolve against a working control subdomain, thrivepos.com's sitemap (about 75 non-blog pages) has no compliance, trust or security page, and across both published corpora - 511 UserVoice articles and 251 Granbury KnowledgeBase articles - 'PCI DSS 4', 'v4.0.1', 'AoC' and 'Attestation of Compliance' return zero, the remaining PCI mentions being product controls (administrative password gate, 90-day expiry, six-attempt lockout, EMV removing card data from the POS). Whether Granbury holds a current v4.0/4.0.1 AoC is not published.

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

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

reliability-failover-terminal-role differentiator

Re-checked 2026-08-08 against both published corpora, including the post-8.1.6 release notes an earlier pass reported as unreachable - granburysolutions.my.site.com is retrievable with a crawler user agent and carries the POS 8.2/8.3.x, TCC 1.1.x, Thrive Online and kiosk release-note streams, so that retrieval barrier is withdrawn. Thrive is a designated-server architecture and the current admin tool reflects it: 'Stations and Cash Drawer Configuration in Thrive Control Center' states that 'Stations will be added as the "Server", "Manager Station", "Station 1", "Station 2" etc. with a "Remote" and "Support" station also added automatically', and the per-station settings it enumerates are name, IP address or 'Allow IP to change', on-screen signature, fingerprint login, restricted order types and defaults - the role is fixed at creation, with no promotion, takeover or standby setting. Hardware Requirements (kb 423702) adds only a purchasing recommendation, 'All systems should have a backup server/workstations to use if primary fails', inside a minimum-spec table that never says whether the changeover is manual. Greps for failover, fail over, redundan, standby, hot spare, 'if the server' and 'becomes the server' return nothing across the 762 articles on the two hosts. Automatic role promotion is therefore undocumented rather than documented as absent.

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

commercial-month-to-month-contract differentiator

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

commercial-no-early-termination-fee differentiator

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

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

commercial-processing-not-bundled differentiator

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

commercial-interchange-plus-published differentiator

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

commercial-rate-increase-clause differentiator

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

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

commercial-module-unbundling differentiator

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

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

commercial-hardware-not-locked differentiator

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

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

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

commercial-export-customer-and-loyalty differentiator

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

commercial-post-termination-export-window differentiator

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

commercial-data-ownership-clause differentiator

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

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

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

commercial-pci-dss-4-controls

Re-checked 2026-08-08 against both published corpora, including the current-product granburysolutions.my.site.com KnowledgeBase (251 articles, with POS 8.2/8.3.x, TCC 1.1.x, Thrive Online and kiosk release-note streams running into 2026), so this is no longer scoped to a v7.7-v8.1 manual. What is documented is a version-8.0-era PCI access regime: 'In version 8.0 and higher, some settings are restricted for PCI compliance... Enter your administrative password (must be an owner level security employee)' (720465), a password policy of at least 1 number, 1 capital, no reuse of the previous 4, 90-day expiry and a 30-minute lockout after 6 failures 'required by PCI guidelines' (1852249), and 8.0 notes citing encrypted storage of login passcodes, an input-validation filter that strips card data from notes, and SSL on internal network traffic. What is absent on both hosts: 'PCI DSS 4', 'v4.0.1', 'multi-factor', 'two-factor' and 'MFA' occur zero times across all 762 articles and across the 75 pages in thrivepos.com's sitemap, and nothing addresses payment-page script integrity (Req 6.4.3 / 11.6.1) for Thrive Online or the kiosk. The only compliance statement the vendor publishes points merchants at the PCI SSC's PA-DSS payment-application listing, a retired standard that is silent on the future-dated DSS v4 requirements. The documented controls are single-factor by construction, but an operator manual - even a current one - is not a compliance statement, so it cannot settle whether the future-dated controls are in effect.

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

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

commercial-wcag-kiosk-accessibility differentiator

'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

commercial-dual-pricing-compliant differentiator

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