Vendors / Pizza & delivery-led
Microworks Prism POS
dossier live
- Claims in scope
- 311
- Scored
- 311
- Assessed
- 307
- Unknown
- 4
- Not applicable
- 3
- Values challenged
- 62
Identity
- Owner
- Microworks POS Solutions, Inc. — independently held. No parent, PE sponsor, or acquisition is disclosed on the vendor's own site, and no filing or newsroom evidence of an owner was found. It is not a listed company and no SEC filer record exists under the name. Beyond 'independent and not publicly traded', the capital structure is unknown.
- Founded
- 1989. Per the vendor FAQ: "Microworks has been providing turnkey point-of-sale solutions for major franchises and independent owners since 1989." HQ 2112 Empire Blvd, Suite 2A, Webster, NY 14580 (Rochester metro). https://www.microworks.com/home/faq.htm ; https://www.microworks.com/home/company.htm
- Scale
- Vendor-claimed: "over two thousand systems in place across the United States, Canada, and worldwide" (https://www.microworks.com/home/faq.htm) and "thousands of satisfied customers" (company page). Note 'systems' is terminals/installs, not necessarily distinct locations. ARR and market share: unknown — not disclosed anywhere. Named references on the vendor's own users page are small pizza chains and franchisees: Glass Nickel Pizza (5 locations), Sarpino's Pizza, Michael Angelo's Pizza, Renzi's Pizzeria (2 locations), and a single Little Caesars franchisee (https://www.microworks.com/home/users.htm). Third-party review presence is very thin: Software Advice/GetApp show 16 verified reviews at 4.8/5 (https://www.softwareadvice.com/retail/prism-pos-profile/); no G2 or TrustRadius product listing was reachable.
- Who it is for
- Independent pizzerias and small multi-unit pizza chains (roughly 1–10 locations), plus takeout/delivery-heavy casual restaurants — long-tenured Windows on-premise sites. The vendor's own reference customers are all in that band. Storenet enterprise management extends it to small franchise groups, but there is no evidence of enterprise-scale (100+ unit) deployments.
- Site
- https://www.microworks.com/
Lineage
- 1989 — founded: Microworks begins selling turnkey point-of-sale systems to pizza franchises and independent operators; per the vendor FAQ, "Microworks has been providing turnkey point-of-sale solutions for major franchises and independent owners since 1989."
Pricing
transparency: quote-only · unit: unknown · processor lock-in: partial
- Software
- quote-only. The vendor's quote page states: "We are experiencing technical difficulties with our online quote form, please call or email us for a quote!" and no dollar figures appear anywhere on microworks.com (https://www.microworks.com/quote.htm). The only vendor-published number is a leasing illustration in the FAQ: "the average cost of leasing a Prism POS system can be less than $8 a day" (https://www.microworks.com/home/faq.htm) — a marketing claim, not a rate card, with no term, hardware scope, or terminal count attached. Third-party listings (Software Advice / GetApp) show "starting at $5,000" for Prism POS; that is a directory-supplied figure, not vendor-published, and should not be treated as a price. No per-terminal, per-location, or per-module pricing is published.
- Card processing
- unknown — not published. Quote page directs all pricing questions to sales.
- Contract
- unknown for the POS software. The payments page references month-to-month billing being available with some service providers, which concerns the processing relationship, not the POS license. No public MSA or terms of service exists on the site, and the admin manual's only commercial topics are Support Policies and RMA Policies, neither of which states a term.
- Early termination
- unknown — no publicly accessible contract terms.
API posture
public API: none
- Cost to integrate
- unknown — no published partner program, certification path, referral fee, or revenue-share terms.
- Webhooks
- none published. The complete PrISM WebHelp table of contents (https://help.microworks.com/webhelp/whxdata/whtdata0.xml) enumerates every topic in the product across eleven books and contains no webhook, event, or callback topic. The integrations that exist — a desktop QuickBooks Interface Module, Caller ID Customer Link, third-party delivery apps, WebOrder→POS injection — are vendor-built point integrations, not a customer-accessible event stream.
- Data export on exit
- unknown as a contractual matter (no public MSA). Structurally the operator is better placed than a cloud tenant: Prism is an on-premise Windows system with a store-local database and only nightly synchronization to the hosted Storenet server (https://www.microworks.com/products/enterprise-management.htm), so the production database sits on operator-owned hardware. But there is no documented export format: the only automated export the manual describes writes PDF or HTML report files to a local folder, an email address, or a printer (https://help.microworks.com/webhelp/Scheduled_Reports.htm).
- Notes
- This remains the single most important structural fact about Microworks: it is not a platform. The full administrator manual — 488 topics across eleven books, now enumerated directly from the help system's own TOC rather than inferred from the marketing sitemap — has no developer portal, no sandbox, no OAuth, no rate limits, no app marketplace and no API changelog. The one documented outbound interface is a desktop QuickBooks file interface whose configuration chapter is titled "Configuring QuickBooks Pro 2002". Integration is a sales conversation, and the FAQ frames custom work as vendor-performed: "We are one of a handful of POS vendors that actually customize our product for your specific needs." Microworks is also absent from DoorDash's 2026 Preferred Integration Partner cohort (Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast, UrbanPiper).
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Table Setup is a real graphical layout editor: a table wizard picks "a table image that best represents your table", names tables with prefix/suffix and starting number, lays out rows/columns with spacing, and tables are then "moved by clicking on the table and dragging it", multi-selected with shift, and aligned or centred with buttons. Table Sections gives multiple named layouts per location ("Many restaurants have a dining room and a bar"). Shortfall: no per-table seat-capacity attribute is documented, section-to-server assignment is not documented on either screen, and only two stock backdrops ship (SECTIONA.JPG and BAR.JPG). https://help.microworks.com/webhelp/Table_Setup_Update.htm · retrieved 2026-08-02
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
Checked the complete order-entry and check surface: Table Setup (table wizard, drag-position, sections — no per-table seat-capacity or seat-number attribute), Splitting Checks (splits by entering "the number of checks you would like to add" or by moving individual items — no seat-based split), and Ordering Advanced Options (Sold Out Item, Reprint History, Re-Assign Orders — no seat function). No topic anywhere in the 488-topic manual assigns an order line to a seat number; the complete Ordering Module book (New Order, Creating An Order, Updating An Order, Settling An Order, Splitting Checks, Customer Last Order, Customer Information, Ordering Advanced Options, Time Clock) has no seat concept. https://help.microworks.com/webhelp/Splitting_Checks.htm · retrieved 2026-08-04
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
Advanced Kitchen Printing routes items "based on order type" and "based on level" with Primary/Secondary printer rules — the complete kitchen-routing mechanism — with no course concept. The Ordering Module book has no hold/fire or course-assignment topic, and the Makeline Monitor's complete field set (Ord#, Qty, Description, Elaps, Type, Clear, Made) has no course grouping or fire-next-course action from a handheld/terminal/expo screen. https://help.microworks.com/webhelp/Advanced_Kitchen_Printing_Tab.htm · retrieved 2026-08-04
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
Check Management is documented: "a single order may have multiple checks, either by splitting existing items into different checks or by creating a new check", Split prompts "for the number of checks you would like to add" (even N-way), and Move re-assigns individual items between checks with Undo. Shortfall: splitting by seat and by arbitrary dollar/percentage amount is not documented, no merge of two separate order numbers is documented (consolidation only moves items between checks of one order), and nothing states whether a check can be split after partial payment. https://help.microworks.com/webhelp/Splitting_Checks.htm · retrieved 2026-08-02
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
The complete card-authorization documentation describes one tender pattern only: "When a charge is made in PrISM, the amount of the sale is simply authorized... The actual transaction is not completed until the batch of validations are processed." No open-tab, incremental re-authorization, or auto-close-at-end-of-day workflow is described, and no "tab" topic exists anywhere in the 488-topic manual or the Ordering Module book. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-04
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
Ownership transfer of an open order is documented as a first-class function, and it is bulk-capable: "Re-Assign Orders - This option allows the user to change either the employee listed as being in charge of an order, or the till to which an order has been settled... Choose \"Reassign Server/Crew ID\" if you wish to change the employee listed as being in charge of the order... It is possible to modify a single order, all open orders, or all closed orders. If \"all open orders\" or \"all closed orders\" are selected, the user will be prompted for both the 'from' and 'to' tills / crew IDs". A generic gate-and-log mechanism can be attached to any function: Setup_Password_Functions.htm states "Every time a password is used, an entry is created in the Weekly Exceptions browser. If 'Log' is checked a second entry is created with additional information about the event." Shortfall: the transfer is server/till only - moving an open check between TABLES is nowhere documented (Table_Setup_Update.htm's "Moving a Table" is layout editing: "Tables may be moved by clicking on the table and dragging it to the proper position on the screen"), device transfer is not a concept in a shared-database LAN install, and no topic states that a reassignment writes an audit entry naming both the sending and receiving employee - the Weekly Exceptions entry records the password used, not a from/to pair. https://help.microworks.com/webhelp/Ordering_Advanced_Options.htm · retrieved 2026-09-04
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Windows 2-in-1 tablet running "the exact same user interface as our fixed POS station" — native, not mirrored. Tableside card payment on the handheld is not documented. https://www.microworks.com/products/Handheld-Ordering.htm · retrieved 2026-08-01
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
On-premise store database with only nightly sync to hosted Storenet implies local ordering survives an internet outage, but no offline feature matrix is published. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
334th: NEW SURFACE, THE LIVE WEBORDER 5.1 APP ACROSS ITS WHOLE TENANT ROSTER (no prior pass opened a tenant's service-type configuration or a DineIn route). Every one of the 339 *.weborder.net certificate names (crt.sh list on disk from the 322nd) was GET-fetched at / and /GetAddress?ReturnURL=~/Ordering (323 answered 200; census.json in .cache/q334/microworks-prism/a). Each GetAddress page declares the tenant's service types in an inline serviceTypes array (name + code): Pickup/WBP 283, Delivery/WBD 240, then a tail of Curbside, Catering, Drive Thru and one 'DoorDash Delivery' (DDD, bucks); 3 tenants (doubledaves, infinitus, littleitalypizza) enable 'WDI' labelled 'Dine In'/'Dine-In', and all 293 GetAddress pages carry a hidden DineInQR flag which the getaddress bundle (getaddress-5.1.817.2272) uses to skip the address step (`if($("#DineInQR").val()!="True")...`). That is the TABLE-TENT path and it creates a new web order of service type WDI, i.e. a separate ticket. THE SECOND PATH IS BOUND TO A SERVER-OPENED ORDER: https://infinitus.weborder.net/DineIn (HTTP 200, 10,792 bytes, while a nonsense path on the same host 302s to /Ordering?Error=true) renders 'Order Not Found' - 'Sorry, this we're unable to find your order. Please talk to your server. Thanks.' - with an HTML comment leaking the handler: 'System.NullReferenceException ... at Weborder.Controllers.DineInController.Index(String id) in C:devWeborder5WeborderControllersDineInController.cs:line 23'. So the dine-in QR route takes an ORDER id and looks up an order the server already opened. The vendor's own 2021-07-20 release on https://www.microworks.com/home/news-events.htm (on disk from the 330th, re-grepped per cell) names exactly these two paths: 'Restaurants can place pre-printed table tents with instructions and a QR Code, or servers can leave a printed QR Receipt with the guests at the table. Guests can easily scan, order and pay', and 'restaurants can receive in-house and take-out orders that feed directly into the Prism POS system'. VERDICT partial/C: the QR-Receipt path binds the guest's phone session to the server's existing order by id (the claim's discriminator: not a separate ticket). SHORTFALL, named: (1) the table-tent path is a separate WDI web order, not the open check; (2) nothing published says guest-added items post as lines on that check rather than the receipt QR serving payment only ('order and pay' is the vendor's phrase, not a line-level statement), so this is not a yes; a yes on this differentiator needs A/B. No real order id was probed (only the bare route). Controls: 'rwg' over the same census hit only inside random __RequestVerificationToken values (POISON), irrelevant here. Retrieved 2026-09-18. https://infinitus.weborder.net/DineIn · retrieved 2026-09-18 adversarially verified
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
First-party kiosk reusing the WebOrder menu/UI. No ADA/accessibility conformance documented. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
The vendor's complete product catalogue (WebOrder, RapidRun, Kiosk/QR Ordering, Digital Surveillance, Enterprise Management/Storenet, Notification Service, Handheld Ordering, plus core POS) contains no drive-thru product, and no drive-thru topic exists anywhere in the 488-topic administrator manual. Microworks positions itself as a pizza/delivery/takeout POS; order-point/pay-window/pickup-window flow is not part of the documented or marketed product. https://www.microworks.com/products.htm · retrieved 2026-08-04
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
Dependent on order-capture-drive-thru (no evidence): the vendor sells no drive-thru product or hardware, so there is no drive-thru order to time. No speed-of-service-by-segment topic exists anywhere in the manual. https://www.microworks.com/products.htm · retrieved 2026-08-04
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
The complete 488-topic help TOC across all eleven books, plus the full vendor product catalogue, contains no AI, voice, speech, or virtual-agent topic anywhere. The only phone-related feature documented is Caller ID Customer Link (inbound call pops the customer record) — a lookup, not order-taking. No named voice-AI partner program is published. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
The Ordering tab of Location Maintenance is the complete set of order-intake configuration: Use Customer Last Order, Maximum orders retrieved, Timed Order Check Interval, Sales Tax, Use Comeback Coupon, Use Buyer's Club, Customer Survey Invitation, Force Street Check, Currency Selection/Conversion. No capacity limit, per-slot order cap, or automatic quote-time extension field exists among them. https://help.microworks.com/webhelp/Ordering_Tab.htm · retrieved 2026-08-04
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
"Orders can be placed for immediate attention or queued for delivery or pick-up later." Per-channel lead time and computed fire-time injection not documented. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
Catering named as a supported order type alongside table-service/delivery/take-out. Quotes, deposits, balance-due, and event schedule not documented. https://www.microworks.com/products/pizza-pos.htm · retrieved 2026-08-01
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
CORRECTION OF GROUNDS, VALUE UNCHANGED. The previous rationale asserted that Makeline_Monitor_Overview.htm's Clear/Made actions are 'local state changes with no documented outbound event'. That is false and is withdrawn. Microworks' 2020-08-10 press release, at https://www.microworks.com/home/news-events.htm (re-fetched 2026-09-15, HTTP 200, 34,638 bytes, Last-Modified Thu, 23 Oct 2025 14:14:25 GMT), enumerates the Prism Notification Service's notification types, and the second reads verbatim in the served bytes: '<strong>Order Ready Notification</strong> - Manual, en route or when an order is cleared from the kitchen monitor'. Clearing an order from the kitchen monitor -- the Clear action documented at https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm (retrieved 2026-09-15, HTTP 200, 3,910 bytes, Last-Modified Sat, 29 Oct 2016 19:12:40 GMT: 'Clear - This removes the highlighted item from the item list') -- therefore DOES fire a documented outbound event. WHY THE CELL IS STILL UNKNOWN. The claim is that the order-ready signal is pushed back to third-party MARKETPLACES (e.g. DoorDash) from POS or KDS state. The sink of the event that is documented is not a marketplace: the same release describes Prism Notification Service as 'an easy way to communicate via SMS messaging between restaurants, customers, and delivery drivers', and the 2020-07-10 release on the same page enumerates its recipients as the customer and the delivery driver only. So a bump emits something, and what it emits is an SMS to a guest or driver. No source says whether any marketplace receives a readiness callback. DoorDash's partner registry reads SUPPORT_ORDER_READY_SIGNAL false for microworks, and that flag remains an unreliable negative -- it also reads false for xenial, whose own developer documentation enumerates an order-ready notification type -- so it is not scored as absence either. The registry does establish that a certified DoorDash marketplace integration exists, so the cell is not blocked on whether marketplace orders reach PriSM. It is blocked on the sink. CONTROLS. Tokenised controls over the 260-file live help library at help.microworks.com/webhelp: DoorDash, Grubhub, Deliverect, Chowly, Otter, Olo and API all 0, positive control PriSM 188/260 -- worthless as absence, the library's Last-Modified headers run 2010-2016 and predate every marketplace integration. POISON: help.microworks.com serves a soft-200 catch-all (webhelp/NONSENSE_CONTROL_XYZZY.htm returns HTTP 200, 16,758 bytes, md5 bccd8d89, Last-Modified Thu, 12 Mar 2020 14:05:24 GMT, the marketing homepage body); Makeline_Monitor_Overview.htm was discriminated against it on md5 and Last-Modified. || 328th: 328th, PER-CELL RE-GREP of the on-disk corpora (275 PrISM v7.4 help topics, the 24-page microworks.com census, the extracted report samples) located the vendor's ONLY order-ready mechanism, and it is guest-facing, not marketplace-facing. Prism Notification Service, verbatim from microworks.com/home/news-events.htm: 'Create Order Notification - general or curbside' and 'Order Ready Notification - Manual, en route or when an order is cleared from the kitchen', introduced as enhancing 'Prism POS systems with an easy way to communicate via SMS messaging'. So a KITCHEN-CLEAR EVENT DOES EXIST and it does drive an automatic ready notification - but the recipient is the guest by SMS. 'order ready' has exactly 3 hits in the whole corpus and all 3 are that one PNS paragraph (in home.html, its news page and the stripped text); no marketplace, callback, status-push or fulfilment-event wording appears anywhere. Held unknown rather than `no`: the third-party channel runs through It'sACheckmate middleware, which is not bounded by Micro Works's own corpus. Retrieved 2026-09-18. || 330th: 330th: the store-level outbound interface of the shipped product was read directly out of the unpacked v7.4 binaries for the first time (strings around 'prismweb' in streams s0538-s0546 of the Prism74Eval image): the PrismWebHandler SOAP contract exposes exactly GetWebOrderStatus, SetWebOrderingAcceptingOrders and SetWebOrderingNotAcceptingOrders against http://<server>/PrismWeb/PrismWeb.WSDL - a PULL status call plus store open/close, with no push, callback or event operation of any kind. Consistent with the SMS-only sink already on record, and still bounded to v7.4. Nothing newer exists to read: microworks.com/files/ re-listed today is unchanged since 2020-03-02 (no newer installer, manual or release note), the site is at an href fixpoint of 24 pages with a now-EMPTY sitemap.xml, the help library's own RoboHelp manifest (whproj.htm -> whxdata/whtdata0-6.xml) enumerates 207 topics of the same 2010-2016 book, and It'sACheckmate's Help Center API still returns 383 articles (unchanged since the q311 census), so no new middleware article has appeared either. Held unknown: the marketplace channel runs through Checkmate, which integrates from its own side. Retrieved 2026-09-18. || 334th: 334th: NEW SURFACE, no move. The live WebOrder 5.1 tenant census (339 names, 323 live) and the Wayback CDX of weborder.net (12,845 distinct URLs) show the app's only status surface is guest-facing: bundles AddressInfo, AutoAddressIreland, Base, CallCenter, DriverMap, Item, OrderStatus, UserInfo, UserPhone, enrollment, getaddress, googlemaps, pickstore, register; controllers Item(s), Login, GetAddress, Groups, Cart, Ordering, OrderStatus, Checkout, GroupOrders, DineIn. Marketplace vocabulary over the census HTML and current bundles: ubereats 0, grubhub 0, doordash 1 - one tenant (bucks) lists a service type 'DoorDash Delivery' (code DDD), i.e. a WebOrder fulfilment option dispatched to DoorDash, not a marketplace order returned to the POS; an adjacent feature is not a partial, and no ready-status call to it is visible client-side. The marketplace route remains Checkmate middleware, whose side is unpublished; held unknown. Retrieved 2026-09-18. adversarially verified
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
All three halves are documented. Reason codes: the Advertised Coupon "Force Explanation" option "will require the order taker to enter an explanation when using this coupon. The explanation can be viewed on the Weekly Exceptions Report." Role gating: each coupon has a "Password Required" flag, and Setup Password Functions makes every discrete system function individually password-gated by Password Group. Exception report: "Every time a password is used, an entry is created in the Weekly Exceptions browser", with an optional camera recording per function. https://help.microworks.com/webhelp/Advertised_Coupons.htm · retrieved 2026-08-02
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
The gateway is fixed and singular — "PCCharge is currently the authorization software package chosen for integration with the PrISM system", supporting "both traditional dial-up as well as broadband Internet-based authorizations". Merchant processor choice exists but is brokered: Microworks requires "information pertaining to your primary credit card processing company" and configures it through tech support. Shortfall: no supported-processor list is published, the operator cannot self-configure or switch, and PCCharge is a discontinued Verifone product, so the available choice is bounded by what an end-of-life gateway still certifies. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-02 adversarially verified
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
No rate is published anywhere; the quote page routes all pricing to phone/email. https://www.microworks.com/quote.htm · retrieved 2026-08-01
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
Same finding as menu-pricing-dual-pricing: Pricing.htm enumerates every price dimension (Count, Fraction, Size, Store Rule, Order Type, Double Count, Level) and payment tender is not among them. Advanced_Pricing_Tab.htm adds only level- and modifier-based pricing. No cash-vs-card price field, no dual-pricing or cash-discount topic exists anywhere in the 488-topic TOC, and the payments marketing page (microworks.com/products/payments.htm, re-read 2026-08-04) sells the integrated processing stack with no dual-pricing program mentioned. https://help.microworks.com/webhelp/Pricing.htm · retrieved 2026-08-04
Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator
payments-surcharge-guardrails
A surcharge/dual-pricing engine does not exist in the documented pricing model (payments-dual-pricing, no), so there is no BIN-detection debit/prepaid exclusion, network percentage cap, or per-location enable/disable to document. The complete pricing surface (Pricing.htm, Advanced_Pricing_Tab.htm) has no tender-based pricing dimension at all. https://help.microworks.com/webhelp/Pricing.htm · retrieved 2026-08-04
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Sourced to a marketing page, and that page attaches a material gate the dossier omitted: counter-top and mobile payment solutions require "running Prism V8.1 or Prism Cloud and using integrated processing platform." So tap/wallet acceptance is conditional on a current version plus PrISM Merchant Services, the vendor's own integrated processing. No terminal model, no PTS listing, no EMV certification named. Claim-level partial, not yes. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01 adversarially verified
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
NEW SURFACE AND A MOVE (326th). CLAIM: accepts contactless payments directly on a phone (Tap to Pay on iPhone / Android tap-to-pay) with NO separate card reader. VERDICT: no. POSITIVE EVIDENCE (this is not bare absence - the vendor names the hardware that performs its contactless acceptance): the 2020-08-25 release on https://microworks.com/home/news-events.htm identifies the 'integrated processing platform' that the payments page footnote defers to: 'Global Payments Integrated and Microworks have teamed up to bring you the Genius family of products. By integrating processing, payment acceptance and customer experience into a secure, cloud-based platform, Genius provides a world-class checkout experience for any business.' The MOBILE option is a device, not a phone: 'Genius Mini is a small device that accepts major payment types from anywhere. When combined with a point-of-sale system, it helps provide a secure, full-featured payment experience no matter where you do business.' The tableside option is likewise a dedicated terminal: 'Pay at the Table/curbside devices come with a large high definition color display and a thermal printer... Includes built-in NFC contactless, electronic signature capture', specified as 'Built-in NFC contactless', 'Large 5-inch capacitive color touch screen', 'PCI PTS 5.x certified', 'SRED'. So both of the vendor's published contactless paths run through a separate certified reader. BOUND: the vendor's COMPLETE public marketing corpus, re-crawled today - https://microworks.com/ plus every internal .htm in its link graph (23 pages; note www.microworks.com now 301s to the bare host) - plus a NEWLY FOUND OPEN APACHE DIRECTORY LISTING at https://microworks.com/files/ (Index of /files: 5 product PDFs, Prism74Eval.exe 38M, Satellite74.exe, Vocelli74Eval.exe, SOAP.EXE, wzpanama.zip and three subdirectories Reporting/, print/, sellsheets/ - sellsheets/ holds 6 more 2010 sell sheets), whose 5 product PDFs were downloaded and text-extracted. Corpus = 28 text files, 154,622 characters. CONTROLS (tokenised, word-boundary, case-insensitive): 'tap to phone' 0, 'tap-to-phone' 0, 'softpos' 0, 'tap to pay on iphone' 0, 'byod' 0, 'your own device' 0, 'commodity' 0. Positive controls: 'prism' 141 hits in 23 of 28 files (corpus is readable), 'contactless' 19 hits in 6 files, 'global payments' 5 hits, 'genius' 2 hits. POISON NAMED: 'tap-to-pay' returns exactly 1 hit and it is NOT this claim - products/payments.htm lists it as an accepted payment TYPE ('Accept all major payment types - Apple Pay, Google Wallet, Credit Card Tap-To-Pay, and more!'), i.e. the customer's card/phone tapping the merchant's reader, the mirror image of the claim. Second poison: the words 'reader' and 'terminal' are 0 across the whole corpus, so the Genius hardware identification rests on the press release's prose ('device', 'devices'), not on a hardware page. HONEST LIMIT: this bounds the vendor's public marketing, which is the only public description of the product (help.microworks.com's RoboHelp library is 2010-2016 vintage and serves a soft-200 catch-all), not an internal feature census; grade C accordingly. Retrieved 2026-09-18. https://microworks.com/home/news-events.htm · retrieved 2026-09-18 adversarially verified
Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.
payments-pay-at-table
Pay-at-the-door EMV on the RapidRun driver app is documented; tableside EMV on the server handheld is not — the POS page says servers "swipe credit cards into any available POS station." https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-01
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
QR "scan, order, and pay" is offered; whether it settles an existing open POS check is not documented. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.
payments-tip-adjust
The pre-auth-then-batch model and its window are documented: "When a charge is made in PrISM, the amount of the sale is simply authorized... The actual transaction is not completed until the batch of validations are processed", and "Close Day ... must be run before the End-Of-Day procedure is begun". Shortfall: no tip-adjust screen, no on-device tip prompt flow, and no manager view of unadjusted tips is documented anywhere in the help system; after the batch closes "the Transaction List will only be available for review from within the PCCharge application's history reports section". https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-02
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
The Payroll tab of Location Maintenance is fully enumerated — Level 1/2 Overtime Rate, Labor Percentage Goal, pay-rate display toggles, daily/weekly/period OT hour thresholds — and contains no tip pooling, tip-out, or distribution field. No tip-pool topic exists anywhere else in the 488-topic manual; the only tip-related report is a per-server Server Tip listing (labor-tip-distribution-audit-trail), not a pooling/allocation engine. https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-08-04
Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator
payments-offline-store-and-forward
CLAIM: card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. Weight is differentiator. WHAT IS MET: the first conjunct is asserted by Microworks in its own voice, once. Its News & Events page (https://microworks.com/home/news-events.htm, re-fetched 200 by me on 2026-09-15; www redirects 301 to the apex; page footer 'Copyright (c) 2025') carries the 10 August 2020 Rochester NY release 'New and Enhanced Features', whose 'Pay at the Door' section says 'Global Payments Integrated and Microworks have teamed up to bring you the Genius family of products. By integrating processing, payment acceptance and customer experience into a secure, cloud-based platform, Genius provides a world-class checkout experience for any business.' and lists among the merchant's ongoing benefits: 'Line-item display, PIN steering, store & forward, cash back and more.' I checked the RAW bytes rather than a tag-stripped rendering: the phrase is literally 'store & forward' inside one <li>, so it is a real contiguous phrase and not a quote welded across tags. SHORTFALLS. (1) The second conjunct is wholly unpublished: tokenised word-boundary controls return 'floor limit' 0, 'offline limit' 0 and 'stand-in' 0 over every corpus below, so the configurable per-transaction and cumulative caps the claim requires - the 'unbounded exposure to declines' its why_it_matters warns about - are nowhere stated. (2) It is a property of the resold Global Payments Integrated Genius terminal family, not of PriSM's own card path, and the whole integrated-processing programme is gated: 'Whether you need a counter-top or mobile solution, Microworks has you covered*' / '*Must be running Prism V8.1 or Prism Cloud and using integrated processing platform' / '**Available with some service providers' (https://microworks.com/products/payments.htm, 200 on 2026-09-15), so it is not a property of the installed base. (3) It is six words in a benefit list: no mechanism, no ceiling, no reconnect behaviour, and the words 'internet', 'outage' and 'offline' never appear near it. (4) The live payments page itself does not carry the phrase at all - 'store & forward' occurs exactly once across the whole live site, in the 2020 news item. (5) PriSM's own documentation contradicts nothing but documents nothing either: the library's card chapter Authorizer_Overview.htm (live at https://help.microworks.com/webhelp/Authorizer_Overview.htm, and archived at https://web.archive.org/web/20130317011216/http://www.microworks.com/webhelp/Authorizer_Overview.htm, capture 2013-03-17) describes only the optional PCCharge add-on, 'both traditional dial-up as well as broadband Internet-based authorizations', and an authorise-now / settle-at-batch model - 'When a charge is made in PrISM, the amount of the sale is simply authorized ... The actual transaction is not completed until the batch of validations are processed' - and is silent on what happens when the link is down. Grade D: the only affirmative source is a press release. A differentiator-weight yes requires grade A or B, so yes is unavailable on this evidence in any case. BOUND CORPUS, all re-derived by me on 2026-09-15, never inherited: (a) the live marketing site as its LINK GRAPH, 26 distinct HTML pages reached by crawling https://microworks.com/ (www.microworks.com 301s to the apex; a fabricated path such as https://microworks.com/status.htm or /zzq-fabricated-9f/nothing.htm returns a real 404 of 355 bytes, so the apex is not a catch-all and a zero over it is bindable); (b) sitemap.xml, 58 <loc> rows, which is a STRICT SUBSET of the site - it omits products/payments.htm, home/news-events.htm, products/rapidrun.htm and products/kiosk-qr-ordering.htm, every page carrying the payments evidence, and 40 of its 58 rows are sample-report PDFs and a case study; absences are therefore bound to the link graph, never to the sitemap; (c) the PriSM WebHelp library, which is LIVE at help.microworks.com/webhelp/<Topic>.htm - its bindable manifest is the publisher's own table of contents (whgdata/whlstt0..120.htm, 427 rows resolving to 205 distinct topics), and the 258-file local crawl covers all 205 TOC topics plus 53 further topics found by link-following; (d) the same library as archived, 645 Wayback captures, 2006-2013; (e) the vendor's PDF information sheet https://microworks.com/files/PrISM_Overview.pdf (200, 323,426 bytes, text-extracted). LIBRARY VINTAGE: it is the vendor's CURRENT published documentation but authored 2009-2010 (Last-Modified 2010-01-19 on Purge_Customers.htm, 2016-10-29 on Credit_Card.htm), so it bounds what Microworks DOCUMENTS, not what the product does today. CONTROLS, tokenised with word boundaries, run over all of (a)-(e) with the positive control 'PriSM' passing on every run (132 hits on the live link graph, 300 across the 258-file live library, 1,351 across the 645 archived captures): 'store and forward' 0 / 0 / 0; 'store & forward' 1 / 0 / 0; 'floor limit' 0; 'stand-in' 0; 'decline' 0; 'declined' 0; 'approval code' 0; 'authorization code' 0; 'manual entry' 0; 'voice' 0; 'off-line' 0. POISON found and published: 'offline' returns 2 hits on the live site and both are PrivacyPolicy.htm boilerplate about handling information 'online and offline', and 1 hit in the library which is Trouble_Shooting.htm telling the operator that Windows must not have a check mark next to 'USE PRINTER OFFLINE' - a printer property, nothing to do with card capture. 'outage' returns 0 on the live site and its only library hits are power outages and a UPS in Random_Thoughts.htm and System_Statup_Procedures.htm. A further trap I cleared: on https://microworks.com/products/payments.htm the entire 'Genius Mini / Genius Handheld / Genius Countertop' product section is inside an HTML COMMENT (source bytes 11,466-14,334) and is therefore not published; only an image filename 'Genius-all-whitebackground.png' is visible there. Anyone quoting that copy from the payments page would be quoting unpublished markup - comments must be stripped BEFORE tags. CORPUS HOLE CLOSED: an earlier pass declared Advanced_Features.htm an uncapturable hole; it is live and was read (see hardware-handheld-lte) and it bears on the handheld cell, not this one. https://microworks.com/home/news-events.htm · retrieved 2026-09-15 adversarially verified
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
The claim asks whether the vendor publicly documents who bears the loss on an offline decline. It does not. The manual's complete card-authorization documentation (Authorizer_Overview.htm) describes an authorize-at-order, settle-at-batch model through the integrated authorizer and contains no store-and-forward or offline-capture concept at all — hence no decline-on-reconnect liability statement and no post-reconnect failed-offline-payments report. No other topic in the complete help TOC (whtdata0-6.xml) covers offline payments, and the payments marketing page (microworks.com/products/payments.htm, re-read 2026-08-04) is silent on offline behaviour and liability. The documentation the claim requires does not exist in the vendor's public corpus. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-04
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
Native prepaid accounts are documented, not just a marketing bullet: "Gift Certificate accounts are very similar in function to Customer Accounts with the exception that these accounts are pre-paid", with a Gift Number, a Transaction History tab showing "payments, credits, and balance", Credit Account, Print Statement, and an Open Gift Activity Report in the reports tree; "under normal circumstances, gift certificates should be created and modified during the order taking process". Shortfall: balances live in the store-local database with only nightly StoreNet upload, so no cross-location balance sharing is documented; redemption through the WebOrder channel is not documented; and integrated plastic gift cards run through third-party authorisation set up on the CC/Gift/Check tab, which the manual says only Microworks Tech Support may touch. https://help.microworks.com/webhelp/Gift_Certificates.htm · retrieved 2026-08-02
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
Documented: "Customer Accounts can be created, at your discretion, allowing customers to purchase merchandise on account", linked to a customer record by phone, with a Transaction History section detailing "payments, credits, and balance", Add Payment, Credit Account, Print Selected Invoice, Print All Invoices and Print Statement; Account Terms exist "to separate accounts into different billing cycles". Shortfall: no per-account credit limit field is documented, and Account Terms are explicitly "free-form text fields; you may enter any name you wish" rather than enforced terms. https://help.microworks.com/webhelp/Customer_Accounts.htm · retrieved 2026-08-02
A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.
payments-split-tender
"Prism POS allows multiple tenders and tips to be used on a single check" and "Split checks are settled independently of each other allowing single or multiple credit cards to be used for each check." No cap is stated. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
Exception reporting and POS-overlay video surveillance with a searchable System Event Log exist; role-based authorization and an immutable approver-identified audit log are not documented. https://www.microworks.com/products/Digital-Surveillance.htm · retrieved 2026-08-01
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
The gateway's documented surface ends at settlement: "the Transaction List will only be available for review from within the PCCharge application's history reports section" once the batch closes. No dispute, chargeback, or evidence-assembly topic exists anywhere in the manual; disputes would be handled entirely inside the third-party PCCharge/processor tooling, outside PrISM. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-04
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
Tokenization is documented and WebOrder gives customers "a secure way to manage their orders while you maintain a single shared credit card batch." Cross-channel reuse of the token in-store is not documented. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
CLAIM: vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. The first conjunct is a claim about PUBLICATION, which is directly observable and bindable to the publisher's own manifest, so a no here is positive evidence of non-publication and not an inference from silence about a feature. FINDING: Microworks publishes no deposit schedule, no settlement timing and no funding-speed option on any surface it controls. Its dedicated payments page, https://microworks.com/products/payments.htm (200 on 2026-09-15), is the whole of what it says about money movement: 'PrISM Merchant Services / Tightly Integrated Point of Sale Payment Options ... Integrating processing into a world-class checkout experience for any business. Incorporating tokenization and point-to-point encryption helps ensure your systems are secure.' Its closed five-bullet enumeration of what the merchant gets is 'Simple - One solution for your stores online and card present transactions', 'Accept all major payment types - Apple Pay, Google Wallet, Credit Card Tap-To-Pay, and more!', 'Enhance data security - Keep cardholder data off the POS ...', 'Update effortlessly - Automatic cloud updates help ensure you have the latest features and functionality with no downtime!', 'Month-to-month - Month to month contracts keep pricing competitive & clear**', under the footnotes '*Must be running Prism V8.1 or Prism Cloud and using integrated processing platform' and '**Available with some service providers'. Deposit timing, settlement timing, funding and payout appear nowhere in that enumeration. The '**Available with some service providers' footnote, together with the Global Payments Integrated partnership named in the 10 August 2020 release on https://microworks.com/home/news-events.htm, establishes that acquiring is brokered per-merchant through third-party providers, so there is no vendor-wide schedule that Microworks could publish. BOUND CORPUS, all re-derived by me on 2026-09-15, never inherited: (a) the live marketing site as its LINK GRAPH, 26 distinct HTML pages reached by crawling https://microworks.com/ (www.microworks.com 301s to the apex; a fabricated path such as https://microworks.com/status.htm or /zzq-fabricated-9f/nothing.htm returns a real 404 of 355 bytes, so the apex is not a catch-all and a zero over it is bindable); (b) sitemap.xml, 58 <loc> rows, which is a STRICT SUBSET of the site - it omits products/payments.htm, home/news-events.htm, products/rapidrun.htm and products/kiosk-qr-ordering.htm, every page carrying the payments evidence, and 40 of its 58 rows are sample-report PDFs and a case study; absences are therefore bound to the link graph, never to the sitemap; (c) the PriSM WebHelp library, which is LIVE at help.microworks.com/webhelp/<Topic>.htm - its bindable manifest is the publisher's own table of contents (whgdata/whlstt0..120.htm, 427 rows resolving to 205 distinct topics), and the 258-file local crawl covers all 205 TOC topics plus 53 further topics found by link-following; (d) the same library as archived, 645 Wayback captures, 2006-2013; (e) the vendor's PDF information sheet https://microworks.com/files/PrISM_Overview.pdf (200, 323,426 bytes, text-extracted). LIBRARY VINTAGE: it is the vendor's CURRENT published documentation but authored 2009-2010 (Last-Modified 2010-01-19 on Purge_Customers.htm, 2016-10-29 on Credit_Card.htm), so it bounds what Microworks DOCUMENTS, not what the product does today. CONTROLS, tokenised, positive control 'PriSM' passing on every corpus (live link graph 132, live 258-file library 300, 645 archived captures 1,351, PrISM_Overview.pdf 8): 'funding' 0 / 0 / 0 / 0; 'funded' 0; 'payout' 0 / 0 / 0 / 0; 'acquirer' 0; 'ACH' 0; 'bank account' 0; 'same day' 0 and 'same-day' 0 everywhere; 'next-day' 0; 'merchant' 0 in the library and 1 on the live site ('PrISM Merchant Services', a product name). POISON, all of it published rather than counted as hits: 'settlement' is 1 on the live site and it is the name of a cash-control report on products/reporting.htm ('Driver / Server Cash Drop | Driver Detail | Server Tip | Settlement Report'), and 17 in the live library where Settlement.htm is the Settlement TAB of an Order Type - till settlement, not bank funding; 'deposit' is 0 on the live site and 16 in the live library, every one of them the operator's own cash bank deposit or a bottle deposit - End_Of_Day.htm 'Entering a deposit tells the PrISM system that you physically have that amount of tender to deposit into the bank', Daily_Paperwork_Screen.htm 'This is assumed to be your "bank deposit" for the day', Menu_Items.htm where a deposit 'is deducted from the listed price of the item and is non-taxable', and System_Accounts.htm where Deposit is one of four system-account TYPES ('Cash Paid Out, Money Received, Deposit, and Other'); 'next day' is 3 hits and all are a clock-in past midnight in Employee_List.htm or an advance-order lead time; 'business day' is 9 hits and every one is End-Of-Day or PCCharge batch close. This is a no on the taxonomy's publication predicate only. It does NOT assert that a Microworks merchant is never funded next-day by their own acquirer - only that Microworks publishes no schedule and offers no funding-speed option of its own. Grade C: the bound source is a first-party feature page written to sell. https://microworks.com/products/payments.htm · retrieved 2026-09-15 adversarially verified
A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator
payments-multi-entity-routing
Settlement is per store by construction rather than by a routing feature. Each install carries its own processing relationship - setup "will require information pertaining to your primary credit card processing company" - the credentials live on a Location Maintenance tab (CC_Gift_Check_Tab_LM.htm: "The information in this section is used for the authorization and verification of integrated Credit Cards, Gift Cards, and Checks"), and each store closes its own batch independently: "Close Day - Choose this option to settle the charge batch for the day. This option must be run before the End-Of-Day procedure is begun." Shortfall: there is no single account routing to several bank accounts and no split-settlement or MID-selection configuration anywhere; funds land per store because each store IS a separate merchant account, the tab that holds them is reserved to the vendor ("Modifying any settings in this area can result in system failure. Contact Microworks Tech Support"), and the multi-store layer (StoreNet, "allows users to maintain 'master' menus and inventory sets for a franchise") is menu/inventory distribution plus a nightly dataset upload, not unified settlement reporting. Same shape the corpus scores partial for SpeedLine ("Card processing credentials live in each store's own database"). https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-09-04
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
"Tokenization and point-to-point encryption" and "keep cardholder data off the POS" are claimed. No PCI DSS 4.x AoC, no P2PE listing, and no SAQ type are published. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
Advanced Kitchen Printing routes per item to multiple destinations: "the ability to print items to multiple kitchen printers at once, the ability to print items differently based on order type, and the ability to print items differently based on level", with a Primary/Secondary rule so a pizza prints at the wing station only when wings are on the same order. Two shortfalls against the claim: the routing targets are kitchen printers, not KDS stations (the Makeline Monitor is configured location-wide on a single Makeline tab, with no per-station routing), and it is not operator-configurable without vendor involvement — "For most new systems, Advanced Kitchen Printing is disabled by default... it must be enabled by Microworks Tech Support." https://help.microworks.com/webhelp/Advanced_Kitchen_Printing_Tab.htm · retrieved 2026-08-02
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
The Makeline Monitor is the product's only kitchen display, and its overview enumerates the entire screen and every control: a flat list of items to make (Ord#, Qty, Description, Elaps, Type) with per-item Clear, an order-type Filter, a Select mode for clearing several items at once, Font, Made (view previously made items), and list navigation. There is no expo or consolidation view, no prep-station concept on the display, and no order-level completion state — items are cleared individually and nothing tracks whether every contributing station has bumped its items. The makeline book in the complete help TOC contains only this screen plus the Makeline tab of Location Maintenance (Makeline_Tab.htm: a refresh interval and an aging timer). https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-04
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
Kitchen routing is fully documented as printer/level/order-type based ("print items to multiple kitchen printers at once... print items differently based on order type... based on level"), with no course concept. Makeline_Monitor_Overview.htm's complete field set (Ord#, Qty, Description, Elaps, Type, Clear, Made) has no course grouping, hold state, or fire-on-demand action from a handheld/terminal/expo screen. https://help.microworks.com/webhelp/Advanced_Kitchen_Printing_Tab.htm · retrieved 2026-08-04
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
The Makeline tab's complete configuration is a Makeline Timer (flags an item "old" after an elapsed threshold) and a Makeline Refresh interval — both location-wide constants, not per-item cook times. Makeline_Monitor_Overview.htm shows a flat, un-staggered item list with a single Elaps column; no per-item configurable cook time and no staggered start/display logic to synchronize finish times is documented anywhere. https://help.microworks.com/webhelp/Makeline_Tab.htm · retrieved 2026-08-04
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
The Ordering tab of Location Maintenance is the complete order-intake configuration (Timed Order Check Interval, Sales Tax, coupons, Survey, Force Street Check, Currency) and contains no load-based throttling or quote-time extension. Makeline_Tab.htm's only thresholds are a display aging timer and refresh interval, not an order-release pacing rule. https://help.microworks.com/webhelp/Ordering_Tab.htm · retrieved 2026-08-04
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: /, barring only /cdn-cgi/ and /monitoring). The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page at https://merchants.doordash.com/en-us/integrations. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general, so grade B is the ceiling here and it can never be A. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. VERIFICATION PASS 2026-09-12: all three sources were re-fetched independently of the frozen cache. The registry is byte-identical (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers, tiers tallying 12/47/5 and exactly 23 distinct flag names), and every quoted span below was re-checked as verbatim-present and contiguous in the file it is attributed to. PRIOR READING CORRECTED, AND THE CORRECTION IS UPHELD ON VERIFICATION: this cell was last left unknown on the ground that the kitchen docs ‘document no propagation of a channel pause to kitchen output’ and that ‘the registry carries no flag bearing on kitchen-side propagation’. That reads the claim backwards. The taxonomy text runs FROM the POS/KDS OUT to the marketplaces — ‘Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces’ — and its why_it_matters is about pausing three marketplace tablets, not about kitchen output. On the correct reading the registry does bear on it: `STORE_AVAILABILITY_WEBHOOKS`, labelled ‘Integrated close/pause store’, is TRUE for `microworks`, inside FEATURE_COLLECTION_NAME_LIVE_ORDER_MANAGEMENT, which carries `active: true` for this provider — unlike its FEATURE_COLLECTION_NAME_ENABLING_DDOO, which carries `active: false` and whose members are therefore not-applicable rather than absent. TWO NAMED SHORTFALLS. First, only the pause disjunct is attested: `ITEM_LEVEL_86` reads false for this provider, so the item-availability disjunct is not established — and that false is not converted into a negative here, it simply carries nothing. Second, the claim names DoorDash, Uber Eats and Grubhub, and this instrument attests DoorDash only. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12 adversarially verified
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
CORRECTION OF GROUNDS, VALUE UNCHANGED. The previous rationale asserted that 'Makeline_Monitor_Overview.htm documents Clear/Made as local state changes only'. That is false and is withdrawn. Microworks' 2020-08-10 press release at https://www.microworks.com/home/news-events.htm (re-fetched 2026-09-15, HTTP 200, 34,638 bytes, Last-Modified Thu, 23 Oct 2025 14:14:25 GMT) enumerates the Prism Notification Service's types and the second reads verbatim in the served bytes: '<strong>Order Ready Notification</strong> - Manual, en route or when an order is cleared from the kitchen monitor'. The KDS bump IS a documented trigger for an outbound event: the Clear action at https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm (retrieved 2026-09-15, HTTP 200, 3,910 bytes, Last-Modified Sat, 29 Oct 2016 19:12:40 GMT) is described as 'This removes the highlighted item from the item list', and clearing from the kitchen monitor is named by the release as one of the three ways an Order Ready Notification fires. WHY THE CELL IS STILL UNKNOWN. The claim is that bumping an order ready on the KDS sends an order-ready STATUS EVENT BACK TO THE THIRD-PARTY MARKETPLACE so couriers are dispatched on actual readiness. The documented recipient is not a marketplace. The same release calls Prism Notification Service 'an easy way to communicate via SMS messaging between restaurants, customers, and delivery drivers', and the 2020-07-10 release on the same page enumerates its sends to the customer and to the RapidRun delivery driver -- the restaurant's own driver, not a marketplace courier platform. So the trigger is established and the sink is SMS; nothing establishes or denies a marketplace callback. DoorDash's partner registry reads SUPPORT_ORDER_READY_SIGNAL false for microworks; that flag is not a reliable negative -- it reads false for xenial too, whose developer docs enumerate an order-ready notification type -- and stacking a second inference on it, that a false flag also forecloses the bump as a trigger, is now doubly wrong, since the bump demonstrably IS a trigger for the SMS path. The registry does establish that the marketplace integration exists. Undetermined on the sink. CONTROLS. Tokenised controls over the 260-file live help library: DoorDash, Grubhub, Deliverect, Chowly, Otter, Olo, API all 0; positive control PriSM 188/260. Those zeros are worthless as absence -- the library's Last-Modified headers run 2010-2016. POISON: help.microworks.com serves a soft-200 catch-all (nonsense path returns HTTP 200, 16,758 bytes, md5 bccd8d89, Last-Modified Thu, 12 Mar 2020 14:05:24 GMT); the Makeline topic was discriminated against it on md5 and Last-Modified, not on size. || 327th: THE SINK QUESTION WAS PUT TO THE SHIPPED BINARIES (327th), NO MOVE, BUT THE EVIDENCE NOW POINTS ONE WAY. The whole PriSM 7.4 install image was unpacked without executing it (Wise SFX, 554 deflate streams, 112.3 MB, complete). Every http/https string literal in all 554 streams was extracted: the shipped product's entire outbound surface is IPCharge (card processing), posapi.loyaltypath.com/LoyaltyPath.asmx (gift/loyalty), and the vendor's own WebOrder SOAP service (http://localhost/PrismWeb/PrismWeb.WSDL, http://wsat.microworks.com/). There is NO marketplace or courier endpoint in the build, and tokenised controls over the 2,036 distinct .dbf field names return `DOORDASH` 0, `UBER` 0, `GRUB` 0, `CHANNEL` 0, `PARTNER` 0, `READY` 0. The Makeline binary (vmake.exe, 4.6 MB, 932 'makeline' string hits) carries no HTTP client literal at all. So in 7.4 the Clear/bump action has no network sink other than the vendor's own WebOrder service. STILL UNKNOWN, and deliberately so: 7.4 predates the current V8/Prism Cloud line and predates the Prism Notification Service (announced 2020-08-10), and DoorDash's registry lists microworks as a certified POS-type partner, so a 2020 desktop build cannot bound the current product's callback behaviour. Retrieved 2026-09-18. || 330th: 330th: same new reading as order-capture-order-ready-signal - the v7.4 PrismWebHandler SOAP surface recovered from the unpacked binaries is GetWebOrderStatus / SetWebOrderingAcceptingOrders / SetWebOrderingNotAcceptingOrders only, i.e. the bump has no push operation to call even in the vendor's own web service, and the Makeline binary carries no HTTP client. Bounded to v7.4, so no verdict. No newer corpus exists: /files/ unchanged since 2020-03-02, site at a 24-page href fixpoint, help library manifest (whxdata/whtdata0-6.xml, 207 topics) is the same 2010-2016 book, Checkmate's Help Center API still 383 articles. Retrieved 2026-09-18. adversarially verified
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Directly documented: "An optional add-on component to the PrISM for Windows system is the Makeline bump bar. Bump bars are built to withstand the demanding requirements of the kitchen environment" — with standard keyboards or touchscreen monitors replaced by the bump bar for "faster manipulation of makeline items." Note it is an optional paid add-on, not base. https://help.microworks.com/webhelp/Advanced_Features.htm · retrieved 2026-08-01 adversarially verified
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Partial aggregation exists: "Marking an inventory item as a Key Ingredient will allow it to be tracked on a Makeline Monitor", with a Key Ing. Code "displayed on the Makeline Monitor next to the Count of the Key Ingredient". Shortfall: the aggregate is per key ingredient, not an all-day view of outstanding quantities per menu item and per modifier, and the manual states the feature "must be configured by Microworks Tech Support" rather than by the operator. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-02
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
The Makeline tab exposes "Makeline Timer — This is the amount of time that may pass before an item on the Makeline Monitor is flagged as being 'old'", alongside a Makeline Refresh interval; the monitor itself shows an "Elaps" column, "the amount of time that has elapsed since the order was placed". Shortfall: one location-level timer, not configurable target cook times per station or per order type, and the manual describes only an "old" flag — no colour escalation ladder and no audible alert are documented. https://help.microworks.com/webhelp/Makeline_Tab.htm · retrieved 2026-08-02
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Printer_Setup.htm documents a per-device Backup Device field: "Choose another device to act as a backup in case PrISM cannot print to this device" — failover to a designated backup printer is a configured, documented behaviour, not an operator workaround. Named shortfall: the docs state no no-ticket-loss guarantee for the failover, describe no staff alert when it engages, and document nothing for a failed Makeline Monitor screen — the Backup Device field is framed entirely around printing ("cannot print to this device"), so KDS-screen failover is unevidenced. https://help.microworks.com/webhelp/Printer_Setup.htm · retrieved 2026-08-04
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
The makeline is a station on the store's own database, not a cloud client. System_Overview.htm: "Station Status contains the status of every computer in the PrISM system and the ability to disconnect them from the PrISM databases"; "Shutdown All Stations... will attempt to close the Ordering Module and any Makeline Modules that are open on the system"; and the data itself is local - "PrISM system data is stored in many specific database tables. Each table has at least one index file", reindexed from the Manager's station with "all other computers... on their main menus". Makeline_Tab.htm confirms the display polls that local store: "Makeline Refresh (Secs) - This is simply the amount of seconds that will pass before the information on the Makeline Monitor is refreshed." The only internet dependency documented anywhere in the product is optional card authorization (Authorizer_Overview.htm) and the nightly StoreNet dataset upload. Shortfall: this is architecture, not a vendor statement - no topic in the closed 269-topic manual census describes makeline behavior during an internet or WAN outage, there is no offline feature matrix, and there is no cloud KDS to degrade in the documented on-premise version. Scored to match this record's sibling structural-inference cells (reliability-offline-order-entry, reliability-offline-kds-printing, both partial). https://help.microworks.com/webhelp/System_Overview.htm · retrieved 2026-09-04
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
The Makeline Monitor's complete field set — Ord#, Qty, Description, Elaps, Type, plus Clear/Select/Made/Font/Filter controls — is fully enumerated. Description is a single text line; there is no dedicated recipe-step, portioning-diagram, or full modifier-breakout view. No item-build or assembly-detail screen is documented anywhere in the manual. https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-04
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
The complete makeline screen (Ord#, Qty, Description, Elaps, Type) has no dedicated visual rendering for half/quarter topping placement — Description is plain text. Fractional pricing is a pricing-engine attribute (Pricing.htm's Fraction field), and nothing documents it carrying through to a graphic or unambiguous half-and-half rendering on the makeline or ticket. https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-04
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
The Makeline Monitor has a "Made" button — "This allows you to view previously made items" — after Clear removes an item from the list. Shortfall: viewing is all that is documented; there is no un-bump/restore action returning a cleared item to the active list, and no per-item refire or reprint from the makeline. Recall of a settled order is a separate Ordering Module function. https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-02
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
The makeline's documented controls are Clear, Select (multi-clear), Made (view cleared items), Font and Filter — there is no flag, highlight, or notification state for an item added, changed, or removed after the ticket first displayed. No modification-alert topic exists anywhere in the manual. https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-04
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
Prism Notification Service sends SMS "when the order is ready for pickup" and on out-for-delivery/arrival. It is listed as a distinct product, so whether it is bundled or separately priced is unknown. https://www.microworks.com/products/pizza-pos.htm · retrieved 2026-08-01
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
The two topics that constitute the complete physical-inventory documentation — Daily_Inventory_Screen.htm (beginning/delivery/ending/ideal/variance) and Inventory_Master_u.htm (item, cost, reorder, key-ingredient fields) — contain no waste, spoilage, or remake logging workflow and no reason-code field. Variance from Ideal is a single aggregate number (the "Food Gap" on the Weekly Sales Recap), not an itemized, reason-coded waste entry, and there is no KDS-side logging screen documented. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-04
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
Per-order Elaps (elapsed time since order placed) is a live field on the Makeline Monitor, and Server_Report.htm provides a per-server daily activity summary, but neither is a ticket/station-time report sliced by daypart and channel with average/percentile figures. The complete reporting surface (Scheduled_Reports.htm export types are PDF/HTML, no CSV/API) has no dedicated speed-of-service report by that name; reporting-server-scorecards (existing cell) already established the manual has no cross-server or trend reporting. https://help.microworks.com/webhelp/Server_Report.htm · retrieved 2026-08-04
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
Forecast Indicators — the only forecast mechanism documented anywhere in the 488-topic manual — computes a labour headcount ratio ("how many employees... need to be scheduled based on the average volume forecast") from operator-defined Numerator/Denominator volume measures, for the Employee Scheduling Module. It is not a per-item prep-quantity prediction and is not surfaced to kitchen staff as a prep list; no separate prep-forecasting topic exists. https://help.microworks.com/webhelp/Forecast_Indicators.htm · retrieved 2026-08-04
Delivery, dispatch & third-party channels
Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).
delivery-driver-roster
Verbatim: the module "displays a list of all employees that are currently clocked in as a Driver job classification and allows simple touch screen access for order assignment." Driver is a first-class job class in the manual — Driver_Tab.htm carries Driver Reimbursement by (Per Mile, Per Order, Percent of Total Sales, Percent of Pre-Tax Sales, Sector/Streets Reimbursement, Manual), Personal Bank, Default Company Car, Check Ins. Exp. Date and Force Odometer Miles — so the roster is driven by clock-in state against a real role. Grade corrected B to C: the roster screen itself is described only on the marketing page. https://www.microworks.com/products/delivery-pos.htm · retrieved 2026-08-02 adversarially verified
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
Native in-house dispatch, confirmed on two sources. The manual establishes the module — "The Assign Orders function launches the Driver Routing module. Within this module, orders may be routed, or assigned, to drivers for delivery" — and the delivery product page supplies the board behaviour verbatim: "Orders are listed in an easy-to-read, oldest order first format with sectors displayed for creating smarter multi-order runs." Routing_Tab.htm adds the lateness policing (Mark Lates Automatic, Auto Late Minutes, flashing warn). Not a DaaS handoff. https://help.microworks.com/webhelp/Assign_Orders.htm · retrieved 2026-08-02 adversarially verified
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
Live map with driver position and "turn-by-turn mapping directions to each location in the run." Automatic stop-order optimization is not explicitly claimed. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-01
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
The vendor claims it — "The store can view driver's location from route screen" and "Turn-by-turn mapping directions to each location in the run" — but RapidRun appears nowhere in the 488-topic PrISM administrator manual: no RapidRun book, no GPS or tracking topic, and Driver_Tab.htm covers only reimbursement method, personal bank, company car and forced odometer entry. Shortfall: live driver position is a marketing claim for an undocumented companion mobile app, with no documented refresh interval, geofence or breadcrumb history, and the page's "No additional Licensing is necessary" applies only to the store-side viewer, implying the driver app is separately licensed. Grade corrected B to C. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-02 adversarially verified
Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator
delivery-zones-polygon
Positive evidence of the alternative design. Delivery areas are Sectors built from street lists: "you may create a sector called 'A1' where the delivery charge is $1.00 and the driver reimbursement is $0.50. Then, simply attach this sector to all applicable streets within that area", and "Sectors are used system-wide; one defined sector may be applied to multiple streets." Mapping is a MapPoint store-address lookup on the Routing tab. No polygon drawing tool and no drive-time isochrone appears anywhere in the help system. https://help.microworks.com/webhelp/Update_Sectors.htm · retrieved 2026-08-02
Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.
delivery-zone-pricing
Fees are genuinely per zone and automatic: Location Maintenance carries a Default Delivery Charge plus a "Per Sector Delivery Charge" switch — "If you are using per sector delivery charges or street-specific delivery charges, this option must be enabled" — and Variable Delivery Charges band the fee by order total ("Orders totaling between $0.00 and $4.99 could have a delivery charge of $1.50, while orders of $5.00 or more could be free"), with the sector attached to the customer's street. Shortfall: the quoted promise time is a single location-level "Estimated Delivery Minutes" constant on the Routing tab, not per zone, and no per-zone order minimum is documented. https://help.microworks.com/webhelp/Delivery_Charges_Tab.htm · retrieved 2026-08-02
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Addresses resolve against operator-maintained Update Streets / Update City / Update Carrier Routes tables, which is what attaches the sector, delivery charge and driver reimbursement to an order. Mapping depends on MapPoint: "If the store address configured on the General Tab is unable to be located in Map Point, an alternate store address can be entered here. If the store can not be located in Map Point, the mapping functionality will not work properly." Shortfall: validation is against the operator's own street table, not a third-party address-verification or geocoding service, and MapPoint is a Microsoft product retired in 2014 — the manual names no successor. https://help.microworks.com/webhelp/Routing_Tab.htm · retrieved 2026-08-02
Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator
delivery-driver-comp
Driver Detail and Cash Drop reports track per-driver runs and cash. Mileage capture and separate reimbursement-vs-wage payroll export lines are not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.
delivery-cash-reconcile
Re-sourced from report names to the mechanism. A cash drop lets you "take any amount of money from the employee, place it in a secure location, and reflect that action as a credit to the employee's cash responsibilities"; the drop is recorded against the employee in the Employee List, and "till totals will reflect receiving cash drops when balancing the till." A per-driver cash-responsibility ledger reconciled against the till, corroborated by Till_List.htm and Driver_Report.htm in the same book. https://help.microworks.com/webhelp/Cash_Drop.htm · retrieved 2026-08-02 adversarially verified
Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.
delivery-daas-dispatch
Every delivery-dispatch topic and page checked (Assign_Orders.htm, Routing_Tab.htm, Delivery_Charges_Tab.htm, Driver_Tab.htm, rapidrun.htm) describes exclusively an in-house driver fleet — clocked-in Driver job class, RapidRun turn-by-turn routing and live position, Sector-based reimbursement. No DoorDash Drive, Uber Direct, Nash, Relay, or generic on-demand-courier hand-off is named anywhere in the manual or on the vendor site. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-04
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
Dependent on delivery-daas-dispatch (no evidence): since no on-demand courier marketplace integration exists at all, there is no overflow/hybrid dispatch rule to document. Routing_Tab.htm's only automation is Mark Lates Automatic / Auto Late Minutes, which flags a late in-house delivery — it does not reassign the order to an outside courier. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-04
Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator
delivery-3p-direct-integration
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. The prior unknown rested on the finding that the 488-topic help TOC contains no marketplace topic and that Microworks was absent from the 2026 Preferred cohort announcement. The registry settles existence: `microworks` is present, CERTIFIED, and classed PROVIDER_AGGREGATION_TYPE_POS rather than MIDDLEWARE_AGGREGATOR, the type it gives Deliverect and Otter. `partial` because the claim requires DoorDash AND Uber Eats AND Grubhub and only DoorDash is attested. Note the type field records how DoorDash CLASSES the provider, not who wrote the connector. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Microworks is a CERTIFIED DoorDash integration of type POS, and DoorDash holds its programme members to a merchant-avoidable cancellation rate measured on orders after they reach the POS, which presupposes orders landing in it over a certified API rather than a re-keyed tablet. No flag in the registry bears on the accept step, so the claim's requirement that orders fire to KDS/printers as normal tickets without a manual accept is inference from membership, not attestation — which is why this is `partial` and not `yes`. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
NEW SURFACE, VALUE UNCHANGED. https://www.microworks.com/products/delivery-pos.htm (live 2026-09-16, HTTP 200, 23,078 bytes) anchors its sentence "Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" with <a href="https://www.itsacheckmate.com/#party-integrations" title="itsacheckmate.com integrations"> around "integrates with 3rd party Apps", so Checkmate is the marketplace route Microworks itself names. NEW SURFACE: Checkmate's anonymous Zendesk Help Center API (support.itsacheckmate.com/api/v2/help_center/en-us/articles.json; 383 articles in the q311-icm census; the 16 article ids referenced inside bodies but absent from the listing all probe 404, none 401/403, so it is a census; its robots.txt names no Claude agent). MicroWorks is a named POS there: article 25998355462299 "List of Components in Checkmate Status Page" (updated 2025-12-02) lists under "Point of Sale": "Toast SpotOn Revel ... Focus Aloha MicroWorks CAKE Upserve", and status.itsacheckmate.com serves a component "MicroWorks" (id 37m5ybgh2qym) in group "Point of Sale" (operational on 2026-09-16). Microworks ALSO has a direct DoorDash integration (DoorDash registry, type POS), which this route does not describe. On the Checkmate route, 86ing is done in Checkmate's portal, not in PrISM: 8107645697563 (re-fetched 2026-09-16) "For our Direct Sync with Checkmate integrated POSs-Toast, Brink, Revel, SpotOn, Clover, Square, and Upserve-you will manage your menu DIRECTLY from the POS! ... For all other POSs, our Checkmate Portal will manage the menu, including the following functions: add/edit/delete items and modifiers, 86 items". 8158208744219 gives the same closed list ("Your POS is Toast, Brink, Revel, Clover, Square, SpotOn, Upserve, and Heartland (case dependent)"), and 8136678055963: "This function is POS-dependent. For Toast, Square, Clover, and Brink POSs, Items/Modifiers must be marked as sold out directly from the POS, not in the Checkmate Portal." MicroWorks is in none of these enumerations, so via Checkmate a POS-side 86 does not propagate. NOT a no: Microworks also has a DIRECT DoorDash integration (registry, CERTIFIED, type POS) whose ITEM_LEVEL_86 false flag is not a reliable negative; a no needs that route bounded too. Retrieved 2026-09-16. || 327th: THE SHIPPED STORE-LEVEL POS ITSELF WAS UNPACKED THIS PASS (327th), A SURFACE NO PRIOR PASS HELD; NO MOVE. https://microworks.com/files/Prism74Eval.exe (39,784,925 bytes, dated 2020-03-02 in the open Apache listing) is a Wise Installation Wizard SFX. It was NOT executed: the archive is a chain of raw-deflate streams each followed by a 4-byte CRC32, and a sequential inflate walk recovered 554 streams / 112,353,659 bytes covering the file end to end (ended at byte 39,784,925 of 39,784,925, 0 unrecovered). The Wise script stream names the installed program set: %MAINDIR%\vtpos.exe (ordering), vpsm.exe (Manager), vmake.exe (Makeline), esm.exe (scheduling), vmarket.exe (marketing), launcher.exe, prism.chm; the runtime is Visual FoxPro 9 (VFP9r.dll, VFP9t.dll). TWO ENUMERATIONS CAME OUT OF IT. (1) THE COMPLETE DATA DICTIONARY: 221 shipped .dbf tables parsed from their headers, 5,088 field slots, 2,036 DISTINCT field names. Item-level 86ing EXISTS in the POS data model - the menu-item table (589 seeded rows) carries `LSOLDOUT` alongside `LINACTIVE`, `IVISIBLE`, `LWEB`, `IWEBSORT`, `IWEBGROUP`, `CWEBLABEL` - but the dictionary contains NO third-party-channel binding of any kind. Tokenised, case-insensitive controls over the 2,036 distinct field names: `DOORDASH` 0, `GRUB` 0, `UBER` 0, `POSTMATE` 0, `CHANNEL` 0, `PARTNER` 0, `MARKET` 0, `THIRD` 0, `QR` 0, `GOOGLE` 0, `RWG` 0, `READY` 0; positive controls `WEB` 30 names, `STOCK` 7, `ROUTE` 12, `TABLE` 8. The only order-origin field is `IWEBORDERS` on the customer table, i.e. the vendor's own WebOrder. (2) THE COMPLETE OUTBOUND ENDPOINT SET of the shipped binaries: every http/https literal in all 554 streams was extracted and deduped; after removing W3C/Adobe/OpenOffice/Microsoft/Verisign/Borland boilerplate the entire remainder is https://IPCharge.net/IPCHAPI/rh.aspx and apidemo.IPCharge.net/DEMO_ADMINAPI/RH.ipc (card processing), https://posapi.loyaltypath.com/LoyaltyPath.asmx?wsdl (gift/loyalty), http://localhost/PrismWeb/PrismWeb.WSDL and http://wsat.microworks.com/ (the vendor's own WebOrder SOAP service, which 302s anonymously today), http://www.microworks.com/weborder/ and two help URLs. NO marketplace endpoint exists in the shipped product. WHY THIS IS STILL NOT A `no`: the build is PriSM 7.4 (2020) while the current line is V8/Prism Cloud, and the vendor's live delivery page names GrubHub/UberEats/DoorDash/Postmates via Checkmate, so a 7.4 dictionary cannot bound the current product; DoorDash's registry also lists microworks as a certified POS-type partner, and item 86ing is mandatory for new POS partners. Recorded as the bound on v7.4 only. Retrieved 2026-09-18. || 328th: 328th, PER-CELL RE-GREP against the two corpora the 327th built but never checked for THIS cell: (a) the unpacked PrISM v7.4 help system, 275 topic texts (1.2 MB), and (b) the 221-table / 5,088-field PrISM data dictionary recovered from the Prism74Eval install. Controls over the help texts and the 24-page marketing census: over the 275 help topics plus the 24-page site census and its stripped text (328 files, 1,196,111 chars): 'out of stock' 0, 'out-of-stock' 0, 'eighty-six' 0, '86ed|86ing' 0, and tokenised '86' exactly 1 hit which is POISON - <option value="86">Lebanon</option>, a country code in the contact form. (Widening the corpus to the extracted CashControl report samples adds 27 more '86' hits, every one a dollar figure such as 2385.86 / 1385.86 / 28.86: the numeral, never the verb.) 'order with google' 0, DoorDash 2 / UberEats 2 / Grubhub 14 (the 2+2 are the single marketing sentence 'Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates'; the other 12 Grubhub hits are a TENDER-TYPE line in CashControl settlement reports, i.e. a payment bucket, not an integration). Field-name controls over all 5,088 columns of the 221 tables: no OOS/OUTSTOCK/UNAVAIL column anywhere, no DOORDASH/GRUBHUB/UBER/3P column anywhere; the only availability-shaped fields are CAVAILABLE:C168 in two tables and two boolean LDISABLE(D) flags. WHY THIS STILL CANNOT CARRY A `no`: the dictionary and help system are PrISM v7.4, not the V8/Cloud product the record scores, and Micro Works reaches the marketplaces through It'sACheckmate middleware, which integrates from its own side - a POS's own schema does not bound what the middleware pushes. Retrieved 2026-09-18. || 330th: 330th: the Checkmate route was re-probed for change and there is none - support.itsacheckmate.com/api/v2/help_center/en-us/articles.json reports count 383, identical to the census the earlier pass used, so no new middleware article covers MicroWorks 86ing. On the vendor side nothing newer exists to read: microworks.com/files/ re-listed today is byte-for-byte the same 2020-03-02 set (no newer installer or manual; sellsheets/ are 2010 duplicates; the only V8-era artefacts, files/print/PizzaToday-V8*AD.pdf, are image-only with 0 extractable characters), the marketing site is at an href fixpoint of 24 distinct pages with an EMPTY sitemap.xml, and the help library reached through its own RoboHelp manifest (whproj.htm -> whxdata/whtdata0-6.xml, 207 TOC topics) is the same 2010-2016 book. Controls over the deduped 2,488-file fixpoint corpus: 'out of stock' 0, 'sold out' 10 hits in 2 files (Menu_Items.htm and Ordering_Advanced_Options.htm - the POS-local sold-out flag, matching the LSOLDOUT column already on record, with no channel binding), 'doordash' 2 hits (the single marketing sentence). The V8 cloud back office (storenet2/5/storenet-eu1.microworks.com, 8.0.27.963) is live but login-gated and ships no anonymous module list. Retrieved 2026-09-18. adversarially verified
Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.
delivery-store-pause
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu's help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu's `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial's developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. The flag `STORE_AVAILABILITY_WEBHOOKS`, which DoorDash labels 'Integrated close/pause store', is TRUE for `microworks`, inside a collection that is active for this provider. A true flag is positive evidence. `partial` because the claim requires the pause on EACH connected marketplace and a timed auto-reactivation, and the registry attests one marketplace and carries no flag for a reactivation timer. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12
Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator
delivery-3p-reconciliation
CLAIM: a third-party reconciliation report matching marketplace payouts to POS-recorded 3P sales, itemising commission, fees, refunds/adjustments, and identifying missing/unpaid orders. VERDICT: partial/D (differentiator; described only by the middleware partner, as a separately signed-up product). https://www.microworks.com/products/delivery-pos.htm (live 2026-09-16, HTTP 200, 23,078 bytes) anchors its sentence "Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" with <a href="https://www.itsacheckmate.com/#party-integrations" title="itsacheckmate.com integrations"> around "integrates with 3rd party Apps", so Checkmate is the marketplace route Microworks itself names. NEW SURFACE: Checkmate's anonymous Zendesk Help Center API (support.itsacheckmate.com/api/v2/help_center/en-us/articles.json; 383 articles in the q311-icm census; the 16 article ids referenced inside bodies but absent from the listing all probe 404, none 401/403, so it is a census; its robots.txt names no Claude agent). MicroWorks is a named POS there: article 25998355462299 "List of Components in Checkmate Status Page" (updated 2025-12-02) lists under "Point of Sale": "Toast SpotOn Revel ... Focus Aloha MicroWorks CAKE Upserve", and status.itsacheckmate.com serves a component "MicroWorks" (id 37m5ybgh2qym) in group "Point of Sale" (operational on 2026-09-16). Microworks ALSO has a direct DoorDash integration (DoorDash registry, type POS), which this route does not describe. EVIDENCE (re-fetched 2026-09-16, HTTP 200): 26108047066139 "What is Reconcile?": "Map POS transactions to Ordering Platform statements and identify unmatched transactions ... Refunds and Adjustments - Tracks refunds and order modifications to ensure proper reconciliation. Sales Reconciliation - Bridges sales records from ordering platform statements with deposits in the bank ... POS to Statement Bridge - Provides a breakdown of how POS sales convert into bank deposits, including all adjustments ... Unreconciled Transactions - Identifies transactions where the POS and ordering platform data do not match"; "Just fill in the Reconcile Sign-Up Form, and our onboarding team will contact you". 26108118491163 "Unreconciled Transactions - Glossary of Terms": "Orders Only in OP Statement: ... orders that errored when integrating and, thus, were not directly injected by Checkmate ... Orders Only in Checkmate: ... it could imply that an order was processed but not paid for"; columns include DEPOSIT_DATE and FINAL_POS_SUBTOTAL_INC_ELEVATION ("Sales recorded by Point of Sales + Elevation"). SHORTFALLS: (1) no Reconcile article names MicroWorks or lists eligible POSs; the POS side appears to be Checkmate's own order-integration data. (2) It is a Checkmate add-on with its own sign-up, not a PrISM report; the Microworks help TOC still has no marketplace reconciliation topic. (3) A commission column is not quoted here. Retrieved 2026-09-16. https://support.itsacheckmate.com/hc/en-us/articles/26108047066139 · retrieved 2026-09-16 adversarially verified
Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator
delivery-injection-error-visibility
CLAIM: vendor exposes integration health to the operator - failed/rejected injections, per-channel connection status, alerts on failure. VERDICT: partial/D (differentiator; every conjunct is described, but only in the middleware partner's help centre, so the grade floor caps it at partial). https://www.microworks.com/products/delivery-pos.htm (live 2026-09-16, HTTP 200, 23,078 bytes) anchors its sentence "Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" with <a href="https://www.itsacheckmate.com/#party-integrations" title="itsacheckmate.com integrations"> around "integrates with 3rd party Apps", so Checkmate is the marketplace route Microworks itself names. NEW SURFACE: Checkmate's anonymous Zendesk Help Center API (support.itsacheckmate.com/api/v2/help_center/en-us/articles.json; 383 articles in the q311-icm census; the 16 article ids referenced inside bodies but absent from the listing all probe 404, none 401/403, so it is a census; its robots.txt names no Claude agent). MicroWorks is a named POS there: article 25998355462299 "List of Components in Checkmate Status Page" (updated 2025-12-02) lists under "Point of Sale": "Toast SpotOn Revel ... Focus Aloha MicroWorks CAKE Upserve", and status.itsacheckmate.com serves a component "MicroWorks" (id 37m5ybgh2qym) in group "Point of Sale" (operational on 2026-09-16). Microworks ALSO has a direct DoorDash integration (DoorDash registry, type POS), which this route does not describe. EVIDENCE (each re-fetched via articles/<id>.json 2026-09-16, HTTP 200): 49389284677787 "What is an Order Attention Required order": "When an order cannot be processed correctly, the restaurant is notified in one of two ways: The first is a notification ticket. If configured, a notification ticket is sent to the kitchen with the message "Order Attention Required," along with the delivery service, order number, customer name, and order details ... The second is a notification email ... with details about the ordering platform, order number, the item or modifier that caused the error". 49389751226267 "Why didn't my order integrate into my POS?": "If the POS is offline, the customer's order will not reach the POS ... a notification email is sent to the restaurant instead." 34845940220699 "Ordering Platforms Offline Notification": "This alert notifies you instantly when an Ordering Platform goes offline ... notifications are sent via email to designated recipients." 34845896740379 "Location Offline Notification": "If a location is marked Offline, an auto-alert is triggered." 25996726444059 (status page): "if GrubHub is down and only affects GrubHub orders ... it would be categorized as a partial outage". SHORTFALLS: (1) apart from the status-page component list these articles are POS-generic and do not name MicroWorks; "To program the Order Attention Required item in the POS, contact Checkmate Support" is unverified for PrISM. (2) The surface is Checkmate's portal and email, not a Microworks screen. (3) The direct DoorDash route (registry DETAILED_ERROR_SPEC true) remains a wire-protocol flag only. Retrieved 2026-09-16. https://support.itsacheckmate.com/hc/en-us/articles/49389284677787 · retrieved 2026-09-16 adversarially verified
Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.
delivery-tracking-page
Customer-facing tracking is stated in its own right, distinct from the store-side route screen: "Customers can see if their order picked up and where the delivery is located on a map," tracked through the web order status page, with SMS alerts when the order is out for delivery and "when the delivery has arrived at the customers door." Grade corrected B to C — the page is marketing, which the floor permits for a table-stakes claim. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-02 adversarially verified
Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator
delivery-promise-time
Documented mechanism, not just the feature name: "Estimated Delivery Minutes — This is the number of minutes which will be added to the time a delivery order is placed. This is used to calculate the Estimated Delivery Time, which can be displayed on the ordering screen at the completion of a delivery order." Lateness is policed alongside it by Mark Lates Automatic, Auto Late Minutes and a Route Late Order Warn that makes waiting orders flash. Worth carrying: the quote is a flat configured constant, not a load- or distance-computed promise. https://help.microworks.com/webhelp/Routing_Tab.htm · retrieved 2026-08-02
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
The on-premise architecture — store-local Windows terminals and database with only nightly sync to hosted Storenet ("Hosted Server and Unit Locations Can Update Database Nightly") — structurally implies cash delivery orders, driver assignment (Assign_Orders.htm) and driver settlement (Cash_Drop.htm, Till_List.htm) continue to function during an internet outage, since none of that machinery depends on the cloud link. Shortfall: the vendor never states this explicitly for delivery specifically, so it remains an inference rather than a documented behavior. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-04
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
WebOrder — custom-branded online ordering portal tightly integrated with the store POS. No marketplace commission model; per-order economics not published. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Branded native apps do exist: the App Store lists the Greco Pizza consumer ordering app with seller "Microworks POS Solutions, Inc.", and the same developer publishes Greco Pizza (com.microworks.weborder.grecopizza) and Mark's Pizzeria on Google Play. Shortfall: two bespoke builds for two named chains is not a productised capability. The PrISM consumer-facing book is Web Ordering Overview and Customer Interface — browser ordering — with no native-app, branding or store-submission topic anywhere in the help TOC, and Microworks publishes no app product page, pricing or self-serve path. The Apple listing shows 2.1/5 across 50 ratings. https://apps.apple.com/ca/app/greco-pizza/id881537471 · retrieved 2026-08-02 adversarially verified
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
Customer accounts with managed orders and saved card handling, plus POS-side "Customer Profile and Order Statistics." Guest checkout also supported. One-tap reorder is not documented. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
The complete Web Ordering book — Web_Ordering_Overview.htm, Customer_Interface.htm, Reporting.htm — was read in full. The checkout flow is documented step by step (menu browse, item customization, order-type/schedule/coupon/payment selection, confirmation, favorite-order save) with no upsell, cross-sell, or suggested-item prompt at any step, and no attach-rate report exists in Reporting.htm's Order List/User List/Performance Report set. https://help.microworks.com/webhelp/Customer_Interface.htm · retrieved 2026-08-04
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
Future/scheduled orders supported; per-daypart capacity throttling and automatic slot closure are not documented. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
Verified verbatim: "Pick-Up and Pay, Pre-Pay and Pick Up, Pre-Pay and Delivery, Delivery and Pay at the Door, Contactless Delivery, Curbside," with customers texting "HERE" for curbside arrival. Also worth adding to digital-account-saved-payment: "favorite order recall" is documented, which the dossier called undocumented. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01 adversarially verified
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
QR scan-to-order-and-pay is offered; attachment to an existing POS check, splitting, and tipping are not documented. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
Self-order kiosk reuses the existing WebOrder menu, pricing, and UI and takes contactless payment. ADA/accessibility conformance is not documented. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
Positive absence by end-to-end enumeration of the first-party ordering product's own customer flow. The Web Ordering book's Customer Interface topic walks the guest from arrival to confirmation and closes both ends against a group flow. Entry is a closed three-way choice: "When a customer first arrives at the web ordering site, they will be given three options: to create a new account, to log in if they have previously created an account, or to log in as a guest." Checkout is likewise closed-form: "The customer can change the order type (delivery or pickup), schedule the order for a later date or time (if the store allows it), apply any coupons or discount codes, and select their payment type." No shareable invite link, no second participant, no per-person or total spend cap, and no split payment appears anywhere in the flow; the cart is built by one logged-in account and "clicking 'Place Order Now' will send the order to the store." Same instrument the corpus already accepts for agilysys, cake-pos and lavu. Retrieved live on 2026-09-04 because this topic was absent from the supplied article corpus. https://help.microworks.com/webhelp/Customer_Interface.htm · retrieved 2026-09-04 adversarially verified
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
CLAIM: a distinct catering ordering flow with separate catering menu and minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. There is no catering entity in PrISM. Microworks' own current product overview places catering on the POS, not on a guest channel: PrISM_Overview.pdf, linked from the current site at https://www.microworks.com/files/PrISM_Overview.pdf (retrieved 2026-09-15), lists under POS Features 'Advanced Touch Screen Ordering; Delivery, Dine-In, Carry-Out, Catering Orders', and https://www.microworks.com/products/pizza-pos.htm (retrieved 2026-09-15, footer Copyright 2025) says only 'intuitive touch screen ordering for table-service, delivery, take-out, and catering'. The word catering appears zero times on the WebOrder page, zero times on the kiosk/QR page, and once in the entire technical library, in an unrelated topic about cost centres. MET, as generic machinery an operator would have to assemble, never as a documented catering feature. (1) A web-only order type carrying its own minimum, https://help.microworks.com/webhelp/Order_Types.htm (live, HTTP 200, 21,193 bytes, md5 2a769066, retrieved 2026-09-15): 'The PrISM system allows the flexibility of specifying custom order types'; 'Min Order - If a value is entered here, an order taken using this order type will not be able to be settled unless the Subtotal is greater than this value'; 'Web Order Type - This marks the order type as used by Online Ordering. This causes the order type to be unusable by in-store order takers.' (2) Future-dating at web checkout, https://help.microworks.com/webhelp/Customer_Interface.htm (live, 11,030 bytes, retrieved 2026-09-15): 'The customer can change the order type (delivery or pickup), schedule the order for a later date or time (if the store allows it), apply any coupons or discount codes, and select their payment type.' (3) Credit-based house accounts with invoices and statements, https://help.microworks.com/webhelp/Customer_Accounts.htm (live, 4,725 bytes, retrieved 2026-09-15): 'Customer Accounts can be created, at your discretion, allowing customers to purchase merchandise on account', with 'Transaction History - This section details account history, including payments, credits, and balance. Invoices may be generated from this screen as well', 'Print All Invoices' and 'Print Statement'; a credit limit is corroborated indirectly at https://help.microworks.com/webhelp/QB_Invoices.htm, 'When placing an order on account, PrISM verifies the customer account balance so a non-zero Credit Limit must be specified.' SHORTFALLS. (1) No catering ordering flow exists as a product; the vendor documents catering only as an in-store POS order type, and never describes configuring a catering channel. (2) No catering menu construct: menu layouts are scoped to stations, not to order types. (3) No lead-time rules. The only future-dating is a per-store on/off 'schedule the order for a later date or time (if the store allows it)' - no cut-off, no minimum notice, no per-item lead time. (4) No quotes or proposals anywhere; tokenised quote and proposal both read 0 in the technical library. (5) No deposits and no ACH. (6) Payment terms are labels, not enforced terms: https://help.microworks.com/webhelp/Account_Terms.htm (live, 988 bytes, retrieved 2026-09-15) says 'you may create any applicable payment terms that you offer your account customers ... These terms are free-form text fields; you may enter any name you wish', used only 'to separate accounts into different billing cycles'. (7) Aged invoicing depends on the separately sold QuickBooks Interface Module (QIM), which PrISM_Overview.pdf lists under 'Integrated Options'. (8) The documented web checkout enumerates its order types as '(delivery or pickup)'. CORPUS AND AGE: bound to the live WebHelp library at help.microworks.com/webhelp/ - the vendor's currently linked 'Online Help' - censused against its own RoboHelp TOC (whgdata/whlstt0..120.htm, 428 rows, 205 distinct topic titles), plus the 16-page current marketing link graph reached by crawling nav and footer hrefs, plus PrISM_Overview.pdf. The help library is current but old: HTTP Last-Modified on these topics reads 2010-01-25 and Welcome.htm carries 'Copyright (c) 1993 - 2009'. The marketing corpus is 2025. CONTROLS, tokenised with word boundaries after stripping HTML comments then tags, positive control PriSM 300 hits / 113 files fired on every run: catering 1 hit / 1 file (Cost_Centers_Update.htm, about cost centres), cater 0, banquet 0, quote 0, proposal 0. POISON. (a) deposit reads 16 hits in 5 files and every one is a bank deposit or a bottle deposit ('If this item is a can or bottle and your state uses bottle deposits'); a substring reader would score a catering deposit. (b) In the archived Wayback unpack catering reads 153 hits in 153 files, of which 152 are mirrored marketing navigation captured under /webhelp/; the true topic count is 1. (c) help.microworks.com serves a soft-200 catch-all - a fabricated path returns HTTP 200 at about 16.75 KB of the marketing homepage - so every citation here was discriminated by byte length and md5 against that body. (d) 'Advanced Order List' on the reporting page is filed under Inventory and Food Cost Control and is a purchase-order report, not a customer advance-order report. (e) Three live files are one Buyer's Club topic under three URL encodings, so raw file counts triple-count. CORRECTION TO THE FIRST PASS: the quotes 'Credit Limit - Specify the credit limit for this account' and 'Account Terms - Choose the appropriate account terms' were attributed to Customer_Accounts.htm and Account_Tracking.htm; neither phrase occurs on either page. 'Credit Limit' occurs exactly once in the whole live library, in QB_Invoices.htm, and is cited there instead. https://help.microworks.com/webhelp/Order_Types.htm · retrieved 2026-09-15 adversarially verified
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
The complete 488-topic help TOC and full vendor product catalogue contain no AI, voice, or phone-ordering-automation topic. The only phone-adjacent feature documented anywhere is Caller ID Customer Link, an inbound-call customer-record lookup, not order transcription or injection. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
No drive-thru product or hardware is sold (order-capture-drive-thru, no), so there can be no drive-thru voice-AI layered on top of it; none is named anywhere on the vendor site or in the manual. https://www.microworks.com/products.htm · retrieved 2026-08-04
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
CLAIM: conversational SMS or chat ordering, text-to-order or text-a-link, landing in the POS. Positive evidence of absence, bound to the vendor's CURRENT surface rather than to its old manual. (1) The digital ordering channels Microworks sells are enumerated in its own site navigation, present identically on all 16 pages of the crawled link graph (retrieved 2026-09-15, footer Copyright 2025): Restaurant POS, Pizza POS, Delivery POS, Web Ordering, RapidRun, Delivery Tracking, Enterprise Management, POS Surveillance, Wireless Tablet Ordering, Self-Ordering Kiosk, QR Ordering, POS Payment Processing, Reporting. There is no SMS or chat ordering channel in that list. (2) The SMS product Microworks does sell is enumerated as a closed list of notification events at https://www.microworks.com/products/web-ordering.htm (retrieved 2026-09-15): 'Prism Notification Service is an easy way to communicate via SMS messaging between restaurants, customers, and delivery drivers ... Notifications can be sent: when an order is created / confirmed. when the order is ready for pickup. to respond when a customer texts "HERE" when they arrive for their curbside pickup. when the order is going out of the restaurant for delivery. when the delivery has arrived at the customers door. with predefined or custom messages, for any reason, at any time.' Every branch is outbound store-to-guest except one inbound curbside keyword. (3) The only other SMS product named is outbound marketing: https://www.microworks.com/products/enterprise-management.htm (retrieved 2026-09-15), 'Create text campaigns to reach your customers via the devices they use most' under the heading 'SMS Marketing'. (4) The vendor's own SMS terms enumerate the inbound keywords its messaging handles, and they are compliance keywords only: https://www.microworks.com/SMSPolicy.htm (retrieved 2026-09-15) - 'You can opt out anytime by replying STOP. For help or more information, reply HELP', with START to resubscribe. No ordering keyword, no conversational flow. (5) First-party technical corroboration: https://help.microworks.com/webhelp/Customer_Interface.htm (live, 11,030 bytes, retrieved 2026-09-15) documents the WebOrder guest flow as a browser flow with no text entry point, and https://help.microworks.com/webhelp/Web_Ordering_Overview.htm (live, 3,778 bytes) scopes texting to status only: 'customers may opt to receive "status alerts" regarding their order. These notifications can be sent via email or cellular phone text message.' CORPUS AND AGE: the decisive corpus is the 16-page current (2025) marketing link graph plus SMSPolicy.htm, not the help library - the Prism Notification Service postdates the library entirely (notification reads 0 hits there). Absences are bound to the crawled nav link graph, never to www.microworks.com/sitemap.xml, which is a 58-URL strict subset that omits at least the kiosk/QR, RapidRun and news pages. CONTROLS, tokenised, positive control Microworks fired on all 16 marketing pages (5 to 19 hits each) and PriSM 300/113 on the help library: SMS reads 0 on the kiosk/QR page, 0 on the handheld ordering page, 0 on the restaurant POS page, and 1 hit in the entire help library. POISON. (a) That single help hit is not about ordering at all - https://help.microworks.com/webhelp/Setup_Custom_Reports.htm, 'SMS Format - This option changes the report to a format which can be sent to a cellular phone as a text message' - i.e. a management report delivered by SMS. (b) text reads 36 hits in 22 help files and is dominated by 'text file', 'text box' and 'General text options'; only three hits concern SMS. (c) 'SMS Marketing' on the enterprise page is an outbound campaign tool and reads as an SMS customer channel. (d) An early control run of mine returned 0 for the token 'order' on a page that plainly contains it, a shell-escaping artefact; the run was discarded and re-done from a file-based script with a passing positive control, which is why every figure above carries one. CAVEAT PUBLISHED AGAINST THE VERDICT: 'with predefined or custom messages, for any reason, at any time' means a store could text a guest a link to the ordering site. That is an operator using a generic message tool, not a documented text-to-order or text-a-link feature landing in the POS. Grade C because the decisive sources are vendor feature pages written to sell. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-09-15 adversarially verified
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
Examined 2026-08-04, unresolved. The complete Web Ordering book of the administrator manual (Web_Ordering_Overview.htm, Customer_Interface.htm, Reporting.htm — its full extent per the help TOC) mentions Google only as Google Maps: delivery-address mapping in the overview and address verification against Google Maps in the customer interface. The web-ordering marketing page (microworks.com/products/web-ordering.htm, re-read 2026-08-04) mentions Google only inside analytics scripts. Nothing anywhere addresses Order with Google or provisioning the direct ordering link to a Google Business Profile — but GBP provisioning is a service-side act performed in Google's dashboard that would not necessarily appear in a manual of this vintage, so absence of mention cannot carry a no. || 322nd: NEW SURFACE, VALUE UNCHANGED. The live direct-ordering app is Microworks WebOrder on *.weborder.net (crt.sh: 340 certificate names, production restaurant tenants plus stage/demo hosts; Play Store developer 'Microworks POS Solutions' also lists branded WebOrder apps com.microworks.weborder.grecopizza and .markspizzeria). Order with Google partners must pass Google's rwg_token conversion parameter; tokenised `rwg` and `rwg_token` 0 hits over 3 tenant landing pages, the prismdemo Groups menu page (125,923 bytes) and 15 production tenants' /Groups pages; the only Google strings are googletagmanager gtag/GTM analytics. BOUND: conversion tracking would sit on checkout/confirmation pages we cannot reach without placing an order, and the sample is 15 of ~330 tenants, so this is not a census and cannot carry a `no`. Retrieved 2026-09-17. || 327th: NEW CORPUS, NO MOVE. The shipped PriSM 7.4 install image (unpacked without executing it; 554 deflate streams, 112.3 MB, complete) was searched for Order-with-Google provisioning: tokenised controls over the 2,036 distinct .dbf field names give `GOOGLE` 0 and `RWG` 0, and over every string literal in all 554 streams the only google.* strings are absent entirely - the whole outbound endpoint set is IPCharge, LoyaltyPath and the vendor's own PrismWeb/WebOrder SOAP service. The decompiled shipped manual (prism.chm, 275 topics) mentions Google only as Google Maps address verification, matching what the 2026-08-04 pass already recorded from the live webhelp. This corroborates rather than settles: GBP ordering-link provisioning is done in Google's own dashboard and in the WebOrder tenant sites (the 322nd's *.weborder.net sample), not in the desktop build, so a 2020 POS image cannot carry a `no`. Retrieved 2026-09-18. || 330th: 330th: tokenised controls for this cell were re-run over the newly completed href-fixpoint corpus (24 distinct microworks.com pages + the whole RoboHelp library reached from whproj.htm -> whxdata/, 2,488 deduped files): 'order with google' 0, 'rwg' 0, 'google business' 0; the only Google strings remain Google Maps address verification and gtag/GTM analytics. Also newly checked and negative: the iTunes publisher census (artist 462237794 = exactly 3 apps) and the live V8 back office storenet2/5/storenet-eu1.microworks.com (8.0.27.963; anonymous /Login only, /robots.txt 404, nonsense path 404, first-party JS = one 899-byte MessageBoxes.js). Still not a `no`: Order-with-Google provisioning happens in Google's dashboard and on the *.weborder.net tenant sites, which no anonymous surface censuses. Retrieved 2026-09-18. || 333rd: 333rd: NEW SURFACE, no move. Google's own help page for the feature, support.google.com/business/answer/10918858 (now 301 to answer/10842217 'Manage online ordering options', 1.6 MB, fetched with curl), no longer publishes a provider roster: it tells the OWNER to 'Add and manage third-party providers and custom ordering links' via Business Profile > Food ordering > 'Add a link', then 'Set as preferred' for pickup/delivery. So a Microworks tenant can place its *.weborder.net link on its profile by hand whether or not Microworks provisions it; the page names no provider (microworks 0, weborder 0, prism 0, checkmate 0), so it neither shows Microworks provisioning nor bounds it. YouTube (yt-dlp search 'Microworks Prism POS', 'Microworks POS', 'Microworks WebOrder', 'Microworks QR ordering'): Microworks runs no vendor channel; the only hits are a third-party reseller review (P.O.S. Experts, vy3qvNKk0lg) and an unattributed 2010s 'MicroWorks Demo.wmv', and 'Prism POS' results are POISON (Big Hairy Dog's videos are RetailPro Prism, a different product). Retrieved 2026-09-18. || 334th: 334th: NEW SURFACE, no move. The whole live WebOrder 5.1 tenant roster was fetched (339 crt.sh names; 323 answered 200 at /, 293 GetAddress pages) plus the current bundles Base-5.1.817.2272, CallCenter-5.1.817.2272 and getaddress-5.1.817.2272. Tokenised controls: 'rwg' 0 as a token; the 4 raw substring hits (bucks, infinitus, renzis roots, pizzavida GetAddress) are all inside random __RequestVerificationToken CSRF values (POISON: rwg inside base64). 'conversion_partner' 0, 'order with google' 0. Not a `no`: Google's rwg_token can be captured and reported server-side, and a client census cannot see a server-side action (331st rule); Google no longer publishes a provider roster (333rd). Retrieved 2026-09-18. adversarially verified
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
The complete Web Ordering book mentions Google only as Google Maps for delivery-address mapping (digital-google-order, existing cell) and never mentions Apple Maps, Apple Business Connect, or an 'Order Food' place-card action. No such topic exists anywhere in the manual or on the marketing site. https://help.microworks.com/webhelp/Web_Ordering_Overview.htm · retrieved 2026-08-04
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Buyer's Club accrual and redemption are both wired to the online ordering channel on the same coupon record, but the manual never shows the guest's point balance inside the web flow. Redemption: the Advertised Coupon carries a points field - "Points ... A coupon set to require points will only be able to be used by a customer with enough points, and will deduct that number of points from the customer's total" - and the same record carries "Visibility - This option is only used for Online Ordering. With it, you can set the coupon to be available only in the store, only on the web, or both in the store and on the web" plus a Web Code and Web Label, so a points-deducting coupon can be published to the web site. Accrual: Order_Types.htm makes Buyer's Club a per-order-type setting ("Eligible for Buyer's Club - If this is checked, orders taken using this order type will allow the customer to accrue points") and web orders arrive as order types flagged "Web Order Type - This marks the order type as used by Online Ordering." Identity is the POS customer record, where Additional_Information_Tab.htm shows "Club Points - This is the total amount of Buyer's Club points available for this customer." SHORTFALL, three parts: (1) the customer-facing walkthrough (Customer_Interface.htm, retrieved 2026-09-04) describes web checkout only as "apply any coupons or discount codes" and never shows a balance, a rewards list or a redeem action; (2) the manual never states the web site enforces the "customer with enough points" test - that is described from the POS coupon-setup side only; (3) Buyer's Club reward availability is documented as reaching the guest on paper, not online: "Buyer's Club coupons are designed to print on receipt-style printers. They can print either at the bottom of the customer's receipt or as a separate ticket entirely." So the guest must carry a code off an in-store receipt to redeem online. https://help.microworks.com/webhelp/Advertised_Coupons.htm · retrieved 2026-09-04
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
The complete Web Ordering book documents account creation, guest checkout, favorite-order recall, and one-time payment at checkout, with no recurring-billing, membership, or subscription concept anywhere. No subscription topic exists elsewhere in the 488-topic manual. https://help.microworks.com/webhelp/Customer_Interface.htm · retrieved 2026-08-04
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Channel scoping is explicit: the Advertised Coupon Advanced tab lets you "control whether the coupon is available for Online Ordering", and modifier lists carry a Visibility flag of All / In-Store Only / Web Only. Shortfall: this is a per-coupon opt-in rather than parity — the manual documents no mechanism guaranteeing that in-store promotions appear on the web channel, and third-party marketplace channels are not addressed at all. https://help.microworks.com/webhelp/Advertised_Coupons.htm · retrieved 2026-08-02
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
The Web Ordering Reporting book documents a self-serve bulk guest export: the User List report is filterable by Name/Email/Phone and by Registered/First Order/Last Order/Ordered date ranges, carries a "NoEmails" column recording promotional opt-out, and exports to XML or CSV; the separate Order List report exports full order history the same way. Both are standard reporting-screen functions with no fee or vendor-approval step documented. https://help.microworks.com/webhelp/Reporting.htm · retrieved 2026-08-04
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
Tokenization and P2PE are claimed platform-wide and WebOrder is described as a "secure" pre-pay flow. Hosted fields/hosted page, 3DS, and PCI DSS 4.0 script-integrity compliance are not documented. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
No dual-pricing/surcharge/service-fee configuration exists anywhere in the pricing engine (payments-dual-pricing, no), so digital channels cannot mirror one. The complete web-ordering checkout flow (Customer_Interface.htm) documents coupon and payment-type selection with no fee-disclosure step of any kind. https://help.microworks.com/webhelp/Customer_Interface.htm · retrieved 2026-08-04
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
WebOrder writes into the same store POS database that holds "Customer Profile and Order Statistics," so in-store and online share one record. Dedup/merge behavior and kiosk attachment are undocumented. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
CLAIM: marketplace orders attach to a native guest profile with usable identity rather than landing as anonymous tickets. VERDICT: partial/D. The prior blocker (whether marketplace orders reach PrISM at all) is settled for the Checkmate route, and what arrives is a name, not a profile. https://www.microworks.com/products/delivery-pos.htm (live 2026-09-16, HTTP 200, 23,078 bytes) anchors its sentence "Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" with <a href="https://www.itsacheckmate.com/#party-integrations" title="itsacheckmate.com integrations"> around "integrates with 3rd party Apps", so Checkmate is the marketplace route Microworks itself names. NEW SURFACE: Checkmate's anonymous Zendesk Help Center API (support.itsacheckmate.com/api/v2/help_center/en-us/articles.json; 383 articles in the q311-icm census; the 16 article ids referenced inside bodies but absent from the listing all probe 404, none 401/403, so it is a census; its robots.txt names no Claude agent). MicroWorks is a named POS there: article 25998355462299 "List of Components in Checkmate Status Page" (updated 2025-12-02) lists under "Point of Sale": "Toast SpotOn Revel ... Focus Aloha MicroWorks CAKE Upserve", and status.itsacheckmate.com serves a component "MicroWorks" (id 37m5ybgh2qym) in group "Point of Sale" (operational on 2026-09-16). Microworks ALSO has a direct DoorDash integration (DoorDash registry, type POS), which this route does not describe. EVIDENCE (re-fetched 2026-09-16, HTTP 200): 49390488826139 "What customer information will I see on my kitchen ticket?": "When an online order flows through Checkmate into the POS, the following customer and order information appears at the top of the kitchen ticket and KDS: Customer's first name and last initial Time of expected pickup Ordering platform the order was placed through For the customer's phone number, access the ordering platform merchant portal or the tablet, if that information was provided at checkout." MET: the ticket is not anonymous. SHORTFALL: no phone number crosses into the POS, and PrISM's customer file is phone/address-keyed (Update_Customers.htm), so nothing documents an attach to a PrISM customer record; the article is POS-generic and does not name MicroWorks; the direct DoorDash route's customer payload is undocumented. This reads close to a no; kept partial only because the identity is not anonymous. Retrieved 2026-09-16. https://support.itsacheckmate.com/hc/en-us/articles/49390488826139 · retrieved 2026-09-16 adversarially verified
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
Two configurable accrual models are documented. Spend-based: "The Buyer's Club is based on a point system, where point values can be set up based on order ticket totals. In turn, points can be awarded to customers each time they order if they meet your minimum order value requirements." Item-based: the menu item Advanced tab has a Points field — "Assigning a value to this field will cause this item to add that number of points to the customer's total when ordered." Redemption is by point-threshold coupons ("Club Points — This is the number of points required for this coupon to be issued"), with the matching Advertised Coupon carrying a Points Req. that "will deduct that number of points from the customer's total". Native, no bolt-on vendor. https://help.microworks.com/webhelp/Buyer_s_Club_Setup.htm · retrieved 2026-08-02
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
The complete loyalty/marketing surface — Buyer's Club Setup (flat point accrual and threshold-coupon redemption), Comeback Coupons (recency-triggered, not status-based), and the 13-topic Marketing Module book (Overview, Customer Activity, Order History, Mailing History, Menu, Other, Sectors, Carrier Routes, Exclusions, Area Type, Labels) — has no status-tier concept, no promotion/demotion rule, and no rolling-window spend or visit-count threshold that changes a customer's standing. https://help.microworks.com/webhelp/Buyer_s_Club_Setup.htm · retrieved 2026-08-04
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
CLAIM: documents explicitly what loyalty lookup, accrual and redemption do when the POS loses connectivity, queue-and-reconcile versus blocked. This is a documentation claim, and the answer is that Microworks never states it, on any surface, old or current. (1) The sole loyalty topic in the technical library is https://help.microworks.com/webhelp/Buyer_s_Club_Setup.htm (live, HTTP 200, 6,060 bytes, md5 0f2e5dfc, retrieved 2026-09-15): 'The Buyer's Club is based on a point system, where point values can be set up based on order ticket totals. In turn, points can be awarded to customers each time they order if they meet your minimum order value requirements. The customer can then use these points in the form of redeemable coupons, which you'll define, for future use.' It specifies Club Points per coupon and the coupon messages, and closes 'For more detailed information on the Buyer's Club feature, please contact Microworks Technical Support.' It says nothing about a network, a server, a connectivity loss or degraded operation. (2) The current marketing surface is the closest the vendor comes, and it describes WHERE the data lives without ever saying what happens when the link drops: https://www.microworks.com/products/delivery-pos.htm and https://www.microworks.com/products/kiosk-qr-ordering.htm (both retrieved 2026-09-15, Copyright 2025) carry the same passage - 'Single store operators can take advantage of the simplicity of gift card account information being stored locally ... [multi-store operators] can optionally implement the flexibility of a web based account database where customers are allowed to purchase or redeem their cards at one of many locations. Loyalty award points can be accumulated in a variety of ways at any store location and redemption monitored and validated.' A web-based account database is precisely the configuration in which offline behaviour matters, and the vendor still does not state it. (3) The one place offline continuity is addressed is not loyalty: https://help.microworks.com/webhelp/System_Overview.htm (live, 21,062 bytes, md5 daeca130, retrieved 2026-09-15), 'Upload Offline PrISM Card Transactions - This option allows you to upload any transactions that used PrISM cards while the system was disconnected from the internet.' That is a queue-and-upload statement about PrISM cards, a product the library never defines; it names neither Buyer's Club nor points lookup, accrual or redemption. (4) Architectural context, which is inference and not documentation: PrISM is on-premise, stations talk to a store-local server (https://help.microworks.com/webhelp/Trouble_Shooting.htm describes 'Unable to Connect to Server' as 'indicative of a network connectivity problem'), and StoreNet upload is a nightly End-of-Day push. Buyer's Club points may well never depend on the internet - but the claim asks for an explicit statement, and there is none, which is why this is no rather than a fabricated yes. CORPUS AND AGE: bound to the publisher's own RoboHelp TOC (whgdata/whlstt0..120.htm, 428 rows, 205 distinct topic titles), which contains exactly one loyalty topic, plus the 16-page current marketing link graph. The help library is the vendor's currently linked 'Online Help' but was authored in 2009/2010 (HTTP Last-Modified 2010-01-25; Welcome.htm 'Copyright (c) 1993 - 2009'); the marketing corpus is 2025. Microworks publishes no other help centre, KB, changelog or API reference. CONTROLS, tokenised, positive control PriSM 300 hits / 113 files: offline 1 hit (the PrISM Card line), connectivity 1 hit (cabling), disconnected 3 hits in 2 files, redundancy 0, failover 0, outage 2 hits and both unrelated. POISON. (a) loyalty reads 0 in the technical library because the vendor's word there is 'Buyer's Club'; a loyalty-only control manufactures a false zero. The inverse trap also exists: loyalty reads 1 to 4 hits on five current marketing pages, so a marketing-only reader sees a loyalty product and a library-only reader sees none. (b) 'Buyer's Club' reads 61 hits in 12 files, but three of those files are the same topic under three URL encodings, so the real topic count is 10. (c) points reads 41 hits and the largest block, 15, is in Order_Types.htm where points are decimal and printing points, not loyalty points. (d) help.microworks.com serves a soft-200 catch-all at about 16.75 KB for unknown paths; every citation here was discriminated by byte length and md5. RE-OPEN this cell if Microworks ever publishes a modern manual. https://help.microworks.com/webhelp/Buyer_s_Club_Setup.htm · retrieved 2026-09-15 adversarially verified
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
Precedence controls exist inside one coupon: "Ask Discount — This will override all other discounts set up on the coupon", Allow Multiple decides whether Set Price hits every qualifying item or only one, Apply % Off restricts the order-level percentage "only to this item, rather than all items on the order", and requirement lines are evaluated independently ("if you set up a requirement line of one pizza and then a second requirement line of one pizza, the system will not check for two pizzas"). Shortfall: nothing documents interaction between two different coupons on one order — no exclusive-versus-combinable flag and no order-of-application rule across coupons. https://help.microworks.com/webhelp/Advertised_Coupons.htm · retrieved 2026-08-02
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Offers are issued to a rule-defined audience, not broadcast. Comeback Coupons "can be created to target specific customers based on the frequency, or infrequency, of their ordering habits", keyed on "Days Since Last Order" with "Days Before Expiration" and a percentage off. Buyer's Club issues coupons on a points threshold derived from ticket totals, and the Marketing Module "uses your system order history data to allow you to target specific customers to print or export". Caveat carried: issuance is by printed coupon on the customer's next receipt or by direct mail, not by email or SMS. https://help.microworks.com/webhelp/Comeback_Coupons.htm · retrieved 2026-08-02
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
Recency is computed by the system without the operator writing a query — Comeback Coupons evaluate "Days Since Last Order" per customer at order time, and the published report catalogue carries "Welcome Back" and "Late-New Customers" lists. Shortfall: no frequency or monetary scoring, no named lifecycle segments (new / regular / at-risk / VIP), and the Marketing Module's own targeting is geographic (Sectors, Carrier Routes, Area Type, Exclusions) rather than value-based. https://help.microworks.com/webhelp/Comeback_Coupons.htm · retrieved 2026-08-02
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
Always-on triggered automations, configured once and left running. First-visit thank-you: "if you wish to create a coupon for customers who have never ordered, this value would be set to zero. As such, the Comeback Coupon will print out with their first order." Lapsed win-back: any positive Days Since Last Order value. Expiry is computed automatically — "Based on the date when the coupon is issued, the system will read this value and calculate the appropriate expiration date." Caveats: no birthday trigger is documented, and delivery is limited to thermal receipt printing. https://help.microworks.com/webhelp/Comeback_Coupons.htm · retrieved 2026-08-02
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
Grade upgraded from a marketing page to the admin manual, and the shortfall is now precisely nameable. The Marketing Module's documented output is physical direct mail: "The PrISM Marketing Module supports three Avery-compatible label formats - 4144, 5160, and 5335", with Address to Name and "Or Current Resident" handling. The only native email and SMS in the 488-topic help system is Advanced Reporting, which sends *reports* to staff contacts ("send reports and other information via email or even cellular phone text message"). Shortfall: no in-product guest campaign builder for either channel; guest SMS is the transactional Prism Notification Service, and email campaigns are sold as a Microworks in-house marketing services engagement. https://help.microworks.com/webhelp/Labels.htm · retrieved 2026-08-02
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Consent is captured and surfaced, but as a single global email flag on one channel. Web Ordering Reporting (fetched live 2026-09-04, HTTP 200): "Note: In the XML and CSV user lists there is a column named NoEmails. If this column is \"TRUE\", the customer chose not to receive promotional emails from your franchise when they signed up for web ordering. It is important to respect their decision." Shortfall, and it is large: consent is captured only at web-ordering signup - Customer_Interface.htm, "The customer may choose to opt in or out of order notifications and promotional emails on this page", which separates transactional from promotional but carries no timestamp and no source-of-consent record; honoring it is left to the operator's good faith in an exported spreadsheet column rather than enforced by the mailing engine; and the POS/marketing side has no consent object at all - the Update Customer screen's field set is enumerated in full (Update_Customer_Information_Overview.htm: "Name... Email... Tax Exempt... VIP... Black List... Accept Checks... Customer Comment... In-Store Comment", plus the Phone, Address, Additional Information and Customer Credits tabs, whose fields are likewise enumerated) and contains no opt-in, opt-out or suppression field, while the Marketing Module's ten filter tabs (Standard, Customer Activity, Order History, Mailing History, Menu, Other, Sectors, Carrier Routes, Exclusions, Area Type) offer no mailable/suppressed predicate - "Other" enumerates only "VIPs Only... With Fax... With Email". The strings consent, opt-in, opt-out and unsubscribe appear zero times across all 269 topics of the closed manual census, so there is no per-channel consent and no non-STOP revocation handling for SMS or direct mail. https://help.microworks.com/webhelp/Reporting.htm · retrieved 2026-09-04
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
331st: PROPOSED partial/C, FOLLOWING THE 330th MERGE RULING THAT SMSPolicy.htm IS EVIDENCE THE VENDOR HANDLES CARRIER REGISTRATION ITSELF. CLAIM: handles OR explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform. WHAT IS PRESENT (the 'handles' branch): the operator's guest SMS runs through a VENDOR-OPERATED service, not the operator's own messaging account - https://www.microworks.com/home/news-events.htm (HTTP 200, 34,638 bytes) 'Prism Notification Service allows the restaurant to send SMS notifications...', 'If a customer has enabled SMS messaging, the Prism Notification Service will send order status and messaging to the customer, which they can reply to', with the typed notifications 'Create Order Notification - general or curbside / Order Ready Notification - Manual, en route or when an order is cleared from the kitchen monitor / Order Completed Notification / Custom Notification'. And the vendor publishes the carrier-mandated programme artefact under ITS OWN brand, https://microworks.com/SMSPolicy.htm (Last-Modified Thu, 25 Jun 2026 19:38:39 GMT, re-checked today): 'receive SMS messages from Microworks POS Solutions, Inc.', confirmation text 'You have successfully been subscribed to messages from Microworks POS Solutions from this number. Message frequency may vary. Message and Data Rates may apply. Reply HELP for help. Reply STOP to unsubscribe', opt-out and HELP texts. So the registered sender is the vendor, and the operator is never asked to register a brand or campaign. NEW THIS PASS (image read as an image): the vendor's own curbside screenshot https://microworks.com/images/Curbside-Message-order%20received-here.png (49,363 bytes) shows a Prism Notification 'Order Received. When you arrive reply HERE and your vehicle type and we'll be right out with your order' arriving FROM (800)787-2068, which home.html's schema.org ContactPoint names as Microworks' own sales line - the vendor's number, not the restaurant's, is the sender in its own demo. SHORTFALLS, named: (1) nothing states 'A2P', '10DLC', brand or campaign registration (controls from the 330th census: 10dlc 0, a2p 0, campaign registration 0, brand registration 0, tcr 0 over 2,488 files); (2) the policy page does not say it covers Prism Notification Service guest traffic rather than Microworks' own notices; (3) the one sender number shown is a TOLL-FREE number, whose carrier regime is toll-free verification, not 10DLC, so which registration the vendor holds is itself undocumented. Grade C: the policy page plus a press release and a marketing screenshot, with the link between them inferred. Retrieved 2026-09-18. https://microworks.com/SMSPolicy.htm · retrieved 2026-09-18 adversarially verified
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
A Coupon Count report tracks coupon redemption in the Products/Promotion Analysis category. Incremental-sales attribution tied to check totals is not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
The Marketing Module "uses your system order history data to allow you to target specific customers to print or export", so a self-serve guest export exists. Shortfall: the manual documents no export file format, no field list, and no transaction-history export — the export is scoped to a targeted mailing audience — and there is no API, so a full guest-plus-history extract is not evidenced. https://help.microworks.com/webhelp/Marketing_Module_Overview.htm · retrieved 2026-08-02
Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator
guest-loyalty-cdp-event-api
There is no public API or webhook of any kind (extensibility-webhooks-push, no; reporting-public-api, no) — the complete 488-topic help TOC has no API, event, or integration topic. With no outbound event mechanism to build on, no CDP/marketing-platform subscription surface (Olo, Punchh, Bridg, Klaviyo or otherwise) can exist. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
The vendor states the absence directly: the survey feature only prints an invitation on the receipt directing the customer to a survey "you have set up elsewhere; a website, for example," and "there is no actual survey response tracking built into the PrISM system." With no response collection, there is no score-based routing to private recovery or public review sites. https://help.microworks.com/webhelp/Customer_Survey.htm · retrieved 2026-08-04
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
Positive absence by enumeration of the complete marketing/loyalty toolset. The help TOC enumerates every marketing mechanic in the product: Buyer's Club points accrual/redemption (Buyer_s_Club_Setup.htm), Comeback Coupons (recency-triggered win-back), Advertised Coupons, Customer Survey, and the Marketing Module whose output channel is direct-mail Labels. No referral topic exists anywhere in the TOC, and none of the retrieved loyalty topics mention per-guest codes or links, attribution of a referred guest's first order, or two-sided rewards. A native referral mechanic could not be configured without appearing in this enumerated surface. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
Gift Certificates and Buyer's Club points are documented as store-printed receipts and in-database balances only; neither topic, nor any topic in the Marketing Module or Web Ordering books, mentions an Apple Wallet or Google Wallet pass. No wallet-pass topic exists anywhere in the 488-topic manual. https://help.microworks.com/webhelp/Gift_Certificates.htm · retrieved 2026-08-04
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
The primitives a rights request needs exist as ordinary admin functions; the workflow does not. Locate: the Marketing Module's Standard tab searches any field - "Value - Enter the field value on which you'd like to filter. Field - A search based on the Value entered will be performed on the field selected from this drop-down list", with Equals/Contains. Access/export: "Export - You may also export the selected customers into a variety of data formats", alongside "Print - Choose this option to print a report of the selected customers" (the web-ordering side adds an XML/CSV User List export, Reporting.htm). Rectify: "Customer data may also be edited from this section. Simply double-click on the customer record of which you'd like to edit". Erasure: deletion is real and hard-deletable - System_Overview.htm, "When a piece of data is deleted from the PrISM system, be it an employee, a menu item, or anything else, the data is not completely deleted at that time. Instead it is marked for deletion... Reindexing the files completely deletes data that is marked for deletion." Shortfall: no per-guest deletion action is documented on the customer maintenance screen at all - the only documented customer-erasure tools are set-wise and criteria-based (Purge_Customers.htm: "allow you to remove customers that have not ordered since a particular date"; Delete_Duplicates.htm), there is no DSAR request workflow, identity-verification step, response clock or CCPA/CPRA/GDPR topic anywhere in the closed 269-topic manual census, and no statement that deleting a customer propagates to Buyer's Club point balances, Customer Credits, Mailing History or retained order history. https://help.microworks.com/webhelp/Browse_Customers.htm · retrieved 2026-09-04
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
A general-purpose control applies to any gated function including coupon and points overrides: each coupon carries a Password Required flag, and every password use "creates an entry... in the Weekly Exceptions browser," optionally with a recorded video (Setup_Password_Functions.htm). Shortfall: this is generic manager-password gating, not a loyalty-specific control — no redemption velocity limit, no employee-self-redemption flag, and no points-adjustment-specific approval step is documented. https://help.microworks.com/webhelp/Advertised_Coupons.htm · retrieved 2026-08-04
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
The complete offer-targeting mechanism is deterministic and rule-based: Comeback Coupons key on operator-set "Days Since Last Order" thresholds, and Buyer's Club redemption is a flat points threshold. Neither topic, nor any topic in the Marketing Module book, describes any AI/ML-generated recommendation for offer content, audience, or send timing. https://help.microworks.com/webhelp/Comeback_Coupons.htm · retrieved 2026-08-04
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
A genuine native prepaid ledger: "Gift Certificate accounts are very similar in function to Customer Accounts with the exception that these accounts are pre-paid," created during order taking, with a transaction history of "payments, credits, and balance", a Credit Account function and Print Statement, plus an Open Gift Activity Report showing "all gift card activity for the date range you specify... the activation of new certificates as well as redemption of existing certificates" grouped per certificate. Shortfall: the activity report is transactional, not a period-end outstanding-liability total, and balances live in the store-local database with only a nightly StoreNet upload, so brand-wide cross-store redemption is undocumented. https://help.microworks.com/webhelp/Gift_Certificates.htm · retrieved 2026-08-02 adversarially verified
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
"Employee Card or Fingerprint ID" at the POS station; Shift Sheet report in the Employee report family. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
Enumeration of the whole employee-identity surface, framed by the vendor as the anti-buddy-punching feature set: "PrISM for Windows provides multiple security options from which to chose: Traditional keyboard entry - employee passwords are entered through either a conventional keyboard device or on-screen numeric keypads. Employee swipe badges - magnetic swipe badges provide an increased level of system security while aiding in the deterring of 'buddy punching'. Biometric fingerprint readers - fingerprint recognition provides the ultimate level of system security." Three options, closed, no photo or facial verification. Corroborated at the two configuration surfaces: the station Security section offers only "Fingerprint Sensor - This tells the system to use an attached fingerprint sensor for crew ID and password input" (General_Tab_-_Stations_File.htm, same text in Advanced_Tab_-_Station_Setup.htm), and the time clock's Advanced menu offers exactly two enrolment options, "Use Bank" and "Enroll Fingerprints" (Ordering_Module_Time_Clock.htm). PrISM does have a camera feature and it is not this one: Setup_Password_Functions.htm's Camera checkbox "tells the system to record and save a video when the function in question is accessed" for review in the Weekly Exceptions Report - a per-password-function surveillance video, not a photo attached to a timecard entry, and clocking in is not password-gated in the documented flow ("This is done simply by pressing the Clock In button"). Words photo/facial/webcam appear nowhere in a punch context across the closed 269-topic manual census, and the ten live www product pages name only fingerprint readers - "photo" occurs there solely in the "Menu Photography" navigation item. https://help.microworks.com/webhelp/Advanced_Features.htm · retrieved 2026-09-04
Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.
labor-geofenced-mobile-punch
The complete time-clock documentation is a fixed-terminal punch (Clock In/Out, Start/Stop Break) tied to Employee Card or fingerprint ID at a POS station. No mobile app, GPS, or geofence validation is documented anywhere in the manual, and the Employee Scheduling Module's 12-topic book has no mobile-punch topic either. https://help.microworks.com/webhelp/Ordering_Module_Time_Clock.htm · retrieved 2026-08-04
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
Punching is a local act on an in-store system, and the manual documents an internet-free configuration as a shipped option: "Dial-up or no Internet access: If you have a dial-up connection or no connection to the internet you will receive an 8-Port Switch with your system. This is used for an internal network only." The time clock is a module of the store-resident Ordering Module and the database is the in-store file server, so a WAN outage cannot reach a punch. SHORTFALL, which is what keeps this off `yes`: the manual never states the punch behaviour under the outage that actually matters for an on-premise system - loss of the LAN or the file server - and describes no local queue, no reconnect reconciliation and no duplicate-entry handling. What it does say cuts the other way about station autonomy: "The file server, or main computer (MANAGER1), must always be the first machine turned on" and "If the file server or any print-serving station is turned off during full system operation, you may have to re-start (or re-boot) each workstation" (System_Statup_Procedures.htm). Same shape as the hungerrush partial. https://help.microworks.com/webhelp/Networking_The_Workstations.htm · retrieved 2026-09-04
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Permissions are per discrete action, not fixed tiers. "The Password Functions section controls which features of the PrISM system require passwords and which don't. The Password Functions browser is divided into various tabs representing different areas of the system", each function carrying Required / Camera / Log checkboxes. Password Groups are the roles: "Password Groups are essentially tiers of access; each group represents a set of permissions which is then assigned to one or more employees", built by moving individual functions into an Included list, with a Super User override checkbox. Individual menu items and coupons carry their own Password Protect / Password Required flags. Caveat: per-location scoping of a group is not documented — the password files are store-local. https://help.microworks.com/webhelp/Setup_Password_Functions.htm · retrieved 2026-08-02
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
Every password-gated action is attributed and logged: "Every time a password is used, an entry is created in the Weekly Exceptions browser. If 'Log' is checked a second entry is created with additional information about the event." A per-function Camera option "tells the system to record and save a video when the function in question is accessed", viewable from the Weekly Exceptions Report. Discounts additionally capture a free-text Force Explanation onto the same report. Caveat: the manual makes no immutability or tamper-evidence claim about the exceptions log. https://help.microworks.com/webhelp/Setup_Password_Functions.htm · retrieved 2026-08-02
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Re-tested by the verification pass because this cell had been scored three ways. "The PrISM Employee Scheduling Module provides comprehensive creation and modification of employee schedules, as well as access to all employee information defined within the system," with "access to key store volume, shift, and scheduling reports" and the ability to open an existing schedule or create a new one. The help TOC carries the whole book beneath it — Create Schedule, Schedule Management, New Schedule, Shifts, Shift Map, Availability, Forecast Indicators — plus an Availability tab on the employee file. Caveat: no publish-to-staff, shift-swap or mobile notification is documented; the schedule is a back-office artefact. https://help.microworks.com/webhelp/Employee_Scheduling_Overview.htm · retrieved 2026-08-02 adversarially verified
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
Forecast Indicators are built from the operator's own POS data, not a static template: "You may create a Forecast Indicator based on any of the system volume measures. What this allows you to do is view how many employees represented by the Forecast Indicator need to be scheduled based on the average volume forecast", with a Numerator/Operator/Denominator formula over system volume measures. Shortfall: the output is a headcount from an operator-defined ratio against an "average volume forecast" whose derivation the manual never documents; there is no daypart-level recommendation and no labour-hour or labour-cost target. https://help.microworks.com/webhelp/Forecast_Indicators.htm · retrieved 2026-08-02
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
Labour as a percentage of sales is a real, shipped figure: the Daily Paperwork report's DAILY RECAP block carries the column header line "Food Cost % Labor Cost % Fixed Labor % Variable Labor % Mileage % Food Waste % Food Waste $" over the day's values (47.19 / 23.19 / 5.88 / 17.30 ...), and the goal side is configurable - "Labor Percentage Goal - This field is used to calculate the Labor Gap on the Weekly Sales Recap report" (Payroll_Tab.htm). SHORTFALL: it is a paperwork figure, not an in-service manager view. The screen behind it is described only as "The Daily Paperwork screen automatically calculates all sales, labor, and tender transactions" and its Totals tab as "a summary of the day's various transactions and overall labor figures" (Daily_Paperwork_Screen.htm) - no percentage is stated to be on the screen, no refresh cadence is documented, and the percentages are attested on the printed daily report and on the Weekly Sales Recap. The only percentage-of-volume display the manual does locate on a screen is projected, not actual: the schedule builder's "Labor Section (Variable/Fixed/Total) - this is the projected amount being paid to all employees scheduled to work on the selected day ... also displayed as a relative percentage of the projected volume sales for the day" (Create_Schedule_-_Shifts.htm). Matches the ury partial (labour percent exists as a daily document, not a live service view). https://www.microworks.com/files/Reporting/P&L/DAILYPAPERWORK.PDF · retrieved 2026-09-04
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
The complete overtime configuration — Level 1/2 Overtime Rate, and Hours Before OT Level 1/2 Applies for Daily, Weekly, and Period periods — is a rate multiplier applied retroactively once a threshold is crossed, calculated at payroll/reporting time. No warning or block at clock-in, and no approaching-threshold notice, is documented anywhere in the manual. https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-08-04
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
The time clock's break handling is documented in full and is a manual punch: "The Break function is used when an employee needs to take an unpaid break during their shift", with Start Break / Stop Break buttons and nothing else. The labour-law configuration surface (Payroll_Tab.htm) enumerates its four parts — overtime rate multipliers, daily/weekly hours-before-OT thresholds, a labor percentage goal, and pay-rate display toggles — so state-tunable rules exist for overtime only. No per-state or per-jurisdiction break rule configuration, no break attestation prompt, and no missed-break premium-pay flag appears in either topic or anywhere else in the complete help TOC. https://help.microworks.com/webhelp/Ordering_Module_Time_Clock.htm · retrieved 2026-08-04
Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.
labor-fair-workweek-support
The complete 12-topic Employee Scheduling Module book (Overview, Reports, Updates, Create Schedule, Schedule Management, New Schedule, Shifts, Shift Map, Availability, Forecast Indicators, Update Jobs, Employee Information) has no advance-notice deadline, schedule-change tracking, or predictability-pay calculation. The schedule is described (labor-native-scheduling, existing cell) as a back-office artefact with no publish-to-staff mechanism to even measure notice against. https://help.microworks.com/webhelp/Employee_Scheduling_Overview.htm · retrieved 2026-08-04
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
The employee file's Details tab — the only place ancillary employee data such as a birth date could live — states in the vendor's own words: "All fields on this tab are optional and are not used elsewhere in the system", which forecloses any age-driven enforcement. The Availability tab is manually entered Available/Preferred/Not Available time frames per day with no age dimension; the complete Employee Scheduling Module book (Create Schedule, Shifts, Shift Map, Availability, Forecast Indicators per whtdata3.xml) and the time clock documentation contain no minor-labor, age-based hours, prohibited-window, or school-day rule at either scheduling or clock-in. https://help.microworks.com/webhelp/Edit_Employee_File_-_Employee_Detail_Tab.htm · retrieved 2026-08-04
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
Same finding as payments-tip-pooling: the complete Payroll tab field set has no tip-pool, tip-out, or distribution-rule field, and no such topic exists anywhere else in the manual. The only tip report is a per-server Server Tip listing, not an allocation engine. https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-08-04
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
A Server Tip report ships in the Cash Control catalog. Pool contribution and distribution detail per shift are not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
The Payroll tab's complete field set has no cash-vs-charged-tip separation and no Treasury tipped-occupation code field. The only external payroll/accounting interface documented anywhere is the QuickBooks Pro 2002 desktop connector (QuickBooks_Interface_Module.htm), which carries no tip-specific W-2 coding. https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-08-04
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
The vendor's phrase is maximal and its enumeration is not: "The PrISM system has a fully integrated payroll system. This section will allow you to define payroll parameters specific to your practices and local/state laws. This section is divided into four parts:" - and the four parts are Rates (Level 1/Level 2 overtime multipliers), Labor Goal, Pay Rate Display and the Daily/Weekly/Period overtime thresholds and pay-cycle selection. No tax table, no filing, no disbursement, no bank account, no EIN. The documented output is a report, not a pay run: "This selection provides a payroll report for all employees who have clocked into the system during the last pay period" (Weekly_Paperwork_Overview.htm), and a job class can be flagged "Daily Contractor" to be excluded from it (Job_Setup.htm). The employee record concedes where payroll actually happens: "Payroll Number - This field is not required. This field may be used as a cross reference with a separate payroll system if applicable" (Edit_Employee_File_-_Employee_Tab.htm). Payroll appears across the closed 269-topic manual census only as setup parameters and printed reports - including in the Employee Scheduling Module book recovered on 2026-09-04, whose ESM_Employee_Information.htm repeats the same concession ("Payroll Number ... can be used as a cross reference with a separate payroll system if applicable") - and the live www site lists payroll only as a report ("Payroll Report"; "Payroll, food cost and labor cost analysis"); the same export/hand-off fact pattern was scored `no` for speedline, xenial, oracle-micros-simphony and thrive. https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-09-04
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
"Intuit QuickBooks Pro Interface" is the only named integration. A second major payroll provider is not documented. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
The complete Employee Scheduling Module book (12 topics, listed under labor-fair-workweek-support) has no shift-swap request, open-shift claim, or manager-approval-workflow topic. The module is described as a back-office scheduling tool with no employee self-service surface documented. https://help.microworks.com/webhelp/Employee_Scheduling_Overview.htm · retrieved 2026-08-04
Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.
labor-digital-onboarding-i9
The Employee Detail tab — the only place ancillary hire paperwork could live — states "all fields on this tab are optional and are not used elsewhere in the system." No W-4, I-9, or E-Verify topic exists anywhere in the Employee Scheduling Module book or the core Employee Information section of the manual. https://help.microworks.com/webhelp/Edit_Employee_File_-_Employee_Detail_Tab.htm · retrieved 2026-08-04
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
Per-employee sales metrics exist: Server Report carries "all of the server's totals for the day" by server number, under an Employee Reports book. Shortfall: average check per server, tip percentage, item mix and sales-per-labour-hour appear only as report names on the vendor marketing page (grade C) and are defined nowhere in the administrator manual; no productivity ratio against hours worked is documented anywhere in the help system. https://help.microworks.com/webhelp/Server_Report.htm · retrieved 2026-08-02 adversarially verified
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
Multi-level BOM is documented explicitly. Assembly Items "are those inventory items which are created by combining other inventory items, such as sauce or dough", and are themselves inventory items ("Because of this, the Stock Price is automatically calculated based on the portions of each inventory item that is used to assemble this item"), so a recipe containing Marinara Sauce inherits its component cost — the manual makes exactly that point: "setting up a menu item that contains Marinara Sauce no longer requires figuring out what inventory items are contained in that very small portion of sauce." The Recipe Cost Manager then rolls ingredients and modifiers to a Recipe Cost and Cost %. Caveat: costs are described as auto-calculated from Inventory Master portion price, but no statement guarantees an automatic re-run when an ingredient cost changes. https://help.microworks.com/webhelp/Assembly_Item_Setup.htm · retrieved 2026-08-02
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
A full three-tier conversion chain with explicit factors is documented: Stocking Unit (cases, bags) → "Stocking Mult — the number of Counting Units in the Stocking Unit" → Counting Unit ("the unit in which you count the item when doing a physical inventory") → "Portion Mult — the number of portioned units per Counting Unit" (32oz can portioned by ounce = 32) → Portion Unit, with Price and Portion Price auto-derived at each step. Alternate vendors may carry their own units and portions. Shortfall: no yield or waste percentage is applied to the raw-to-usable conversion anywhere in the item file. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-02
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
The Daily Inventory screen is a theoretical-vs-actual variance sheet per item per count period: it "details the beginning inventory amount for each item, any delivery amount for the day as entered by the Add Invoice function, the ending inventory amount, the ideal ending amount (assuming Ideal Food Cost has been properly set up), and any variance from Ideal." The currency expression is the "Food Gap number on the Weekly Sales Recap", which the manual says goes to zero if the physical count is skipped. Theoretical usage comes from the Recipe Cost Manager BOM; actual comes from counts plus invoiced deliveries. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-02
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
Recipe_Cost_Setup.htm defines the bill-of-materials that theoretical usage is computed from, but the actual on-hand decrement happens through the Daily Inventory screen's periodic reconciliation against Ideal Food Cost (Daily_Inventory_Screen.htm), not as each order fires. No topic anywhere states that a sale decrements on-hand inventory in real time; the documented model is theoretical-vs-actual variance at count-period boundaries. https://help.microworks.com/webhelp/Recipe_Cost_Setup.htm · retrieved 2026-08-04
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Inventory_Master_u.htm's Reorder Level field only triggers a purchase-order suggestion ("the level at which you would like the system to prompt you to order more"); it has no link to menu-item availability. The menu item Advanced and Web tabs (fully enumerated) have no inventory-driven availability field, and Ordering_Advanced_Options.htm's Sold Out Item is a manual toggle, not inventory-threshold-triggered. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-04
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
Recurring cycle counts are configured per item — "Inv. Cycle — This is the frequency of when a physical inventory is taken for this item. Your choices are D - Daily, W - Weekly, M - Monthly, B - Biweekly, or N - None" — and a full physical count is entered on the Daily Inventory screen, with Inventory Locations (Freezer, Dry Storage) to sort the count sheet. Two shortfalls, one of them serious: no ad-hoc spot-count mode for an arbitrary subset is documented, and counts are overwritable rather than kept as separate history — "If you enter a manual ending inventory count and you are using the Ideal Food Cost feature, do not go back into the Daily Inventory Screen after entering your count. The system will automatically recalculate the ending inventory values based on Ideal Food Cost, and the manual figures you had entered will be replaced." https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-02
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
The complete physical-counting documentation — Daily_Inventory_Screen.htm's Count column entry and Inventory_Master_u.htm's Inv. Cycle field — describes desktop-terminal entry only. No mobile app, tablet, barcode, or QR scanning device is named anywhere in the two topics that constitute the entire inventory-counting surface of the 488-topic manual. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-04
Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator
inventory-vendor-catalogs-edi
The manual enumerates the alternative and it is entirely manual. Vendors are free-form per-item fields — "Item Number — The vendor's item number. If you do not purchase this item from a specific vendor, you may assign an arbitrary number", plus a Vendors/Stocking table where "you may specify alternate vendors... alternate means of pricing, stocking units, counting units, and portion amounts" typed in by hand. Receiving is manual invoice entry via Add/Modify Invoice, and purchase orders are printed forms ("allows you to print out a form with the quantities you wish to order"). No distributor integration, catalogue import or electronic PO/invoice transmission topic exists anywhere in the 488-topic help system. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-02
Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator
inventory-invoice-ocr
The complete invoice-entry mechanism is manual: "Add Invoice" records delivery amounts by hand, and the "Load PO" button imports items from an existing PrISM-generated purchase order — not from a photographed, PDF, or emailed supplier invoice. No OCR, image-ingestion, or email-parsing topic exists anywhere in the manual. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-04
Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator
inventory-price-change-alerts
Positive absence by enumeration, not silence. The receiving workflow is documented end to end and puts price-change detection on the human: on the Add/Modify Invoice line, "Cost: This is the cost per stocking unit as you have defined in the Inventory Master. The cost will automatically be populated when the item has been specified. You can override the price if it has changed by clicking in the cost field and entering the correct price." The received price is stored (the printed Invoice Detail carries Qty / Item ID / Description / Cost / Ext. per line - https://www.microworks.com/files/Reporting/Inventory/WEEKLYINVOICEDETAIL.PDF), so the history exists, but nothing compares it to a prior or contracted price. Measured across the closed 269-topic manual census on 2026-09-04: zero topics contain the word "threshold", and the only three occurrences of "alert" are a kitchen-ticket future time (Order_Types), driver-routing/web-order "alert sounds" (Sounds_Tab) and a Buyer's Club coupon prompt (Buyer_s_Club_Setup). There is no configurable price-variance alert. https://help.microworks.com/webhelp/Add_Invoice_Delivery.htm · retrieved 2026-09-04
Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator
inventory-par-auto-suggest
Both halves are documented. Static par per item: "Reorder Level — This is the level at which you would like the system to prompt you to order more of the item. Enter this value as Stocking Units", with a Reorder Qty and a Re-order Level report. Forecast-driven mode: "The Purchase Orders function will prompt the system to suggest reorder quantities based on a future theoretical sales figure and allows you to print out a form with the quantities you wish to order", and the resulting PO loads into an invoice with the 'load PO' button on receipt. Caveat: par is per item in a store-local file — there is no above-store par management. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-02
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Same finding as kitchen-waste-logging: the complete inventory documentation (Daily_Inventory_Screen.htm, Inventory_Master_u.htm) has no waste/spoilage logging workflow, no reason-code field, and no waste-cost-separate-from-variance report. Variance from Ideal is a single aggregate figure, not itemized waste entries. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-04
Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.
inventory-transfers
Inventory_Master_u.htm's Location field only attaches an item to a single Inventory Location (e.g., Freezer, Dry Storage) within one store. inventory-commissary (existing cell) already established that only the receiving store's view is documented, with "no inter-location transfer document." No transfer, in-transit, or approval-state topic exists anywhere in the manual. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-04
Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.
inventory-commissary
The purchasing side is explicitly built for it: the Purchase Orders function "was designed specifically for franchise-type operations that use a central commissary for inventory ordering/delivery", and in-store production of prep items is handled by Assembly Items, where counting the finished batch "will also take the appropriate amounts out of your inventory for the items used to create the batch". Shortfall: only the receiving store's view is documented — there is no commissary-side production run, no inter-location transfer document, and no computed transfer cost or inter-company billing. https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm · retrieved 2026-08-02
Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.
inventory-lot-traceability
The complete inventory item field set (Item Number, Stock Price, Stocking/Counting/Portion Units and Multipliers, Reorder Level/Qty, Key Ingredient, Assembly Item, Batch Description) has no lot or batch number field for received or produced stock — "Batch Description" is a free-text label for an Assembly Item recipe, not a traceable lot ID. No recall-trace topic exists anywhere in the manual. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-04
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
The complete inventory item field set has no expiration or use-by date field and no expiring-soon report or alert. Inv. Cycle governs count frequency (D/W/M/B/N), not shelf life. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-04
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
The unit-conversion chain (Stocking Unit → Counting Unit → Portion Unit, with Stocking Mult and Portion Mult) is generic and manually typed for any item; no scale/weight integration and no bottle-fraction counting mode is documented, and no bar/beverage-specific counting topic exists anywhere in the manual. https://help.microworks.com/webhelp/Inventory_Master_u.htm · retrieved 2026-08-04
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
Intuit QuickBooks Pro interface is named. Per-category GL account mapping and a second named accounting system are not documented. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
Re-sourced from marketing to the manual by the verification pass. Recipe Cost Manager lets you "specify which inventory items, and in what amounts, are always used to assemble a given menu item. This aides in the providing accurate food cost calculations," with portion units, auto-derived assembly cost, order-type-dependent components and modifier costs. Assembly Item Setup, Inventory Master, Inventory Prices, Inventory Location and the Daily Inventory variance sheet are all first-party PrISM topics; no third-party product is named in the inventory books. https://help.microworks.com/webhelp/Recipe_Cost_Setup.htm · retrieved 2026-08-02 adversarially verified
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
Confirmed, and if anything the partial is generous-leaning-correct: Storenet is browser/mobile accessible but the documented mechanism is a nightly full-database upload per store, so above-store figures are next-day. There is no evidence of intraday polling. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01 adversarially verified
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
Daily Paperwork, Simple Sales, and the Cash Control family (Weekly/Monthly Cash, Cash Drop, Settle, System Transaction) constitute a daily close-out set. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
The Mix Detail report is modifier-level by default and the manual proves it by documenting the switch that turns it off: "Hide Modifiers — This hides all modifiers that were added to items, but still displays a separate line for each menu item", alongside "Hide all detail" for group totals only. It is daypart-filterable ("Start Time / End Time — The report will display items sold between the start time and the end time"), groupable "by menu group, by primary or secondary product code", sortable by quantity or dollar value, with an item filter for food / beverage / other and a Show Zero Values option. Revenue-centre scoping comes from the shared Report Filter / Cost Center selector. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-02
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
The Exceptions report carries every element the claim asks for: "Exception Type — You may choose to show all exceptions that took place during the set time frame, to only display Reduced/Canceled/Bad orders, or to only display exceptions other than Reduced/Canceled/Bad orders", filtered by Start Time / End Time and by "all employees, or only one specific employee", with Show Detail adding "any additional information about events". Reason codes arrive via the coupon Force Explanation option, whose free text "can be viewed on the Weekly Exceptions Report", and approver attribution via the password log entry written on every gated action. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-02
Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.
reporting-cash-over-short
Cash Control family: Weekly Cash, Monthly Cash, Cash Drop, Settle, System Transaction — plus "Detailed Cash Control options for Servers and Tills" on the POS page. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
"Food & labor cost analysis" plus employee shift/schedule reports. Sales-per-labor-hour and labor-percent-by-hour slicing are not documented. https://www.microworks.com/products/pizza-pos.htm · retrieved 2026-08-01
Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator
reporting-server-scorecards
Server Report is "a summary of a server's activity for the day", "generated according to server number", with an optional "one-line summary of each order assigned to the server" and the server's totals. Shortfall: that is a per-server day sheet run one server at a time — no cross-server ranking, league table, benchmark or trend. The scorecard metrics previously cited (Average Ticket, Server Ticket, Server Mix, Server Tip) are report titles on the marketing reporting page, which is grade C, and are defined nowhere in the manual. https://help.microworks.com/webhelp/Server_Report.htm · retrieved 2026-08-02 adversarially verified
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
Profit Center Ledger supports revenue/order-type separation. Marketplace-commission-net margin per third-party channel is not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator
reporting-multiloc-drilldown
Storenet reports by individual store or across all stores, in spreadsheet format. Drill-down from group total to individual transaction is not documented. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator
reporting-custom-report-builder
A saved, operator-built report definition exists: "Custom reports, also referred to as simple reports, allow you to custom-tailor reports that show only the information you want", where each candidate Field has a checkbox controlling whether "this value will appear on the report", plus Column and Sort placement, a one- or two-column layout, an SMS format, and a saved Report Name; Report Filter and Cost Center can then be applied when it is scheduled. Shortfall: it selects and arranges fields from a fixed list into a summary sheet — there is no choice of dimension or measure, no grouping or aggregation control, no filter expression, and it cannot reach the transaction detail the canned reports expose. https://help.microworks.com/webhelp/Setup_Custom_Reports.htm · retrieved 2026-08-02
Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.
reporting-scheduled-delivery
"The Scheduled Reports section is used to configure reports that are emailed out, saved as a new file, or printed out automatically, as well as when these events take place." Cadence: "End of Day", "Specific Time", or "Interval" with a Start time and Repeat Minutes ("if the Start time is 12:00 PM and the Repeat Minutes is 60, the report will activate at 12 PM, then again at 1 PM"). Recipient list: "All email addresses you wish to send reports to must be set up in the Contacts section." Destinations: Save Report, Save Report As a chosen folder, Email Report To, or Print Report To a named printer; formats PDF or HTML; custom reports may be formatted as an SMS to a cellular phone. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-02
Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator
reporting-raw-warehouse-export
The automated-export destinations are enumerated in full and none is a customer-controlled data destination: "Export Type... Save Report — This will save the report as a new file in the default reports folder. On most systems, this default folder is located at C:\VPSM\REPORTS", Save Report As a chosen local path, Email Report To, or Print Report To. The only formats offered are "a PDF file (opens in Adobe Acrobat Reader), or HTML". There is no CSV, no SQL or flat-file extract, no SFTP/S3/warehouse target, and no API in the help system to carry one. The operator does physically possess the store-local database, but that is file access, not a documented export. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-02
Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator
reporting-public-api
Citation replaced. The previous evidence was microworks.com/sitemap.xml, which the verification pass correctly ruled unsafe because it does not cover the documentation host. The replacement is the documentation host's own table of contents: the complete PrISM WebHelp TOC enumerates every topic in the system across eleven books (Getting Started, Manager, Ordering, Marketing, Makeline Monitor, Employee Scheduling, Integrated Credit Card Authorization, QuickBooks Integration, Software Installation, Advanced Features, Help & Troubleshooting) and contains no API, developer, integration, webhook or export topic. The only documented outbound interface is a desktop QuickBooks file interface. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-02
Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator
reporting-webhooks
Consistent with the already-established extensibility-webhooks-push (no) on the same citation: the complete help TOC across eleven books contains no webhook, event, or callback topic. The only outbound surfaces are Scheduled_Reports.htm (PDF/HTML files to folder/email/printer) and the QuickBooks desktop file interface. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
There is no public API at all (reporting-public-api, no; api_posture.public_api: none), so there is nothing to be included or upcharged. The claim's premise — API and raw-data access, at some price point — does not exist in the documented product. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
CLAIM: core reporting beyond basic sales summaries - labour versus sales, PMIX, comps/voids audit, multi-location comparison - is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. MET on three of the four named reports, because Microworks sells no plan tiers at all: PrISM is quote-priced, on-premise and module-licensed, and the store-side system ships with one undifferentiated report catalogue. (1) https://www.microworks.com/products/reporting.htm (retrieved 2026-09-15, Copyright 2025) publishes roughly 40 reports in one list with no tier labels and no upgrade prompts, grouped as Profit and Loss Reporting (Daily Sales Recap, Weekly Key Indicators, Monthly Sales Recap, Monthly Key Indicators, Profit Centers, Simple Sales Summary, Income Statement, Payroll Report), Inventory and Food Cost Control, Product Mix and Promotion Analysis (Product Mix, Coupons / Promotions Mix, Menu Detail, Modifier Detail, Menu Setup Detail), Cash Control Reporting, Transaction Detail Reporting (Daily Sales Journal, Daily Sales Detail, System Exception Report), Employee Reporting and Customer / Marketing; 39 of them are downloadable as specimen PDFs under /files/Reporting/. Labour-versus-sales, PMIX and the comps/voids audit analogue are all in that one catalogue. (2) Scheduling and delivery are in the base manager module, not an add-on: https://help.microworks.com/webhelp/System_Overview.htm (live, 21,062 bytes, retrieved 2026-09-15) lists Advanced Reporting as a manager-station System-menu function, and https://help.microworks.com/webhelp/Advanced_Reporting_Overview.htm (live, 3,466 bytes) reads 'The PrISM system can be configured to send reports and other information via email or even cellular phone text message ... These reports can be scheduled to send at specific times or on certain system events, such as End of Day.' SHORTFALLS. (1) Multi-location comparison is not on the store-side licence. It requires the separately sold StoreNet Enterprise Management server, which the vendor's own overview sheet files under add-ons: PrISM_Overview.pdf (https://www.microworks.com/files/PrISM_Overview.pdf, retrieved 2026-09-15) lists 'Web Hosted Enterprise Management' under 'Integrated Options', alongside the QuickBooks interface and surveillance. https://www.microworks.com/products/enterprise-management.htm (retrieved 2026-09-15, Copyright 2025) then concedes the split in one sentence: 'Storenet's reporting tools allow any of the complete selection of reports available at each store location to be available when and where you need them. Multi-unit sales reports are also available with spreadsheet style rows for each location that can provide full corporate or regional sales totals.' The complete selection already exists at each store; the multi-unit comparison is the StoreNet capability. (2) No dollar figures and no tier ladder are published anywhere, so it cannot be shown that the base licence is an 'entry-level paid plan' in any pricing sense - only that there is one licence family and one report catalogue, with multi-unit rollup sold separately. https://www.microworks.com/quote.htm (retrieved 2026-09-15) publishes no prices, no tiers and no module checklist, and currently reads 'We are experiencing technical difficulties with our online quote form, please call or email us for a quote!' CORPUS AND AGE: the 16-page current marketing link graph crawled from nav and footer hrefs (absences bound to that graph, not to the 58-URL sitemap, which is a strict subset), plus PrISM_Overview.pdf, plus the live help library (currently linked, authored 2009/2010). CONTROLS, tokenised, positive control Microworks fired on every one of the 16 pages: tier 0 hits and plan 0 hits across all 16 current marketing pages including the quote page - there is no published tier ladder anywhere to gate against. POISON. (a) void 0 hits and comp 0 hits in the help library, which reads as though PrISM has no comps/voids audit; it does not use that vocabulary. The same function is the 'System Exception Report' on the reporting page, the Activity List topic, and System_Overview.htm's 'Pre-define Explanations - The PrISM system can be set to require that the order taker enter an explanation for certain events, such as cancelling an order or the use of a coupon.' A zero on void here would be a false negative about the vendor's own vocabulary. (b) 'Advanced Order List' in that catalogue sits under Inventory and Food Cost Control and is a purchase-order/reorder report, not a customer advance-order report. (c) Every product page, not just the enterprise page, carries a 'Get a Quote or Call' button, so a separate quote CTA on its own proves nothing about SKU separation; the load-bearing evidence is the 'Integrated Options' listing in PrISM_Overview.pdf. https://www.microworks.com/products/reporting.htm · retrieved 2026-09-15 adversarially verified
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
CLAIM: documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. Microworks documents no window at all, and what it does document is the opposite of a guarantee: an operator-run, support-supervised truncation of older data on store-local storage. (1) https://help.microworks.com/webhelp/System_Overview.htm (live, HTTP 200, 21,062 bytes, md5 daeca130, retrieved 2026-09-15, HTTP Last-Modified 2010-01-25): 'Trim and Archive - Trimming data removes older data from the PrISM system. It is highly recommended that you contact Microworks Tech Support before attempting to use this feature, as improper use can cause system failure.' That is the entire published statement about historical data lifetime: no months, no years, no floor, no ceiling, no archive-retrieval path. The truncation is not silent - it is documented and operator-initiated - but no retained window is stated. (2) The data lives on store-local storage, so lifetime is a function of the store's disk and its own trimming practice; the off-site copy is described only as a nightly backup, System_Overview.htm: 'Force Data Upload - This tells the system to push a copy of your store's data to the StoreNet Server for record-keeping purposes. This process takes place during End of Day', and https://www.microworks.com/products/enterprise-management.htm (retrieved 2026-09-15, Copyright 2025) says only 'each store can upload its entire database nightly providing critical off-site backups'. No term is stated for that copy either. (3) Customer history is separately and permanently destroyable on an operator-supplied period: https://help.microworks.com/webhelp/Purge_Customers.htm (live, 1,293 bytes, md5 2d0c0c5e, retrieved 2026-09-15) - 'Selecting Purge Customers will allow you to remove customers that have not ordered since a particular date ... useful for removing the customers who have not placed an order after a number of months or years. It is suggested that a full system backup is done prior to running this function.' The permanence is stated only in the 2010 capture of the parent topic, https://web.archive.org/web/20101230112207/http://microworks.com/webhelp/Marketing_Module_Overview.htm (captured 2010-12-30): 'Once performed, the purge is permanent'. I verified the corpus change: the live Marketing_Module_Overview.htm has been rewritten down to a two-sentence stub and no longer carries that passage, so the permanence sentence is cited to Wayback and the surviving mechanism to the live child topic. (4) Every reporting topic read - Scheduled_Reports.htm, Setup_Custom_Reports.htm, Batched_Reports.htm, Reporting.htm, Daily_Inventory_Screen.htm - takes an arbitrary Start Date / End Date with no stated limit and no stated minimum. CORPUS AND AGE: bound to the publisher's own RoboHelp TOC (428 rows, 205 distinct topic titles) plus the 16-page current marketing link graph plus PrISM_Overview.pdf plus the privacy and SMS policy pages. Microworks publishes no other help centre, KB, changelog or API reference. The library is the vendor's currently linked 'Online Help' but was authored 2009/2010; the marketing corpus is 2025. CONTROLS, tokenised, positive control PriSM 300 hits / 113 files and Microworks firing on all 16 marketing pages: retention 0 hits in the entire help library, archive 1 hit and trim 1 hit, both the Trim and Archive line. POISON. (a) The single largest trap on this cell is that the vendor DOES publish a section headed 'Data Retention' - https://www.microworks.com/PrivacyPolicy.htm, 'Microworks stores personal data for as long as necessary to facilitate the functions outlined above. Transaction and payment data is sent directly to the store and not retained on Microworks servers, while location data is retained for 30 days.' Read in isolation that looks like a POS transaction retention policy. It is not: the whole section is scoped to the RapidRun driver app, which is what collects the location and payment data it describes. Citing it for POS reporting retention would be a false attribution. (b) On many vendors 'retention' means employee retention; here the word is simply absent from the technical library. (c) purge reads 0 over the crawled live sample but 7 in the Wayback unpack, and Purge_Customers.htm is nonetheless live at 200 and 1,293 bytes - proof that any live-crawl file set is a sample and not a census, which is why this verdict leans on the positive Trim-and-Archive statement and never on a live-corpus zero. (d) help.microworks.com serves a soft-200 catch-all at about 16.75 KB; all citations discriminated by length and md5. SCOPE: this says the vendor does not document a queryable window of at least 24 months and does document discretionary truncation. It is not a claim that PrISM discards data at any particular age. https://help.microworks.com/webhelp/System_Overview.htm · retrieved 2026-09-15 adversarially verified
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
Scheduled_Reports.htm documents all three report-trigger mechanisms in full: End of Day, Specific Time, and Interval (Start time plus Repeat Minutes). All three are time-based; none is conditioned on a metric threshold or a deviation from historical pattern. No anomaly, alert, or push-notification topic exists anywhere else in the manual. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-04
Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.
reporting-nl-query
The complete 488-topic help TOC has no AI, natural-language, chat, or assistant topic anywhere; the only report-building surfaces are canned reports and the field-selection Custom Report builder (Setup_Custom_Reports.htm), which requires manually checking fixed fields, not asking a question in plain language. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator
reporting-guest-cohorts
Score stands but the underlying evidence is misread in both this cell and guest-loyalty-targeted-offers. The report is "No/Bad Check List" — an NSF/bad-check list — not a "No Checks" lapsed-customer report. The lapsed/win-back function is carried by "Welcome Back" and "Late-New Customers" alone. Correct the note before anyone builds a claim on it. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01 adversarially verified
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
Forecast Indicators — the only forecast mechanism documented anywhere — computes a labour-to-volume ratio for staffing purposes ("how many employees... need to be scheduled based on the average volume forecast"), not a forward sales figure at daypart/hourly granularity exposed in the reporting UI. No separate sales-forecast topic exists in the manual. https://help.microworks.com/webhelp/Forecast_Indicators.htm · retrieved 2026-08-04
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
Server Tip report exists. Declared-vs-charged split, pool distribution detail, and jurisdictional tax liability summary are not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
A named third tier exists and is a server-side object, not an ad-hoc filter. StoreNet Log Viewer, Stores selector: "All - This displays all stores in the franchise." / "Group - This allows the user to specify a certain group of stores. The groups available are configured on the StoreNet Server." / "Store - This allows the user to specify one store to view." That is franchise > group > store, three levels, with the group defined centrally. SHORTFALL: the hierarchy is a reporting object only. Group-scoped reporting IS documented - Advanced_Features.htm: "Multi-unit sales reports are also available with spreadsheet style rows for each location with corporate or regional totals", and the live Enterprise Management page markets "Single or Multi-Unit Data - Detailed Reporting by Unit, Unit Groups, or All" - but the permission model is entirely store-local - Password Groups are "tiers of access; each group represents a set of permissions which is then assigned to one or more employees" inside a single store's PrISM install, with no franchise, group or store dimension. The corporate-side data tool works one store at a time (Change Data Directory: "Select - This option sets the PrISM data of the local machine to the most recent dataset retrieved from the highlighted store"). https://help.microworks.com/webhelp/Log_Viewer_Satellite.htm · retrieved 2026-09-04
Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator
multi-location-local-override-policy
Storenet provides "tools to manage differences in pricing, costs, and product selection" per store. Per-field lock/unlock governance enforced at store level is not documented. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
Per-location price differences are managed centrally off one master item. Per-channel and per-daypart price tiers are not documented. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator
multi-location-scheduled-publish
Storenet Satellite's master-data distribution is documented as immediate and irreversible, not scheduled or rollback-able: a franchise master upload "cannot be undone," and stores "download the updated data at the next prescribed interval" — a fixed sync cadence, not a chosen future activation time interpreted per store timezone. No preview, staged-activation, or rollback mechanism is documented anywhere. https://help.microworks.com/webhelp/Upload_Dataset_Satellite.htm · retrieved 2026-08-04
A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator
multi-location-new-store-template
The complete Software Installation book (Overview, Installing PrISM for Windows, USB Software License Keylok, Users Accounts & Passwords, Network Protocols, Computer Name and Workgroup, Installing Workstations and Devices) documents a from-scratch install process, not cloning a saved configuration template. No template, clone, or time-to-open figure is published anywhere on the vendor site or in the manual. https://help.microworks.com/webhelp/whxdata/whtdata5.xml · retrieved 2026-08-04
The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator
multi-location-corp-vs-franchisee-roles
The corporate half is documented and the franchisee-ownership half is contradicted. Corporate can enforce config: "Force Menu Set Update - This option only appears if your system is part of a franchise with a franchise-controlled master menu. Force Menu Set Update tells the system to connect to the corporate StoreNet Server, download the latest menu configured for the store, and install it into the system", with the same mechanism for a "franchise-controlled inventory set". Corporate can see the stores: Log Viewer "allows the user to monitor the StoreNet activities of franchise systems". SHORTFALL 1: what corporate receives is not a sales-scoped view but the store's entire dataset - "Force Data Upload ... tells the system to push a copy of your store's data to the StoreNet Server for record-keeping purposes", and the satellite's "Get All" "downloads the most recent datasets for every store in the franchise", so the franchisee's employee, payroll and banking records travel with it. SHORTFALL 2: the separation is by application (a separate StoreNet Satellite install) rather than by a permission model - PrISM's only documented permission construct is the store-local Password Group, which has no franchisor/franchisee distinction and no tenant boundary. https://help.microworks.com/webhelp/System_Overview.htm · retrieved 2026-09-04
Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator
multi-location-royalty-calculation
A royalty IS calculated from POS sales, which the previous unknown missed. Fixed Percentages: "Royalties - This field changes the value of the Royalties line on the Non-Control Expenses tab of the Projection. The percentage entered here is a percentage of Royalty Sales." and "Royalties are a fee collected by specific franchisors as per a franchise agreement." It reaches actuals too: System Accounts offers a "% of Royalty Sales" account type - "This will cause the account to appear on the Income Statement automatically" - and the printed INCOME STATEMENT sample carries both "Royalty Sales: 50,871.79 100.0%" and a "Royalties" line under Non-Control Expenses (https://www.microworks.com/files/Reporting/P&L/INCOMEACTUAL.PDF, retrieved 2026-09-04). SHORTFALL 1: the ad-fund half exists but does not reach the P&L - the same Fixed Percentages screen carries an "Advertising Fund" percentage, and the topic disclaims it: "This field is used by certain Storenet reports and is not factored into the Income Statement reports. To account for advertising costs, see the Control Expenses tab of Projections." No StoreNet report consuming it is named anywhere in the manual, and no marketing-fee concept exists at all. SHORTFALL 2: no defined schedule - the output is an expense line on the store's own P&L, not a fee due on a cycle. SHORTFALL 3: the royalty basis is not documented as configurable gross-vs-net; "Royalty Sales" is defined nowhere and the manual defers it - "For more information about Royalty Sales, contact Microworks Tech Support." https://help.microworks.com/webhelp/Income_Statement_-_Fixed_Percentages.htm · retrieved 2026-09-04
Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.
multi-location-royalty-collection
Positive absence by enumeration rather than by word-count. Income_Statement_-_Fixed_Percentages.htm enumerates the complete franchise-percentage field set (Coupons - Reg, Cost of Goods Sold, Wages - Employee, Driver Reimbursement, Royalties, Advertising Fund, Customer Frequency, Active Customer, Advertising Return) and defines what the royalty one produces: it "changes the value of the Royalties line on the Non-Control Expenses tab of the Projection" - an expense figure the store computes for itself, mirrored on the printed INCOME STATEMENT (https://www.microworks.com/files/Reporting/P&L/INCOMEACTUAL.PDF, retrieved 2026-09-04). The same topic places collection outside the software: "Royalties are a fee collected by specific franchisors as per a franchise agreement." PrISM holds and moves no funds - the card path terminates at the merchant's own acquirer (Authorizer_Overview.htm) - so there is no account to debit, no franchisee-visible statement of amounts charged and no sweep. Corroborated across the closed 269-topic manual census (2026-09-04): zero whole-word occurrences of ACH, EFT or sweep. https://help.microworks.com/webhelp/Income_Statement_-_Fixed_Percentages.htm · retrieved 2026-09-04
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
Storenet delivers reporting by individual store or across all locations, accessible by browser or mobile, in spreadsheet format. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator
multi-location-normalized-item-rollup
CLAIM: item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. MET: the normalisation half is real and documented first-party. (1) A corporate item master exists and is pushed down, not authored per store: https://help.microworks.com/webhelp/Storenet_Satellite.htm (live, HTTP 200, 1,915 bytes, md5 e2741900, retrieved 2026-09-15) 'StoreNet Satellite allows users to maintain "master" menus and inventory sets for a franchise'; https://help.microworks.com/webhelp/System_Overview.htm (live, 21,062 bytes, retrieved 2026-09-15) 'Force Menu Set Update - This option only appears if your system is part of a franchise with a franchise-controlled master menu. Force Menu Set Update tells the system to connect to the corporate StoreNet Server, download the latest menu configured for the store, and install it into the system', with a matching 'Force Inventory Set Update'. Item identity therefore originates at corporate. (2) https://www.microworks.com/products/enterprise-management.htm (retrieved 2026-09-15, Copyright 2025): 'It creates the ability for a single "Master" menu and inventory to be shared by multiple locations, and provides the tools to sort out differences in price, costs and selection.' (3) A real item-level cross-store data path exists, but only for web orders: https://help.microworks.com/webhelp/Reporting.htm (live, 17,989 bytes, md5 4ee01f94, retrieved 2026-09-15) describes the Web Portal Order List, 'Group - If your franchise has multiple locations, different Groups may be configured, allowing you to see only the orders for one store, or for a certain sub-set of stores', where 'Clicking the order number of an order will display detailed information, including customer information and the items which were ordered', exportable as XML or CSV. SHORTFALLS. (1) The rename conjunct is unaddressed by every source, help and marketing alike. The corporate-push model means a local rename is not contemplated rather than handled, and no source says what happens to rollup if one occurs. (2) The multi-unit report Microworks actually describes in prose is per-location rows of TOTALS, not item mix: 'Multi-unit sales reports are also available with spreadsheet style rows for each location that can provide full corporate or regional sales totals.' The item-level reading rests on crossing two bullets in that page's filter list - 'Filter reports by: Location or multiple locations' and 'Marketing Engine - report by menu group/item' - which is an inference about how filters combine, not a documented item-mix-by-store report. Note the third bullet in that same list narrows rather than helps: 'Product Mix - report filter (all, beverage, alcohol, food or other)' filters PMIX by category, not by store. (3) The local-pricing conjunct is weaker than it looks. https://help.microworks.com/webhelp/Pricing_Tab.htm (live, 8,146 bytes, md5 19025302, retrieved 2026-09-15) says of the per-item field only: 'Store Rule - Store rules are only used by multi-store franchises, and even then only in very specific scenarios. The vast majority of users can safely disregard this field. For more information, contact Microworks Tech Support.' It never says the field is a per-store price override; treating it as one is reading a feature out of a field name. The support for local pricing is therefore the marketing sentence 'tools to sort out differences in price, costs and selection', at grade C. (4) The StoreNet server's own reporting UI is documented nowhere; the help library covers only the store-side Satellite client (Change Data Directory, Log Viewer, Upload Dataset). There is no grade-B source for the rollup report itself, which is why this is partial at C and not yes at B. CORPUS AND AGE: the live WebHelp library censused against its 205-title RoboHelp TOC, the 16-page current marketing link graph, and PrISM_Overview.pdf. Library authored 2009/2010 and currently linked; marketing 2025 and written to sell. CONTROLS, tokenised, positive controls PriSM 300 hits / 113 files and Microworks on all 16 marketing pages: rollup 0, 'roll up' 0, consolidated 0, normalized 0, polling 0. POISON. (a) Those five zeros are the claim's vocabulary, not the vendor's, whose words are 'master menu', 'inventory set', 'dataset', 'Store Rule' and 'Group'; a control built from the claim's own wording manufactures a false no on this cell. (b) enterprise reads 150 hits in 150 files in the Wayback unpack, which looks like deep enterprise documentation and is one navigation link repeated across 150 mirrored marketing pages captured under /webhelp/; the help library proper uses the word once. (c) Storenet_Satellite.htm and its three children are absent from the archived unpack entirely and exist only in the live library, so a corpus bound to the archive alone would have missed the entire master-menu mechanism. RE-OPEN this cell if Microworks ever publishes StoreNet server documentation - that is the one surface that would settle the rename conjunct either way. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-09-15 adversarially verified
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Gift cards are listed as a Storenet centrally managed capability across locations. Outstanding-liability reporting and inter-store redemption settlement are not documented. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Customer loyalty programs are listed as a Storenet centrally managed capability. A single shared profile/balance/history across all stores is implied but not explicitly stated. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
Storenet's documented purpose throughout enterprise-management.htm is a single 'Master' menu and inventory shared by multiple locations of one operation, with tools to manage per-store differences in price/cost/selection — not two distinct brands with separate menus, receipts, and reportable revenue on shared hardware. No virtual-brand, multi-brand, or dual-menu-on-one-terminal topic exists anywhere in the manual. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-04
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
A per-location tax rate is documented: "Sales Tax — The location's total sales tax rate," configured on the Ordering tab of Location Maintenance, so each location can carry its own rate. Shortfall: the field is a single total rate, not multiple simultaneous jurisdiction-specific rates, and the documentation warns changing it "will update every order in the system (on the current day)" including settled orders — the opposite of clean multi-jurisdiction handling. No prepared-food-vs-grocery split, inclusive/exclusive toggle, or per-location exemption is documented. https://help.microworks.com/webhelp/Ordering_Tab.htm · retrieved 2026-08-04
Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator
multi-location-config-audit-log
The previous rationale was wrong that only sync logs exist. A real who/what/when trail ships as the Weekly Exception report: "The Log option tells the system to record additional information about the event in the Weekly Exceptions Report. Every time a password is used, an entry is created in the Weekly Exceptions browser. If 'Log' is checked a second entry is created with additional information about the event", and the same screen can attach camera video to a function. The printed WEEKLY EXCEPTION sample (https://www.microworks.com/files/Reporting/Transaction/EXCEPTION.PDF, retrieved 2026-09-04) has columns DATE / TIME / DESCRIPTION / EMPLOYEE / Super User and does capture configuration objects, not just transactions: "Location Maintenance *MICROWORKS SUPPORT* YES", "Edit Order Types *MICROWORKS SUPPORT* YES", "Edit Employee File", "Inventory Master", "Add/Edit webordering store hour exceptio", and one before/after value - "Edit SYSTRANS type Deposit - $275.09 (originally $0.00)". SHORTFALL 1: most rows record only that a function was opened, not which field changed to what. SHORTFALL 2: it is opt-in per function (Required/Log checkboxes) rather than always-on. SHORTFALL 3: it is neither immutable nor corporate-queryable - the report is per store ("Store #: 001"), it lives in the same store-local database that Trim and Archive removes older data from, and the StoreNet Log Viewer that corporate can see carries sync events, not these entries. https://help.microworks.com/webhelp/Setup_Password_Functions.htm · retrieved 2026-09-04
Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator
multi-location-enterprise-api
There is no public API of any kind (reporting-public-api, no), and Storenet's own reporting is described (reporting-realtime-dashboard, existing cell) as a nightly full-database upload viewed in a browser/mobile UI, not a queryable multi-location data warehouse or authenticated bulk-transaction API. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
Labor rules are configured per individual location — each Location Maintenance record carries its own Payroll tab with OT rate multipliers and Hours Before OT thresholds, enforced at that location's terminals during clock-in/payroll calculation. Shortfall: this is single-location configuration, not a location-group policy tier; Storenet's one-way nightly menu/inventory distribution (Upload_Dataset_Satellite.htm) does not extend to labor policy, and no predictive-scheduling or break-rule enforcement exists at any level (labor-break-compliance-by-state, existing cell: no). https://help.microworks.com/webhelp/Payroll_Tab.htm · retrieved 2026-08-04
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
Documented directly: "Microworks PrISM for Windows turn-key systems ship on Dell(TM) hardware," naming a Mini Tower (MANAGER1) and a Low Profile (POS1) with ordinary parallel, serial, network, video and USB connectors. Commodity x86 Windows PCs, not proprietary terminals. Note the previously cited demo.htm does not mention Dell at all — it says only "your home or office Windows based computer" — and the citation was corrected by the verification pass. https://help.microworks.com/webhelp/Setting_Up_Workstations.htm · retrieved 2026-08-02 adversarially verified
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
Windows is named for the POS; RapidRun is named for Android and iOS. Minimum OS versions and device specs are not published. https://www.microworks.com/products/rapidrun.htm · retrieved 2026-08-01
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
Verified: 12.3" PixelSense 2-in-1, Intel Core, Wi-Fi 6, under 2 lb, ">10.5 hours" battery — a consumer tablet. The page never mentions a card reader and never claims payment at the table, which also independently supports the partial on payments-pay-at-table. https://www.microworks.com/products/Handheld-Ordering.htm · retrieved 2026-08-01 adversarially verified
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
Rated "10.5+ hour battery life" is published, satisfying the full-shift alternative. Hot-swap/field-replaceable batteries are not offered on this form factor. https://www.microworks.com/products/Handheld-Ordering.htm · retrieved 2026-08-01
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
CLAIM: handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover. Weight is niche, so no grade floor applies. FINDING: no. Microworks' handheld is documented as Wi-Fi only, and the vendor's own published remedy for coverage gaps is more Wi-Fi, which is the enumerate-the-alternatives shape that makes this positive evidence of absence rather than silence. (1) The dedicated product page for the vendor's order-entry handheld, https://microworks.com/products/Handheld-Ordering.htm (200 on 2026-09-15), treats connectivity directly and offers only Wi-Fi: 'Fast Wi-Fi - Prism Wireless Tablet Ordering uses Intel(R) WiFi 6 (Gig+) WiFi networking technology, this allows a single wireless router to host multiple handheld devices, and delivers a fast and reliable Wi-Fi connection. For larger or multi-room facilities wireless antennas can provide optimal coverage to the entire area.' The published answer to a coverage gap is additional antennas, not a cellular failover. (2) The vendor's own documentation agrees. Advanced_Features.htm - live at https://help.microworks.com/webhelp/Advanced_Features.htm, and the topic a previous pass had wrongly declared an uncapturable corpus hole - is the library's treatment of the handheld, and it is Wi-Fi/wireless only: 'PrISM for Tablet PC - In addition to traditional fixed-position ordering terminals, Microworks offers wireless tablet PCs. These are small enough to be easily carried by table servers ... Servers can quickly enter an order table side and send that information directly to the appropriate kitchen printer or makeline display with the tap of a stylus.' No cellular, no failover. (3) There is no LTE anywhere: tokenised controls return 'LTE' 0, '4G' 0, '5G' 0 and 'GPRS' 0 across every corpus. COUNTER-EVIDENCE, published in full because it is the strongest thing pointing the other way and it is what an earlier pass scored a partial on: the 10 August 2020 press release on https://microworks.com/home/news-events.htm says of a Global Payments Integrated payment terminal, 'Genius Mini is a small device that accepts major payment types from anywhere', and in its benefit list, 'Update effortlessly - Automatic cloud updates help ensure you have the latest features and functionality with no downtime, wiith both WIFi and cellular connectivity' (the misspelling 'wiith' is the vendor's, quoted verbatim from the served bytes); the Pay at the Table/Curbside device in the same release lists 'Multiple connectivity' among its stability features. That does not satisfy this claim, for three reasons. First, device class: the Genius Mini is a payment terminal in a resold processor family, not the POS handheld the claim is about - Microworks' handheld product line is Prism Wireless Tablet Ordering, and the claim's why_it_matters is about order entry on patios and rooftops. Second, purpose: the single cellular sentence is about delivering automatic cloud UPDATES to that terminal, not about order or payment traffic surviving a Wi-Fi drop, and nothing anywhere states cellular as a fallback when store Wi-Fi fails - the third conjunct is unmet for either device. Third, currency and gating: the SAME bullet on the current product page has had the cellular clause REMOVED - https://microworks.com/products/payments.htm (200 on 2026-09-15) reads 'Update effortlessly - Automatic cloud updates help ensure you have the latest features and functionality with no downtime!' and stops there - and the whole programme is gated on '*Must be running Prism V8.1 or Prism Cloud and using integrated processing platform' and '**Available with some service providers'. So the one cellular sentence Microworks has ever published survives only inside a five-year-old news item. BOUND CORPUS, all re-derived by me on 2026-09-15, never inherited: (a) the live marketing site as its LINK GRAPH, 26 distinct HTML pages reached by crawling https://microworks.com/ (www.microworks.com 301s to the apex; a fabricated path such as https://microworks.com/status.htm or /zzq-fabricated-9f/nothing.htm returns a real 404 of 355 bytes, so the apex is not a catch-all and a zero over it is bindable); (b) sitemap.xml, 58 <loc> rows, which is a STRICT SUBSET of the site - it omits products/payments.htm, home/news-events.htm, products/rapidrun.htm and products/kiosk-qr-ordering.htm, every page carrying the payments evidence, and 40 of its 58 rows are sample-report PDFs and a case study; absences are therefore bound to the link graph, never to the sitemap; (c) the PriSM WebHelp library, which is LIVE at help.microworks.com/webhelp/<Topic>.htm - its bindable manifest is the publisher's own table of contents (whgdata/whlstt0..120.htm, 427 rows resolving to 205 distinct topics), and the 258-file local crawl covers all 205 TOC topics plus 53 further topics found by link-following; (d) the same library as archived, 645 Wayback captures, 2006-2013; (e) the vendor's PDF information sheet https://microworks.com/files/PrISM_Overview.pdf (200, 323,426 bytes, text-extracted). LIBRARY VINTAGE: it is the vendor's CURRENT published documentation but authored 2009-2010 (Last-Modified 2010-01-19 on Purge_Customers.htm, 2016-10-29 on Credit_Card.htm), so it bounds what Microworks DOCUMENTS, not what the product does today. CONTROLS, tokenised, positive control 'PriSM' passing on every corpus (live link graph 132, live 258-file library 300, 645 archived captures 1,351): 'LTE' 0 / 0 / 0; '4G' 0 / 0 / 0; '5G' 0 / 0 / 0; 'GPRS' 0 / 0 / 0; 'cellular' 1 on the live site (the Genius Mini update sentence quoted above); 'PDA' 0; 'handheld' 0 in both libraries. POISON: 'cellular' returns 10 hits across the live library and 11 across the archive and EVERY ONE is the 'Cellular' phone-number field on the customer or contact record and in report field pickers (Contacts.htm, Advanced_Reporting_Overview.htm, Setup_Custom_Reports.htm, Web_Ordering_Overview.htm) - a homonym that would read as device connectivity to anyone counting hits. 'wireless' and 'tablet' return 53 hits each on the live site, but almost all are the site-wide nav item 'Wireless Tablet Ordering' repeated on all 26 pages, so the raw count is a template artefact, not coverage. A further trap: on products/payments.htm the entire 'Genius Mini / Genius Handheld / Genius Countertop' section, including the words 'Genius Handheld is a mobile acceptance payment device', sits inside an HTML COMMENT at source bytes 11,466-14,334 and is NOT published - comments must be stripped before tags or this cell can be scored off markup the vendor deliberately hid. SCOPE OF THIS NO: it says Microworks documents no cellular/LTE connectivity on its POS handhelds and publishes a Wi-Fi-antenna remedy instead; it does not assert that a Genius payment terminal sold alongside PriSM lacks a cellular radio. https://microworks.com/products/Handheld-Ordering.htm · retrieved 2026-09-15 adversarially verified
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
Store-local Windows architecture with nightly sync to the hosted server means terminals are not cloud-request-dependent, but the vendor publishes no explicit list of what degrades offline. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
Refutes the earlier "no" and resolves the verification pass's "unknown": there is a documented first-party KDS. "The PrISM system's Makeline Monitor is an easy-to-read video display that lists all of the order items that the kitchen needs to make", with Ord#, Qty, Description, an Elaps elapsed-time column and order Type; touch Select mode for multi-item bump, Clear, Made to view previously made items, an order-type Filter, two font sizes, and a Dash button opening a sales dashboard. Input hardware is first-party too — the optional Makeline Bump Bar "built to withstand the demanding requirements of the kitchen environment". Shortfall: it is "an optional system component that is, in many cases, replaced by a Kitchen Printer"; routing rules target printers rather than makeline stations (the Makeline tab holds only a refresh interval and an aging timer for the location); and no course or fire timing is documented. https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm · retrieved 2026-08-02
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Self-order kiosk offered, running the WebOrder menu/UI with contactless payment; an ELO-class touchscreen is pictured. Countertop-vs-freestanding options and ADA conformance are not documented. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
Same basis as order-capture-drive-thru: the complete vendor product/hardware catalogue names no drive-thru menu board, order-confirmation display, or headset system, and no drive-thru topic exists anywhere in the 488-topic manual. https://www.microworks.com/products.htm · retrieved 2026-08-04
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Printers are third-party and are addressed as ordinary shared Windows devices, not as vendor-branded appliances: "Device Path - This is the Universal Naming Convention (UNC) path, as used by Microsoft Windows, for this device. For example, if a receipt printer is connected to a machine labeled POS1 and the printing device itself is called POS1RCT, then the device path would be \\POS1\POS1RCT", with "Printer Type - Select the applicable printer model" implying a multi-model list, plus a documented failover ("Backup Device - Choose another device to act as a backup in case PrISM cannot print to this device"). Exactly one manufacturer is ever named, in a formatting option: "Please be sure to check the T88 option for both the header and footer if your cash receipt printer is an Epson T-88 Thermal receipt printer" (Advanced_Receipt_Printing.htm). SHORTFALL: the model list itself is never published ("If unsure as to what model printer you are configuring, contact Microworks Tech Support"), only one manufacturer is named so the multi-manufacturer half of the claim is unevidenced, ESC/POS is never mentioned, and LAN/Ethernet printers are contradicted rather than supported by the one statement on attachment - "Nearly all printers connect directly to a computer, if the computer is off the printer will not function" (Trouble_Shooting.htm). Same shape as the sambapos and lightspeed-restaurant partials. https://help.microworks.com/webhelp/Printer_Setup.htm · retrieved 2026-09-04
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Documented peripherals include cash drawers/tills, touchscreens, fingerprint readers, caller-ID hardware, and barcode label printing ("Barcode blaster pizza box labels"). No published compatibility list; scales and customer-facing displays are not mentioned. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
"Keep cardholder data off the POS" via P2PE and tokenization is claimed, but no PCI-listed PTS device model is named and no merchant SAQ type is stated. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
NEW SURFACE AND A MOVE (326th). CLAIM: contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. VERDICT: no, on the same evidence as payments-softpos-tap-to-pay. The vendor's payments platform is Global Payments Integrated's Genius family (https://microworks.com/home/news-events.htm, 2020-08-25 release), and every contactless path it publishes is a separate certified device: 'Genius Mini is a small device that accepts major payment types from anywhere' for the mobile case, and a Pay at the Table/curbside terminal with 'Built-in NFC contactless', 'PCI PTS 5.x certified', 'SRED' for the tableside case. Microworks' own handheld product page (products/Handheld-Ordering.htm) is about wireless tablet ORDER entry and names no acceptance hardware. BOUND: the complete public marketing corpus re-crawled 2026-09-18 (23 internal pages from the homepage link graph; https://microworks.com/sitemap.xml is a known strict subset and omits several of these pages) plus the newly found open directory listing https://microworks.com/files/ (5 product PDFs downloaded and text-extracted, plus sellsheets/, print/, Reporting/ subdirectories and public Prism 7.4 evaluation installers Prism74Eval.exe / Satellite74.exe / Vocelli74Eval.exe, dated 2020-03-02 and NOT unpacked this pass - a lead for a later session). 28 files, 154,622 characters. CONTROLS: 'tap to phone' 0, 'tap-to-phone' 0, 'softpos' 0, 'tap to pay on iphone' 0, 'byod' 0, 'your own device' 0, 'commodity' 0; positive control 'prism' 141 hits in 23 of 28 files. POISON: the single 'tap-to-pay' hit is a list of accepted card types on products/payments.htm, not phone-as-reader. Grade C: marketing-bounded, and it is the only public description of the product. Retrieved 2026-09-18. https://microworks.com/home/news-events.htm · retrieved 2026-09-18 adversarially verified
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
No hardware SKU prices anywhere on the site; the quote page routes to phone/email. https://www.microworks.com/quote.htm · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Both paths documented: turn-key purchase (Dell hardware with 3-year on-site warranty) and leasing through partner leasing companies. Neither is priced. https://www.microworks.com/home/faq.htm · retrieved 2026-08-01
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
The licence answers the question for the software and is silent on the hardware, which is the better half of the answer here. The lock is a detachable dongle, not a device: EULA 2(c), "Upon acceptance of this EULA and purchase of the Software, you will receive a Software Keylok that will enable you to activate or operate the Software", and USB_Software_License_Keylok.htm (recovered 2026-09-04) describes it as an ordinary USB dongle installed with a driver from the psmkeylocusb folder into "any available USB port", so removing it disables the software and leaves the PC untouched. Termination reaches only software copies: "Upon any termination of this EULA, you must cease all use of the Software, licensed hereunder, destroy all copies in your possession or control" - with "Software" defined at 1(b) as "only the Microworks software program(s) and corresponding documentation, associated media, printed materials, and online or electronic documentation", and the agreement declared at 7 to be "the entire agreement between You and Microworks relating to the Software". There is no clause restricting what the customer may run on the equipment and no remote-deactivation right, and the equipment is customer-purchased Windows PCs ("Station Name - This is the station name. This must match the Microsoft Windows computer name", General_Tab_-_Stations_File.htm) sold outright with a warranty, a restocking fee on returns and an RMA/Hot Spares program (RMA_Policies.htm, Support_Policies.htm). SHORTFALL: no vendor document affirmatively states that hardware bought from Microworks remains usable with other software after cancellation; the finding is that the documented lock is scoped to the software, which is one step short of the confirmation this claim asks for. https://help.microworks.com/webhelp/EULA.htm · retrieved 2026-09-04
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
Warranty terms published: Dell computers three years with on-site support; other peripherals one year; touchscreens two years. No advance-exchange turnaround SLA is stated. https://www.microworks.com/home/faq.htm · retrieved 2026-08-01
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
The only mobile ordering hardware documented anywhere is the vendor-supplied Handheld-Ordering device — a 12.3" Windows 2-in-1 tablet running "the exact same user interface as our fixed POS station." No personal-phone, BYOD, or bring-your-own-device permission model is named on this page, in the RapidRun driver-app documentation, or anywhere in the manual. https://www.microworks.com/products/Handheld-Ordering.htm · retrieved 2026-08-04
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
Station Setup (General, Devices, Advanced) and Printer_Setup.htm are per-terminal, locally-configured screens — Printer_Setup's only fleet-adjacent feature is a per-device Backup Device failover field. Neither topic, nor any other in the manual, documents a remote console showing terminal/printer/KDS online/offline status, remote reboot, software-version visibility, or staged update rollout. https://help.microworks.com/webhelp/Printer_Setup.htm · retrieved 2026-08-04
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
"Caller ID Customer Link" is listed as an integrated add-on POS feature — inbound call pops the customer record. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
Upheld with the citation the previous pass said was needed. The PrISM WebHelp table of contents enumerates all 488 topics across the eleven books of the system and contains no API, developer, SDK, webhook or integration topic; the vendor's 13-item product catalogue contains no platform product; and the FAQ frames extension as vendor-performed work — "We are one of a handful of POS vendors that actually customize our product for your specific needs." https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-02
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
There is no API at all (extensibility-public-api-docs, no; api_posture.public_api: none), so there is no access to be included in or excluded from the base subscription. The claim's premise does not exist in the documented product. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
A free Windows software evaluation download exists for prospective operators, but it is a product trial, not a developer sandbox with API credentials and seeded data. https://www.microworks.com/demo.htm · retrieved 2026-08-01
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
There is no third-party app surface to authenticate. The complete help TOC — the authoritative enumeration of the product across eleven books — contains no API, developer, OAuth, token, scope, or partner-app topic of any kind; the only documented integrations are vendor-built point connections (the desktop QuickBooks Interface Module, Caller ID Customer Link, WebOrder-to-POS injection). With no public API and no app marketplace, there are no operator-granted, individually revocable app credentials, OAuth or otherwise — integration is a sales conversation with the vendor, not a permission grant. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
The complete help TOC enumerates every topic in the product across eleven books and contains no webhook, event, callback, or push-notification topic. The product's only documented outbound surfaces are scheduled report files delivered as PDF/HTML to a folder, an email address, or a printer (Scheduled_Reports.htm) and the desktop QuickBooks file interface. Order lifecycle events are not exposed outside the system by any documented mechanism — there is not even a polling API as the alternative, because there is no API at all (see api_posture). https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
Consistent with extensibility-webhooks-push (no): no webhook mechanism exists at all, so there is nothing to be HMAC-signed, retried with backoff, or replayed from an event log. The complete help TOC confirms the absence across all eleven books. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
An ingestion path exists and is explicitly NOT public. The only external order-data hook anywhere in the 269-topic WebHelp manual is a pair of file directories on the Location Maintenance Advanced tab, and the vendor documents it by refusing to document it: "XML Interface - In / Out Directories, Network Path. These fields are used for advanced support functionality. Making any unnecessary changes may result in system failure. Please contact Microworks Tech Support for more information." Injection itself is real but vendor-operated: Web_Ordering_Overview.htm (retrieved 2026-09-04) states "The orders are entered into your system automatically by the web ordering module" - Microworks' own hosted channel, provisioned by Tech Support, not an endpoint an operator or a third party may call. No endpoint, auth model, payload, rate limit or spec is published in the manual, and the measured retrieval facts show no developer surface exists to publish one: developer.microworks.com, api.microworks.com and docs.microworks.com all answer a 163-byte cPanel defaultwebpage.cgi wildcard, i.e. no such host. This is the fact pattern the corpus already scores 'no' for slice - orders do inject, but through vendor-operated private integrations, with no public write API offered. https://help.microworks.com/webhelp/Advanced_Tab_-_LM.htm · retrieved 2026-09-04
Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator
extensibility-data-symmetry
With no public API to read or write any object (extensibility-public-api-docs, no), there is no basis for read/write symmetry across orders, menu, customers, employees, or inventory. All access is through the desktop application itself. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
API rate limits are published as specific numeric quotas with documented throttling behavior and headers.
extensibility-published-rate-limits
Citation replaced (was the marketing-host sitemap, which the verification pass ruled unsafe). The documentation host's own complete topic index contains no API reference, so there is nothing on which rate limits could be published; no throttling, quota or fair-use topic exists in the help system. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-02
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `microworks`, rendered as 'Microworks', with qualityStatus CERTIFIED and 3 of the 8 high-quality features built. CERTIFIED and AT_RISK are the program's other two tiers, so this is positive evidence of non-membership rather than a failure to find the vendor: it is present in the registry and carries a status that is not PREFERRED. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: /, barring only /cdn-cgi/ and /monitoring). The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page at https://merchants.doordash.com/en-us/integrations. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general, so grade B is the ceiling here and it can never be A. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. VERIFICATION PASS 2026-09-12: all three sources were re-fetched independently of the frozen cache. The registry is byte-identical (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers, tiers tallying 12/47/5 and exactly 23 distinct flag names), and every quoted span below was re-checked as verbatim-present and contiguous in the file it is attributed to. The prior unknown was a verification-pass downgrade: the only source was the marketing sentence naming GrubHub, UberEats, DoorDash and Postmates, and the property this claim actually tests — whether such an integration is first-party and direct rather than middleware-brokered — was exactly what the vendor never stated. The registry states it for one of the three: `microworks` is present, CERTIFIED, and classed PROVIDER_AGGREGATION_TYPE_POS, which DoorDash’s integrations page glosses ‘Integrates directly with DoorDash so you can accept, process, and fulfill orders’, as against PROVIDER_AGGREGATION_TYPE_MIDDLEWARE_AGGREGATOR, glossed ‘Requires a compatible POS system’. Its own entry’s providerPortalLink is https://microworks.com/, its providerFriendlyName is Microworks, and its countriesSupportedList is [COUNTRY_AVAILABILITY_US]. TWO NAMED SHORTFALLS. First, the claim requires DoorDash AND Uber Eats AND Grubhub, and only DoorDash is attested. Second, the type field records how DoorDash CLASSES the provider, not who wrote the connector, so ‘first-party’ is established only in the sense that no middleware layer sits between Microworks and DoorDash. This is the same instrument and the same verdict already recorded on the near-duplicate claim delivery-3p-direct-integration, which stands at `partial`/B. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-12 adversarially verified
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
CLAIM. The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate); weight table-stakes. MET, in both directions, for exactly one platform. Microworks side: https://www.microworks.com/products/delivery-pos.htm (retrieved 2026-09-15, HTTP 200, 23,120 bytes, Last-Modified Wed, 22 Oct 2025 15:43:32 GMT) says 'Delivery Service Integration - Get rid of a counter full of tablets and phones trying to track all those 3rd-party delivery apps. Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few).' In the RAW bytes the phrase 'integrates with 3rd party Apps' is itself the anchor, verified verbatim across a line break: <a href="https://www.itsacheckmate.com/#party-integrations" title="itsacheckmate.com integrations" target="_blank">. Microworks is naming ItsaCheckmate as the route. Middleware side: https://www.itsacheckmate.com/integrations (retrieved 2026-09-15, HTTP 200, 153,434 bytes; /pos-integrations 301-redirects to it and serves the byte-identical body, md5 9e67259d) carries a POS card whose image is .../662f9e08eb18fe2c2937243c_prism-logo.svg with alt="prism-logo", and a JSON-LD featureList reading 'Point of Sale Integrations (e.g., PAR Brink, Revel Systems, Toast, SpotOn, Genius, Clover, Upserve, Square, Ovvi, HungerRush, Union, Cake, Salido, NCR, NCR Silver, Maitre'D, SpeedLine, Focus POS, Micros, Micros RES, PixelPoint, Rezku, Prism POS, OrderCounter, 4Soft, UpMenu, Xenial, Dinerware)'. SHORTFALLS. (1) The claim requires TWO platforms and exactly ONE is attested. (2) The taxonomy's example list names 'Checkmate, ItsaCheckmate' as separate entries; they are ONE company (ItsaCheckmate trades as Checkmate) and must never be counted twice to reach the threshold. (3) Neither side documents the DEPTH of the link -- no integration guide, no statement about menu push, 86ing or injection error handling -- which is why this finding does not carry the delivery or menu-sync cells. (4) Both citations are first-party feature pages written to sell, hence grade C, not B; the marketplace enumeration is additionally open ('to name just a few'), so it bounds nothing. CONTROLS. Tokenised word-boundary controls (\b...\b, case-insensitive) over the 6 middleware pages fetched 2026-09-15 (deliverect.com/en-us/integrations and /integrations/pos-systems, chowly.com/ and chowly.com/integrations, cuboh.com/integrations, tryotter.com/integrations): prism 0/6, microworks 0/6, weborder 0/6. Positive control POS 6/6 (338 occurrences). Over the 260-file live help library: Checkmate, ItsaCheckmate, Deliverect, Chowly, Otter, Olo, Ordermark, Cuboh and API all 0, with positive control PriSM 188/260 -- expected and worthless, the library's Last-Modified headers run 2010-2016. THESE ZEROS ARE NOT A CENSUS AND ARE NOT SCORED AS ABSENCE. Bounding control: the named-POS probe over the same 6 pages reads Toast 2/6, Clover 3/6, Revel 2/6, Lightspeed 2/6, Square 4/6, and Rezku, OrderCounter and Ovvi 0/6 -- Deliverect's own POS-systems page does not name Toast or Clover in its served bytes at all. Those lists are client-rendered, so a zero there proves the string is absent from the HTML, not that the integration is absent. POISON, PUBLISH IT: a SUBSTRING search for 'prism' on https://www.tryotter.com/integrations returns 489 hits and every single one is PRISMIC, the headless CMS Otter runs on -- 488 'prismic.io' and 1 'prismic.js'. Tokenised \bprism\b returns 0. A substring reader publishes a false Otter integration and reaches a wrongly-earned yes. VALUE. partial, not unknown: one platform is positively attested in both directions, so the capability exists and the shortfall is a named count (one of two). Not yes: the second platform is undetermined, not present. https://www.microworks.com/products/delivery-pos.htm · retrieved 2026-09-15 adversarially verified
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
A real, documented connector exists: the QuickBooks Interface Module has its own book in the manual — Requirements, Installing & Configuring QIM, QuickBooks Item List, Sales Receipts, Invoices. Shortfall, and it is a sharp one: the configuration chapter is titled "Configuring QuickBooks Pro 2002", i.e. the documented target is a desktop QuickBooks release from 2002. No cloud accounting connector (QuickBooks Online, Xero, Sage, NetSuite) is documented anywhere, and there is no general GL-mapped journal export for anything else. https://help.microworks.com/webhelp/QuickBooks_Interface_Module.htm · retrieved 2026-08-02
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
The claim asks for native export to two or more named payroll providers without re-keying; PrISM names zero and documents the opposite mechanism. The employee record's own field for interoperating with an outside payroll system is a manual cross-reference key, not a feed: "Payroll Number - This field is not required. This field may be used as a cross reference with a separate payroll system if applicable." Payroll is positioned as in-house rather than exported - Payroll_Tab.htm: "The PrISM system has a fully integrated payroll system" - and the payroll report is a report, run weekly/biweekly/period from the Paperwork menu. The one place an export destination is chosen is Scheduled_Reports.htm, whose Export Type field enumerates every available behaviour closed-form: "Save Report... Save Report As... Email Report To... Print Report To" - file, email or printer, no provider connector. Gusto, ADP, Paychex, Paylocity and every other payroll vendor are absent from all 269 topics of the closed manual census read 2026-09-04, and QuickBooks - the sole named external system - is an accounting interface whose own book enumerates its supported objects closed-form (QB_Invoices.htm and Sales_Receipts.htm: "QIM presently supports the ability to create Sales Receipts to capture each store’s daily sales activity, Sales Invoices to handle orders placed on account, and Bills to handle PrISM system Invoices or Cost of Goods Sold"), and payroll is not among them. https://help.microworks.com/webhelp/Edit_Employee_File_-_Employee_Tab.htm · retrieved 2026-09-04
Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator
extensibility-bi-data-warehouse
The complete automated-export mechanism is enumerated on reporting-raw-warehouse-export (existing cell, no): Save Report, Save Report As, Email Report To, or Print Report To, in PDF or HTML only. No S3, SFTP, database, or Snowflake-share destination exists, and no API exists to build one outside the documented export types. https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-04
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
No integrations marketplace exists; the site's full product catalog and sitemap contain no partner directory. https://www.microworks.com/products.htm · retrieved 2026-08-01
Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.
extensibility-custom-fields-scripting
Operator-defined classification attributes on POS objects exist; operator-defined arbitrary fields and any scripting facility do not. The clearest instance is Menu Classes, a free-form operator-created label attached to menu items and consumed by other subsystems: "Menu Classes are 'wild cards'. They allow multiple disparate items to be linked together for report filters and coupons... Click Add to create a new class. Classes themselves are just text labels; enter the name you want for the class. The class can then be attached to Menu Items." Report_Filters_Update.htm adds operator-composed filter logic ("There are many system and user-defined options that can be used in creating the filter"), and Cost_Centers_Update.htm, Setup_Custom_Reports.htm, Inventory_Location.htm and Account_Terms.htm are further operator-defined extension points. SHORTFALL: none of these is a general custom-field facility - the operator cannot add a field to a customer, order or employee record - and no scripting, formula, webhook or vendor-hosted custom-logic surface appears in any of the 255 topics read. Worse for the 'without a vendor engineering engagement' half of the claim, the manual routes the adjacent extension points through the vendor by name: Web_Tab.htm's Base Item is "an advanced feature of the PrISM system, please contact Microworks Tech Support before using", Web Specials and web coupon behaviour must be changed by Tech Support (Advertised_Coupons.htm: "Changing the way your coupons are used on the web must be done by Microworks Tech Support"), and the XML Interface is support-only. Matches thrive-pos's partial, which rests on three fixed user-defined fields. https://help.microworks.com/webhelp/Menu_Classes.htm · retrieved 2026-09-04
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
A headless mode requires an API for a third-party UI to drive the transaction engine through; none exists (extensibility-public-api-docs, no). WebOrder, the kiosk, and the handheld all run Microworks' own first-party UI, not a third-party front end over an API. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-04
The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.
extensibility-api-versioning-deprecation
Citation replaced (was the marketing-host sitemap). The complete WebHelp topic index has no API changelog, no versioning policy and no deprecation notice topic, because it documents no public API. Product versions are referenced only in prose ("Prism V8.1 or Prism Cloud" on the payments page), with no published support-window or upgrade policy. https://help.microworks.com/webhelp/whxdata/whtdata0.xml · retrieved 2026-08-02
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
Reports covering sales, inventory, customer, and driver activity can be exported on demand as PDF or HTML files (Scheduled_Reports.htm), and the operator physically holds the store-local production database on their own hardware (reliability-local-transaction-engine, existing cell). Shortfall: no complete raw export of orders, customers, menu, and payments metadata in a machine-readable format (CSV/JSON/SQL) is documented, and no contractual export window at termination exists because no public MSA exists at all (commercial-autorenew-terms-published, existing cell: no). https://help.microworks.com/webhelp/Scheduled_Reports.htm · retrieved 2026-08-04
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
On-premise store server plus local Windows terminals with only nightly cloud sync strongly implies local order entry and printing survive an internet outage, but the vendor never states it. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
CLAIM: card payments can be accepted while offline via store-and-forward, not just cash-only fallback. Weight is differentiator. WHAT IS MET: the single conjunct is asserted once, first-party, in a precise term of art. Microworks' News & Events page (https://microworks.com/home/news-events.htm, 200 on 2026-09-15) reproduces the 10 August 2020 release describing the Global Payments Integrated Genius family it sells with Prism POS - 'Global Payments Integrated and Microworks have teamed up to bring you the Genius family of products' - and lists among the merchant's ongoing benefits 'Line-item display, PIN steering, store & forward, cash back and more.' Verified in the served RAW bytes as one contiguous phrase inside a single <li>, not a tag-welded artefact. SHORTFALLS, each of which independently blocks a yes. (1) The capability is a property of the resold Global Payments Genius terminal, and Microworks publishes nothing about what PriSM itself does while the link is down: the POS-side behaviour - whether the order can still be taken, tendered, reconciled and reported - is undocumented. (2) The programme is gated twice over: '*Must be running Prism V8.1 or Prism Cloud and using integrated processing platform' and '**Available with some service providers' (https://microworks.com/products/payments.htm, 200 on 2026-09-15), so it is not available to the installed base generally. (3) Nothing is published about ceilings, durations or who bears a store-and-forward decline; the sibling decline-liability question is untouched. (4) The vendor's own live documentation is silent: its card chapter, Authorizer_Overview.htm (https://help.microworks.com/webhelp/Authorizer_Overview.htm; archived copy https://web.archive.org/web/20130317011216/http://www.microworks.com/webhelp/Authorizer_Overview.htm, capture 2013-03-17), documents the optional PCCharge add-on, 'both traditional dial-up as well as broadband Internet-based authorizations', and an authorise-now / settle-at-batch-close model, and says nothing whatever about link failure. (5) Grade D - a press release - and a differentiator-weight yes requires grade A or B, so the grade floor independently forbids yes on this evidence. This is NOT a no: the term of art is asserted by the vendor and the documentation is a 2009-2010 vintage library that cannot bound a 2020 platform. BOUND CORPUS, all re-derived by me on 2026-09-15, never inherited: (a) the live marketing site as its LINK GRAPH, 26 distinct HTML pages reached by crawling https://microworks.com/ (www.microworks.com 301s to the apex; a fabricated path such as https://microworks.com/status.htm or /zzq-fabricated-9f/nothing.htm returns a real 404 of 355 bytes, so the apex is not a catch-all and a zero over it is bindable); (b) sitemap.xml, 58 <loc> rows, which is a STRICT SUBSET of the site - it omits products/payments.htm, home/news-events.htm, products/rapidrun.htm and products/kiosk-qr-ordering.htm, every page carrying the payments evidence, and 40 of its 58 rows are sample-report PDFs and a case study; absences are therefore bound to the link graph, never to the sitemap; (c) the PriSM WebHelp library, which is LIVE at help.microworks.com/webhelp/<Topic>.htm - its bindable manifest is the publisher's own table of contents (whgdata/whlstt0..120.htm, 427 rows resolving to 205 distinct topics), and the 258-file local crawl covers all 205 TOC topics plus 53 further topics found by link-following; (d) the same library as archived, 645 Wayback captures, 2006-2013; (e) the vendor's PDF information sheet https://microworks.com/files/PrISM_Overview.pdf (200, 323,426 bytes, text-extracted). LIBRARY VINTAGE: it is the vendor's CURRENT published documentation but authored 2009-2010 (Last-Modified 2010-01-19 on Purge_Customers.htm, 2016-10-29 on Credit_Card.htm), so it bounds what Microworks DOCUMENTS, not what the product does today. CONTROLS: identical tokenised sweep to payments-offline-store-and-forward, positive control 'PriSM' passing on every corpus (132 / 300 / 1,351). 'store and forward' 0 everywhere; 'store & forward' 1, the bullet quoted; 'floor limit' 0; 'stand-in' 0; 'decline' 0; 'declined' 0; 'approval code' 0; 'authorization code' 0; 'voice' 0; 'manual entry' 0. POISON: 'offline' is 2 hits of PrivacyPolicy.htm boilerplate on the live site and 1 hit of 'USE PRINTER OFFLINE' (a Windows printer property, Trouble_Shooting.htm) in the library; 'outage' in the library is power outages and a UPS, not connectivity. Further trap: the Genius Mini / Handheld / Countertop copy on products/payments.htm is inside an HTML comment (bytes 11,466-14,334) and is unpublished, so the live payments page names no store-and-forward at all. https://microworks.com/home/news-events.htm · retrieved 2026-09-15 adversarially verified
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
Same finding, same page, as the already-established payments-offline-decline-liability (no): the complete card-authorization documentation describes an authorize-at-order, settle-at-batch model with no store-and-forward concept at all, hence no decline-on-reconnect liability statement and no offline cap. No other topic in the complete help TOC covers offline payments. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-04
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
Multiple POS stations share check state — "Servers can swipe credit cards into any available POS station" and real-time table status across stations — against a store-local database. LAN-degraded behavior during an internet outage is not explicitly documented. https://www.microworks.com/products/restaurant-pos.htm · retrieved 2026-08-01
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
The manual documents an in-store estate of named Windows machines — a MANAGER1 mini tower and POS1/POS2 low-profile stations wired to a store LAN — so the transaction engine is on-premise by construction. Corroborated verbatim on the Storenet page: "each store can upload its entire database nightly" and "Hosted Server and Unit Locations Can Update Database Nightly", i.e. the hosted copy is a nightly extract of a store-local production database. Caveat: the payments page gates current devices on "Prism V8.1 or Prism Cloud" and Prism Cloud has no published architecture, so this applies to the on-premise product only. https://help.microworks.com/webhelp/Setting_Up_Workstations.htm · retrieved 2026-08-02 adversarially verified
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
Kitchen output is LAN-attached printers driven by the local POS, so printing should continue offline; no KDS exists and no offline statement is published. https://www.microworks.com/products/web-ordering.htm · retrieved 2026-08-01
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
Failover itself is documented: every device defined in Printer Setup takes a Backup Device — "Choose another device to act as a backup in case PrISM cannot print to this device" — so tickets reroute to a designated backup when a configured printer is unreachable. Named shortfall: the second half of the claim, alerting staff, is documented nowhere — neither Printer_Setup.htm nor the troubleshooting topics describe any notification to staff when a printer is down and its backup engages. https://help.microworks.com/webhelp/Printer_Setup.htm · retrieved 2026-08-04
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
The claim asks whether the vendor documents conflict-resolution behaviour; it documents none. The only multi-node data flow in the manual is StoreNet Satellite: a franchise master uploads a menu or inventory dataset ("Once performed this cannot be undone") and stores "download the updated data at the next prescribed interval" (Upload_Dataset_Satellite.htm) — one-way distribution with no merge, prompt, or conflict concept. In-store, workstations share a single store-local database over the LAN, and Networking_The_Workstations.htm is a cabling/router installation guide with no partition or reconnect behaviour. No topic in the complete help TOC addresses concurrent edits from two devices, so the documented behaviour the claim requires does not exist in the vendor's public corpus. https://help.microworks.com/webhelp/Storenet_Satellite.htm · retrieved 2026-08-04
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
Publication claim, measured against the complete publication surface. The entire PrISM WebHelp manual - 269 topics, enumerated from the manual’s own full-text-search topic table (whxdata/topictable_0-4.xml) rather than by link-crawling, every one fetched and read on 2026-09-04 - discusses connectivity loss in exactly one sentence, and it is a gift-card catch-up utility rather than a feature matrix: "Upload Offline PrISM Card Transactions - This option allows you to upload any transactions that used PrISM cards while the system was disconnected from the internet." Nothing anywhere states which functions stop when the link drops: the strings offline, outage and disconnect return only this line, the Networking topic's no-internet cabling option, two power-outage/UPS mentions and two unplugged-cable troubleshooting steps. No statement on gift cards, loyalty lookup, refunds, manual card entry or card authorisation without connectivity; the Authorizer (PCCharge) chapter and the Credit Card and Settlement tabs are silent on it too. Same standard applied to ~25 peers scored `no` on this id. This supersedes the earlier `no` that the verification pass correctly overturned: that one rested on the marketing host's sitemap while this documentation host went unopened - the host is now fully enumerated and still carries no matrix. https://help.microworks.com/webhelp/System_Overview.htm · retrieved 2026-09-04 adversarially verified
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
CLAIM: a public, per-component status page exists showing current and historical incident state without a login. Weight is table-stakes, so no grade floor applies. FINDING: there is none, and the cell is settleable on live surfaces alone. WHAT I PROBED MYSELF on 2026-09-15 with a browser user-agent. (1) status.microworks.com returns HTTP 200, but the body is 163 bytes and is a cPanel placeholder in full: '<html><head><META HTTP-EQUIV="Cache-control" CONTENT="no-cache"><META HTTP-EQUIV="refresh" CONTENT="0;URL=/cgi-sys/defaultwebpage.cgi"></head><body></body></html>'. (2) trust.microworks.com and support.microworks.com return the identical body. (3) THE CONTROL THAT MATTERS, reproduced with two independently fabricated hosts: nonsense-xyzzy-9f.microworks.com AND zzq-not-a-host-42.microworks.com both return the same 163 bytes, md5 f1fb042c62910c34be16ad91cbbd71fa, identical to all three real-sounding hosts. The domain runs a wildcard catch-all and a 200 on status. or trust. is a soft-200, not a page. (4) Third-party status vendors: microworks.statuspage.io redirects to https://www.atlassian.com/software/statuspage and microworks.instatus.com redirects to https://instatus.com/, i.e. both subdomains are unclaimed; status.microworks.net and microworks.status.io do not resolve at all (status 0). (5) https://microworks.com/status.htm returns a genuine 404 of 355 bytes, and so does a fabricated nested path, so the apex is not itself a catch-all and a path-level absence there is bindable. (6) The vendor's own site-wide nav enumerates its entire support surface under SUPPORT as exactly three destinations, read from the raw homepage bytes: 'Online Help' -> https://help.microworks.com/webhelp/prism.htm, 'Online Support' -> home/supportform.htm (a web form), 'Help Desk' -> mailto:support@microworks.com. That closed enumeration of support routes, published by the vendor, contains no incident status destination. (7) The help library is real and was searched, not assumed away: help.microworks.com/webhelp/ serves the live 205-topic PriSM WebHelp library, and it contains no status, uptime or incident topic. BOUND CORPUS, all re-derived by me on 2026-09-15, never inherited: (a) the live marketing site as its LINK GRAPH, 26 distinct HTML pages reached by crawling https://microworks.com/ (www.microworks.com 301s to the apex; a fabricated path such as https://microworks.com/status.htm or /zzq-fabricated-9f/nothing.htm returns a real 404 of 355 bytes, so the apex is not a catch-all and a zero over it is bindable); (b) sitemap.xml, 58 <loc> rows, which is a STRICT SUBSET of the site - it omits products/payments.htm, home/news-events.htm, products/rapidrun.htm and products/kiosk-qr-ordering.htm, every page carrying the payments evidence, and 40 of its 58 rows are sample-report PDFs and a case study; absences are therefore bound to the link graph, never to the sitemap; (c) the PriSM WebHelp library, which is LIVE at help.microworks.com/webhelp/<Topic>.htm - its bindable manifest is the publisher's own table of contents (whgdata/whlstt0..120.htm, 427 rows resolving to 205 distinct topics), and the 258-file local crawl covers all 205 TOC topics plus 53 further topics found by link-following; (d) the same library as archived, 645 Wayback captures, 2006-2013; (e) the vendor's PDF information sheet https://microworks.com/files/PrISM_Overview.pdf (200, 323,426 bytes, text-extracted). LIBRARY VINTAGE: it is the vendor's CURRENT published documentation but authored 2009-2010 (Last-Modified 2010-01-19 on Purge_Customers.htm, 2016-10-29 on Credit_Card.htm), so it bounds what Microworks DOCUMENTS, not what the product does today. CONTROLS, tokenised, positive control 'PriSM' passing on every corpus (132 live site, 300 live library, 1,351 archive): 'uptime' 0 / 0 / 0; 'SLA' 0 / 0 / 0; 'incident' 0 / 0 / 0; 'service status' 0; 'status page' 0 in both libraries. POISON: 'status page' returns 2 hits on the live site and BOTH are homonyms - they are on products/rapidrun.htm and refer to the CUSTOMER'S ORDER status page in the WebOrder delivery tracker, 'a customer who places a web order can track their driver and see how close they are using the order status page' - an untokenised or substring search would read those as hits. 'outage' is 0 on the live site, and its only library hits are power outages and a UPS in Random_Thoughts.htm and System_Statup_Procedures.htm. 'downtime' returns 3 live hits, all marketing - warranty swap-out in the FAQ and the 'no downtime' cloud-update bullet on the payments page and in the 2020 release. CATCH-ALL POISON, measured: every fabricated subdomain of microworks.com returns HTTP 200 with a byte-identical 163-byte cPanel placeholder (md5 f1fb042c62910c34be16ad91cbbd71fa) - I probed status., trust., support., nonsense-xyzzy-9f. and zzq-not-a-host-42. and all five are the same body, so a 200 on any subdomain is a wildcard soft-200, not a page. Separately, help.microworks.com has its OWN catch-all: its root and any fabricated path (https://help.microworks.com/zzq-fabricated-9f.htm) return 16,758 bytes, md5 prefix bccd8d89, Last-Modified Thu, 12 Mar 2020 14:05:24 GMT, which is the marketing homepage - discriminate on md5 and Last-Modified, never on a byte count. Real library topics under /webhelp/ are small files with their own Last-Modified dates, which is how the live library was distinguished from the catch-all. Grade C: a first-party marketing site plus my own probes of hosts the vendor controls. https://microworks.com/ · retrieved 2026-09-15 adversarially verified
A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator
reliability-contractual-uptime-sla
Consistent with commercial-autorenew-terms-published and commercial-soc2-attestation (both existing cells, no): no MSA, terms of service, or trust-centre page is publicly accessible anywhere on the site, and the complete documentation-host TOC has no SLA, uptime, or service-credit topic. There is no contractual document to carry an SLA. https://www.microworks.com/sitemap.xml · retrieved 2026-08-04
The vendor publishes written post-incident reports or root-cause summaries for major outages.
reliability-incident-postmortems
No blog, status page, or trust-centre section exists anywhere on the site (per the sitemap) or in the complete help TOC. No post-incident report or root-cause summary has ever been published for the hosted Storenet service or any other component. https://www.microworks.com/sitemap.xml · retrieved 2026-08-04
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
The manual's Support Policies topic states the hours: 'Technical support by telephone is available Monday through Thursday from 9 a.m. to 8 p.m. EST, Friday from 9 a.m. to 6 p.m. EST, and Saturday from 11 a.m. to 3 p.m. EST. After-hours and holiday support calls will be handled via pager until 11 p.m. EST, with a 30-minute or less target response time', limited to system-down problems. It is also not included in a base subscription: 'PrISM Users must have a current support contract to receive telephone support. All new turnkey systems ship with one (1) year free support', with contracts 'issued on a per-store basis' for 6, 12 or 24 months. https://help.microworks.com/webhelp/Support_Policies.htm · retrieved 2026-09-03 adversarially verified
The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator
reliability-onsite-install
On-site work is offered as a paid line item: 'Shipping, setup, travel, and installation charges are non-refundable' (Returned Equipment policy). Shortfall: no topic describes what the on-site installation or go-live service contains, who performs it, or when it applies; the FAQ's default posture is that systems 'ship pre-configured and thoroughly tested complete with diagrams and cables customized to the specifics of each location'. https://help.microworks.com/webhelp/Support_Policies.htm · retrieved 2026-09-03 adversarially verified
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Dell three-year on-site hardware warranty, two years on touchscreens, one year on other peripherals. No stated replacement turnaround time. https://www.microworks.com/home/faq.htm · retrieved 2026-08-01
Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.
reliability-backup-restore
The backup half is documented and operator-triggered. The operator runs "Paperwork | Daily | End Of Day" and "During this process all of your system data is backed up to a local folder on your hard drive and to another station (if your PrISM system has multiple computers), sales and employee information are processed for the day and transferred to history files", and the operator is warned when it fails: "you will also be prompted with warnings if there are any open orders, unposted invoices, employees not clocked out, and/or if the system cannot communicate with the computer where the backup is stored." The copy lands on hardware the operator owns, so retrieval is theirs. Three other topics instruct that "a full system backup is done prior to running this function" before destructive maintenance (Delete_Duplicates.htm, Purge_Customers.htm, Zero_Lifetime_Orders.htm). SHORTFALL: restore is undocumented and is a vendor act, not an operator one - the only recovery path in the manual is "Microworks Tech Support can often recover the missing data if you call before reindexing" (System_Overview.htm), the Import function is flagged "used by Microworks Tech Support ... there is no reason for an end-user to access this function", and no RPO or RTO figure is published anywhere. Also no on-demand backup command: the backup is a side effect of End Of Day. https://help.microworks.com/webhelp/End_Of_Day.htm · retrieved 2026-09-04
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
No AoC, P2PE listing, or compliance page is published; the payments page makes only a general encryption/tokenization claim. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
The role-based half is fully documented and granular — Password Groups as permission tiers assigned to employees, built from individually selected system functions, with a Super User override, plus per-function Required flags, per-item Password Protect, and four routing-station password modes (Passwords on Router, Password on Entry, Password on Route, Password on Entry and Route). Shortfall: authentication is a single password entered at the terminal; multi-factor authentication is not documented anywhere in the help system for either the POS or the back office, and there is no back-office login separate from the Windows workstation. https://help.microworks.com/webhelp/Setup_Password_Groups.htm · retrieved 2026-08-02
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
"Online Help" documentation is referenced from the support page. A free public video/LMS training library and an on-terminal training mode are not documented. https://www.microworks.com/home/supportform.htm · retrieved 2026-08-01
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
The documented architecture assigns fixed roles to named machines — a MANAGER1 mini tower as the server and POS1/POS2 low-profile stations as clients — with no automatic promotion of a client terminal to the server role on failure. Networking_The_Workstations.htm is a cabling/router guide with no failover procedure documented. https://help.microworks.com/webhelp/Setting_Up_Workstations.htm · retrieved 2026-08-04
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
The store's own network setup chapter documents wired LAN and router configuration only, with no cellular/LTE failover option. Only the RapidRun driver app and the handheld tablet reference wireless connectivity (Wi-Fi 6 on the handheld), and neither names a cellular failover for the store network itself. https://help.microworks.com/webhelp/Networking_The_Workstations.htm · retrieved 2026-08-04
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
There is no subscription to be month-to-month: the software is a capital purchase under a perpetual licence - EULA 2(a): "Microworks grants you a personal non-exclusive, non-transferable ... limited license to install and use a copy of the Software on your compatible computer, up to the Permitted Number of computers. The Permitted Number of computers shall be delineated at such time as you elect to purchase the Software" - and EULA 6 lets either party terminate on written notice with no term or early-termination clause. So no multi-year software commitment is imposed. SHORTFALL: the recurring commitment that does exist is enumerated and month-to-month is not among the options - "Microworks support contracts are issued on a per-store basis and have terms of six (6), twelve (12), and twenty-four (24) months", the shortest being six months, and the contract is not optional for anyone wanting help: "PrISM Users must have a current support contract to receive telephone support." Second shortfall: Microworks publishes no price for the licence or the support contract, so a buyer cannot compare terms without a quote. Third fact, from the live site rather than the manual: www.microworks.com/products/payments.htm (retrieved 2026-09-04, footer “Copyright 2025”) does advertise “Month-to-month - Month to month contracts keep pricing competitive & clear”, but its own asterisks scope it away from this claim - it is a merchant-services processing term, conditioned on “*Must be running Prism V8.1 or Prism Cloud and using integrated processing platform” and “**Available with some service providers”. The core POS software tier is still a perpetual licence plus a six-month-minimum support contract, and the newer “Prism Cloud” tier named on that page is unpriced with no published term. https://help.microworks.com/webhelp/Support_Policies.htm · retrieved 2026-09-04
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
Same basis as the already-established commercial-autorenew-terms-published (no): no MSA, terms of service, or subscription agreement is publicly accessible anywhere on the site or the documentation host's complete TOC — only Support Policies and RMA Policies exist, and neither addresses termination fees. With no published terms at all, none can state an ETF waiver. https://www.microworks.com/sitemap.xml · retrieved 2026-08-04
The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.
commercial-autorenew-terms-published
No MSA, terms of service, or subscription agreement is publicly accessible; the sitemap contains no legal/terms page beyond a privacy and SMS policy. Re-checked 2026-08-02 against the documentation host as well: the complete PrISM WebHelp table of contents (whxdata/whtdata0.xml) enumerates every topic in the system and contains no terms, contract or subscription-agreement page either — only Support Policies and RMA Policies, neither of which states renewal terms. https://www.microworks.com/sitemap.xml · retrieved 2026-08-02
The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator
commercial-processing-not-bundled
Same underlying fact as the already-established payments-processor-choice (partial): merchant processor choice exists — Microworks requires "information pertaining to your primary credit card processing company" — but the gateway is fixed and singular (PCCharge) and configured through Microworks Tech Support rather than self-service, so the operator's processor choice is brokered rather than a fully open bring-your-own-processor model. https://help.microworks.com/webhelp/Authorizer_Overview.htm · retrieved 2026-08-04
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
No processing rate of any structure is published. https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
No processing agreement or rate card is published anywhere (payments-published-rates, no; commercial-interchange-plus-published, no), so there is no published document that could cap or prohibit a unilateral rate increase, or grant a penalty-free exit on one. https://www.microworks.com/quote.htm · retrieved 2026-08-04
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
Quote-only. The quote page: "We are experiencing technical difficulties with our online quote form, please call or email us for a quote!" No per-location or per-terminal figure exists on the site. https://www.microworks.com/quote.htm · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
The catalog is structured as discrete purchasable modules — WebOrder, RapidRun, Kiosk/QR, Surveillance, Enterprise Management, Notification Service — implying à la carte purchase, but no terms or prices confirm independent cancellation. https://www.microworks.com/products.htm · retrieved 2026-08-01
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
Turn-key outright purchase is available (Dell hardware, warranty included) with leasing as an alternative, not a requirement. No published prices. https://www.microworks.com/home/faq.htm · retrieved 2026-08-01
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
The PC is commodity — turn-key systems ship on Dell and the evaluation runs on the buyer's own Windows machine — but the licence is bound to vendor-issued hardware. "The installation of a USB software license keylok is required to unlock the full operational abilities of the PrISM software," verified in Help | About by a four-digit key serial and a licensed user count, showing "N/A" if the driver fails. Shortfall: adding or replacing a terminal requires Microworks to issue a physical dongle carrying a seat count, so hardware freedom stops at the licence key. https://help.microworks.com/webhelp/USB_Software_License_Keylok.htm · retrieved 2026-08-02 adversarially verified
One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.
commercial-implementation-fee-published
No implementation, menu-build, onboarding, or training fee figure is published, nor is any stated as $0. https://www.microworks.com/quote.htm · retrieved 2026-08-01
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
Storenet reports are described as delivered in spreadsheet format by store or across stores. Full transaction-level self-serve export of orders, line items, payments, and labor is not documented — though the on-premise database is physically in the operator's possession. https://www.microworks.com/products/enterprise-management.htm · retrieved 2026-08-01
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Customer report family produces customer lists and mailing labels; reports are available in spreadsheet format. Machine-readable export of loyalty point ledgers and gift-card liability balances is not documented. https://www.microworks.com/products/reporting.htm · retrieved 2026-08-01
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Same basis as commercial-autorenew-terms-published (no): no MSA or terms of service is publicly accessible anywhere, so no post-termination data-retrieval window is stated. The only documented export mechanism at any time is Scheduled_Reports.htm's PDF/HTML report files, with no termination-specific provision. https://www.microworks.com/sitemap.xml · retrieved 2026-08-04
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Read the complete published agreement end to end. The EULA is self-declared as the whole of it - section 7: "This EULA (including any addendum or amendment to this EULA which is included with the Software) is the entire agreement between You and Microworks relating to the Software and the support services (if any) and they supersede all prior or contemporaneous oral or written communications, proposals and representations" - and nowhere in its seven sections is merchant transaction or customer data mentioned at all. Every ownership clause runs the other way and is about the software: 3, "You acknowledge that Microworks retains the ownership of all patents, copyrights, trade secrets, trademarks and other intellectual property rights pertaining to the software", and 2(d), "Microworks and its suppliers retain all right, title and interest ... in and to, the Software and all copies thereof. All rights not specifically granted in this EULA are reserved by Microworks." There is no merchant-ownership statement and no constraint on vendor use or resale of operator data, because operator data is not a subject of the document. (The manual-hosted binding set was read to its end and is now complete: EULA.htm, RMA_Policies.htm, Support_Policies.htm and Copyright.htm - the last recovered on 2026-09-04 from the manual’s own search index, having been unreached by the href crawl. RMA_Policies is hardware logistics, Support_Policies is support terms and hours, Copyright is a documentation-reproduction and trademark notice dated 1993-2016; none mentions merchant transaction or customer data. Confirmed 2026-09-04 that microworks.com publishes no terms, privacy policy, DPA or MSA - /terms, /legal, /privacy, /eula, /msa and /sla all 404. The on-premise architecture gives the operator physical custody of the database, which is a structural protection, not a contractual one.) https://help.microworks.com/webhelp/EULA.htm · retrieved 2026-09-04
The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).
commercial-source-available-selfhost
Proprietary commercial software. It is self-hosted on-premise, which satisfies the deployment half, but no source is published under any license. https://www.microworks.com/demo.htm · retrieved 2026-08-01
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
P2PE and tokenization claimed with "keep cardholder data off the POS." No validated P2PE listing and no named SAQ type (A / P2PE-HW). https://www.microworks.com/products/payments.htm · retrieved 2026-08-01
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
Authentication is documented as a single password entered at the terminal (reliability-mfa-role-based-access, existing cell: partial, no MFA documented anywhere in the help system for POS or back office), which forecloses the MFA-for-CDE-access control. The payments marketing page (re-read 2026-08-04) makes only a general tokenization/P2PE claim with no PCI DSS 4.0.1 AoC and no mention of payment-page script-integrity monitoring. https://help.microworks.com/webhelp/Setup_Password_Groups.htm · retrieved 2026-08-04
Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.
commercial-soc2-attestation
No SOC 2, ISO 27001, or trust center is mentioned anywhere on the site or in the sitemap. Re-checked 2026-08-02 against the documentation host as well: the complete PrISM WebHelp table of contents contains no trust-centre, audit or certification topic. https://www.microworks.com/sitemap.xml · retrieved 2026-08-02
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
Two of the three mechanical DSAR actions are documented in-product. Locate: the Marketing Module's Customer Filter searches on a chosen field with Equals or Contains - "Value - Enter the field value on which you'd like to filter. Field - A search based on the Value entered will be performed on the field selected from this drop-down list" - plus a Search Name lookup on the order screen. Export: "You may also export the selected customers into a variety of data formats." Edit: "Customer data may also be edited from this section. Simply double-click on the customer record of which you'd like to edit." SHORTFALL 1: no per-record erasure is documented; the only documented deletions are bulk and rule-based - Purge Customers "will allow you to remove customers that have not ordered since a particular date" and Delete Duplicates "will remove records with duplicate addresses" - and deletion is soft until an unrelated maintenance run: "When a piece of data is deleted from the PrISM system ... it is marked for deletion, meaning that it is hidden from view but still actually exists. Reindexing the files completely deletes data that is marked for deletion" (System_Overview). SHORTFALL 2: no DPA, and none is possible from the published record - the EULA is the entire published agreement and contains no data-protection terms, and zero of the 269 topics of the closed manual census mention GDPR, CCPA or a privacy policy. https://help.microworks.com/webhelp/Browse_Customers.htm · retrieved 2026-09-04
Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator
commercial-wcag-kiosk-accessibility
No VPAT/ACR or WCAG claim is published; the kiosk and QR ordering page is silent on accessibility. https://www.microworks.com/products/kiosk-qr-ordering.htm · retrieved 2026-08-01
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
Follows directly from payments-dual-pricing and menu-pricing-dual-pricing (both no): the complete pricing engine has no tender-based price dimension at all, so there is no dual-pricing/surcharge feature to be card-network-compliant, exclude debit/prepaid cards, or carry a disclosure requirement. https://help.microworks.com/webhelp/Pricing.htm · retrieved 2026-08-04
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 62 values — 47 upheld, 15 downgraded, 0 upgraded. It separately resolved 152 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.processor_lock_in | upheld | Checked against the authorisation chapter rather than the payments marketing page the earlier passes used. Lock-in is real but partial: PrISM authorises exclusively through one gateway — "PCCharge is currently the authorization software package chosen for integration with the PrISM system" — while the merchant's own processor is configurable, but only by Microworks tech support, who "require information pertaining to your primary credit card processing company." No supported-processor list, no self-service switch, and the payments page separately gates counter-top and mobile devices on "Prism V8.1 or Prism Cloud and using integrated processing platform," which pulls current hardware toward the vendor's own PrISM Merchant Services. Partial, not full lock-in and not open choice. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| menu-pricing-fractional-placement | yes / grade B, cites help.microworks.com/webhelp/Pricing.htm | upheld | I retrieved Pricing.htm myself rather than trusting the citation. The Fraction field is real and first-class: "This field is used for fractional topping pricing such as half and quarter. Fractions only apply to modifiers," with the worked row set "(Price=1.00, Count=1, Fraction=Whole), (Price=0.50, Count=1, Fraction=1st Half) and (Price=0.50, Count=1, Fraction=2nd Half)." That is per-fraction placement with its own price row, in first-party product documentation. Nothing to downgrade. source |
| menu-pricing-half-and-half-rule | yes / grade B, cites Pricing.htm; note already conceded no max-of-halves or average-of-halves rule | downgrade-to-partial | Same page, read for the rule rather than the field. Pricing.htm enumerates its pricing axes — Count, Fraction, Size, Store Rule, Order Type, Double Count, Level — and contains no guidance whatsoever on how a half-and-half pizza resolves to a price. There is no charge-the-higher-half rule, no average-the-halves rule, and no whole-pizza reconciliation; the operator gets additive per-fraction modifier rows and nothing else. The researcher wrote that shortfall into the note and then scored it `yes` anyway. Named shortfall: pricing a half-and-half is an operator convention expressed by hand-entered 1st Half / 2nd Half price rows, not a configurable rule the system applies. source |
| menu-pricing-size-style-matrix | yes / grade B, note states "Style (crust) as a second axis is still undocumented" | downgrade-to-partial | A matrix needs two axes. Pricing.htm documents one: "The Size field relates the pricing level selected to the menu item that you are working on." I checked the full axis list on the page — Count, Fraction, Size, Store Rule, Order Type, Double Count, Level — and crust or style appears nowhere as a pricing dimension, nor is there a Style Setup topic in the 488-topic help TOC (Size_Setup.htm exists, no style equivalent). Named shortfall: size-based price levels only; crust/style must be modelled as separate menu items or modifiers, so there is no size x style price matrix. source |
| reporting-server-scorecards | yes / grade B, cites www.microworks.com/products/reporting.htm, note lists Average Ticket, Server Ticket, Server Mix, Server Tip | downgrade-to-partial | Two problems, one fatal. First, the citation is graded wrong: I retrieved products/reporting.htm and it is a vendor marketing feature page — promotional framing, a list of report names, no field definitions or procedures. Under the evidence rules that is grade C, not B, which puts a differentiator `yes` below the floor. Second, I went to the administrator manual to see whether a scorecard actually exists. Server_Report.htm describes "a summary of a server's activity for the day", "generated according to server number", with an optional "one-line summary of each order assigned to the server" — a per-server day sheet, run one server at a time. Named shortfall: no cross-server ranking, no benchmark or league table, no period-over-period trend; the scorecard metrics are report titles on a sales page, not documented fields. source |
| labor-server-performance-metrics | yes / grade B, cites www.microworks.com/products/reporting.htm | downgrade-to-partial | Same mis-grade — products/reporting.htm is a marketing page (grade C), so a differentiator `yes` cannot rest on it. Checking the manual instead: Server_Report.htm gives "all of the server's totals for the day" per server number, and Employee_Reports_Overview.htm sits over an employee report family. Per-employee sales totals are therefore documented. Named shortfall: the specific metrics the claim asks about — average check per server, tip percentage, item mix, sales per labour hour — appear only as report *names* on the marketing page and are defined nowhere in the manual, and no productivity ratio against hours worked is documented anywhere. source |
| inventory-native-not-partner | yes / grade B, cites www.microworks.com/products/reporting.htm with the note "delivered by Prism itself" | upheld | The citation was a marketing page, so I re-derived the conclusion from the manual and it holds comfortably. Recipe_Cost_Setup.htm: the Recipe Cost Manager lets you "specify which inventory items, and in what amounts, are always used to assemble a given menu item. This aides in the providing accurate food cost calculations," with portion units, auto-derived assembly costs, order-type-dependent components and modifier costs. Assembly_Item_Setup.htm, Inventory_Master_u.htm, Inventory_Prices_u.htm, Inventory_Location.htm and Daily_Inventory_Screen.htm are all first-party PrISM topics. No third-party product is named anywhere in the inventory books. Value upheld; evidence replaced with grade-B documentation. source |
| hardware-commodity-devices | yes / grade B, cites www.microworks.com/demo.htm, note asserts "turn-key systems ship on standard Dell PCs" | upheld | The note was right and the citation was wrong. I retrieved demo.htm: it is a marketing evaluation-request page, it says only "encourage you to try our full featured software evaluation on your home or office Windows based computer," and it never mentions Dell — the researcher's Dell assertion was not supported by the page they cited. The manual does support it. Setting_Up_Workstations.htm states "Microworks PrISM for Windows turn-key systems ship on Dell(TM) hardware," naming a Mini Tower (MANAGER1) and a Low Profile (POS1) with ordinary parallel, serial, network, video and USB connectors. Commodity x86 Windows hardware, not proprietary terminals. Value upheld, citation moved to the documentation that actually says it. source |
| commercial-hardware-not-locked | yes / grade B, cites www.microworks.com/demo.htm — "software runs on standard Windows PCs" | downgrade-to-partial | The hardware is commodity but the licence is not, and the manual says so in a topic the researcher did not open. USB_Software_License_Keylok.htm: "The installation of a USB software license keylok is required to unlock the full operational abilities of the PrISM software," verified in Help | About by a four-digit key serial and a licensed user count, and showing "N/A" instead of a serial if the driver fails. Named shortfall: you may buy your own Dell, but PrISM will not run in full without a vendor-issued physical dongle carrying a seat count, so adding a terminal is gated on Microworks issuing hardware — that is a licence lock expressed in hardware, and the differentiator `yes` overstates the buyer's freedom. source |
| reliability-menu-build-service | yes / grade B, cites www.microworks.com/products/pizza-pos.htm — "Customized Menu and Database Setup is listed as part of the delivered offering" | downgrade-to-partial | I retrieved pizza-pos.htm. It is a marketing page — grade C, not B — and the entire evidence base is one bullet, "Customized Menu and Database Setup," plus the sales sentence "Our support staff will pre-configure your system to arrive with your menu, pricing, and inventory, setup and ready to go." A differentiator `yes` cannot stand on a feature-page bullet. I searched the 488-topic help TOC for a corroborating implementation or onboarding chapter: there is Installation Overview, Going Live, Support Policies and RMA Policies, and none of them describes a menu-build service. Named shortfall: the service is asserted in sales copy with no documented scope, turnaround, item ceiling, or statement of whether it is included in the purchase or billed separately. source |
| reliability-local-transaction-engine | yes / grade B, cites www.microworks.com/products/enterprise-management.htm | upheld | Cited page is marketing (grade C), so I re-sourced it. Setting_Up_Workstations.htm documents an in-store estate of named Windows machines — a MANAGER1 mini tower and POS1/POS2 low-profile stations wired to a store LAN — which is an on-premise transaction estate by construction. The marketing page's verbatim "each store can upload its entire database nightly" and "Hosted Server and Unit Locations Can Update Database Nightly" corroborate that the production database is store-local and the hosted side is a nightly copy. Caveat I am carrying forward from the previous pass rather than clearing: the payments page conditions current payment devices on "Prism V8.1 or Prism Cloud," and Prism Cloud has no published architecture, so this `yes` applies to the on-premise product only. source |
| delivery-driver-tracking | yes / grade B, cites www.microworks.com/products/rapidrun.htm | downgrade-to-partial | I retrieved rapidrun.htm. It is a marketing page, so the grade is C and a differentiator `yes` is below the floor — and the substance is thinner than the grade problem suggests. The page does say "The store can view driver's location from route screen" and "Turn-by-turn mapping directions to each location in the run," but RapidRun does not appear anywhere in the 488-topic PrISM administrator manual: there is no RapidRun book, no GPS or tracking topic, and Driver_Tab.htm covers only reimbursement method, personal bank, company car and odometer forcing. The same page also says "No additional Licensing is necessary" for the store-side viewing app specifically, which implies the driver app itself is licensed separately. Named shortfall: live driver position is a vendor marketing claim for an undocumented, separately licensed companion app, with no documented refresh interval, geofence, or breadcrumb history. source |
| digital-native-app | yes / grade B, cites the Apple listing for Greco Pizza; note concedes the apps are per-chain WebOrder wrappers | downgrade-to-partial | I opened the App Store listing myself and the factual core survives: the seller is "Microworks POS Solutions, Inc." and the app is a single-brand consumer ordering app for Greco Pizza. But two branded builds for two named chains is not a productised capability. The PrISM help system's consumer-facing book is Web Ordering Overview and Customer Interface — browser ordering — with no native-app topic, no app configuration chapter, and no branding or store-submission workflow anywhere in the TOC, and Microworks publishes no app product page. Named shortfall: branded native apps exist only as bespoke per-chain builds the vendor produces for specific customers (Greco Pizza, Mark's Pizzeria), with no documented availability, pricing or self-serve path for an ordinary buyer, and the app store rating of 2.1/5 across 50 ratings is consistent with a wrapper rather than a maintained product. source |
| delivery-tracking-page | yes / grade B, cites www.microworks.com/products/rapidrun.htm | upheld | Challenged because the sibling driver-tracking cell conflated store-facing and customer-facing views. Retrieving rapidrun.htm and reading for the distinction, the customer-facing half is stated in its own right: "Customers can see if their order picked up and where the delivery is located on a map," tracked through the web order status page, with SMS alerts when the order is out for delivery and "when the delivery has arrived at the customers door." That is separate from "The store can view driver's location from route screen." Value upheld; grade corrected from B to C because the page is marketing, which the floor permits for a table-stakes claim. source |
| delivery-dispatch-board | yes / grade B, cites www.microworks.com/products/delivery-pos.htm | upheld | Held to the conclusion-flipping bar, and it clears it on two independent sources. The manual confirms the module exists and is native: Assign_Orders.htm — "The Assign Orders function launches the Driver Routing module. Within this module, orders may be routed, or assigned, to drivers for delivery." The marketing page supplies the board's behaviour verbatim — "Orders are listed in an easy-to-read, oldest order first format with sectors displayed for creating smarter multi-order runs" — and Routing_Tab.htm supplies the lateness policing (Mark Lates Automatic, Auto Late Minutes). This is an in-house dispatch board, not a DaaS handoff. Value upheld; citation moved to the manual and grade held at B on that basis. source |
| delivery-driver-roster | yes / grade B, cites www.microworks.com/products/delivery-pos.htm | upheld | Retrieved delivery-pos.htm and confirmed verbatim: the module "displays a list of all employees that are currently clocked in as a Driver job classification and allows simple touch screen access for order assignment." The manual corroborates that Driver is a real job class with its own configuration — Driver_Tab.htm carries Driver Reimbursement by (Per Mile, Per Order, Percent of Total Sales, Percent of Pre-Tax Sales, Sector/Streets Reimbursement, Manual), Personal Bank, Default Company Car, Check Ins. Exp. Date and Force Odometer Miles — so the roster is driven by clock-in state against a first-class driver role. Value upheld; grade corrected B to C, since the roster screen itself is described only on the marketing page. source |
| delivery-cash-reconcile | yes / grade B, cites www.microworks.com/products/reporting.htm — report names only | upheld | Report names on a marketing page are not a settlement flow, so I went looking for the mechanism. Cash_Drop.htm documents it: a cash drop lets you "take any amount of money from the employee, place it in a secure location, and reflect that action as a credit to the employee's cash responsibilities," the drop is recorded against the employee in the Employee List, and "till totals will reflect receiving cash drops when balancing the till." That is a per-driver cash-responsibility ledger reconciled against the till, corroborated by Till_List.htm and Driver_Report.htm in the same book. Value upheld, evidence replaced with grade-B documentation. source |
| delivery-3p-direct-integration | partial / grade D, cites www.microworks.com/products/delivery-pos.htm | downgrade-to-unknown | `partial` asserts the capability exists and is limited. Here even existence is unestablished. The whole basis is one hedged marketing sentence I retrieved verbatim — Prism "integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" — with no named integration partner, no middleware vendor, no certification, no setup topic, and no configuration screen. I checked the complete 488-topic help TOC: there is no marketplace, aggregator, GrubHub, Uber Eats, DoorDash or injection topic in any of the eleven books. Microworks is absent from DoorDash's 2026 Preferred Integration Partner cohort, and every downstream cell in this record (injection, menu push, 86 sync, store pause, reconciliation, error visibility) is already `unknown`. A sales sentence establishes a claim, not a fact. Grade F, rationale only, no url. source |
| extensibility-first-party-delivery-integrations | partial / grade D, cites www.microworks.com/products/delivery-pos.htm | downgrade-to-unknown | Identical evidence to delivery-3p-direct-integration and it fails for the identical reason: the sole source is the hedged sentence "integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" on a marketing page. This claim asks specifically whether the integrations are first-party and direct, and the vendor never says — no partner page, no integration directory, no certification badge, and nothing in the help TOC across all eleven books. Since the distinguishing property the claim tests is exactly the one the vendor declines to state, `unknown` is the honest value and `partial` was an inference dressed as a finding. Grade F, no url. source |
| menu-pricing-franchise-hierarchy | partial / grade D, cites www.microworks.com/products/enterprise-management.htm | upheld | Challenged because the note's "Master menu" language read like a paraphrase of a bullet. It is not — I retrieved the page and it is verbatim: Storenet "creates the ability for a single 'Master' menu and inventory to be shared by multiple locations, and provides the tools to sort out differences in price, costs and selection." So a corporate-to-store menu hierarchy with per-store variance is a first-party stated capability. The partial is correct and its shortfall is understated rather than overstated: propagation is nightly ("Hosted Server and Unit Locations Can Update Database Nightly"), not real-time, no field-level lock or approval governance is described, and the page contains no mention of franchise royalty reporting at all — which is why multi-location-royalty-calculation and -collection remain `unknown`, correctly. Grade corrected D to C: this is a first-party product feature page, not a press release. source |
| payments-processor-choice | partial / grade B, cites help.microworks.com/webhelp/Authorizer_Overview.htm | upheld | Retrieved the page and the partial is right, though the shortfall deserves sharper naming. The gateway is fixed and singular: "PCCharge is currently the authorization software package chosen for integration with the PrISM system," supporting "both traditional dial-up as well as broadband Internet-based authorizations." Merchant processor choice exists but is brokered — Microworks requires "information pertaining to your primary credit card processing company" and setup runs through their tech support. Named shortfall: no supported-processor list is published, the customer cannot self-configure, and PCCharge is a discontinued Verifone product, so the choice is whatever that end-of-life gateway still certifies. source |
| reliability-offline-card-auth | unknown / grade F, "no public documentation located" | upheld | Tested rather than accepted, because this is a conclusion-flipping cell and the record now has a card-authorisation chapter it did not have two passes ago. Authorizer_Overview.htm describes a deferred-capture model — "When a charge is made in PrISM, the amount of the sale is simply authorized... The actual transaction is not completed until the batch of validations are processed" — which is auth-now/settle-at-batch, not offline authorisation. The page states nothing about behaviour when the dial-up or broadband link is unavailable, nothing about a store-and-forward queue, floor limits, or who carries the decline risk. So the answer really is unresolved rather than absent, and `unknown` stands; I am recording the source so the next pass does not have to rediscover that this chapter exists and does not answer the question. source |
| guest-loyalty-stored-value-gift | partial / grade B, cites Gift_Certificates.htm — reversal of an earlier pass's downgrade | upheld | This cell has now been scored three different ways, so I checked it from scratch. Gift_Certificates.htm confirms a genuine prepaid ledger: "Gift Certificate accounts are very similar in function to Customer Accounts with the exception that these accounts are pre-paid," created during order taking, with a transaction history of "payments, credits, and balance," a Credit Account function and Print Statement, and a manual-override warning that normal issuance happens at the till. Open_Gift_Activity_Report.htm shows "all gift card activity for the date range you specify... the activation of new certificates as well as redemption of existing certificates," grouped per certificate. So the earlier pass's "no balance or activation reporting exists anywhere" was wrong. Partial rather than yes is still correct, and I am tightening the shortfall: the activity report is transactional, not a period-end outstanding-liability total, and balances live in the store-local database with only a nightly StoreNet upload, so brand-wide redemption is undocumented. source |
| labor-native-scheduling | yes / grade B — a re-score that overturned a prior verification downgrade to partial | upheld | An overturned adversarial verdict is exactly the thing to re-test, so I opened the module myself. Employee_Scheduling_Overview.htm: "The PrISM Employee Scheduling Module provides comprehensive creation and modification of employee schedules, as well as access to all employee information defined within the system," with "access to key store volume, shift, and scheduling reports" and the ability to work with existing schedules or create a new one. The help TOC carries the whole book beneath it — Create Schedule, Schedule Management, New Schedule, Shifts, Shift Map, Availability, Forecast Indicators — plus an Availability tab on the employee file. That is schedule construction in-product, not a schedule report, so the re-score was right and the earlier downgrade was wrong. Caveat for the note: no publish-to-staff, shift-swap or mobile-notification mechanism is documented; the schedule is a back-office artefact. source |
| menu-pricing-dual-pricing | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | Positive absence by enumeration of the pricing engine. Pricing.htm enumerates every dimension a price row can vary on — Count, Fraction, Size, Store Rule, Order Type, Double Count, Level — and payment tender is not among them; Advanced_Pricing_Tab.htm adds only level- and modifier-based methods. The complete help TOC has no dual-pricing, cash-discount, or surcharge topic, and the payments marketing page (microworks.com/products/payments.htm), the one place a processing-side cash-discount program would be sold, is silent on it. source |
| payments-offline-decline-liability | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | The claim is about documentation existing, and it does not: the manual's complete card-auth documentation (Authorizer_Overview.htm) has an authorize-at-order, settle-at-batch model with no store-and-forward or offline-capture concept at all, so no decline-on-reconnect liability statement and no post-reconnect failure report exists anywhere in the enumerated 11-book manual, and the payments marketing page is silent on offline behaviour. source |
| kitchen-expo-consolidation | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | Makeline_Monitor_Overview.htm enumerates the entire screen and every control of the product's only kitchen display: a flat item list (Ord#, Qty, Description, Elaps, Type) with per-item Clear, order-type Filter, Select mode, Font, Made, and navigation. No expo view, no station concept, no order-level completion state exists on a complete UI enumeration, and the makeline book in the TOC holds only this screen plus a refresh-interval/aging-timer tab. source |
| kitchen-printer-fallback | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-partial | Printer_Setup.htm documents a per-device Backup Device field: "Choose another device to act as a backup in case PrISM cannot print to this device" — documented failover to a designated backup printer, grade B. Named shortfall: no no-ticket-loss guarantee, no staff alert on failover, and nothing documented for a failed Makeline Monitor screen, since the field is framed entirely around printing. source |
| guest-loyalty-referral-program | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | Positive absence by enumeration of the complete marketing/loyalty toolset in the help TOC: Buyer's Club points, Comeback Coupons, Advertised Coupons, Customer Survey, and direct-mail Labels. No referral topic exists anywhere in the TOC and no retrieved loyalty topic mentions per-guest codes, referred-order attribution, or two-sided rewards; a native referral mechanic could not be configured without appearing in this enumerated surface. source |
| labor-break-compliance-by-state | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | The time clock documents break handling in full as a manual unpaid punch ("The Break function is used when an employee needs to take an unpaid break during their shift", Start/Stop Break), and Payroll_Tab.htm enumerates the entire labour-law configuration surface as overtime multipliers, daily/weekly OT thresholds, a labor goal, and pay-rate display toggles. No break-rule configuration, attestation prompt, or missed-break premium flag exists anywhere in the complete TOC. source |
| labor-minor-labor-rules | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | The employee file's Details tab — the only home for ancillary data like a birth date — states "All fields on this tab are optional and are not used elsewhere in the system", the vendor's own words foreclosing age-driven enforcement. The Availability tab is manual per-day time frames with no age dimension, and the complete scheduling module book and time clock documentation contain no minor-labor, age, or school-hours rule at scheduling or clock-in. source |
| extensibility-oauth-partner-apps | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | There is no third-party app surface to authenticate: the complete help TOC across eleven books has no API, developer, OAuth, token, or partner-app topic, and the only documented integrations are vendor-built point connections (desktop QuickBooks Interface Module, Caller ID link, WebOrder injection). No app credentials of any kind exist for an operator to grant or revoke. source |
| extensibility-webhooks-push | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | The complete help TOC contains no webhook, event, callback, or push topic; the only documented outbound surfaces are scheduled report files (PDF/HTML to folder, email, or printer) and the desktop QuickBooks file interface. This aligns the cell with the record's api_posture, which already established webhooks: none published from the same enumeration. source |
| reliability-printer-fallback | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-partial | Failover is documented — every device in Printer Setup takes a Backup Device "in case PrISM cannot print to this device" — but the claim's second half, alerting staff, is documented nowhere in Printer_Setup.htm or the troubleshooting topics. Partial with the missing staff alert as the named shortfall. source |
| reliability-sync-conflict-handling | unknown, grade F, carrying the placeholder rationale "No public documentation located during the 2026-08-01 research pass" — a marker that no one had examined the cell, not a finding of absence | resolve-to-no | The claim asks whether conflict-resolution behaviour is documented; it is not. The only multi-node data flow in the manual is StoreNet Satellite's one-way master upload ("Once performed this cannot be undone") with stores downloading "at the next prescribed interval" — no merge, prompt, or conflict concept — and Networking_The_Workstations.htm is a cabling/router install guide with no partition behaviour. Nothing in the complete TOC addresses concurrent edits on two devices. source |
| order-capture-seat-level | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Checked the complete order-entry and check surface: Table Setup (table wizard, drag-position, sections — no per-table seat-capacity or seat-number attribute), Splitting Checks (splits by entering "the number of checks you would like to add" or by moving individual items — no seat-based split), and Ordering Advanced Options (Sold Out Item, Reprint History, Re-Assign Orders — no seat function). No topic anywhere in the 488-topic manual assigns an order line to a seat number; the complete Ordering Module book (New Order, Creating An Order, Updating An Order, Settling An Order, Splitting Checks, Customer Last Order, Customer Information, Ordering Advanced Options, Time Clock) has no seat concept. source |
| order-capture-coursing-hold-fire | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Advanced Kitchen Printing routes items "based on order type" and "based on level" with Primary/Secondary printer rules — the complete kitchen-routing mechanism — with no course concept. The Ordering Module book has no hold/fire or course-assignment topic, and the Makeline Monitor's complete field set (Ord#, Qty, Description, Elaps, Type, Clear, Made) has no course grouping or fire-next-course action from a handheld/terminal/expo screen. source |
| order-capture-bar-tab-preauth | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete card-authorization documentation describes one tender pattern only: "When a charge is made in PrISM, the amount of the sale is simply authorized... The actual transaction is not completed until the batch of validations are processed." No open-tab, incremental re-authorization, or auto-close-at-end-of-day workflow is described, and no "tab" topic exists anywhere in the 488-topic manual or the Ordering Module book. source |
| order-capture-drive-thru | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The vendor's complete product catalogue (WebOrder, RapidRun, Kiosk/QR Ordering, Digital Surveillance, Enterprise Management/Storenet, Notification Service, Handheld Ordering, plus core POS) contains no drive-thru product, and no drive-thru topic exists anywhere in the 488-topic administrator manual. Microworks positions itself as a pizza/delivery/takeout POS; order-point/pay-window/pickup-window flow is not part of the documented or marketed product. source |
| order-capture-drive-thru-timers | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Dependent on order-capture-drive-thru (no evidence): the vendor sells no drive-thru product or hardware, so there is no drive-thru order to time. No speed-of-service-by-segment topic exists anywhere in the manual. source |
| order-capture-voice-ai | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete 488-topic help TOC across all eleven books, plus the full vendor product catalogue, contains no AI, voice, speech, or virtual-agent topic anywhere. The only phone-related feature documented is Caller ID Customer Link (inbound call pops the customer record) — a lookup, not order-taking. No named voice-AI partner program is published. source |
| order-capture-throttling | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Ordering tab of Location Maintenance is the complete set of order-intake configuration: Use Customer Last Order, Maximum orders retrieved, Timed Order Check Interval, Sales Tax, Use Comeback Coupon, Use Buyer's Club, Customer Survey Invitation, Force Street Check, Currency Selection/Conversion. No capacity limit, per-slot order cap, or automatic quote-time extension field exists among them. source |
| menu-pricing-86-propagation | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | A manual 86 mechanism exists at the terminal: "Sold Out Item — Mark menu items as unavailable. The interface displays available items in green and 'Sold Out' items in red," toggled by pressing the Sold Out button then the item, or Avail. to re-enable. Shortfall: this is a single-terminal manual toggle documented nowhere as propagating to WebOrder, kiosk, or third-party marketplaces — the Web tab's Visibility field (store/web/both) is a separate, independently-set flag — and no propagation latency is stated anywhere. source |
| menu-pricing-countdown-auto-86 | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The menu item Advanced tab and Web tab are fully enumerated (UPC, Advanced Web images, Doubles Class, Points, Fav. Sort, Auto Note, Key Item, Password Protect, Visibility, Web Sort/Group/Label/Desc.) and contain no countdown/par-count field. Inventory_Master_u.htm's Reorder Level is a purchase-order threshold ("the level at which you would like the system to prompt you to order more"), not a per-item sale counter that zeroes and auto-86s a menu item, and no scheduled auto-restore exists anywhere in the manual. source |
| menu-pricing-versioning-effective-dates | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Pricing Level Exceptions is the complete mechanism for time-varying prices: Level Name, Level Type, Level Priority, Inactive, and Triggered By (most commonly Time of Day, combinable with other conditions), with an Advanced tab letting one level override another. Every documented trigger is a recurring day/time window, not a one-time future effective date; there is no staged-version preview, publish action, or rollback-to-prior-version concept anywhere in Pricing.htm or Pricing_Level_Exceptions.htm. source |
| menu-pricing-allergen-nutrition | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The menu item Web tab (Visibility, Reference, Web Sort, Web Group, Instructions, Base Item, Web Label, Web Desc., Web Special, Special Image File, Web Thumbnail, Web Image) and Advanced tab are the complete set of documented per-item metadata fields, and neither carries an allergen flag or nutrition value. Includes_Tab.htm (ingredient/topping allowances) likewise has no allergen field. No allergen or nutrition topic exists anywhere in the 488-topic manual. source |
| menu-pricing-dynamic-pricing | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Pricing.htm enumerates every dimension a price row can vary on — Count, Fraction, Size, Store Rule, Order Type, Double Count, Level — and Advanced_Pricing_Tab.htm adds only level- and modifier-based methods. None is demand-based or algorithmic; all are operator-set tables activated by fixed rules (day/time, order type, size). No floor/ceiling guardrail concept and no automatic demand-responsive adjustment is documented anywhere. source |
| payments-dual-pricing | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same finding as menu-pricing-dual-pricing: Pricing.htm enumerates every price dimension (Count, Fraction, Size, Store Rule, Order Type, Double Count, Level) and payment tender is not among them. Advanced_Pricing_Tab.htm adds only level- and modifier-based pricing. No cash-vs-card price field, no dual-pricing or cash-discount topic exists anywhere in the 488-topic TOC, and the payments marketing page (microworks.com/products/payments.htm, re-read 2026-08-04) sells the integrated processing stack with no dual-pricing program mentioned. source |
| payments-surcharge-guardrails | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | A surcharge/dual-pricing engine does not exist in the documented pricing model (payments-dual-pricing, no), so there is no BIN-detection debit/prepaid exclusion, network percentage cap, or per-location enable/disable to document. The complete pricing surface (Pricing.htm, Advanced_Pricing_Tab.htm) has no tender-based pricing dimension at all. source |
| payments-tip-pooling | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Payroll tab of Location Maintenance is fully enumerated — Level 1/2 Overtime Rate, Labor Percentage Goal, pay-rate display toggles, daily/weekly/period OT hour thresholds — and contains no tip pooling, tip-out, or distribution field. No tip-pool topic exists anywhere else in the 488-topic manual; the only tip-related report is a per-server Server Tip listing (labor-tip-distribution-audit-trail), not a pooling/allocation engine. source |
| payments-offline-store-and-forward | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete card-authorization documentation describes an authorize-at-order, settle-at-batch model through the integrated PCCharge gateway and contains no store-and-forward concept, no offline capture, and no per-transaction or cumulative offline cap. No other topic in the complete help TOC covers offline card capture. Consistent with the already-established payments-offline-decline-liability finding (no) on the same page. source |
| payments-chargeback-tooling | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The gateway's documented surface ends at settlement: "the Transaction List will only be available for review from within the PCCharge application's history reports section" once the batch closes. No dispute, chargeback, or evidence-assembly topic exists anywhere in the manual; disputes would be handled entirely inside the third-party PCCharge/processor tooling, outside PrISM. source |
| kitchen-course-firing | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Kitchen routing is fully documented as printer/level/order-type based ("print items to multiple kitchen printers at once... print items differently based on order type... based on level"), with no course concept. Makeline_Monitor_Overview.htm's complete field set (Ord#, Qty, Description, Elaps, Type, Clear, Made) has no course grouping, hold state, or fire-on-demand action from a handheld/terminal/expo screen. source |
| kitchen-prep-time-pacing | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Makeline tab's complete configuration is a Makeline Timer (flags an item "old" after an elapsed threshold) and a Makeline Refresh interval — both location-wide constants, not per-item cook times. Makeline_Monitor_Overview.htm shows a flat, un-staggered item list with a single Elaps column; no per-item configurable cook time and no staggered start/display logic to synchronize finish times is documented anywhere. source |
| kitchen-order-throttling | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Ordering tab of Location Maintenance is the complete order-intake configuration (Timed Order Check Interval, Sales Tax, coupons, Survey, Force Street Check, Currency) and contains no load-based throttling or quote-time extension. Makeline_Tab.htm's only thresholds are a display aging timer and refresh interval, not an order-release pacing rule. source |
| kitchen-item-build-screens | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Makeline Monitor's complete field set — Ord#, Qty, Description, Elaps, Type, plus Clear/Select/Made/Font/Filter controls — is fully enumerated. Description is a single text line; there is no dedicated recipe-step, portioning-diagram, or full modifier-breakout view. No item-build or assembly-detail screen is documented anywhere in the manual. source |
| kitchen-pizza-fractional-display | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete makeline screen (Ord#, Qty, Description, Elaps, Type) has no dedicated visual rendering for half/quarter topping placement — Description is plain text. Fractional pricing is a pricing-engine attribute (Pricing.htm's Fraction field), and nothing documents it carrying through to a graphic or unambiguous half-and-half rendering on the makeline or ticket. source |
| kitchen-order-modification-alerts | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The makeline's documented controls are Clear, Select (multi-clear), Made (view cleared items), Font and Filter — there is no flag, highlight, or notification state for an item added, changed, or removed after the ticket first displayed. No modification-alert topic exists anywhere in the manual. source |
| kitchen-waste-logging | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The two topics that constitute the complete physical-inventory documentation — Daily_Inventory_Screen.htm (beginning/delivery/ending/ideal/variance) and Inventory_Master_u.htm (item, cost, reorder, key-ingredient fields) — contain no waste, spoilage, or remake logging workflow and no reason-code field. Variance from Ideal is a single aggregate number (the "Food Gap" on the Weekly Sales Recap), not an itemized, reason-coded waste entry, and there is no KDS-side logging screen documented. source |
| kitchen-speed-of-service-reporting | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Per-order Elaps (elapsed time since order placed) is a live field on the Makeline Monitor, and Server_Report.htm provides a per-server daily activity summary, but neither is a ticket/station-time report sliced by daypart and channel with average/percentile figures. The complete reporting surface (Scheduled_Reports.htm export types are PDF/HTML, no CSV/API) has no dedicated speed-of-service report by that name; reporting-server-scorecards (existing cell) already established the manual has no cross-server or trend reporting. source |
| kitchen-prep-forecasting | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Forecast Indicators — the only forecast mechanism documented anywhere in the 488-topic manual — computes a labour headcount ratio ("how many employees... need to be scheduled based on the average volume forecast") from operator-defined Numerator/Denominator volume measures, for the Employee Scheduling Module. It is not a per-item prep-quantity prediction and is not surfaced to kitchen staff as a prep list; no separate prep-forecasting topic exists. source |
| delivery-daas-dispatch | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Every delivery-dispatch topic and page checked (Assign_Orders.htm, Routing_Tab.htm, Delivery_Charges_Tab.htm, Driver_Tab.htm, rapidrun.htm) describes exclusively an in-house driver fleet — clocked-in Driver job class, RapidRun turn-by-turn routing and live position, Sector-based reimbursement. No DoorDash Drive, Uber Direct, Nash, Relay, or generic on-demand-courier hand-off is named anywhere in the manual or on the vendor site. source |
| delivery-daas-fallback | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Dependent on delivery-daas-dispatch (no evidence): since no on-demand courier marketplace integration exists at all, there is no overflow/hybrid dispatch rule to document. Routing_Tab.htm's only automation is Mark Lates Automatic / Auto Late Minutes, which flags a late in-house delivery — it does not reassign the order to an outside courier. source |
| delivery-offline-behavior | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | The on-premise architecture — store-local Windows terminals and database with only nightly sync to hosted Storenet ("Hosted Server and Unit Locations Can Update Database Nightly") — structurally implies cash delivery orders, driver assignment (Assign_Orders.htm) and driver settlement (Cash_Drop.htm, Till_List.htm) continue to function during an internet outage, since none of that machinery depends on the cloud link. Shortfall: the vendor never states this explicitly for delivery specifically, so it remains an inference rather than a documented behavior. source |
| digital-upsell-engine | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete Web Ordering book — Web_Ordering_Overview.htm, Customer_Interface.htm, Reporting.htm — was read in full. The checkout flow is documented step by step (menu browse, item customization, order-type/schedule/coupon/payment selection, confirmation, favorite-order save) with no upsell, cross-sell, or suggested-item prompt at any step, and no attach-rate report exists in Reporting.htm's Order List/User List/Performance Report set. source |
| digital-voice-ai-phone | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete 488-topic help TOC and full vendor product catalogue contain no AI, voice, or phone-ordering-automation topic. The only phone-adjacent feature documented anywhere is Caller ID Customer Link, an inbound-call customer-record lookup, not order transcription or injection. source |
| digital-drivethru-ai | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | No drive-thru product or hardware is sold (order-capture-drive-thru, no), so there can be no drive-thru voice-AI layered on top of it; none is named anywhere on the vendor site or in the manual. source |
| digital-apple-business-connect | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete Web Ordering book mentions Google only as Google Maps for delivery-address mapping (digital-google-order, existing cell) and never mentions Apple Maps, Apple Business Connect, or an 'Order Food' place-card action. No such topic exists anywhere in the manual or on the marketing site. source |
| digital-subscriptions | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete Web Ordering book documents account creation, guest checkout, favorite-order recall, and one-time payment at checkout, with no recurring-billing, membership, or subscription concept anywhere. No subscription topic exists elsewhere in the 488-topic manual. source |
| digital-guest-data-ownership | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-yes | The Web Ordering Reporting book documents a self-serve bulk guest export: the User List report is filterable by Name/Email/Phone and by Registered/First Order/Last Order/Ordered date ranges, carries a "NoEmails" column recording promotional opt-out, and exports to XML or CSV; the separate Order List report exports full order history the same way. Both are standard reporting-screen functions with no fee or vendor-approval step documented. source |
| digital-surcharge-transparency | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | No dual-pricing/surcharge/service-fee configuration exists anywhere in the pricing engine (payments-dual-pricing, no), so digital channels cannot mirror one. The complete web-ordering checkout flow (Customer_Interface.htm) documents coupon and payment-type selection with no fee-disclosure step of any kind. source |
| guest-loyalty-tiers | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete loyalty/marketing surface — Buyer's Club Setup (flat point accrual and threshold-coupon redemption), Comeback Coupons (recency-triggered, not status-based), and the 13-topic Marketing Module book (Overview, Customer Activity, Order History, Mailing History, Menu, Other, Sectors, Carrier Routes, Exclusions, Area Type, Labels) — has no status-tier concept, no promotion/demotion rule, and no rolling-window spend or visit-count threshold that changes a customer's standing. source |
| guest-loyalty-cdp-event-api | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | There is no public API or webhook of any kind (extensibility-webhooks-push, no; reporting-public-api, no) — the complete 488-topic help TOC has no API, event, or integration topic. With no outbound event mechanism to build on, no CDP/marketing-platform subscription surface (Olo, Punchh, Bridg, Klaviyo or otherwise) can exist. source |
| guest-loyalty-review-capture-routing | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The vendor states the absence directly: the survey feature only prints an invitation on the receipt directing the customer to a survey "you have set up elsewhere; a website, for example," and "there is no actual survey response tracking built into the PrISM system." With no response collection, there is no score-based routing to private recovery or public review sites. source |
| guest-loyalty-wallet-pass | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Gift Certificates and Buyer's Club points are documented as store-printed receipts and in-database balances only; neither topic, nor any topic in the Marketing Module or Web Ordering books, mentions an Apple Wallet or Google Wallet pass. No wallet-pass topic exists anywhere in the 488-topic manual. source |
| guest-loyalty-redemption-fraud-controls | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | A general-purpose control applies to any gated function including coupon and points overrides: each coupon carries a Password Required flag, and every password use "creates an entry... in the Weekly Exceptions browser," optionally with a recorded video (Setup_Password_Functions.htm). Shortfall: this is generic manager-password gating, not a loyalty-specific control — no redemption velocity limit, no employee-self-redemption flag, and no points-adjustment-specific approval step is documented. source |
| guest-loyalty-ai-offer-recommendation | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete offer-targeting mechanism is deterministic and rule-based: Comeback Coupons key on operator-set "Days Since Last Order" thresholds, and Buyer's Club redemption is a flat points threshold. Neither topic, nor any topic in the Marketing Module book, describes any AI/ML-generated recommendation for offer content, audience, or send timing. source |
| labor-geofenced-mobile-punch | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete time-clock documentation is a fixed-terminal punch (Clock In/Out, Start/Stop Break) tied to Employee Card or fingerprint ID at a POS station. No mobile app, GPS, or geofence validation is documented anywhere in the manual, and the Employee Scheduling Module's 12-topic book has no mobile-punch topic either. source |
| labor-overtime-prevention | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete overtime configuration — Level 1/2 Overtime Rate, and Hours Before OT Level 1/2 Applies for Daily, Weekly, and Period periods — is a rate multiplier applied retroactively once a threshold is crossed, calculated at payroll/reporting time. No warning or block at clock-in, and no approaching-threshold notice, is documented anywhere in the manual. source |
| labor-fair-workweek-support | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete 12-topic Employee Scheduling Module book (Overview, Reports, Updates, Create Schedule, Schedule Management, New Schedule, Shifts, Shift Map, Availability, Forecast Indicators, Update Jobs, Employee Information) has no advance-notice deadline, schedule-change tracking, or predictability-pay calculation. The schedule is described (labor-native-scheduling, existing cell) as a back-office artefact with no publish-to-staff mechanism to even measure notice against. source |
| labor-tip-pooling-rules | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same finding as payments-tip-pooling: the complete Payroll tab field set has no tip-pool, tip-out, or distribution-rule field, and no such topic exists anywhere else in the manual. The only tip report is a per-server Server Tip listing, not an allocation engine. source |
| labor-qualified-tips-w2-reporting | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Payroll tab's complete field set has no cash-vs-charged-tip separation and no Treasury tipped-occupation code field. The only external payroll/accounting interface documented anywhere is the QuickBooks Pro 2002 desktop connector (QuickBooks_Interface_Module.htm), which carries no tip-specific W-2 coding. source |
| labor-shift-swap-workflow | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete Employee Scheduling Module book (12 topics, listed under labor-fair-workweek-support) has no shift-swap request, open-shift claim, or manager-approval-workflow topic. The module is described as a back-office scheduling tool with no employee self-service surface documented. source |
| labor-digital-onboarding-i9 | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The Employee Detail tab — the only place ancillary hire paperwork could live — states "all fields on this tab are optional and are not used elsewhere in the system." No W-4, I-9, or E-Verify topic exists anywhere in the Employee Scheduling Module book or the core Employee Information section of the manual. source |
| inventory-realtime-depletion | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Recipe_Cost_Setup.htm defines the bill-of-materials that theoretical usage is computed from, but the actual on-hand decrement happens through the Daily Inventory screen's periodic reconciliation against Ideal Food Cost (Daily_Inventory_Screen.htm), not as each order fires. No topic anywhere states that a sale decrements on-hand inventory in real time; the documented model is theoretical-vs-actual variance at count-period boundaries. source |
| inventory-86-auto-sync | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Inventory_Master_u.htm's Reorder Level field only triggers a purchase-order suggestion ("the level at which you would like the system to prompt you to order more"); it has no link to menu-item availability. The menu item Advanced and Web tabs (fully enumerated) have no inventory-driven availability field, and Ordering_Advanced_Options.htm's Sold Out Item is a manual toggle, not inventory-threshold-triggered. source |
| inventory-mobile-count-offline | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete physical-counting documentation — Daily_Inventory_Screen.htm's Count column entry and Inventory_Master_u.htm's Inv. Cycle field — describes desktop-terminal entry only. No mobile app, tablet, barcode, or QR scanning device is named anywhere in the two topics that constitute the entire inventory-counting surface of the 488-topic manual. source |
| inventory-invoice-ocr | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete invoice-entry mechanism is manual: "Add Invoice" records delivery amounts by hand, and the "Load PO" button imports items from an existing PrISM-generated purchase order — not from a photographed, PDF, or emailed supplier invoice. No OCR, image-ingestion, or email-parsing topic exists anywhere in the manual. source |
| inventory-waste-logging | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same finding as kitchen-waste-logging: the complete inventory documentation (Daily_Inventory_Screen.htm, Inventory_Master_u.htm) has no waste/spoilage logging workflow, no reason-code field, and no waste-cost-separate-from-variance report. Variance from Ideal is a single aggregate figure, not itemized waste entries. source |
| inventory-transfers | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Inventory_Master_u.htm's Location field only attaches an item to a single Inventory Location (e.g., Freezer, Dry Storage) within one store. inventory-commissary (existing cell) already established that only the receiving store's view is documented, with "no inter-location transfer document." No transfer, in-transit, or approval-state topic exists anywhere in the manual. source |
| inventory-lot-traceability | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete inventory item field set (Item Number, Stock Price, Stocking/Counting/Portion Units and Multipliers, Reorder Level/Qty, Key Ingredient, Assembly Item, Batch Description) has no lot or batch number field for received or produced stock — "Batch Description" is a free-text label for an Assembly Item recipe, not a traceable lot ID. No recall-trace topic exists anywhere in the manual. source |
| inventory-shelf-life-expiry | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete inventory item field set has no expiration or use-by date field and no expiring-soon report or alert. Inv. Cycle governs count frequency (D/W/M/B/N), not shelf life. source |
| inventory-bar-partial-bottle | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The unit-conversion chain (Stocking Unit → Counting Unit → Portion Unit, with Stocking Mult and Portion Mult) is generic and manually typed for any item; no scale/weight integration and no bottle-fraction counting mode is documented, and no bar/beverage-specific counting topic exists anywhere in the manual. source |
| reporting-webhooks | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Consistent with the already-established extensibility-webhooks-push (no) on the same citation: the complete help TOC across eleven books contains no webhook, event, or callback topic. The only outbound surfaces are Scheduled_Reports.htm (PDF/HTML files to folder/email/printer) and the QuickBooks desktop file interface. source |
| reporting-api-not-upcharged | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | There is no public API at all (reporting-public-api, no; api_posture.public_api: none), so there is nothing to be included or upcharged. The claim's premise — API and raw-data access, at some price point — does not exist in the documented product. source |
| reporting-anomaly-alerts | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Scheduled_Reports.htm documents all three report-trigger mechanisms in full: End of Day, Specific Time, and Interval (Start time plus Repeat Minutes). All three are time-based; none is conditioned on a metric threshold or a deviation from historical pattern. No anomaly, alert, or push-notification topic exists anywhere else in the manual. source |
| reporting-nl-query | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete 488-topic help TOC has no AI, natural-language, chat, or assistant topic anywhere; the only report-building surfaces are canned reports and the field-selection Custom Report builder (Setup_Custom_Reports.htm), which requires manually checking fixed fields, not asking a question in plain language. source |
| reporting-sales-forecast | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Forecast Indicators — the only forecast mechanism documented anywhere — computes a labour-to-volume ratio for staffing purposes ("how many employees... need to be scheduled based on the average volume forecast"), not a forward sales figure at daypart/hourly granularity exposed in the reporting UI. No separate sales-forecast topic exists in the manual. source |
| multi-location-scheduled-publish | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Storenet Satellite's master-data distribution is documented as immediate and irreversible, not scheduled or rollback-able: a franchise master upload "cannot be undone," and stores "download the updated data at the next prescribed interval" — a fixed sync cadence, not a chosen future activation time interpreted per store timezone. No preview, staged-activation, or rollback mechanism is documented anywhere. source |
| multi-location-new-store-template | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete Software Installation book (Overview, Installing PrISM for Windows, USB Software License Keylok, Users Accounts & Passwords, Network Protocols, Computer Name and Workgroup, Installing Workstations and Devices) documents a from-scratch install process, not cloning a saved configuration template. No template, clone, or time-to-open figure is published anywhere on the vendor site or in the manual. source |
| multi-location-multi-brand | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Storenet's documented purpose throughout enterprise-management.htm is a single 'Master' menu and inventory shared by multiple locations of one operation, with tools to manage per-store differences in price/cost/selection — not two distinct brands with separate menus, receipts, and reportable revenue on shared hardware. No virtual-brand, multi-brand, or dual-menu-on-one-terminal topic exists anywhere in the manual. source |
| multi-location-multi-tax-jurisdiction | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | A per-location tax rate is documented: "Sales Tax — The location's total sales tax rate," configured on the Ordering tab of Location Maintenance, so each location can carry its own rate. Shortfall: the field is a single total rate, not multiple simultaneous jurisdiction-specific rates, and the documentation warns changing it "will update every order in the system (on the current day)" including settled orders — the opposite of clean multi-jurisdiction handling. No prepared-food-vs-grocery split, inclusive/exclusive toggle, or per-location exemption is documented. source |
| multi-location-enterprise-api | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | There is no public API of any kind (reporting-public-api, no), and Storenet's own reporting is described (reporting-realtime-dashboard, existing cell) as a nightly full-database upload viewed in a browser/mobile UI, not a queryable multi-location data warehouse or authenticated bulk-transaction API. source |
| multi-location-central-labor-policy | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Labor rules are configured per individual location — each Location Maintenance record carries its own Payroll tab with OT rate multipliers and Hours Before OT thresholds, enforced at that location's terminals during clock-in/payroll calculation. Shortfall: this is single-location configuration, not a location-group policy tier; Storenet's one-way nightly menu/inventory distribution (Upload_Dataset_Satellite.htm) does not extend to labor policy, and no predictive-scheduling or break-rule enforcement exists at any level (labor-break-compliance-by-state, existing cell: no). source |
| hardware-drive-thru | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same basis as order-capture-drive-thru: the complete vendor product/hardware catalogue names no drive-thru menu board, order-confirmation display, or headset system, and no drive-thru topic exists anywhere in the 488-topic manual. source |
| hardware-byod | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The only mobile ordering hardware documented anywhere is the vendor-supplied Handheld-Ordering device — a 12.3" Windows 2-in-1 tablet running "the exact same user interface as our fixed POS station." No personal-phone, BYOD, or bring-your-own-device permission model is named on this page, in the RapidRun driver-app documentation, or anywhere in the manual. source |
| hardware-remote-device-management | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Station Setup (General, Devices, Advanced) and Printer_Setup.htm are per-terminal, locally-configured screens — Printer_Setup's only fleet-adjacent feature is a per-device Backup Device failover field. Neither topic, nor any other in the manual, documents a remote console showing terminal/printer/KDS online/offline status, remote reboot, software-version visibility, or staged update rollout. source |
| extensibility-api-access-cost | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | There is no API at all (extensibility-public-api-docs, no; api_posture.public_api: none), so there is no access to be included in or excluded from the base subscription. The claim's premise does not exist in the documented product. source |
| extensibility-webhook-reliability | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Consistent with extensibility-webhooks-push (no): no webhook mechanism exists at all, so there is nothing to be HMAC-signed, retried with backoff, or replayed from an event log. The complete help TOC confirms the absence across all eleven books. source |
| extensibility-menu-write-api | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | There is no API of any kind, read or write (extensibility-public-api-docs, no). Menu items, modifiers, and prices are entered only through the on-terminal Product Information screens documented in the manual. source |
| extensibility-data-symmetry | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | With no public API to read or write any object (extensibility-public-api-docs, no), there is no basis for read/write symmetry across orders, menu, customers, employees, or inventory. All access is through the desktop application itself. source |
| extensibility-bi-data-warehouse | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The complete automated-export mechanism is enumerated on reporting-raw-warehouse-export (existing cell, no): Save Report, Save Report As, Email Report To, or Print Report To, in PDF or HTML only. No S3, SFTP, database, or Snowflake-share destination exists, and no API exists to build one outside the documented export types. source |
| extensibility-headless-embedded | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | A headless mode requires an API for a third-party UI to drive the transaction engine through; none exists (extensibility-public-api-docs, no). WebOrder, the kiosk, and the handheld all run Microworks' own first-party UI, not a third-party front end over an API. source |
| extensibility-data-portability-exit | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Reports covering sales, inventory, customer, and driver activity can be exported on demand as PDF or HTML files (Scheduled_Reports.htm), and the operator physically holds the store-local production database on their own hardware (reliability-local-transaction-engine, existing cell). Shortfall: no complete raw export of orders, customers, menu, and payments metadata in a machine-readable format (CSV/JSON/SQL) is documented, and no contractual export window at termination exists because no public MSA exists at all (commercial-autorenew-terms-published, existing cell: no). source |
| reliability-offline-decline-liability | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same finding, same page, as the already-established payments-offline-decline-liability (no): the complete card-authorization documentation describes an authorize-at-order, settle-at-batch model with no store-and-forward concept at all, hence no decline-on-reconnect liability statement and no offline cap. No other topic in the complete help TOC covers offline payments. source |
| reliability-contractual-uptime-sla | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Consistent with commercial-autorenew-terms-published and commercial-soc2-attestation (both existing cells, no): no MSA, terms of service, or trust-centre page is publicly accessible anywhere on the site, and the complete documentation-host TOC has no SLA, uptime, or service-credit topic. There is no contractual document to carry an SLA. source |
| reliability-incident-postmortems | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | No blog, status page, or trust-centre section exists anywhere on the site (per the sitemap) or in the complete help TOC. No post-incident report or root-cause summary has ever been published for the hosted Storenet service or any other component. source |
| reliability-failover-terminal-role | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The documented architecture assigns fixed roles to named machines — a MANAGER1 mini tower as the server and POS1/POS2 low-profile stations as clients — with no automatic promotion of a client terminal to the server role on failure. Networking_The_Workstations.htm is a cabling/router guide with no failover procedure documented. source |
| reliability-cellular-backup | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | The store's own network setup chapter documents wired LAN and router configuration only, with no cellular/LTE failover option. Only the RapidRun driver app and the handheld tablet reference wireless connectivity (Wi-Fi 6 on the handheld), and neither names a cellular failover for the store network itself. source |
| commercial-no-early-termination-fee | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same basis as the already-established commercial-autorenew-terms-published (no): no MSA, terms of service, or subscription agreement is publicly accessible anywhere on the site or the documentation host's complete TOC — only Support Policies and RMA Policies exist, and neither addresses termination fees. With no published terms at all, none can state an ETF waiver. source |
| commercial-processing-not-bundled | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-partial | Same underlying fact as the already-established payments-processor-choice (partial): merchant processor choice exists — Microworks requires "information pertaining to your primary credit card processing company" — but the gateway is fixed and singular (PCCharge) and configured through Microworks Tech Support rather than self-service, so the operator's processor choice is brokered rather than a fully open bring-your-own-processor model. source |
| commercial-rate-increase-clause | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | No processing agreement or rate card is published anywhere (payments-published-rates, no; commercial-interchange-plus-published, no), so there is no published document that could cap or prohibit a unilateral rate increase, or grant a penalty-free exit on one. source |
| commercial-post-termination-export-window | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Same basis as commercial-autorenew-terms-published (no): no MSA or terms of service is publicly accessible anywhere, so no post-termination data-retrieval window is stated. The only documented export mechanism at any time is Scheduled_Reports.htm's PDF/HTML report files, with no termination-specific provision. source |
| commercial-pci-dss-4-controls | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Authentication is documented as a single password entered at the terminal (reliability-mfa-role-based-access, existing cell: partial, no MFA documented anywhere in the help system for POS or back office), which forecloses the MFA-for-CDE-access control. The payments marketing page (re-read 2026-08-04) makes only a general tokenization/P2PE claim with no PCI DSS 4.0.1 AoC and no mention of payment-page script-integrity monitoring. source |
| commercial-dual-pricing-compliant | unknown / grade F, placeholder rationale ("No public documentation located during the 2026-08-01 research pass") | resolve-to-no | Follows directly from payments-dual-pricing and menu-pricing-dual-pricing (both no): the complete pricing engine has no tender-based price dimension at all, so there is no dual-pricing/surcharge feature to be card-network-compliant, exclude debit/prepaid cards, or carry a disclosure requirement. source |
| payments-emv-nfc | partial, grade B - Sourced to a marketing page, and that page attaches a materi | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| payments-refund-void-controls | partial, grade B - Exception reporting and POS-overlay video surveillance with | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| kitchen-guest-ready-notification | partial, grade B - Prism Notification Service sends SMS "when the order is read | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| delivery-route-map | partial, grade B - Live map with driver position and "turn-by-turn mapping dire | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| delivery-driver-comp | partial, grade B - Driver Detail and Cash Drop reports track per-driver runs an | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-menu-single-source | yes, grade B - WebOrder "uses all of the same menu and location settings th | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| digital-fulfillment-modes | yes, grade B - Verified verbatim: "Pick-Up and Pay, Pre-Pay and Pick Up, Pr | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| guest-loyalty-campaign-attribution | partial, grade B - A Coupon Count report tracks coupon redemption in the Produc | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| labor-clock-in-at-pos | yes, grade B - "Employee Card or Fingerprint ID" at the POS station; Shift | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| labor-tip-distribution-audit-trail | partial, grade B - A Server Tip report ships in the Cash Control catalog. Pool | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| labor-payroll-export-formats | partial, grade B - "Intuit QuickBooks Pro Interface" is the only named integrat | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| inventory-cogs-gl-export | partial, grade B - Intuit QuickBooks Pro interface is named. Per-category GL ac | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-realtime-dashboard | partial, grade B - Confirmed, and if anything the partial is generous-leaning-c | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-eod-closeout | yes, grade B - Daily Paperwork, Simple Sales, and the Cash Control family ( | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-cash-over-short | yes, grade B - Cash Control family: Weekly Cash, Monthly Cash, Cash Drop, S | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-channel-profitability | partial, grade B - Profit Center Ledger supports revenue/order-type separation. | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-guest-cohorts | partial, grade B - Score stands but the underlying evidence is misread in both | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-tip-tax-compliance | partial, grade B - Server Tip report exists. Declared-vs-charged split, pool di | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-os-platforms | partial, grade B - Windows is named for the POS; RapidRun is named for Android | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-handheld-purpose-built | no, grade B - Verified: 12.3" PixelSense 2-in-1, Intel Core, Wi-Fi 6, unde | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-handheld-battery-swap | partial, grade B - Rated "10.5+ hour battery life" is published, satisfying the | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-peripherals | partial, grade B - Documented peripherals include cash drawers/tills, touchscre | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-byod | no, grade B - The only mobile ordering hardware documented anywhere is the | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-callerid-integration | yes, grade B - "Caller ID Customer Link" is listed as an integrated add-on | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reliability-pci-dss-4-attestation | no, grade B - No AoC, P2PE listing, or compliance page is published; the p | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-interchange-plus-published | no, grade B - No processing rate of any structure is published. | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-export-customer-and-loyalty | partial, grade B - Customer report family produces customer lists and mailing l | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-wcag-kiosk-accessibility | no, grade B - No VPAT/ACR or WCAG claim is published; the kiosk and QR ord | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reliability-247-live-support | unknown, grade F - Support phone, email, an online support form, and online help are published; hours of operation and whether 24/7 coverage is included in the base agreement are not stated. | resolve-to-no | The August rationale said hours were not stated anywhere; they are, in two topics the earlier pass never cited: Support_Policies.htm (Microworks Company Information book) and Getting_Product_Support.htm (Getting Started book), which agree with each other except that the latter gives Friday as 9 a.m. to 7 p.m. No-audit: this is not an enumeration argument but a direct first-party statement of the coverage window (no coverage Sunday, none after 11 p.m. any day, pager-only after 8 p.m.) and of the contract requirement, so both halves of the claim are contradicted by the vendor's own text. Positive evidence of absence; no. source |
| reliability-onsite-install | unknown, grade F - The FAQ emphasizes the opposite posture — "All systems ship pre-configured and thoroughly tested complete with diagrams and cables customized to the specifics of each location" — which reads as remote/self-install. On-site go-live support is neither offered nor denied. | resolve-to-partial | Read Support_Policies.htm and re-read the FAQ. The policy page's non-refundable 'travel, and installation charges' establish that first-party travel and installation are sold, which is more than the remote-only posture the August pass inferred, but nothing documents the service itself. Partial with the shortfall named. source |
| order-capture-transfer-audit | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Re-Assign Orders confirmed in the cited Ordering_Advanced_Options.htm, and I confirmed that Table_Setup_Update.htm's 'Moving a Table' really is layout editing, so the named shortfall (server/till only, no table-to-table check move, no from/to pair written to the exception log) is verified rather than assumed. Peer 22 partial / 5 unknown / 3 yes / 3 no. source |
| menu-pricing-upsell-prompts | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | This was the parent's most serious mechanical allegation and it is a false positive. I read Modifier_Lists.htm in full: it carries 'Auto Show ... the modifier list will automatically be displayed on the ordering screen when a menu item that is using this specific list is selected' and the Visibility All / In-Store Only / Web Only enumeration verbatim. The detector matched the note's span to an Arryved article only because the note joins the field label to its description with ' - ' ('Auto Show - If this option...'), a string no PrISM page contains, so the exact-span lookup fell through to the other corpus loaded in the same checker process. The citation carries its own proposition and needs no re-pointing. Substance: two of the claim's three conjuncts hold (per item, per channel), the third - the vendor reporting attach-rate - fails, and the 2025 site now sells kiosk and QR channels the manual does not cover, which is a further gap rather than a rescue. Peer 29 partial / 8 unknown / 7 no. source |
| payments-multi-entity-routing | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Verified the per-store construction myself: Authorizer_Overview.htm on the acquirer relationship, CC_Gift_Check_Tab_LM.htm holding the credentials on a per-Location-Maintenance tab, and per-store 'Close Day' batch settlement. I came close to downgrading, because what the note describes is arguably the absence of the mechanism rather than a limited version of it - there is no single account and no unified settlement reporting. It stays partial on corpus consistency: the SpeedLine cell records the identical shape ('Card processing credentials live in each store's own database') as partial, and the shortfall is named. Flagged as one of my less certain calls. Peer 9 partial / 6 unknown / 4 yes / 4 no. source |
| kitchen-offline-operation | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | The architecture is documented rather than inferred from silence: System_Overview.htm's Station Status and local index files, and Makeline_Tab.htm's refresh interval polling the store's own database. The note is honest that no topic states makeline behaviour during an outage, which is what keeps it off yes. One live fact cuts the same way rather than against it: the 2025 site now markets a 'Prism Cloud' tier whose degradation behaviour is undocumented, so partial remains right for the product as sold today. Consistent with this record's sibling reliability-offline-order-entry and reliability-offline-kds-printing partials. Peer 13 partial / 9 yes / 7 no / 6 unknown. source |
| digital-group-ordering | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | I read Customer_Interface.htm myself. This is not a zero-hit search: the topic walks the guest from arrival ('three options: to create a new account, to log in ..., or to log in as a guest') through cart, checkout ('change the order type (delivery or pickup), schedule the order for a later date or time ..., apply any coupons or discount codes, and select their payment type') to 'Place Order Now', naming every screen. No invite link, second participant, spend cap or split payment appears. The parent's challenge was that this topic is an orphan of a book that was missed - true, and it is why it is the RIGHT citation, not a weaker one: I re-fetched it live and it is a genuine 200 (11,030 bytes, title 'Customer Interface'), not the 16,758-byte marketing soft-404 that help.microworks.com serves for non-existent topic names. Live 2025 marketing carries no group-ordering claim (zero hits for 'group order' across the ten www product pages), so the vintage argument does not rescue it. Peer distribution 12 no / 9 partial / 20 unknown / 1 yes: not an outlier. source |
| digital-loyalty-attach | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld, one label corrected. I confirmed in Advertised_Coupons.htm the points gate ('coupon set to require points will only be able to be used by a customer with enough points, and will deduct that number of points'), the Visibility field ('only used for Online Ordering ... available only in the store, only on the web, or both'), and the Web Code / Web Label fields. The field on that screen is labelled 'Points', not 'Points Req.' - 'Points Req.' is the Buyer's Club Setup field, a different screen. Substance and shortfall unaffected, but the note should not quote a label that is not on the page it cites. The three-part shortfall (no balance in the web flow, no documented web-side enforcement of the points test, rewards reaching the guest on a printed receipt) I verified independently. Peer 21 partial / 13 yes / 7 no / 3 unknown. source |
| guest-loyalty-consent-management | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld, one shortfall corrected. The note said consent is 'one boolean' with 'no per-channel consent'. Customer_Interface.htm - a topic outside the corpus the author searched - documents two separate choices at registration, order notifications and promotional emails, which is a transactional/promotional split. The rest of the shortfall survives intact and is decisive: no timestamp, no source of consent, honouring left to the operator reading a NoEmails column in an exported spreadsheet, no consent object anywhere on the POS side, and zero occurrences of consent / opt-in / opt-out / unsubscribe across the closed 269-topic census, which I re-ran including the 24 recovered topics. The Reporting.htm NoEmails quote is verbatim in the cited topic; that defect flag is another ' - ' artifact. Peer 28 partial / 9 unknown / 5 no. source |
| guest-loyalty-privacy-rights-tooling | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Locate, access/export, rectify and hard-delete-on-reindex all verified in Browse_Customers.htm and System_Overview.htm; Purge_Customers.htm and Delete_Duplicates.htm confirm the only documented customer erasure is set-wise and criteria-based, which is the named shortfall. Peer 28 partial / 10 unknown / 5 no / 1 yes. source |
| labor-photo-punch-verification | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Upheld, and this is where the vintage argument resolves. The support is a genuine enumeration, not a search: Advanced_Features.htm's Enhanced Security section says PrISM 'provides multiple security options from which to chose:' and lists exactly three - keyboard entry, swipe badges, fingerprint readers - framed by the vendor as its buddy-punching answer, which is this claim's own rationale. It is corroborated at the two station configuration surfaces, which offer only a fingerprint sensor, and at the time clock, whose Advanced menu offers exactly 'Use Bank' and 'Enroll Fingerprints'. The camera feature exists and is bound to password functions, not to timecards. Decisively for the vintage objection: I read all ten current www product pages and Microworks makes no photo or facial claim anywhere today - the live marketing corroborates the old enumeration instead of contradicting it, which is exactly the opposite of the delivery-3p situation. Peer 21 no / 16 unknown / 3 partial. source |
| labor-offline-time-punch | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Verified the Networking_The_Workstations.htm 'Dial-up or no Internet access' option and the System_Statup_Procedures.htm file-server dependency quotes; the WRONG-DOC flag is the ' - ' artifact and the cited topic carries its own proposition. I nearly downgraded this to unknown, because the claim's operative words are 'with the behavior documented' and the note concedes no topic documents punch behaviour under the outage that matters for an on-premise system - loss of the LAN or the file server - nor any queue or reconciliation. It stays partial because the documented no-internet configuration does establish that a WAN outage cannot reach a punch, which is the whole of this claim for a cloud product, and hungerrush carries the same shape at partial. My least certain upheld in chunk 4. Peer 21 unknown / 12 no / 8 partial / 1 yes. source |
| labor-realtime-labor-percent | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value and evidence upheld; the URL was wrong and is corrected. The cited host was 'microworks.com' without the www label the vendor's own sitemap uses for these files. I extracted the PDF myself and the quoted header line is exact: 'Food Cost % Labor Cost % Fixed Labor % Variable Labor % Mileage % Food Waste % Food Waste $' over the DAILY RECAP values. The shortfall - a paperwork figure, no documented on-screen percentage or refresh cadence, the only screen percentage being the schedule builder's projected one - is accurate. Peer 20 partial / 12 no / 6 yes / 4 unknown. source |
| labor-native-payroll | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Upheld after making it prove itself, as instructed. The vendor's sentence 'The PrISM system has a fully integrated payroll system' is a headline, and the very next sentence enumerates what it means: 'This section is divided into four parts:' - Rates (two overtime multipliers), Labor Goal, Pay Rate Display, and daily/weekly/period overtime thresholds plus pay-cycle selection. I read Payroll_Tab.htm in full: no tax table, no filing, no disbursement, no bank account, no EIN, and the NOT-FOUND defect flag is the ' - ' artifact. Scoring against an enumeration the vendor supplies immediately after its own headline is the right move, not a dodge. Three independent corroborations: the documented output is a report run from the Paperwork menu; the employee record concedes 'a separate payroll system'; and the ESM book, unread by the author and recovered by me, repeats that concession. The live 2025 site corroborates, listing 'Payroll Report' among reports and claiming no payroll service. Peer 28 no / 10 partial / 3 unknown / 2 yes - the crowd, and here on stronger evidence than most. source |
| inventory-price-change-alerts | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | The parent named this as a zero-hit victim. It is not one: the load-bearing evidence is an in-document enumeration. Add_Invoice_Delivery.htm walks the receiving line field by field and assigns price-change detection to the operator - 'You can override the price if it has changed by clicking in the cost field and entering the correct price' - which is the documented alternative to an alert, and I confirmed that sentence verbatim (the NOT-FOUND flag is the ' - ' artifact). I re-ran the word searches over the closed 269-topic census: still zero 'threshold'; 'alert' still occurs only in Buyer's Club, Order_Types, Sounds_Tab, Support_Policies and Web_Ordering_Overview, none about purchase price; and the only 'variance' concepts in the product are usage-vs-ideal food cost (Daily_Inventory_Screen.htm) and invoice balance, never received price against a prior or contracted price. Peers 13 no / 16 partial / 11 unknown. source |
| inventory-menu-margin-linkage | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | I extracted PRODUCTMIX.PDF myself and confirm the column set is GROUP/NAME, QTY, TOTAL and % across DAY / WEEK / PERIOD with no cost, margin or profit column - the join the claim asks for genuinely is not made. The Recipe_Cost_View self-limitation ('This does not include any modifiers, nor the labor involved in producing the item') is verbatim in the cited topic. 'threshold' still returns zero over the closed 269-topic census. Peer 22 partial / 8 no / 8 unknown / 3 yes. source |
| multi-location-org-hierarchy | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld, a false shortfall removed. The note asserted 'No sales or above-store report is documented as scopeable to a group'. That is contradicted inside the corpus the author read: Advanced_Features.htm says StoreNet's multi-unit sales reports carry 'corporate or regional totals', and the live www Enterprise Management page markets reporting 'by Unit, Unit Groups, or All'. The claim is conjunctive (reporting AND permissions scoped to the hierarchy) and the permission half genuinely fails - PrISM's only permission construct is the store-local Password Group - so partial still stands, but on the correct shortfall. Peer 38 partial / 18 unknown / 16 yes / 9 no. source |
| multi-location-corp-vs-franchisee-roles | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Both halves verified in System_Overview.htm and Log_Viewer_Satellite.htm. The 'Force Data Upload ... push a copy of your store's data to the StoreNet Server' plus satellite 'Get All' evidence really does show corporate receiving the franchisee's whole dataset rather than a sales-scoped view, which is the named shortfall, and the second shortfall (separation by application rather than by permission model) I confirmed - Setup_Password_Groups.htm has no franchisor/franchisee dimension. No peer scores this id `no` (16 partial / 7 unknown / 2 yes); partial is the crowd. source |
| multi-location-royalty-calculation | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld, a factually false shortfall replaced. The note claimed 'zero of the 252 manual topics contain "ad fund"' and that advertising is only a hand-posted expense. Both are wrong, and the counter-evidence sits eleven lines below the sentence the note quotes, in the very document it cites: Income_Statement_-_Fixed_Percentages.htm carries an 'Advertising Fund' fixed-percentage field. It is still a shortfall, but a different one - the field feeds unnamed StoreNet reports and is explicitly 'not factored into the Income Statement reports'. This is the clearest instance in the set of a zero-hit assertion written without reading the cited page to its end. Shortfalls 2 (no defined schedule) and 3 (basis not documented as configurable gross-vs-net) I verified and they stand. Peer 13 unknown / 8 no / 3 partial / 1 yes - partial is thin here, but a royalty percentage genuinely is calculated from Royalty Sales, so `no` is not available. source |
| multi-location-royalty-collection | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Value upheld, the argument rebuilt. As written the note led with a word-count ('not one whole-word occurrence of ACH, EFT, debit or sweep'), which is a failed search and cannot carry a `no` however complete the corpus - and its NOT-FOUND defect flag turned out to be the ' - ' artifact rather than a missing quote. I re-measured over the closed 269-topic census (still zero) and, more importantly, found the enumeration that does carry it: the Fixed Percentages screen enumerates the franchise-percentage fields and defines the royalty output as a projection expense line, while attributing collection to the franchisor 'as per a franchise agreement', i.e. a contractual act outside the product. Peer 13 unknown / 9 no / 2 partial / 1 yes; niche weight. source |
| multi-location-config-audit-log | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | I extracted Transaction_EXCEPTION.PDF myself and confirm the DATE / TIME / DESCRIPTION / EMPLOYEE / Super User columns and that configuration screens appear as logged events, not only transactions. The Setup_Password_Functions.htm Log and Camera quotes are verbatim in the cited topic. All three shortfalls (function-opened rather than field-changed for most rows, opt-in per function, per-store and mutable because Trim and Archive removes older data) are real, and the third is what keeps this off yes given the claim's 'immutable' and 'queryable by corporate'. Peer 13 partial / 8 unknown / 2 yes / 1 no. source |
| hardware-printer-compatibility | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Device Path, Printer Type ('Select the applicable printer model. If unsure as to what model printer you are configuring, contact Microworks Tech Support') and the Trouble_Shooting.htm sentence 'Nearly all printers connect directly to a computer, if the computer is off the printer will not function' all confirmed verbatim. The shortfalls are real: the model list is never published, Epson T-88 is the only manufacturer named anywhere, ESC/POS occurs zero times across the closed 269-topic census, and the one statement about attachment argues against LAN printers rather than for them. Table-stakes; peer 24 partial / 9 yes / 1 no / 1 unknown. source |
| hardware-usable-after-churn | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld; evidence strengthened with a topic the author never saw. USB_Software_License_Keylok.htm - one of the genuine orphans - is the single most on-point document for this claim and confirms the lock is a removable USB dongle on a generic Windows PC, not firmware or device binding. The named shortfall still holds exactly as written: no Microworks document affirmatively states that hardware bought from Microworks stays usable with other software after cancellation, which is literally what this claim asks documentation to confirm. I considered unknown, since it is a documentation-confirmation test the documentation does not pass; partial is right because the EULA's termination clause is scoped to 'Software' as defined at 1(b) and there is no remote-deactivation right, which answers most of the question. One of my less certain calls. Peer 15 unknown / 10 partial / 6 no / 4 yes. source |
| extensibility-order-injection-api | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | I confirmed the XML Interface quote is in the cited Advanced_Tab_-_LM.htm verbatim; the WRONG-DOC flag is a detector artifact (the notes join a field label to its description with ' - ', which the source does not contain, so the exact-span lookup fell through). I pressed hardest on the vintage objection, because www.microworks.com/products/delivery-pos.htm states today that 'Prism integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates' - externally originated orders demonstrably do reach the POS in 2026. That does not reach this cell: the claim asks for a PUBLIC write API, and the only documented external order hook is reserved to the vendor ('used for advanced support functionality ... Please contact Microworks Tech Support'), with developer / api / docs.microworks.com all answering the 163-byte cPanel wildcard, i.e. no developer surface exists to publish one. This is verbatim the corpus's settled slice `no` ('orders do inject ... through Slice-operated private integrations - no public write API is offered'). Peer position 7 no / 23 partial / 13 yes / 3 unknown is a minority, so I checked the precedent rather than the crowd. source |
| extensibility-payroll-export | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Upheld and strengthened. The parent's floor argument bites hardest here, because the seven-topic QuickBooks Interface Module book was one of the 24 topics the href crawl never reached - the author asserted what QuickBooks does without having read the book that says it. I fetched and read all seven. They vindicate the verdict rather than breaking it: QIM_Requirements.htm, QB_Invoices.htm and Sales_Receipts.htm enumerate the supported transaction types (Sales Receipts, Sales Invoices, Bills) and payroll is not among them. The Scheduled_Reports Export Type enumeration (Save / Save As / Email / Print) and the Payroll Number cross-reference field I confirmed verbatim; the NOT-FOUND defect flag is the ' - ' artifact. Zero named payroll providers across the closed 269-topic census. Re-measured on 2026-09-04 over a CLOSED census: the manual's own full-text-search topic table (whxdata/topictable_0-4.xml, the RoboHelp search index) enumerates 270 entries; all 269 real topics were fetched and read on 2026-09-04, closing the census; the earlier '252 topics' figure was a proper subset (24 topics, including the whole QuickBooks Interface Module book, the Software Installation book and the Employee Scheduling Module book, were unreached by the href crawl). The count is unchanged after re-measurement. source |
| extensibility-custom-fields-scripting | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Quote-defect flag is a false positive: Menu_Classes.htm carries 'Menu Classes are "wild cards". They allow multiple disparate items to be linked together for report filters and coupons' verbatim; the detector missed it because the note joins lines the source wraps and interleaves with   entities. The shortfall is named and correct, and the 'without a vendor engineering engagement' half is genuinely contradicted by the manual routing Base Item, web specials and the XML interface through Tech Support by name. Peer 12 partial / 8 unknown / 3 yes / 2 no. source |
| reliability-offline-feature-matrix | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Value upheld; the premise underneath it replaced, which is the point of this audit. The author staked the verdict on corpus completeness and said in terms that if the crawl missed a book the verdict falls. The crawl did miss books - 24 topics, including the entire QuickBooks Interface Module, Software Installation and Employee Scheduling Module books, none reachable from any href in the crawled set. So I stopped crawling and read the manual's own search index: whxdata/whfts.xml lists topictable_0-4.xml, which enumerate 270 entries (269 real topics plus one PDF-image page), and I fetched every one. Over that closed census the measurement is unchanged: 'offline' still appears in exactly one topic and it is the PrISM-card catch-up utility, 'outage' only in power-loss and troubleshooting contexts, and the Authorizer chapter is still silent on connectivity loss. This is now the strongest form of this verdict available - a publication claim measured against an enumerated publication surface rather than a link-crawl. Separately, and against the brief: three of the seven topics named as proven orphans (Store_Rule.htm, Update_Customer.htm, Hourly_Reports.htm) do not exist - they return the 16,758-byte marketing page that help.microworks.com serves as a soft-404 for any invented topic name, which I verified with a nonsense path. Peer 28 no / 9 partial / 8 yes / 1 unknown. source |
| reliability-backup-restore | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | End_Of_Day.htm's backup sentence and its failure warning confirmed verbatim, as is the vendor-only recovery path ('Microworks Tech Support can often recover the missing data if you call before reindexing') and the Import function's end-user prohibition. One live fact adds a second operator-retrievable copy without touching the shortfall: the Enterprise Management page markets the nightly StoreNet upload as 'critical off-site backups'. Restore remains a vendor act and no RPO or RTO figure is published anywhere, so partial with the named shortfall stands. Peer 12 unknown / 10 partial / 2 yes / 1 no. source |
| commercial-month-to-month-contract | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Value upheld, a material live fact added that the author, working from the manual, could not have seen. The vendor DOES publish the words 'month to month contracts' - on its 2025 payments page - and an audit that missed that would have been silently wrong in the vendor's favour. It does not move the cell: it is a processing contract, doubly conditioned, and the claim is about the core POS software tier, which is a capital purchase with 6/12/24-month support terms. The EULA 2(a) and section 6 quotes and the Support_Policies term list I confirmed verbatim. Peer 13 yes / 12 partial / 11 no / 9 unknown. source |
| commercial-data-ownership-clause | unknown — never examined against the 2026-09-04 corpus | resolve-to-no | Upheld after answering the parent's specific objection. Microworks does publish binding documents inside the manual, so '404s on www' would not be enough - I therefore read the manual-hosted set to its end. It is EULA.htm, RMA_Policies.htm and Support_Policies.htm, plus Copyright.htm, which the href crawl never reached and which I recovered from the manual's own search index; I read all four in full and none mentions merchant transaction or customer data. With EULA section 7 declaring itself 'the entire agreement' and /terms, /privacy, /legal all confirmed 404 by me on www, the non-publication is positively established rather than merely unfound. Peer 21 partial / 13 no / 7 unknown / 5 yes. source |
| commercial-privacy-dsar-tooling | unknown — never examined against the 2026-09-04 corpus | resolve-to-partial | Locate, export and edit verified in Browse_Customers.htm ('You may also export the selected customers into a variety of data formats'), and the mark-for-deletion-until-reindex behaviour verified in System_Overview.htm. GDPR/CCPA re-measured as zero over the closed 269-topic census, including the 24 recovered topics. Peer 35 partial / 6 no / 4 unknown - partial is overwhelmingly the crowd and both shortfalls are named. source |
| delivery-3p-direct-integration | unknown / grade F — Downgraded from partial by the verification pass. The entire basis was one hedged marketing sentence — Prism "integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)" — with no named integration partner, no middleware vendor, no certification and no setup s | resolve-to-partial | DoorDash partner-integrations registry pass. unknown/F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NO source |
| delivery-3p-injection | unknown / grade F — Integration is claimed but the injection mechanism (auto-fire vs tablet accept) is not described. | resolve-to-partial | DoorDash partner-integrations registry pass. unknown/F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NO source |
| delivery-menu-push | unknown / grade F — Depends on the third-party marketplace integration whose existence is unestablished (delivery-3p-direct-integration, unknown). Menu publishing is documented only to the vendor's own WebOrder channel (Web_Tab.htm Visibility flag); no marketplace-menu-sync topic exists in the complete help TOC. Unreso | resolve-to-partial | DoorDash partner-integrations registry pass. unknown/F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NO source |
| delivery-store-pause | unknown / grade F — Same dependency as delivery-86-sync and delivery-menu-push. No store-pause-to-marketplace topic exists anywhere in the manual; whether a store-level pause on any connected channel is even possible cannot be assessed without a documented integration. | resolve-to-partial | DoorDash partner-integrations registry pass. unknown/F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash's integrations comparison page. SCOPE: this attests the vendor's DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NO source |
| kitchen-channel-pause-propagation | unknown / grade F — STALE PREMISE CORRECTED, VERDICT UNCHANGED. This cell was recorded as depending on a third-party marketplace integration whose existence was unestablished. That dependency is now discharged: DoorDash's partner registry lists `microworks` as a CERTIFIED integration of type POS, so the integration exists. The cell remain | resolve-to-partial | 260th session, DoorDash partner-integrations feature-flag pass. unknown / grade F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. PRIOR READING CORRECTED: this cell was last left unknown on the ground that the kitchen docs ‘document no propagation of a channel pause to kitchen output’ and that ‘the registry carries no flag bearing on kitchen-side propagation’. That reads the claim backwards. The claim runs FROM the POS/KDS OUT to the marketplaces — ‘Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces’ — not from the marketplace in to the kitchen. On that reading the registry does bear on it: `STORE_AVAILABILITY_WEBHOOKS`, labelled ‘Integrated close/pause store’, is TRUE for `microworks`, inside the LIVE_ORDER_MANAGEMENT collection, which is active for this provider (unlike its ENABLING_DDOO collection, which is not). TWO NAMED SHORTFALLS. First, only the pause disjunct is attested: `ITEM_LEVEL_86` reads false for this provider, so the item-availability disjunct is not established — and that false is not converted into a negative here, it simply carries nothing. Second, the claim names DoorDash, Uber Eats and Grubhub, and this instrument attests DoorDash only. source |
| delivery-injection-error-visibility | unknown / grade F — Same dependency. With no documented marketplace ingestion path (delivery-3p-direct-integration, unknown), there is no connection-health, failed-injection, or per-channel-alert surface to find; none exists in the complete help TOC. | resolve-to-partial | 260th session, DoorDash partner-integrations feature-flag pass. unknown / grade F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. The flag `DETAILED_ERROR_SPEC`, which DoorDash labels ‘Detailed order error reporting’, is TRUE for `microworks`, inside the active PREFERRED_PARTNER collection. It is one of the eight high-quality features and the programme page defines it: ‘provides clear error reasons so order issues can be identified and resolved more quickly’. The prior unknown held that with no documented marketplace ingestion path there was no error surface to find; the ingestion path is now established (the same registry classes `microworks` as a CERTIFIED integration of type PROVIDER_AGGREGATION_TYPE_POS) and a per-order error-reason contract with it is attested. TWO NAMED SHORTFALLS, and they are why this is not `yes`. First, the claim requires the VENDOR to expose integration health to the operator, and what is attested is the error detail Microworks returns into DoorDash’s contract; the operator-facing view of it is DoorDash’s own merchant integrations page, not a Microworks surface, and Microworks’ 488-topic help TOC contains no connection-health or failed-injection topic. Second, the claim requires connection status per channel and alerting on failure, and no flag in the registry bears on either. source |
| menu-pricing-3p-menu-push | unknown / grade F — Whether Microworks pushes menu data to any third-party marketplace depends on the marketplace integration itself, whose existence is unestablished (delivery-3p-direct-integration, unknown) — the complete help TOC has no marketplace, aggregator, or menu-sync topic. Checked Web_Tab.htm and the Web Ordering book (menu pub | resolve-to-partial | 260th session, DoorDash partner-integrations feature-flag pass. unknown / grade F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. Two of the claim’s three components are attested for `microworks`. The certified-direct-rather-than-middleman component: the registry classes this provider as CERTIFIED and of type PROVIDER_AGGREGATION_TYPE_POS, which DoorDash renders on its integrations page as ‘Integrates directly with DoorDash so you can accept, process, and fulfill orders’, as against MIDDLEWARE_AGGREGATOR, rendered ‘Requires a compatible POS system’ and given to Deliverect and Otter. The menu-push component: `MENU_PULL_SUPPORTED` (‘Real-time menu syncing’, defined on the programme page as ‘keeps your DoorDash menu aligned with your POS to reduce outdated or unavailable items’) and `MENU_CONTAINS_ITEM_IMAGE_URL` (‘Integrated images’) are both TRUE. The rejection-error component is attested in part by `DETAILED_ERROR_SPEC`, also TRUE. This overturns the prior unknown, which reasoned that no marketplace menu-sync topic exists in the 488-topic help TOC and that menu publishing therefore reaches only Microworks’ own WebOrder channel. TWO NAMED SHORTFALLS. First, the claim requires per-item sync status surfaced TO THE OPERATOR and nothing here attests an operator-facing sync view inside Microworks. Second, the claim reads on third-party marketplaces generally and this attests DoorDash alone. Specifically NOT read as a shortfall: `CHANNEL_BASED_MENU` reads false, but it sits inside the ENABLING_DDOO collection, which carries `active: false` for this provider, and a flag inside an inactive collection is not-applicable rather than absent. source |
| extensibility-first-party-delivery-integrations | unknown / grade F — Downgraded from partial by the verification pass, same evidence and same defect as delivery-3p-direct-integration: the sole source is the marketing sentence "integrates with 3rd party Apps like GrubHub, UberEats, DoorDash and Postmates (to name just a few)". This claim tests specifically whether such integrations are f | resolve-to-partial | 260th session, DoorDash partner-integrations feature-flag pass. unknown / grade F -> partial/B. DoorDash publishes a machine-readable registry of its integration partners at https://merchants.doordash.com/api/partner-integrations — 64 providers, each tiered PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), and each carrying an explicit true/false flag for 23 named integration features across four collections. It is served anonymously and merchants.doordash.com/robots.txt permits it. The programme is described, and its eight high-quality features defined in prose, at https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program; the merchant-facing label for each flag comes from the label dictionary embedded in DoorDash’s integrations comparison page. SCOPE: this attests the vendor’s DOORDASH integration specifically — not Uber Eats, not Grubhub, and not the POS in general. DIRECTION: a true flag is a positive attestation; a false flag is NOT a reliable negative on its own, because Lavu’s help centre documents a DoorDash temporary-closure control with scheduled auto-reopen while Lavu’s `STORE_AVAILABILITY_WEBHOOKS` flag reads false, and Xenial’s developer docs enumerate an order-ready notification while its `SUPPORT_ORDER_READY_SIGNAL` flag reads false. Re-probed 2026-09-12: the registry payload is byte-identical to the 259th’s frozen copy (md5 e638fc99931673ecdcdbbb3ea2fbbfaf, 158,095 bytes, 64 providers) and every quotation below was confirmed verbatim-present in the bytes fetched that day. The prior unknown was a verification-pass downgrade: the only source was the marketing sentence naming GrubHub, UberEats, DoorDash and Postmates, and the property this claim actually tests — whether such an integration is first-party and direct rather than middleware-brokered — was exactly what the vendor never stated. The registry states it for one of the three: `microworks` is present, CERTIFIED, and classed PROVIDER_AGGREGATION_TYPE_POS, which DoorDash renders as ‘Integrates directly with DoorDash so you can accept, process, and fulfill orders’, as against MIDDLEWARE_AGGREGATOR, rendered ‘Requires a compatible POS system’. Its own entry’s providerPortalLink is https://microworks.com/, and countriesSupportedList is [COUNTRY_AVAILABILITY_US]. TWO NAMED SHORTFALLS. First, the claim requires DoorDash AND Uber Eats AND Grubhub, and only DoorDash is attested. Second, the type field records how DoorDash CLASSES the provider, not who wrote the connector, so ‘first-party’ is established only in the sense that no middleware layer sits between Microworks and DoorDash. This is the same instrument and the same verdict already recorded on the near-duplicate claim delivery-3p-direct-integration. source |
| kitchen-channel-pause-propagation | partial / grade B — resolved from unknown on 2026-09-12, asserting the prior pass had misread the claim's direction and that `STORE_AVAILABILITY_WEBHOOKS` TRUE for `microworks` bears on it | upheld | On the direction dispute the 260th is right and the prior pass was wrong. The taxonomy text is "Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically", and its why_it_matters is about pausing three marketplace tablets during a rush. The prior rationale looked for "propagation of a channel pause to kitchen output", which is the opposite vector and is not what the claim asks. Both of the quoted prior-rationale spans are verbatim-present in the row it replaced. On the evidence: STORE_AVAILABILITY_WEBHOOKS is true for microworks inside FEATURE_COLLECTION_NAME_LIVE_ORDER_MANAGEMENT with active:true, and the note handles trap 2 correctly by recording that ENABLING_DDOO carries active:false for this provider and by refusing to read the false ITEM_LEVEL_86 as a negative. Two real shortfalls named. `partial` is the correct ceiling for a DoorDash-only positive on a claim naming three marketplaces. source |
| delivery-injection-error-visibility | partial / grade B — resolved from unknown on 2026-09-12 off `DETAILED_ERROR_SPEC` TRUE for `microworks`, with two named shortfalls: that the operator-facing view is DoorDash's own page rather than a Microworks surface, and that no flag bears on per-channel connection status or alerting | downgrade-to-unknown | This cell should not have been scored. The flag is genuinely true — I re-fetched and confirmed DETAILED_ERROR_SPEC true for microworks in an active collection — but it does not evidence this claim. The claim's subject is the VENDOR exposing integration health TO THE OPERATOR, in three named components: failed/rejected injections, per-channel connection status, alerts on failure. Every DoorDash gloss of this flag describes what the provider transmits into DoorDash's contract: "Detailed order error reporting", "provides clear error reasons so order issues can be identified and resolved more quickly", "Provide actionable error reasons for failed orders, reducing repeat order failures." None of them is an operator-facing surface. The note itself concedes both that the operator-facing view is DoorDash's merchant integrations page rather than a Microworks one and that no flag bears on the other two components — that is two of three components unattested and the third attested in a sense the claim does not ask about. Shortfalls that negate the claim's subject are not shortfalls, and `partial` requires a limit on a capability that has been established. Not `no`: a silent help TOC is absence of evidence, not evidence of absence. source |
| menu-pricing-3p-menu-push | partial / grade B — resolved from unknown on 2026-09-12 off CERTIFIED + PROVIDER_AGGREGATION_TYPE_POS, `MENU_PULL_SUPPORTED`, `MENU_CONTAINS_ITEM_IMAGE_URL` and `DETAILED_ERROR_SPEC` all TRUE, with two named shortfalls | upheld | Survives the same attack that killed the qu 86-sync cell, and the difference is worth stating. All four attestations check out in my own fetch, and the two tooltip spans are verbatim-present in the integrations page dictionary — PROVIDER_AGGREGATION_TYPE_POS renders "Integrates directly with DoorDash so you can accept, process, and fulfill orders" and MIDDLEWARE_AGGREGATOR renders "Requires a compatible POS system", which 27 of the 64 providers carry, Deliverect and Otter among them. The direction objection does apply on its face — MENU_PULL_SUPPORTED is DoorDash pulling, glossed "Automatically pull the most up-to-date version of your menu from your provider into DoorDash" — but unlike delivery-86-sync, where DoorDash publishes push and poll as two distinct features and the vendor has only the poll, this claim's operative discriminandum is certified-direct versus scraping or a menu-management middleman, which is exactly what the tier and type fields attest, and the taxonomy's own why_it_matters speaks of "push/pull menu APIs". I added the pull caveat as a third named shortfall rather than downgrading. Trap 2 is handled correctly: CHANNEL_BASED_MENU false is excluded because ENABLING_DDOO carries active:false for this provider. source |
| extensibility-first-party-delivery-integrations | unknown / grade F, verified true — a prior verification-pass downgrade from partial on the ground that the only source was a marketing sentence naming four marketplaces and never stated whether the integrations were first-party and direct; re-scored to partial / grade B on 2026-09-12 off CERTIFIED + PROVIDER_AGGREGATION_TYPE_POS | upheld | Re-scoring a cell a previous adversarial pass had downgraded is legitimate here because the instrument is new and it speaks to precisely the property the prior pass said the vendor never stated. Confirmed from my own fetch: microworks is present in the registry, QUALITY_STATUS_CERTIFIED, PROVIDER_AGGREGATION_TYPE_POS, providerPortalLink https://microworks.com/, countriesSupportedList [COUNTRY_AVAILABILITY_US] — so the integration is DoorDash-classed as direct rather than middleware-brokered, and the claim's "without requiring a paid middleware layer" is met on that leg. Both shortfalls are honest and one of them is unusually careful: the type field records how DoorDash classes the provider, not who wrote the connector. The cross-reference checks out too — delivery-3p-direct-integration does stand at partial/B in this record, so the consistency claim is true rather than asserted. `partial` on one of three conjoined marketplaces matches what foodtec's equivalent cell carries. source |
| reliability-offline-card-auth | unknown, grade F | upheld | Proposed partial from the help.microworks.com manual and Wayback payments pages (310th session); rejected on verification: Quote confirmed verbatim, re-fetched 2026-09-15. The Wayback capture 20211118213439 (id_, 200, 21,832 bytes) has 'Receive ongoing benefits - Line-item display, PIN steering, store & forward, cash back and more.' The live news-events.htm (200, 34,581 bytes) carries the same bullet in the 2020 Global Payments Genius release, so the bullet was not withdrawn everywhere, only from payments.htm. The live payments.htm (200, 22,208 bytes) has 0 raw hits for 'store & forward' and goes from 'no downtime!' straight to 'Month-to-month'. Rejected for four reasons. (1) CONFLICT: the same vendor holds payments-offline-store-and-forward = no/B (Authorizer_Overview.htm: no store-and-forward concept, no offline capture). That claim's first clause restates this one. Publishing partial here while that no stands would put 'card payments work offline via store-and-forward' and 'they do not' side by side on one record. If this lead is real, that no cell is what is wrong. It rests on silence in the help centre and now faces a first-party mention, so it should be re-examined, arguably toward unknown. Scoring this cell alone would be a double standard, not a finding. (2) The conjunct is not met. The bullet is a two-word item in a list of processor benefits. It never says 'offline', 'internet down' or 'outage', and it gives no mechanism, scope or limit. 'Store & forward' is industry shorthand for offline capture, but reading that meaning into an unexplained marketing bullet is exactly the marketing-as-capability error. (3) Attribution and scope. The copy is Global Payments Genius product text reproduced by Microworks. It establishes at most that a processor device family advertises the feature, not that Prism's integrated card flow keeps authorising when the store WAN is down. The live page also gates the Genius integration on 'Prism V8.1 or Prism Cloud'. The claim asks whether the POS can accept cards offline, and the proposal itself concedes that the capability 'belongs to the processor device, not to Prism software'. (4) The partial is self-refuting. Its own four shortfalls (marketing grade and later removal, device-only scope with nothing on Prism fixed stations, no floor limit or liability, no help-centre corroboration) leave no conjunct established. Even for a lead that survived, grade C is generous: the only live host is a news release (grade D). The help-centre census has zero hits for 'store and forward' or 'stand-in'. Leave the cell unknown/F with its existing rationale. The Genius bullet can be added to that rationale as an unresolved lead, together with the payments-offline-store-and-forward re-check. source |
| guest-loyalty-offline-behavior | unknown, grade F | upheld | Proposed partial from the help.microworks.com manual and Wayback payments pages (310th session); rejected on verification: Quote confirmed verbatim on a re-fetch of System_Overview.htm on 2026-09-15 (HTTP 200, 21,059 bytes, System menu): 'Upload Offline PrISM Card Transactions - This option allows you to upload any transactions that used PrISM cards while the system was disconnected from the internet. For more information please contact Microworks Tech Support.' It does not carry the claim, for four reasons. (1) The claim is a publication claim: the vendor must document EXPLICITLY what loyalty lookup, accrual and redemption do offline. The sentence names none of the three. It implies only that some card transactions can be taken while offline and sent later, and says nothing of balance lookup, point accrual, redemption limits or reconciliation. The proposal's own shortfalls (1)-(4) fail every conjunct, so the partial refutes itself. (2) The loyalty link is inferred, not stated. The token 'PrISM card' occurs once in the whole 266-topic manual, in this line, and no help topic defines it. The marketing sources never use the phrase either. pizza-delivery-pos.htm (re-fetched, 200) says 'Gift and Loyalty Cards'. It ties the web-based account database to GIFT cards ('customers are allowed to purchase or redeem their cards at one of many locations') and describes Loyalty Cards separately ('Award points can be accumulated ... and redemption monitored and validated'), with no connectivity statement. PrISM_Overview.pdf (re-fetched, 200, text via pypdf) lists only 'Franchise-wide Gift and Loyalty Cards'. The prismcards portal asks for card number and email to see 'card activity and balance', which reads as stored value. So equating 'PrISM cards' with loyalty takes a two-hop inference across grade-C pages, and nothing on them says so. (3) The record's own verified, grade-B row reliability-offline-feature-matrix already reads this same sentence as 'a gift-card catch-up utility' and records 'No statement on gift cards, loyalty lookup ...' in the manual. Accepting this partial would contradict a verified note. (4) Buyer's Club, the documented points programme, has no connectivity statement anywhere. Stays unknown/F. Suggested rationale: 'The manual's only connectivity statement on cards is System_Overview.htm's Upload Offline PrISM Card Transactions utility, which uploads card transactions taken while the store was offline. It does not say whether those are gift or loyalty cards, or what lookup, accrual or redemption do offline. Buyer's Club has no connectivity statement. Marketing names Gift and Loyalty Cards without any offline behaviour.' source |
| payments-offline-store-and-forward | no, grade B | downgrade-to-unknown | Re-fetched both pages 2026-09-15 (the paths as given, /Authorizer_Overview.htm and /news-events.htm, are 404 or a marketing soft-200; the real paths are /webhelp/Authorizer_Overview.htm, 5,239 bytes, and /home/news-events.htm, 34,581 bytes). The no/B had no positive evidence of absence. Its note says only that the chapter 'contains no store-and-forward concept', which is silence in a PCCharge-era chapter and not an enumeration or an 'unsupported' statement. The evidence rules require unknown for that. A first-party Microworks page advertising 'store & forward' on its integrated Genius devices directly contests the no, though as unexplained processor marketing it cannot carry a partial. No conjunct is met: no offline capture is described and no limits are published. Not partial. Amended to unknown/F. Knock-on: payments-offline-decline-liability and reliability-offline-decline-liability (both no/B on the same page) rest on the same premise ('no store-and-forward concept at all'). Their no is still defensible, because they are publication claims and no liability statement or failed-offline report is published anywhere. But their notes should drop the 'no offline concept exists' framing. source |
| order-capture-qr-same-check | unknown (F) — scored 2026-08-03 off marketing pages only | downgrade-to-unknown | Contested and downgraded from the proposed partial/D to unknown/F. Three independent grounds. First, the load-bearing sentence does not say what the claim says: 'leave the check open until they are ready to close out their order and pay' grants the guest a deferred-payment option on their own order ('their order', same clause) and never asserts that QR items land on the server-opened check. Those are different claims and only the weaker one is attested, so there is no established capability for 'partial' to limit -- absence of evidence is unknown by the evidence rules. Second, the same release's own description of the pipeline, 'orders ... feed directly into the Prism POS system', reads as an arriving order record rather than an append, so the single joining source contains a counter-signal as well as the hint. Third, I re-fetched the release myself (HTTP 200, 34,638 bytes, Last-Modified 2025-10-23) and confirmed the dateline 'Rochester, NY July 20, 2021' and every quoted string in the served bytes -- the proposer's transcription is accurate; the disagreement is about what the sentence licenses, not about whether it exists. ON THE GRADE-FLOOR ARGUMENT: the proposer's rule citation is CORRECT, not a misapplication. atlas-evidence-rules states 'A yes on a differentiator-weight claim requires grade A or B. Nothing weaker ... If the best you have is a marketing page saying the feature exists, the honest value is partial or unknown -- not yes at grade D', and scripts/validate/grade-floor.mjs returns 'error' for exactly that shape. This cell is weight: differentiator in data/taxonomy/restaurant.yaml, so a yes at D would fail validation. The rule does gate the VALUE, not only the grade. It is moot here, since the conjuncts are not met on the merits. THE COORDINATOR'S MID-TASK UPDATE CHANGED THIS VERDICT'S GROUNDS: the 27 live-only topics include Order_Types.htm and Customer_Interface.htm, which I read and which supply real counter-evidence; I declined to convert them into a 'no' because both predate QR (2016 and 2010 Last-Modified) and the 2021 release supersedes the 2010 checkout's delivery-or-pickup enumeration by adding to-the-table service. The corpus-vintage objection cuts both ways and I applied it symmetrically. Catch-all discrimination done on md5/Last-Modified per the refinement, not on byte size; my own measurement of the nonsense path was 16,758 bytes / md5 bccd8d89. final_url is empty deliberately: grade F carries no url (scripts/validate/index.mjs errors on 'Grade F carries a url'), and no live URL carries this claim. |
| extensibility-middleware-compatibility | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Upheld at partial/C after verifying both directions myself rather than accepting the proposal. Microworks side: I re-fetched delivery-pos.htm and confirmed the itsacheckmate.com/#party-integrations anchor wraps the exact phrase 'integrates with 3rd party Apps' in the raw bytes -- it spans a line break, so a naive single-line grep misses it, and my first grep did. Middleware side: I confirmed the prism-logo.svg card and the literal string 'Prism POS' in the JSON-LD featureList on itsacheckmate.com/integrations, and that /pos-integrations is a redirect to the same body (md5 9e67259d), not a second independent source. Second-platform hunt run independently over Deliverect (/integrations and /integrations/pos-systems), Chowly (homepage; /integrations and /pos-integrations both 404 with the identical 50,608-byte body), Cuboh and Otter: tokenised prism and microworks 0/6 with a passing POS positive control. I did NOT treat those zeros as evidence of absence, and I bounded them with a named-POS control that shows Deliverect's list is client-rendered. The proposer's poison held and got worse on the full page: 489 substring 'prism' hits on tryotter.com, all prismic.io/prismic.js. I add one poison the proposer missed -- the taxonomy's own example list writes 'Checkmate, ItsaCheckmate' as two entries for one company, which is a live route to a fabricated second platform. Grade C confirmed against the rubric: both sources are first-party feature pages, not documentation, and no integration guide exists on either side. The coordinator's mid-task note (independent corroboration of the delivery-pos quote and the open 'to name just a few' enumeration) did not change the verdict; it is recorded as shortfall 4. The grade floor does not apply -- this cell is weight table-stakes. |
| order-capture-order-ready-signal | unknown (F) — scored 2026-08-03 off marketing pages only | downgrade-to-unknown | Rationale correction only; value and grade unchanged at unknown/F. I verified the correcting quote in the RAW served bytes of news-events.htm, where it is line-wrapped ('...cleared from\n the kitchen monitor'), so a naive single-line grep returns nothing -- the proposer's transcription is accurate. The old rationale's sentence 'local state changes with no documented outbound event' is a false statement about a named vendor's product and had to go regardless of the cell's value. I also read the live Makeline_Monitor_Overview.htm to confirm the Clear action is the one the release's phrase 'cleared from the kitchen monitor' refers to. The cell stays unknown because the documented sink is SMS to guests and drivers, not a marketplace callback, and because the DoorDash registry flag is a known-unreliable negative. Grade stays F with no url: the corrected grounds are still analyst inference over sources that do not carry the claim, and scripts/validate/index.mjs errors on a grade-F row carrying a url. The coordinator's mid-task note did not change this verdict; the live-only topic set contains nothing on notifications. |
| kitchen-order-ready-callback | unknown (F) — scored 2026-08-03 off marketing pages only | downgrade-to-unknown | Rationale correction only; value and grade unchanged at unknown/F. Same verified quote as order-capture-order-ready-signal, confirmed in the raw served bytes where it is line-wrapped. This cell's old rationale was the more wrong of the two, because it specifically denied that the BUMP emits anything, and the release names 'when an order is cleared from the kitchen monitor' as a trigger. I read the live Makeline topic to tie the release's phrase to the documented Clear action rather than assume it. Still unknown: the sink is SMS to guests and to RapidRun drivers, which are the restaurant's own drivers, not marketplace couriers, so the claim's actual conjunct -- a status event back to the marketplace -- is untouched either way. Grade stays F with no url per scripts/validate/index.mjs. The coordinator's mid-task note did not change this verdict. |
| digital-catering-portal | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Resolution from unknown. I re-fetched all six cited topics live and discriminated each against the soft-200 catch-all by byte length and md5 (Order_Types.htm 21,193/2a769066, Customer_Interface.htm 11,030/19ede90f, Customer_Accounts.htm 4,725/7d4669b6, Account_Terms.htm 988/77b87b5c versus the fabricated-path body at 16,758/bccd8d89), and verified every quoted sentence verbatim. The caller's specific challenge is answered against the proposal: catering in PrISM is an in-store POS order type, not a guest portal - the vendor's own PrISM_Overview.pdf lists 'Delivery, Dine-In, Carry-Out, Catering Orders' under POS Features, and catering reads zero on the WebOrder and kiosk/QR pages. I found two defects in the proposal and corrected them in the note: 'Credit Limit - Specify the credit limit for this account' and 'Account Terms - Choose the appropriate account terms' are not on the pages they were cited to (a tokenised 'Credit Limit' control returns 1 hit in the whole library, in QB_Invoices.htm), and the proposal's 'named payment terms' overstates Account_Terms.htm, which says the terms are free-form text fields used only to separate billing cycles. Partial nevertheless survives rather than collapsing to no, and not because generic machinery was read as a feature: one conjunct is squarely met at grade B - credit-based customer accounts that generate invoices and statements - so the partial is not self-refuting, and the value is consistent with settled atlas practice on the same shape (revel-systems partial/B 'catering exists as a distinct POS dining option scheduled to a future day/time ... billed to a House Account', gotab partial/B 'the pieces exist as generic mechanisms rather than a catering portal', touchbistro partial/B). The coordinator's live-corpus correction mattered here: Order_Types.htm and Customer_Interface.htm are both absent from the Wayback unpack, so the whole met side of this cell is invisible to the old corpus. Grade B upheld; the two decisive quotes are vendor product documentation. |
| digital-sms-ordering | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | Resolution from unknown, and the absence is STRUCTURAL rather than a silence in an old document. I did not rest this on the 2010 library at all. I crawled the current marketing link graph myself (16 pages, 2025 copyright) and verified the Prism Notification Service enumeration verbatim, and I found a surface the proposal missed which sharpens it: https://www.microworks.com/SMSPolicy.htm, the vendor's own SMS terms, enumerates the inbound keywords its messaging handles as STOP, START and HELP only. Combined with the nav-level enumeration of ordering channels - which includes Web Ordering, Self-Ordering Kiosk, QR Ordering and Wireless Tablet Ordering and no SMS or chat channel - this is an enumerated absence on a current surface, which is what a published zero requires. I checked the two pages the coordinator warned are missing from the sitemap, kiosk-qr-ordering.htm and rapidrun.htm, directly from the link graph; SMS reads 0 on the kiosk page and the RapidRun page's SMS content is driver-to-guest delivery notification. I considered raising the grade to B on the strength of SMSPolicy.htm, and rejected it: that page governs Microworks' own messaging to its own subscribers, not the restaurant-to-guest product, so it corroborates but does not carry the claim. C stands. The coordinator's live-corpus note did not change this verdict, because the verdict never leaned on the help library. |
| guest-loyalty-offline-behavior | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | Resolution from unknown, and I judge the absence STRUCTURAL rather than merely old - but only after deliberately trying to break it, because an outage behaviour is exactly the thing an old manual would omit for uninteresting reasons. What decides it is that the silence is not confined to the 2010 library. I crawled the 16-page current marketing link graph and found the one passage that comes closest, on the delivery-POS and kiosk/QR pages (2025), distinguishing gift and loyalty card accounts 'stored locally' from an optional 'web based account database' for multi-store operators. That is a 2025 statement about where loyalty data lives which still declines to say what lookup, accrual or redemption do when the link drops - so the vendor is silent on a current surface, not just an old one, and the claim as worded ('documents explicitly') is false today. I also corrected a poison claim in the proposal that pointed the wrong way: it asserted loyalty appears only on enterprise-management.htm, whereas a tokenised run over all 16 pages finds it on kiosk-qr-ordering, restaurant-pos, delivery-pos, pizza-pos and products as well - the proposal's zero was bound to too small a marketing corpus, and fixing it strengthened rather than weakened the cell. I re-fetched Buyer_s_Club_Setup.htm live (6,060 bytes, md5 0f2e5dfc, distinct from the 16,758-byte catch-all) and confirmed the quote verbatim, and ran offline, connectivity, disconnected, redundancy, failover and outage as tokenised controls over the live 258-file corpus with PriSM passing at 300/113. Grade B upheld: the citation is vendor product documentation and it is the only loyalty documentation that exists. |
| reporting-tier-paywall | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Resolution from unknown. The caller's specific challenge was that a partial asserting a paywall may be unevidenced if Microworks publishes no tier structure at all, and I tested that directly: I crawled the full 16-page current marketing link graph and ran tokenised controls with a passing Microworks positive control on every page - tier returns 0 and plan returns 0 across all 16, including quote.htm, whose form is currently broken. So there is genuinely no tier ladder. That does not make the cell unknown, because the partial does not assert a tier ladder; it asserts that one of the four reports the claim names by name, multi-location comparison, is gated behind a separately sold product, and that is positively evidenced twice. Beyond the enterprise-management sentence the proposal cited, I found a second and better first-party source it missed: PrISM_Overview.pdf, still linked from the current site, files 'Web Hosted Enterprise Management' under 'Integrated Options' next to the QuickBooks interface and the surveillance system, which is the vendor's own word for an add-on. Three conjuncts met and one gated is not a partial that shortfalls every conjunct, so it is not self-refuting. I also noted against the proposal that its separate-quote-CTA argument is worthless, since every product page carries the same CTA, and removed that reasoning from the note. Grade C upheld and not raised: the decisive evidence is a vendor feature page written to sell, and no price list exists. |
| reporting-history-retention | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | Resolution from unknown, and I judge the absence STRUCTURAL - with the important qualifier that the claim itself is a documentation claim ('documents a historical retention window'), so what has to be bounded is the publisher's whole published surface rather than the product's behaviour. I bounded it: the 205-title RoboHelp TOC, the 16-page current marketing link graph, PrISM_Overview.pdf, PrivacyPolicy.htm and SMSPolicy.htm. No retention window for transaction detail appears on any of them, old or current, and the verdict does not rest on a zero anyway - it rests on a positive statement, the Trim and Archive line, which I re-fetched live (21,062 bytes, md5 daeca130, distinct from the 16,758-byte catch-all) and confirmed verbatim. I also confirmed the corpus change the proposal reported, that the live Marketing_Module_Overview.htm has lost the 'the purge is permanent' passage the 2010 Wayback capture still holds, which is why that one sentence stays cited to Wayback. The material thing I added is a poison the proposal missed and that would have been easy to score the wrong way: Microworks does publish a section literally headed 'Data Retention', on PrivacyPolicy.htm, stating that transaction and payment data is not retained on Microworks servers - but the entire section is scoped to the RapidRun driver app, and I read the surrounding paragraphs to establish that before rejecting it. That correction is now in the note. Grade B upheld; System_Overview.htm is vendor product documentation. |
| multi-location-normalized-item-rollup | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Resolution from unknown. The caller's specific challenge - whether the evidence shows items normalised under a shared master or merely reports aggregated per store - is the right question, and the answer is that it shows both halves at different strengths, which is exactly what a partial should record. Normalisation is documented at grade B and I verified it live: Storenet_Satellite.htm (1,915 bytes, md5 e2741900) states the franchise master menu and inventory sets, and System_Overview.htm's Force Menu Set Update and Force Inventory Set Update describe the store downloading the corporate menu, so item identity originates at corporate rather than per store. The rollup half is weaker and I tightened the note against the proposal on two points. First, I rejected its reading of Pricing_Tab.htm: I re-fetched the page and the Store Rule entry says only that store rules are used by multi-store franchises in very specific scenarios and that most users can disregard the field - it never says it is a per-store price override, and the proposal's 'exactly the shape the claim describes for local pricing' reads a feature out of a field name. Second, the proposal's item-level cross-store rollup rests on crossing two bullets in a marketing filter list; I checked the third bullet in that same list and it narrows the reading, since the Product Mix filter is by category rather than by store. What keeps this a partial rather than an unknown is the shared corporate item master at grade B plus one genuinely documented item-level cross-store path at grade B, the Web Portal Order List filtered by store Group with per-order item detail and CSV/XML export - limited to the web-ordering channel, which is now named as a shortfall. Not every conjunct shortfalls, so the partial is not self-refuting. Grade C upheld, because the general item-level rollup and the local-pricing tooling both rest on the marketing page. The coordinator's live-corpus note was decisive here: Storenet_Satellite.htm and its three children do not exist in the archived unpack at all, so a verdict bound to that corpus would have missed the master-menu mechanism entirely and probably landed on no. |
| payments-offline-store-and-forward | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Value upheld at partial/D, note rewritten and rebound. I re-fetched the served bytes and confirmed the quote is genuine and contiguous in RAW HTML ('store & forward' inside one <li>), that the typo 'wiith' is the vendor's, and that the item is dated 'Rochester, NY August 10, 2020'. On the value-vs-grade question: the coordinator's first instruction to treat value and grade as independent was retracted and the retraction is correct - the atlas encodes a hard differentiator floor - but it does not matter here, because this cell shortfalls on SUBSTANCE: the claim has two conjuncts and the second (configurable per-transaction and cumulative offline limits) is unpublished everywhere, which is a named shortfall in its own right. On scope: I do not reject the cell on the peripheral-device ground, because in a semi-integrated deployment the Genius terminal IS the merchant's card path ('Keep cardholder data off the POS'), so a terminal that stores and forwards does let that merchant take cards while the link is down; the device origin and the V8.1/Prism-Cloud/'some service providers' gating are recorded as shortfalls instead. The coordinator's corpus correction DID change this note: it is now bound to the LIVE 205-topic WebHelp TOC rather than a 506-topic archived count, and the two payments-area topics that the archive lacked, Credit_Card.htm and Settlement.htm, were read and are stubs ('This must be configured by Microworks Tech Support'), so they add nothing either way. I also corrected the corpus-hole declaration (Advanced_Features.htm is live) and found and published a new trap: the Genius product copy on the live payments page is commented out. |
| reliability-offline-card-auth | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-partial | Value upheld at partial/D, but the PROPOSER'S REASONING IS REPLACED. The proposer argued the single conjunct was met so this 'would read yes', and that only the grade floor forced partial. That form of argument is bad even where the floor is real, because it treats partial as a grading artefact and leaves no named shortfall. I re-derived the value on substance and it lands in the same place for four independent reasons: the store-and-forward assertion is about a resold terminal with nothing published about PriSM's own outage behaviour; the programme is gated on V8.1/Prism Cloud plus integrated processing plus 'some service providers'; no cap, duration or decline treatment is published; and the vendor's own card documentation is silent on link failure. Only after that does the differentiator grade floor apply, and it bites in the same direction - the coordinator retracted its 'value and grade are independent' instruction and the retraction is correct (atlas-evidence-rules line 103 and scripts/validate/grade-floor.mjs make a yes at D on a differentiator a validation error). I did not let the retracted argument inflate the cell, and I did not let the floor do the work that the shortfalls do. The coordinator's corpus correction did not change the value: the two payments-area topics missing from the archive, Credit_Card.htm and Settlement.htm, are live stubs deferring configuration to Microworks Tech Support. |
| payments-payout-timing | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | Upheld at no/C after re-deriving the corpus from scratch, which is what the coordinator's correction demanded. The proposer's note bound the absence to a '506-topic archived library' that lacked 27 live topics, several of them squarely in the payments area, so the zero was not publishable as written. I re-ran every control over the LIVE library at help.microworks.com/webhelp/ (258 files covering all 205 topics of the publisher's own TOC, whgdata/whlstt0..120.htm) and over the 645 archived captures, plus the 26-page live link graph, the 58-row sitemap and the extracted text of PrISM_Overview.pdf. The two newly available payments topics settle nothing in either direction: Credit_Card.htm and Settlement.htm are both stubs reading 'Due to the complexity of these settings ... This must be configured by Microworks Tech Support', and Settlement.htm is order settlement, which reconfirms the 'settlement' poison rather than disturbing it. I also re-derived the sitemap myself: 58 <loc> rows, not 59 - a reader artefact, so the note publishes the invariance (the sitemap omits payments.htm, news-events.htm, rapidrun.htm and kiosk-qr-ordering.htm) rather than the figure, and I checked its residue, 40 sample-report PDFs, by extracting SETTLE.PDF and PrISM_Overview.pdf to text and running the same controls: funding, payout, deposit and same-day are 0 in both. The absence is bindable because the apex returns a genuine 404 (355 bytes) on a fabricated path, so it is not a catch-all. |
| reliability-public-status-page | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | Upheld at no/C; I reproduced the control myself and corrected one false statement in the proposer's note. The wildcard control replicates exactly - five subdomains, including a second nonsense host of my own, all return a byte-identical 163-byte cPanel placeholder (md5 f1fb042c62910c34be16ad91cbbd71fa) - and the statuspage.io and instatus subdomains are indeed unclaimed redirects. The proposer's item (7) was wrong and is removed: help.microworks.com is NOT 'a mirror of the marketing site' that 'cannot be hiding a status page'. Its ROOT is a second catch-all (16,758 bytes, md5 prefix bccd8d89, Last-Modified Thu, 12 Mar 2020 14:05:24 GMT), while /webhelp/<topic>.htm serves the real live PriSM help library, whose topics carry their own Last-Modified dates (Credit_Card.htm 2016-10-29, Purge_Customers.htm 2010-01-19). The corrected fact is stronger than the mistake, because it lets the absence be bound to the publisher's own 205-topic table of contents rather than waved away, and uptime, SLA, incident and 'status page' are all zero across it. I also added a path-level probe the proposer did not run: microworks.com/status.htm is a genuine 404, which shows the apex is not a catch-all and makes the live-site zeros bindable. |
| hardware-handheld-lte | unknown (F) — scored 2026-08-03 off marketing pages only | resolve-to-no | DOWNGRADED from partial/D to no/C - the one value I moved. The proposal rested the partial on a payment terminal's update channel, and three things I checked knock it out. First, the declared corpus hole is closed: Advanced_Features.htm, which the proposer said was never captured and 404s live, is live at help.microworks.com/webhelp/Advanced_Features.htm, and it is precisely the library's handheld topic - it describes 'wireless tablet PCs' and a stylus and no cellular, so the hole closes AGAINST the claim rather than leaving it open. Second, the cellular clause is not current: the same 'Update effortlessly' bullet on the live payments page has had ', wiith both WIFi and cellular connectivity' deleted, so the only cellular sentence Microworks publishes survives in a 2020 news item, and the Genius Handheld copy on that page is inside an HTML comment and unpublished. Third, device class decides it. The claim is about handhelds as order-entry devices failing over when store Wi-Fi drops; Microworks' handheld is Prism Wireless Tablet Ordering, its dedicated page treats connectivity head-on and answers a coverage gap with more wireless antennas, and the third conjunct - cellular documented AS the Wi-Fi fallback - is unmet for both device classes. That is the enumerate-the-alternatives shape the evidence rules accept, so the honest value is no at grade C on the handheld feature page, not a partial resting on a resold terminal's firmware-update path, and the Genius Mini sentence is published in the note as counter-evidence with the no explicitly bounded. The value-vs-grade instruction played no part in this downgrade, and the grade floor is irrelevant here because the weight is niche. |
Sources
Every URL this record cites. 113 in total.
- https://www.microworks.com/products/restaurant-pos.htm
- https://www.microworks.com/products/Handheld-Ordering.htm
- https://www.microworks.com/products/enterprise-management.htm
- https://www.microworks.com/products/kiosk-qr-ordering.htm
- https://www.microworks.com/products/web-ordering.htm
- https://www.microworks.com/products/pizza-pos.htm
- https://www.microworks.com/products/reporting.htm
- https://www.microworks.com/quote.htm
- https://www.microworks.com/products/payments.htm
- https://www.microworks.com/products/rapidrun.htm
- https://www.microworks.com/products/Digital-Surveillance.htm
- https://www.microworks.com/products/delivery-pos.htm
- https://www.microworks.com/sitemap.xml
- https://www.microworks.com/demo.htm
- https://www.microworks.com/home/faq.htm
- https://www.microworks.com/products.htm
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://www.microworks.com/home/supportform.htm
- https://www.pmq.com/online-ordering-company-spotlight/
- https://apps.apple.com/ca/app/greco-pizza/id881537471
- https://play.google.com/store/apps/developer?id=Microworks+POS+Solutions
- https://www.microworks.com/products/custom-graphics.htm
- https://help.microworks.com/webhelp/
- https://help.microworks.com/webhelp/prism.htm
- https://help.microworks.com/webhelp/whxdata/whtdata0.xml
- https://help.microworks.com/webhelp/whxdata/whtdata1.xml
- https://help.microworks.com/webhelp/whxdata/whtdata2.xml
- https://help.microworks.com/webhelp/whxdata/whtdata3.xml
- https://help.microworks.com/webhelp/whxdata/whtdata4.xml
- https://help.microworks.com/webhelp/whxdata/whtdata5.xml
- https://help.microworks.com/webhelp/whxdata/whtdata6.xml
- https://help.microworks.com/webhelp/Pricing.htm
- https://help.microworks.com/webhelp/Advanced_Features.htm
- https://help.microworks.com/webhelp/Employee_Scheduling_Overview.htm
- https://help.microworks.com/webhelp/Create_Schedule.htm
- https://help.microworks.com/webhelp/Forecast_Indicators.htm
- https://help.microworks.com/webhelp/Makeline_Monitor_Overview.htm
- https://help.microworks.com/webhelp/Makeline_Tab.htm
- https://help.microworks.com/webhelp/Advanced_Kitchen_Printing_Tab.htm
- https://help.microworks.com/webhelp/Table_Setup_Update.htm
- https://help.microworks.com/webhelp/Table_Sections_Update.htm
- https://help.microworks.com/webhelp/Splitting_Checks.htm
- https://help.microworks.com/webhelp/Setup_Password_Groups.htm
- https://help.microworks.com/webhelp/Setup_Password_Functions.htm
- https://help.microworks.com/webhelp/Advanced_Reporting_Overview.htm
- https://help.microworks.com/webhelp/Setup_Custom_Reports.htm
- https://help.microworks.com/webhelp/Scheduled_Reports.htm
- https://help.microworks.com/webhelp/Account_Tracking.htm
- https://help.microworks.com/webhelp/Customer_Accounts.htm
- https://help.microworks.com/webhelp/Account_Terms.htm
- https://help.microworks.com/webhelp/Gift_Certificates.htm
- https://help.microworks.com/webhelp/Recipe_Cost_Setup.htm
- https://help.microworks.com/webhelp/Assembly_Item_Setup.htm
- https://help.microworks.com/webhelp/Daily_Inventory_Screen.htm
- https://help.microworks.com/webhelp/Inventory_Master_u.htm
- https://help.microworks.com/webhelp/Inventory_Location.htm
- https://help.microworks.com/webhelp/Modifier_Lists.htm
- https://help.microworks.com/webhelp/Includes_Tab.htm
- https://help.microworks.com/webhelp/Doubles_Classes.htm
- https://help.microworks.com/webhelp/Advanced_Tab.htm
- https://help.microworks.com/webhelp/Buyer_s_Club_Setup.htm
- https://help.microworks.com/webhelp/Comeback_Coupons.htm
- https://help.microworks.com/webhelp/Marketing_Module_Overview.htm
- https://help.microworks.com/webhelp/Labels.htm
- https://help.microworks.com/webhelp/Advertised_Coupons.htm
- https://help.microworks.com/webhelp/Authorizer_Overview.htm
- https://help.microworks.com/webhelp/Delivery_Charges_Tab.htm
- https://help.microworks.com/webhelp/Routing_Tab.htm
- https://help.microworks.com/webhelp/Update_Sectors.htm
- https://help.microworks.com/webhelp/QuickBooks_Interface_Module.htm
- https://help.microworks.com/webhelp/index.htm
- https://help.microworks.com/webhelp/Printer_Setup.htm
- https://help.microworks.com/webhelp/Advanced_Pricing_Tab.htm
- https://help.microworks.com/webhelp/CC_Gift_Check_Tab_LM.htm
- https://help.microworks.com/webhelp/Order_Types.htm
- https://help.microworks.com/webhelp/Payroll_Tab.htm
- https://help.microworks.com/webhelp/Ordering_Module_Time_Clock.htm
- https://help.microworks.com/webhelp/Edit_Employee_File_-_Employee_Detail_Tab.htm
- https://help.microworks.com/webhelp/Edit_Employee_File_-_Availability_Tab.htm
- https://help.microworks.com/webhelp/Web_Ordering_Overview.htm
- https://help.microworks.com/webhelp/Customer_Interface.htm
- https://help.microworks.com/webhelp/Storenet_Satellite.htm
- https://help.microworks.com/webhelp/Upload_Dataset_Satellite.htm
- https://help.microworks.com/webhelp/Devices_Tab_-_Station_Setup.htm
- https://help.microworks.com/webhelp/Networking_The_Workstations.htm
- https://microworks.com/products/payments.htm
- https://microworks.com/products/web-ordering.htm
- https://help.microworks.com/webhelp/Ordering_Tab.htm
- https://help.microworks.com/webhelp/Reporting.htm
- https://help.microworks.com/webhelp/Update_Whiteboard.htm
- https://help.microworks.com/webhelp/Ordering_Advanced_Options.htm
- https://help.microworks.com/webhelp/Web_Tab.htm
- https://help.microworks.com/webhelp/Pricing_Level_Exceptions.htm
- https://help.microworks.com/webhelp/Store_Rule.htm
- https://help.microworks.com/webhelp/Server_Report.htm
- https://help.microworks.com/webhelp/Hourly_Reports.htm
- https://help.microworks.com/webhelp/Update_Customer.htm
- https://help.microworks.com/webhelp/Exclusions.htm
- https://help.microworks.com/webhelp/Order_History.htm
- https://help.microworks.com/webhelp/Customer_Survey.htm
- https://help.microworks.com/webhelp/Support_Policies.htm
- https://help.microworks.com/webhelp/Getting_Product_Support.htm
- https://help.microworks.com/webhelp/whdata/whtdata0.htm
- https://microworks.com/robots.txt
- https://help.microworks.com/webhelp/whcshdata.htm
- https://status.microworks.com/
- https://microworks.com/terms.htm
- https://help.microworks.com/webhelp/whxdata/whfts.xml
- https://merchants.doordash.com/api/partner-integrations
- https://merchants.doordash.com/en-us/learning-center/doordash-preferred-integrations-program
- https://merchants.doordash.com/en-us/integrations
- https://help.microworks.com/webhelp/NONSENSE_CONTROL_XYZZY.htm
- https://web.archive.org/cdx/search/cdx?url=microworks.com%2Fwebhelp*&output=text&fl=original,timestamp,statuscode&filter=statuscode:200