Build pattern: controlled supplier fulfilment in WooCommerce

The operational problem

Supplier fulfilment often begins with spreadsheets and email. That can work at low volume, but repeated copying creates duplicate-send risk, unclear ownership and inconsistent tracking return. The product decision starts by mapping the current workflow rather than immediately replacing it.

The control model

Order lines are routed by an explicit supplier mapping, held in an approval queue and released in an immutable batch. The batch records which lines were included, who approved it and where it was sent. Completed orders do not remain in active work, and a line cannot silently enter two supplier batches.

Data minimisation

Each supplier receives only the customer and order fields required to fulfil its assigned items. Access, exports and logs follow the same separation. Tracking intake validates duplicates and updates the appropriate order only after the required line-level evidence is present.

Productisation test

The reusable value is the workflow contract: routing, approval, idempotent release, exception ownership, tracking reconciliation and audit history. Store-specific supplier rules remain configuration. This separation allows a proven internal capability to mature into an enterprise module without copying an entire customer system.

Operational acceptance criteria

A controlled supplier workflow should prove that an eligible line enters exactly one queue, approval is attributable, release is idempotent, the supplier receives only required data and returned tracking updates the correct order. Exceptions need an owner and ageing view. A batch that sends successfully but cannot be reconciled is not complete.

The rollout should begin with representative suppliers and a fallback path, then expand after real operational review. Migration must preserve open work and prevent completed orders from reappearing. These controls matter more than decorative dashboard metrics.