Omnichannel Operations & Fulfillment — Ongoing Independent Study

Investigating how e-commerce operators manage fulfillment, replenishment, system discrepancies, and human intervention across automated order management, ERP, and warehouse workflows.

Scope

Enterprise retail & FMCG operations

Role

Independent UX Researcher

Status

Ongoing · 2 practitioner interviews completed

Human intervention in automated omnichannel operations: connected commerce, order management, ERP, and fulfillment systems, with operator oversight across exceptions.
An ongoing study of fulfillment, replenishment, and operational control across enterprise e-commerce systems.

Why study operations that are already automated?

Routine e-commerce operations are increasingly automated, but operational teams still intervene when orders, inventory, fulfillment, or system states deviate from the expected flow.

This study begins with that remaining human work: understanding what operators do, why it matters, and whether the underlying friction can be addressed through design.

The question guiding the research

Where does meaningful human effort remain in already-automated omnichannel operations, and which of those frictions are actually designable?

The aim is to understand the work before selecting a product direction. An interface change is one possible response; some issues may instead depend on capacity, coordination, or business rules.

Who I’m learning from

Two practitioner interviews currently anchor the study: an e-commerce fulfillment operator in a large multi-brand retailer, and an e-commerce operations practitioner in a global fast-moving consumer goods (FMCG) environment. Company and participant names are withheld.

~18 brands

A multi-brand retail fulfillment environment described in the interviews.

3+ marketplaces

Major marketplace channels represented in the operational context.

OMS / SAP

Order management, ERP, and fulfillment-partner environments.

These figures describe the environments discussed, not the size of the research sample. Further interviews are in progress.

The system landscape behind an order

The conversations span marketplace and direct-to-consumer (D2C) channels, order management systems (OMS), SAP as an enterprise resource planning (ERP) system, and the teams or partners responsible for fulfillment.

  1. Marketplace / D2C
  2. OMS
  3. SAP
  4. Warehouse / Store / Fulfillment Partner
  5. Customer

Supporting tools: Excel · Power BI · internal tools

Exact architectures vary by company. This is a simplified landscape, with two-way exchanges shown between OMS, SAP, and fulfillment systems.

Two workflows currently in focus

The interviews describe different operating contexts. Keeping the workflows separate helps identify where human effort appears without assuming both organizations share the same process.

Workflow A · Multi-brand retail

Store-based fulfillment

  1. Order received
  2. OMS
  3. Store fulfillment app
  4. Assigned store
  5. Store fulfills or rejects the order

When fulfilled, the order continues toward the customer. Rejection can trigger rerouting to another store.

Exception path: rejection → reroute → unresolved or failed order → operator intervention.

Workflow B · Global FMCG

E-commerce operations

  1. Demand / replenishment
  2. Inventory allocation
  3. Fulfillment partner
  4. Order processing
  5. SLA monitoring

Operators monitor fulfillment performance while the partner processes orders.

Exception path: cancellation or SLA risk → operator follow-up with the fulfillment partner.

These are simplified workflow summaries from the interviews, not complete process maps. Exception paths are conditional.

What I’ve learned so far

Four early observations are shaping the next round of research. They are working interpretations of two interviews and still need to be tested across more participants.

Automation handles most happy paths well.

Both participants described substantial automation across routine fulfillment and monitoring. The starting point is understanding where that automation already works and what still requires a person.

Human work concentrates around uncertainty and intervention.

Operators step in when fulfillment risks a service-level agreement (SLA) breach, system states disagree, or a decision depends on business context that the automated flow does not capture.

Accountability can sit apart from execution.

Central e-commerce operations may own performance targets while stores or external fulfillment partners execute the work. Following up on an exception can therefore involve coordinating across teams.

Not every manual step is a UX problem.

Some human judgment is intentional, especially in replenishment and exception decisions. The research needs to distinguish useful oversight from avoidable effort before proposing changes.

Emerging opportunities to investigate

These questions are candidate areas for further research. They do not yet represent validated needs, selected features, or a committed solution.

A. Fulfillment intervention

How might operators identify which orders need intervention before SLA or cancellation risk materializes?

B. Human assurance

How might systems help operators verify uncertain cross-system states without repetitive spreadsheet checking?

C. Decision support

How might replenishment tools combine system recommendations with business context while reducing human-input errors?

What I’m not concluding yet

  • Two interviews are not enough to generalize across omnichannel operations.
  • Reconciliation work may reflect company-specific integrations or practices.
  • Warehouse coordination may primarily be an operational-capacity problem rather than an interface problem.
  • A final product direction has not yet been selected.

The study has not reached prototyping or usability evaluation. No operational improvements or business outcomes are claimed at this stage.

Next steps: from early observations to a testable direction

  1. Interview 3–5 additional practitioners to test and extend the early observations.
  2. Synthesize across participants, separating recurring patterns from company-specific conditions.
  3. Prioritize by frequency × effort × business impact × designability.
  4. Benchmark existing tools against the prioritized needs.
  5. Define a target workflow and the operator decisions it needs to support.
  6. Prototype the selected direction.
  7. Evaluate usability with practitioners using realistic operational scenarios.
The next decision is which workflow is worth designing for, based on recurring operator effort and the extent to which design can meaningfully help.

Continue exploring

More projects across research, commerce, systems, and spatial experiences.