# When Every Order Update Still Has to Go Through the Owner

By Leandro “Aian” Bauzon

*Case basis: This illustrative case concerns a small Philippine online seller. Its people, transactions, and operating details are hypothetical; no implementation results are claimed.*

Start by fixing the shared order record and the rules for updating it, rather than migrating immediately to another platform. For the seller in this case, the first problem is that payment, packing, and courier updates never come together in a dependable view.

That recommendation changes if the team already understands the handoffs but the existing tool makes timely, accurate updates impractical. Better software should address a demonstrated constraint, not substitute for deciding how the work should move.

This case develops the approach introduced in my article, “The Operational Truth Layer: Why Growing MSMEs Fail at Status Tracking (And Why More Software Isn't the Answer).”

## The situation: information exists, but the owner still has to ask

The seller accepts orders through messaging channels. Sales records customer requests, accounts checks payments, and fulfillment packs orders and arranges courier collection. A shared spreadsheet exists, but staff also maintain separate conversations about addresses, payment confirmations, and delivery schedules.

A customer asks about an order. Sales has the payment screenshot. Accounts has confirmed receipt in another conversation. Fulfillment has packed the parcel, but the courier has not collected it. The spreadsheet still says “Processing.”

Sales asks the owner what to tell the customer.

The owner is not merely supervising. The owner is reconciling information that the workflow should already connect.

The immediate objective is to make routine order questions answerable without that intervention. The practical constraints are limited administrative capacity, an existing spreadsheet, and no dedicated systems specialist. The seller needs a manageable test, not a large implementation project.

## Diagnose the handoff before choosing the tool

A status label is useful only when staff agree on the event behind it. “Dispatched” should mean that the courier has taken custody—not that someone created a booking or intends to send the parcel.

GS1’s Global Traceability Standard makes a useful distinction between critical tracking events, such as packing and shipping, and the data describing those events. It also directs organizations to identify relevant steps in their internal business processes and establish how the associated data will be captured. [1]

Applied here, each important handoff needs:

- A defined event that changes the record.
- Evidence sufficient to confirm it.
- An authorized person responsible for the update.
- A deadline for updating it.
- A next action when the expected event does not occur.

This is the practical purpose of an Operational Truth Layer: a shared view connecting the order, its current position, its evidence, and responsibility for what happens next.

### Keep one order identity, not necessarily one physical row

A simple order may fit in one row. An order with multiple shipments or a partial refund may require linked records.

GS1 recognizes that different kinds of traceability data can be managed in different systems while contributing to a connected view. [1, section 3.3.1] For this seller, the design implication is one order identifier and an agreed summary, with supporting records linked where needed—not a requirement to squeeze every event into one cell.

### Separate progress from problems

Payment and fulfillment should remain distinguishable. Payment confirmation does not establish delivery, and a refund request does not explain where the parcel is.

An exception should also preserve the last confirmed stage. “Packed; address clarification required” gives staff more usable information than replacing everything with “Exception.”

The record should show both what has happened and what is preventing the next step.

## Worked example: one order, one visible next action

The following example continues the same hypothetical transaction. The identifier is illustrative.

| Record element | Before | Proposed record |
| --- | --- | --- |
| Order identity | Customer name repeated across chats | Order O-104, used in the register and related messages |
| Payment | Screenshot in sales chat | Confirmed by accounts; verification time and evidence reference recorded |
| Fulfillment | “Processing” | Packed; awaiting courier collection |
| Next action | “Follow up” | Fulfillment to confirm collection by the agreed pickup cutoff |
| If collection is missed | Another message to the owner | Flag missed pickup; retain “Packed”; assign fulfillment to rebook and sales to update the customer |
| Dispatch confirmation | Booking message treated as progress | Fulfillment records collection time against courier acknowledgment |

Under this design, sales can explain the last confirmed position without reconstructing several conversations. If collection is missed, the record identifies the response instead of merely announcing a problem.

The courier need not edit the spreadsheet. An authorized fulfillment employee can record the handoff against evidence. Receiving-side confirmation is useful where practical, but it should not prevent the business from recording an externally verifiable event.

Chat remains available for coordination. Any decision that changes the order’s position or next action must also reach the agreed record.

## Compare three workable responses

The owner should compare options on visibility, maintenance effort, dependence on one person, and ability to handle the seller’s transactions.

| Option | Visibility and dependence | Effort and suitability |
| --- | --- | --- |
| Appoint a status coordinator using existing tools | Gives staff a clear contact, but may simply transfer dependence from the owner | Lowest disruption; reasonable when consolidation is light and records remain accessible |
| Redesign the shared register and handoff rules | Makes status accessible across roles if updates remain accurate | Moderate setup and continuing manual effort; suitable for a manageable order stream |
| Adopt an order-management system with workflow redesign | May support structured access and automated updates, depending on the product | Greater setup and migration burden; appropriate when duplicate entry, access, or complexity defeats the register |

The second option is the best starting point under the case assumptions. It tests the suspected failure directly without committing the seller to a migration.

The first remains credible for a very small operation. The third becomes preferable when specific requirements exceed the current tool’s capabilities.

A systematic review of cloud ERP implementation in SMEs identifies compatibility with organizational needs, data security, and senior-management support as prominent success factors. [2, abstract] The implication is not that tools are secondary in every situation. Tool fit and operating responsibility need to be considered together.

## Run a bounded pilot, then decide

Use seven days as an initial diagnostic window, not as proof that the business is ready—or unready—for ERP.

### Establish the starting position

The owner and a designated process lead should select one reasonably consistent order stream, reconcile its open orders, and agree on status definitions and closure conditions.

Each participating role needs an update responsibility, a backup, and a realistic deadline. The process lead should establish evidence links, appropriate access, and edit history where the tool supports it.

Before changing the process, record how often the owner must reconstruct an order’s status and sample how often the register matches payment and courier evidence. Staff time spent maintaining the record also matters: a clearer register that requires excessive duplicate entry may not be sustainable.

### Review overdue work, not just declared exceptions

During the pilot, staff update their assigned fields. The process lead checks a small daily sample against supporting evidence. GS1 identifies completeness, accuracy, consistency, and timestamping among the relevant dimensions of traceability-data quality. [1, section 3.3.4]

The owner shifts away from routine status chasing toward overdue work, unresolved exceptions, and discrepancies.

Reviewing only entries already marked “Exception” is insufficient. An order can be stuck while its record still appears normal. Overdue-order checks and sample verification help test whether the new visibility is trustworthy.

### Let the findings change the diagnosis

At the review point, examine record accuracy, update delays, owner involvement, unresolved overdue work, and maintenance effort.

- If records become reliable but orders still stall, investigate stock, staffing, or courier constraints.
- If responsibilities are clear but updates remain cumbersome, reconsider the tool.
- If staff disagree about when to advance an order, revise the handoff definitions.
- If owner inquiries decline but discrepancies rise, do not mistake reduced escalation for improvement.

Continue through another representative operating cycle before judging sustainability. The pilot should reveal the next decision, not merely confirm the initial preference.

## The practical test

The question is not whether the business has a spreadsheet or a platform. It is whether someone can establish what happened, what remains unresolved, and who acts next without assembling the answer from chat histories.

Fix that connection first where the current tools can support it. Where they cannot, use the same requirements to choose a better system.

## Source notes

[1] GS1. *GS1 Global Traceability Standard*, Release 2.0, ratified August 2017. Relevant passages: sections 3.1 (tracking events and their data), 3.3.1 (data sources across systems), and 3.3.4 (data quality). The standard concerns supply-chain traceability; its recording principles inform this case, rather than establish outcomes for the proposed workflow. https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard

[2] Leonardo Moro Barbieri, Michele Kremer Sott, and Jefferson Marlon Monticelli. *Critical Success Factors for Implementing Cloud ERP in SMEs: A Systematic Review.* International Journal of Innovation and Technology Management, 21(02), 2024. DOI: 10.1142/S0219877024300039. The cited statement is expressly contained in the accessible publisher abstract; full-text access is restricted. https://www.worldscientific.com/doi/abs/10.1142/S0219877024300039