Workflow design · scope to your operationFrom trigger to finished work
- Local POS + online orders + supplier feeds
- canonical SKU/location records
- freshness and ownership checks
- calculate available-to-promise
- reserve or flag conflict
- publish channel-specific availability
- reconcile acknowledgements
The rules that matter
Keep local on-hand, committed, damaged, in-transit and supplier-reported stock distinct. Do not count the same physical unit twice. Supplier stock is an external promise, not owned stock. Version and log every availability decision.
When the normal path breaks
Stale feeds; simultaneous last-unit purchases; supplier withdrawal; phone colour swaps; mixed baskets; cancelled orders; event replays.
Uncertain inputs go to an assigned owner with the source, reason and next decision. Failed writes are reconciled before retrying, so a recovered connection does not create a duplicate order, payment or stock movement.
How we would measure it
Human touches/order; oversell cancellations per 1,000 orders; discrepancy units by location; feed age; time to resolve exceptions.
Sample representative work before the build, including difficult cases. Compare the same task mix after launch; include review, exception handling and system upkeep in the time used.
Start with one accountable slice
Map the first input, the final accepted result and who can approve it. Agree source systems, read/write access, rules, exception ownership and acceptance checks. Run representative normal, failure and recovery cases before expanding across teams.
What makes this suitable for larger teams?
Role-based access, separation of preparation and approval, versioned rules, an action history, duplicate protection, reconciliation, alerts and a named recovery owner. Private deployment or customer-controlled infrastructure can be scoped where needed. These are design requirements to validate, not an unsupported promise of perfect source data or regulatory compliance.
Before you buildQuestions about this workflow
Specific answers to help you judge the fit, the information needed and the decisions your team keeps.
Can we keep our current POS and online store?
Usually the first step is to inspect their stock records, APIs or exports and update permissions. We map product variants and locations between them, then identify which system owns each field. Existing native stock features may already cover part of the job.
How do you separate our stock from supplier availability?
Local stock, reservations, damaged units and supplier availability remain separate records. The promise shown to a buyer follows your fulfilment rules and source freshness. Supplier stock can support an eligible delivery option, but it should not appear as a unit ready for immediate local pickup.
What if a walk-in and online customer buy the last unit?
We check whether the connected systems support reservations or conditional stock updates. Where they do, those controls can reduce competing allocations. Where they do not, the design needs a stock buffer, a confirmation step or a clearly owned conflict queue rather than an unsupported instant-sync promise.
What happens when a supplier feed is late or incomplete?
Each source gets an agreed freshness threshold and missing-data policy. A missing row is not automatically zero stock. Affected products can retain a qualified status, lose an immediate-availability promise or enter review, with the last successful update visible to the person resolving the issue.
What product data do we need before starting?
Bring a sample supplier file, product and variant identifiers, location codes, reservation rules and several real problem orders with customer details removed. Pack sizes and supplier aliases matter as much as SKU names. Unresolved mappings should be reviewed before they can change saleable quantities.
How would we test the first stock workflow?
Start with a bounded product group and compare proposed availability against current records before publishing changes. Test a last-unit sale, stale feed, cancellation and failed update. Measure oversell cancellations, human corrections and unresolved discrepancies, while separating source-data errors from failures in the new workflow.