CH17-02: Inventory, Fulfillment, and Operational Requirements

Goal

This section turns back-office needs into architecture requirements. It defines the inventory, fulfillment, return, supplier, dashboard, security, and support states that the platform must be able to trust.

The previous section established the mental model: back-office automation connects customer promises to operational work. Now we need to name the operational states that make those promises trustworthy.

The Short Version

Back-office requirements should name the operational state that must be trusted.

For customer-facing systems, a simple status such as available or shipped may be enough to display. For back-office automation, that simplicity is dangerous. The architecture needs to know what kind of availability exists, whether stock has been reserved, where it has been allocated, whether a warehouse task is complete, whether a carrier has accepted the shipment, whether a return has been inspected, and who owns exceptions.

Good requirements make these state differences explicit. They tell the team which states need strong correctness, which states can be near-real-time views, which states need audit evidence, and which failures need human review.

Inventory State Is Not One Thing

A useful inventory model separates at least these states.

Available
	-> Reserved
	-> Allocated
	-> Picked and packed
	-> Shipped
	-> Delivered
	-> Returned, restocked, repaired, or written off

This diagram is simplified, but it shows the important point: each state answers a different business question.

The platform may also track damaged stock, quarantined stock, supplier-owned stock, in-transit transfers, backorders, and safety stock. The chapter does not need to design every variant, but a real architecture must make room for them.

Visibility Versus Correctness

Not every requirement needs the same consistency model.

Near-real-time visibility is useful for product pages, dashboards, support screens, and analytics. These views can often tolerate small delays if they are clearly understood. For example, a dashboard that refreshes every few minutes may still be useful for operations.

Operational correctness is different. Reservation, allocation, refund approval, inventory adjustment, and shipment cancellation may need stronger controls because mistakes can oversell stock, lose money, create duplicate work, or harm customer trust.

This distinction helps prevent two common design errors: forcing every read to behave like a financial transaction, or treating every operational decision like a disposable cache update.

Fulfillment Requirements

Fulfillment requirements connect inventory to physical work.

The architecture should answer:

• Which fulfillment node owns this order or line item?

• Can the order be split across warehouses or sellers?

• What warehouse tasks are required?

• What happens when stock cannot be found during picking?

• Which carrier service should be used?

• How are shipping labels, tracking numbers, delivery events, and delays handled?

• How does customer support see the current operational state?

These questions turn into requirements for workflow state, warehouse integration, carrier integration, support visibility, alerting, and exception handling.

Returns and Replenishment Requirements

Returns are not just the reverse of shipping. A return may require customer authorization, carrier label generation, package receipt, inspection, refund decision, restocking, repair, disposal, fraud review, and seller or finance updates.

Replenishment is also its own workflow. A popular product may need purchase orders, supplier updates, warehouse transfers, demand forecasts, safety stock rules, and approval paths. Some replenishment can be automated. Some should require human approval because it affects cash, supplier commitments, or warehouse capacity.

If a design ignores returns and replenishment, it may look clean during checkout but fail in the real operating cycle.

Example: A Fast-Selling Product

Imagine a game console sells quickly across the web store, mobile app, and seller portal.

Availability tells customers that units appear sellable. Reservation holds units while checkout completes. Allocation chooses which warehouse or seller will fulfill each order. Replenishment decides whether more units should be ordered, transferred, or prioritized. These are related, but they are not the same state.

If the platform treats them as one number, it can overpromise. One storefront may display stale availability while another reserves the last unit. A warehouse may receive more work than it can process. Support agents may see in stock but have no way to explain why an order is delayed. Replenishment may trigger too late because the system cannot distinguish real demand from temporary reservations.

A stronger design names the states, records the transitions, and gives teams dashboards that reveal risk before it becomes a customer complaint.

Operational Visibility Requirements

Different teams need different views.

These views should not be invented after the workflow is already hard to operate. They are part of the architecture requirements.

Common Mistakes

• Promising inventory without a reservation or allocation strategy. This creates customer confidence before the system has protected the stock or fulfillment path.

• Treating near-real-time visibility and operational correctness as the same requirement. They have different costs, failure modes, and design controls.

• Designing dashboards after the workflow is already difficult to operate. Operators need visibility from the first production design.

• Ignoring return and exception flows. Returns, failed picks, stale feeds, and carrier delays are normal operating paths.

• Leaving support agents with customer-visible statuses but no operational explanation.

If Someone Asks You

What requirements matter most for inventory and fulfillment automation?

Start by naming the operational states the business must trust: availability, reservation, allocation, warehouse progress, shipment, delivery, return, replenishment, and exceptions. Then decide which states need strong correctness, which can be near-real-time views, and which need human review, audit evidence, and ownership. Inventory and fulfillment architecture is not just about storing stock counts. It is about making reliable state transitions visible and recoverable.

What You Should Remember

Trustworthy operations require trustworthy state.

Questions to Check Your Understanding

1. How is inventory availability different from allocation?

2. Which flows need human review or exception handling?

3. What operational visibility does customer support need?