Platform Frame: Ordermatic Is an Agentic Inbox

Generated from an /office-hours vision session on 2026-09-07. This is an internal frame for how we talk about the architecture, not a new feature and not outward-facing copy. Nothing about the website, the sales pitch to Cleveland Kitchen, or any shipped surface changes because of this doc.

In one paragraph

Every inbound document or message Ordermatic handles — a new PO, a change to an order already on file, a vendor’s acknowledgment of a PO we sent them, eventually a shortage notice or a plain status question — is the same shape: a ticket. Triage classifies it. An agent finds the ERP record it’s about, or determines there isn’t one yet. The agent matches, diffs, and drafts a resolution. A human decides. The agent applies the decision to the ERP. That loop is the platform, underneath whatever we call it in a given quarter’s pitch.

Why write this down now

Two live prospect conversations four weeks apart — All State Fasteners on 2026-09-03, P.F. Markey on 2026-08-11 — described their own problem back to us in inbox and ticket language, unprompted, without either of them having seen this framing from us:

P.F. Markey / AFC Tooling (Brandi Goodman, 2026-08-11): already runs vendor-acknowledgment matching as a literal Zendesk inbox — roughly 300 acknowledgments a day, one person comparing each PDF to its P21 PO by hand and attaching it. Their mental model of the problem is already “an inbox of tickets that need matching and resolving,” not “purchase order automation.”
All State Fasteners (Pat, Director of Supply Chain, 2026-09-03): asked, unprompted, for “one view to see what’s unconfirmed, price-flagged, or needs action” across their two ERPs (P21 and InSQL). That is a cross-system ticket queue, in his words, not an order-entry screen.

Neither of them was shown this frame before they described their problem in it. That is a stronger signal than a good pitch: it means the frame matches how the buyer already thinks, not just how we want to talk.

We already build this way — this names a shape, it doesn’t propose one

The existing webapp Inbox is a ticket-status queue for new orders today, backed by the workItems table (Unified inbox). The schema persists a simpler lifecycle (new → in_progress → awaiting_review → submitted → archived / error); the UI layer derives a richer set of operator-facing states on top of it (e.g. needs_review, needs_fix, processing, ready, failed — see Work items state model for the full set).
workItems already accepts a ticket, not just an email, as a source. The zendesk source type and a dedicated POST /api/webhook/zendesk route exist today: a Zendesk ticket tagged as an order is pulled into the exact same pipeline an emailed PO travels (R2 → pdf_documents → workItems → the extraction workflow), and the CSR reviews it in the existing inbox. It is gated off by default per connection (zendesk_order_source_v1) — no org has it on — but the pipeline itself is not hypothetical: it is the concrete, already-built version of “a ticket becomes a work item,” scoped today to tickets tagged as new orders rather than vendor acknowledgments.
Inbox Is The Product (CEO-reviewed and largely shipped, 2026-03) already treats every order — email, upload, or API — as one row in a single work queue: open it, resolve it, move to the next. snoozedUntil, SLA timers, and the supervisor dashboard are the ticket mechanics of that plan, already in the schema.
The Revision tab (approved 2026-09-03, in flight on PR #3339 against the Unified Revision Workbench plan): its approved rail is a progress meter plus Needs attention / Changes / Unchanged groups — a ticket queue, arrived at for a completely different reason (reusing existing review-page vocabulary) and never named as one.
order_events (designed in the June 2026 order-lifecycle-expansion plan, not yet built): a status machine — captured → in_review → approved → applied / rejected / superseded / failed — that is a ticket lifecycle, waiting on the document-less changes (plain-text edits, cancellations) that don’t fit the Revision tab.
Aurora Material Solutions evaluated Conexiom and Ordermatic head-to-head and preferred us — not a signed close, and the door isn’t fully shut on the incumbent (per internal deal notes, not in this repo). Supervisor visibility across individual CSR inboxes was one of the stated reasons. If that holds up, this frame — unnamed — already worked once in a competitive evaluation.

None of this requires new tables, a new UI, or a new engineering surface. It is a name for the shape several already-built and already-designed pieces already share.

What this changes today, and what it doesn’t

Internal, starting now: use “agentic inbox” as the description of the platform architecture in engineering and product conversations, roadmap docs, and when explaining the system to a new hire. It is the one-sentence answer to “what is Ordermatic, structurally.”
With All State Fasteners and P.F. Markey, specifically: use this language directly. Pat’s cross-ERP “needs action” view is this frame — naming it to him costs nothing and is not a new promise, since the underlying pieces (the Revision tab, the diff engine) already exist or are in flight.
Not on the website. Not with Cleveland Kitchen yet. CK’s CSR experiences a document-review screen, not a queue, and the outward GTM line for the sell-side stays “order changes, not just order entry” (see the Unified Revision Workbench plan’s positioning discussion) until order_events and a real cross-ERP view exist. Claiming a platform frame before the parts that make it true exist is the same shipped-but-unregistered mistake we’ve caught in other places — we are not going to make it here.
No architecture change, no new build. This document changes nothing about packages/db schema, the Revision tab’s scope, or any phase table. It is a naming exercise with a falsifiable premise, below.

The premise this creates, and what would prove it wrong

The premise is: the existing rail-and-progress-meter vocabulary generalizes to a ticket queue across sell-side and buy-side without inventing new UI concepts. That is testable, not assumed.

If a real buy-side workbench for All State Fasteners or P.F. Markey turns out to need materially different queue mechanics than the sell-side rail — SLA timers, per-buyer assignment, a different set of resolution actions than accept/skip/dispute — the premise breaks, and “agentic inbox” stops being a description of the product and starts being a claim ahead of it. Watch for this specifically when the buy-side workbench (the Revision plan’s B2 phase) is built against a real buyer, not a mockup.