Order status assistant

An order is not a shipment with a nicer number.

An order status assistant answers customer questions from authorized order, fulfillment, package and payment records. The pattern Werkon would validate explains split orders, current source evidence and uncertain delivery dates without flattening them into one status. Software controls access and status mappings, while support, warehouse, carrier and payment teams own exceptions, remedies and confirmed resolution.

Order access and the commercial record

Account authentication, order access, recipient identity, payer status and representative authority are separate checks. A shared address, public tracking reference or approximate identifier does not grant access. Bind every displayed field to the authorized role, source and freshness rule, with payment and address details redacted as needed.

Preserve submitted, accepted, partially accepted, changed, cancellation-requested, canceled and closed states at both order and line level. Keep quantities, prices, taxes, discounts, address versions and promises tied to the controlling order version. Backorders, substitutions, pre-orders, made-to-order goods, digital items, services and pickup can follow different fulfillment paths.

Physical events and dates

Map each line through fulfillment records and handling units to its packages, including splits, merges, replacements and canceled fulfillment. A label is not movement, a manifest is not carrier handover, and a delivered assertion does not prove correct recipient, complete contents or acceptable condition. Missing scans alone do not prove a shipment is lost.

Customer-facing language should follow approved source-state mappings with locale, disclosure, freshness and conflict rules. Preserve committed, requested, planned, estimated, predicted, appointment and actual dates with source, assumptions, version and timezone. A model or carrier scan cannot create a new contractual delivery promise.

Payments, returns and accepted support ownership

Keep payment authorization, capture, settlement, void, chargeback and refund states distinct. Refund request, approval, processor acceptance and funds received require different evidence. Returns likewise separate eligibility, authorization, label, carrier acceptance, receipt, inspection, disposition, replacement, credit and refund. The assistant should not determine tax, warranty or remedy policy.

An exception needs affected lines, source evidence, reason, owner, due time and restrictions. Carrier inquiries, warehouse tasks, payment investigations, returns and complaints retain their own owners and states. Handoff requires receiving-owner acceptance, including decline, fallback and concurrent ownership. Approved actions and later physical or financial results must be reconciled; silence does not prove satisfaction.

Status boundary

Answer the order question without flattening the order.

Commercial, physical, financial and support systems describe different parts of the customer's situation. Four boundaries preserve the answer.

Requester, order, line, and disclosure scope

Authenticate the requester or approved guest-order proof, resolve account and representative roles, bind the exact order version and affected lines and apply server-side field disclosure and redaction before retrieval or response.

Required evidence: Tenant, brand and channel, requester and session, account and customer links, guest proof or representative authority, order and version, line identifiers, question intent, channel and locale, authorization decision, allowed and redacted fields, access time, retention and disclosure owner.

Fulfillment, package, event, and promise evidence

Map each line through allocation and fulfillment to shipments and packages, reconcile commercial documents with warehouse and carrier events and keep last-known physical state, freshness, conflict and committed or estimated dates explicit.

Required evidence: Order and line quantities and states, allocation and backorder, fulfillment lines, handling units and packages, carrier and service, despatch and receipt advice, physical events and source, event and received times, duplicate and ordering result, last location and condition assertion, promise type, window, timezone, source, version and assumptions.

Customer-safe answer and uncertainty

Translate only approved source states into accessible localized phrases, preserve line or package scope, redact sensitive data, label unknown, partial, stale and conflicting evidence and offer only next steps supported by policy.

Required evidence: Answer-policy and mapping versions, source snapshot and freshness, selected facts, scope, conflicts and omissions, promise wording, redaction, locale and accessibility, draft and approval where required, rendered response, source links available internally, delivery events, correction route and answer expiry.

Exception, accepted owner, and resolution

Create an idempotent evidence packet for late, missing, partial, damaged, wrong, payment, return or other exceptions, require a qualified receiver to accept work and reconcile actions and physical or financial outcomes without automatic remedies.

Required evidence: Exception and affected lines, reason and severity candidate, source packet, service policy, named queue and owner, due time, acceptance, decline, transfer and fallback, restrictions, approved action, execution receipt, carrier, warehouse, payment or return response, delivery or receipt, refund or replacement, customer communication, correction, complaint and resolution.

Question-to-resolution path

Keep commercial state, physical evidence, answer, and resolution separate.

A customer deserves a direct answer, but direct does not mean certain when sources are stale or split.

01
Establish requester and question scope
Authenticate the account or approved guest flow, verify representative authority, resolve tenant, market, order and line references, classify the question and determine fields and actions allowed for this role, channel and jurisdiction.
Owner
Identity, privacy, commerce and customer-support owners
Evidence
Session and authentication, proof method, requester, customer and representative roles, tenant and channel, order candidates and match result, intent, locale, accessibility, allowed and restricted fields, retention, risk route and authorization receipt.
02
Reconstruct order and line state
Read the controlling commercial order and changes, payment boundary, allocations, cancellations, substitutions and backorders; preserve versions and quantities and expose partial and conflicting line state before joining any package.
Owner
Commerce, order-management, payment and inventory owners
Evidence
Order and response documents, header and line versions, submitted, accepted, changed and canceled states, item and quantities, currency and amounts allowed for display, address version and redaction, payment authorization and capture boundary, allocation, substitution, backorder, split and source conflicts.
03
Join fulfillment, event, and promise evidence
Map lines to fulfillment and handling units, reconcile warehouse, carrier and receipt evidence, deduplicate and order events, preserve last-known source and freshness and distinguish requested, committed, estimated, predicted and actual dates.
Owner
Fulfillment, warehouse, logistics, carrier and promise owners
Evidence
Fulfillment and package graph, despatch and receipt advice, carrier identifiers, event sources, object and location, business step and disposition, event and received times, duplicate and ordering state, cancellations and corrections, coverage, promise source and type, window, timezone, version and data age.
04
Answer or hand off with evidence
Apply approved status mappings and disclosure rules, produce a line-scoped answer with freshness and uncertainty or create an idempotent exception packet and transfer it only when a named owner accepts responsibility.
Owner
Customer-communications, localization, support and exception owners
Evidence
Policy and status mapping, selected source facts, missing and conflict handling, redaction, rendered answer and next step, approval where needed, generated and delivery states, exception identifier and reason, source packet, queue and owner, due time, acceptance, decline, transfer, fallback and concurrent ownership.
05
Reconcile action and realized resolution
Join later warehouse, carrier, payment, return and support actions to the answer-time packet, correct customer-visible state, notify through the permitted channel and measure answer and handoff quality separately from physical and commercial outcomes.
Owner
Resolution, correction, quality and outcome owners
Evidence
Investigation and external responses, approved and executed actions, cancellation, reroute, replacement, return, credit or refund states, delivery and receipt evidence, communication and acknowledgment, correction and reopen, complaint, answer accuracy, promise variance, owner response, resolution time and reviewed outcome.

Authority map

Separate status controls, language assistance, and remedy authority.

A model can summarize split fulfillment. It cannot authorize order access, create a promise or issue a refund.

Deterministic order controls

Software owns tenant and requester authorization, order and line identities, source allowlists, state mappings, event deduplication, field disclosure, redaction, freshness, date and currency handling, action gates, idempotency, retention and receipts.

Requester, order, line, fulfillment, package, event, promise, answer, exception and action identifiers
Role, field, source, state, version, freshness, redaction and locale enforcement
Quantity, currency, line-package, duplicate, ordering, promise and precondition validation
Access, source, answer, delivery, handoff, action, correction and outcome receipts

Bounded AI assistance

Models can classify questions, retrieve allowed facts, compare source states, summarize line and package evidence, explain freshness, translate approved wording and draft handoff notes, but cannot browse, authorize or act.

Question intent and identifier candidates
Source conflict, missing-line and stale-event prompts
Approved status, uncertainty and next-step explanations
Exception packet, customer response and correction-note drafts

Human commercial and operational authority

Qualified people own disclosure policy, source priority, customer promises, exception severity, liability, customs, payment, tax, return and warranty interpretation, compensation, cancellation, rerouting, refund, reshipment, complaint and stop decisions.

Order-access, sensitive-field, guest-proof and representative decisions
Source conflict, promise, carrier, warehouse and delivery judgments
Cancellation, reroute, replacement, return, credit, refund and compensation authority
Exception acceptance, customer remedy, complaint, correction and release decisions

Status components

Build a question-to-resolution ledger, not a tracking veneer.

Order, shipment, payment and support records have different identifiers and owners. Four ledgers preserve their joins.

Requester, order, and line ledger

Bind tenant, requester, account or guest proof, customer and representative roles, authorization, order and versions, lines, items, quantities, currency, address version, submitted, accepted, changed, canceled, held, substituted and backordered states.

Operating contract: Contact is not identity, address is not authority, order number is not access, submission is not acceptance, payment authorization is not order approval, cancellation request is not cancellation, header state is not every line state and one order may produce zero, one or many fulfillments.

Fulfillment, package, and event ledger

Link order lines to allocations, fulfillment lines, despatches, handling units and packages; preserve warehouse, carrier, EPCIS-like and receipt events, sources, event and received times, location and condition assertions, duplicates, order, cancellations, corrections and freshness.

Operating contract: Allocation is not stock, pick is not pack, label is not movement, despatch advice is not carrier handover, carrier acceptance is not current location, out for delivery is not guarantee, delivered assertion is not recipient receipt and one package state is not the whole order.

Promise, answer, and communication ledger

Version requested, committed, planned, estimated, predicted and actual dates, source and assumptions; map authoritative states to localized accessible customer phrases, disclosure and redaction; record unknown, partial and conflicts, rendered answer, delivery, reply, correction and expiry.

Operating contract: Estimate is not promise, model prediction is not commitment, generated is not sent, sent is not delivered, delivered is not understood, friendly summary is not source fact, stale data is not current and answer is not resolution.

Exception, action, and resolution ledger

Preserve exception reason and affected lines, evidence packet, queue and owner, due time, acceptance and transfer, investigation, external responses, approved action, execution, replacement, return, credit, refund, delivery or receipt, customer communication, complaint, correction and reopen.

Operating contract: Case opened is not assigned, assigned is not accepted, investigation is not remedy, refund requested is not approved, processor accepted is not funds received, replacement created is not delivered, closed is not necessarily resolved and later outcome is not caused by the assistant.

Delivery path

Prove one split order through answer and correction.

Start with one market, channel and fulfillment path whose order, package, payment, return and exception sources can be replayed together.

01
Choose one bounded question set
Select tenant, market, channel, customer role, order types and status questions; name identity, commerce, fulfillment, carrier, payment, returns, privacy, communications, support, exception, correction and stop owners.
02
Map identifiers and source authority
Inventory authentication and guest proof, orders and lines, changes and cancellations, payments, allocations, fulfillment, packages, carrier and warehouse events, promises, returns, support and communications; document field authority, clocks, retention and conflicts.
03
Encode hard status and disclosure rules
Implement server-side access, line-package mapping, state machine, source priority, duplicate and ordering handling, freshness, status phrasing, redaction, date and currency semantics, uncertainty wording, exception triggers, handoff acceptance and failure behavior before model summaries.
04
Pilot read-only answers and handoffs
Let the assistant answer approved low-risk questions or assemble exception packets while people own conflicts and remedies; replay split, partial, stale, disputed, payment and return cases and measure answer correction, disclosure, escalation and burden.
05
Release narrowly and reconcile resolution
Expand only proven read paths, keep every write and remedy behind current authority, re-read sources before response, preserve human takeover and join later physical, financial and support evidence to answers, handoffs and corrections.

Release controls

Six controls before an assistant answers where an order is.

Response speed cannot repair unauthorized access, a flattened split or an invented delivery promise.

Requester rights are checked server-side: Resolve authenticated account, guest proof, customer, recipient, payer and representative roles for the exact order and channel; disclose only allowed redacted fields and never treat an address, tracking number or model match as authority.
Order and line state remain distinct: Version submission, response, change, cancellation, hold, item and quantity state by line and keep payment, allocation, fulfillment and invoice boundaries visible; never let a header status overwrite partial or exceptional lines.
Physical events show source and freshness: Map lines to packages explicitly, preserve warehouse, carrier and receipt evidence with event and received times, deduplicate and order where possible, expose canceled and conflicting events and label last-known state and data age.
Promises keep their type and owner: Separate requested, committed, planned, estimated, predicted, appointment and actual dates, record source, timezone, assumptions and version and never let a model or scan create contractual certainty or an unsupported ETA.
Answers preserve scope and uncertainty: Use approved accessible localized state mappings, redact sensitive fields, name affected lines or packages, state unknown, partial, stale and conflicts directly, give only supported next steps and keep communication delivery states honest.
Exceptions have accepted owners: Create idempotent evidence packets with reason, source snapshots, service policy, queue, owner and due time, require acceptance and fallback and prohibit automatic cancellation, reroute, reshipment, refund, compensation or closure.

Proof model

Measure authorized answers, current evidence, and accepted resolution.

A fast tracking reply can still expose another customer, hide a partial line or turn a stale scan into a false promise.

Baseline

Tenants, brands, markets, channels, requester and representative roles, authentication and guest flows, order and line types, split and substitution patterns, fulfillment and carrier paths, payment and return methods, locales and support queues
Current source coverage, line-package mapping, event delay and conflict, canceled and corrected events, status-map versions, promise types, stale thresholds, redaction, exception triggers, owner capacity and correction paths
Current time and burden from question through authorization, retrieval, reconciliation, answer, communication, exception creation, acceptance, investigation, action, resolution, correction and reopen
Current answer, delivery, exception, resolution, return and refund counts by question and material segment, with physical delivery, receipt, customer understanding and commercial outcome kept separate

Outcome evidence

Correct requester authorization and field disclosure, exact order and line resolution, complete split and package mapping, source coverage, event freshness, conflict visibility and promise-type accuracy
Direct answer coverage, appropriate abstention, localized accessibility, redaction, line-scoped clarity, answer correction, communication delivery and supported next-step quality
Exception trigger accuracy, packet completeness, acceptance and fallback, owner response, action authorization, execution receipts, correction and reopen handling without concurrent ownership
Customer and staff burden plus physical delivery, receipt, return, refund, complaint and service outcomes measured separately, with carrier and operational effects visible and causal attribution withheld

Guardrails

Wrong tenant, account, requester, order, line or representative; guessed or shared identifier; address exposed; payment detail leaked; excessive prompt or log data; deleted record retained; injected product or carrier text changes access or answer
Submission called acceptance, payment called fulfillment, cancellation request called canceled, header overwrites line, split or substitution hidden, label called movement, carrier acceptance called location, delivered called receipt, stale or conflicting event hidden
Estimated date called promise, time zone wrong, model invents ETA, partial order called complete, package status applied to all lines, refund request called paid, return label called received, generated message called delivered or unsupported remedy promised
Exception not created, duplicate case, owner does not accept, fallback fails, concurrent actions, stale reply changes order, unauthorized cancellation, reroute, refund or reshipment, case closed without resolution, correction suppressed or outcome attributed without evidence

Fit test

Use this pattern when order questions can be answered from replayable sources.

Good reason to begin

One market and channel has named identity, commerce, fulfillment, warehouse, carrier, payment, returns, privacy, communications, support, exception, correction and stop owners with capacity to accept handoffs.
Requester roles, guest proof, order and line identities, source authority, state mappings, line-package relations, event freshness, promise types, field disclosure, redaction, exception and remedy policies are explicit and versioned.
Representative split, partial, changed, canceled, substituted, backordered, stale, disputed, payment, return and refund histories can be replayed with source events, prior answers, corrections and outcomes.
The system can answer read-only questions without write authority, show unknown and conflict, create an idempotent case, obtain owner acceptance and reconcile later physical, financial and support evidence.

Resolve before beginning

Requester authorization, guest proof, line identity, source authority, event freshness, promise ownership, field disclosure, status mapping, exception queue, handoff acceptance or correction route is undefined.
The process cannot distinguish order from payment, line from header, fulfillment from shipment, package from order, scan from location, estimate from promise, delivered assertion from receipt, assigned case from accepted work or refund request from funds received.
Success is defined by containment or response time without unauthorized exposure, answer correction, stale and conflict handling, split-order accuracy, promise variance, exception acceptance, resolution, complaints and customer burden.
The assistant is expected to guess access, reveal addresses, invent status or ETA, browse arbitrary tracking pages, blame a party, decide liability, reroute, cancel, refund, reship, compensate, promise a remedy or close unresolved work.

Source basis

Sources behind the control model.

01
OASIS Open
Universal Business Language Version 2.4
UBL 2.4, approved as an OASIS Standard on 20 June 2024, defines generic business-document schemas including Order, Order Change, Order Response, Order Cancellation, Despatch Advice, Receipt Advice, Fulfilment Cancellation, Document Status and related references. It does not authenticate a party or document, make a source current or complete, define a merchant's state mapping, authorize customer access, prove physical movement or receipt, create a promise, resolve an exception or prove outcome.
02
GS1
EPCIS 2.0.1
GS1 lists EPCIS 2.0.1 as the latest standard for sharing supply-chain visibility events and frames event dimensions around what, when, where, why and how. It does not authenticate the producer, guarantee identifier mapping, event completeness, order or current location, establish commercial order, payment or promise state, authorize requester disclosure, prove recipient receipt or resolve an exception or outcome.
03
United Nations Economic Commission for Europe
Buy-Ship-Pay Reference Data Model
UN/CEFACT describes Buy-Ship-Pay as a generic semantic reference model for contextualized supply-chain data exchange across organizations and industries. It does not authenticate a party or record, make every implementation complete or current, choose local order, fulfillment, payment, return or customer-status semantics, grant access, create a promise, execute a remedy or prove resolution or outcome.
04
Cloud Native Computing Foundation
CloudEvents 1.0.2
The CloudEvents project lists 1.0.2 as the latest released core specification for common event-envelope semantics and protocol or data-format bindings. An envelope does not authenticate its source or payload, guarantee a unique business event, authorization, ordering, completeness, delivery or exactly-once handling, establish order or shipment state, prove customer attention or receipt, create a promise or resolve an exception or outcome.

[ WORKFLOW / SYSTEMS AUDIT ]

THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the Workflow Start with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Stay with the operating question. The technology can wait until the work is clear.

An order is not a shipment with a nicer number.

Order access and the commercial record

Physical events and dates

Payments, returns and accepted support ownership

Answer the order question without flattening the order.

Requester, order, line, and disclosure scope

Fulfillment, package, event, and promise evidence

Customer-safe answer and uncertainty

Exception, accepted owner, and resolution

Keep commercial state, physical evidence, answer, and resolution separate.

Establish requester and question scope

Reconstruct order and line state

Join fulfillment, event, and promise evidence

Answer or hand off with evidence

Reconcile action and realized resolution

Separate status controls, language assistance, and remedy authority.

Deterministic order controls

Bounded AI assistance

Human commercial and operational authority

Build a question-to-resolution ledger, not a tracking veneer.

Requester, order, and line ledger

Fulfillment, package, and event ledger

Promise, answer, and communication ledger

Exception, action, and resolution ledger

Prove one split order through answer and correction.

Choose one bounded question set

Map identifiers and source authority

Encode hard status and disclosure rules

Pilot read-only answers and handoffs

Release narrowly and reconcile resolution

Six controls before an assistant answers where an order is.

Measure authorized answers, current evidence, and accepted resolution.

Baseline

Outcome evidence

Guardrails

Use this pattern when order questions can be answered from replayable sources.

Good reason to begin

Resolve before beginning

Sources behind the control model.

Start with one real workflow

Choose the next useful path.

Explore governed AI agents

Design customer communications

Build retail and commerce systems

Compare shipment-event controls