Start by choosing who controls the operation, define the workflow, onboard the client, receive and digitise inventory, store it with accountable location control, operate requests and fulfilment, then publish approved inventory to selected commerce destinations.
The seven stages below are deliberately separate. Each answers a different operational question and links to a detailed Level 2 guide, while the same inventory identity, ownership, location, history and approval context continue through the whole lifecycle.
Seller Central can support a new operating design, an existing warehouse/catalogue environment or a narrower starting problem. The first step is to decide the real scope instead of forcing every client through the same implementation.
Start with Operating Models and Assess and Configure before committing inventory, sites, users or technology.
Assess the current physical and digital state, then decide whether the first workstream is onboarding, migration, receiving, identification or storage control.
Start with the urgent operational stage while preserving a path into the wider lifecycle later.
Each stage has its own Level 2 page. Use the sequence as the default journey, but the actual depth and responsible operator depend on the selected operating model.
Choose Vault-managed, client-managed or hybrid responsibility for storage, services, fulfilment and software.
Define the inventory, facilities, responsibilities, workflows, services, systems, commercial routes and implementation baseline.
Create the client account, verification, addresses, users, categories, commercial intent, selected services and required connections.
Verify physical arrival, establish permanent custody identity and capture the required images, measurements, attributes and exceptions.
Allocate physical locations, control movement, client areas, capacity, counts, holds and reconciliation.
Reserve, pick, verify, pack, dispatch, deliver, receive returns, inspect, restore and complete the applicable lifecycle.
Approve destination eligibility, prepare channel-specific listing data, publish deliberately, synchronise supported state and expand.
Start with the consolidated journey infographic, then move through the seven completed How It Works stages plus cross-cutting exception and reporting views.
The first two stages answer different questions. Operating Models decides who controls the work. Assess and Configure translates that decision into sites, inventory scope, workflows, services, systems, approvals and implementation priorities.
This separation prevents a technology choice from silently becoming a managed-service commitment—or a storage decision from automatically enabling catalogue, fulfilment or commerce.
Choose who physically and digitally controls the inventory operation.
Understand the physical and digital environment before designing the future state.
Define how the chosen model should operate.
Approve the operating baseline before the client account and inventory flow are activated.
The account is built after the operating model is known. Business type, applicable verification, addresses, users, categories, custody/commercial intent, selected services, fulfilment ownership and required technology connections become reusable operating data.
Optional marketplace or integration work should remain visibly optional instead of blocking unrelated storage or inventory operations.
Create the business/profile record and applicable verification state.
Give each participant access according to actual responsibility.
Configure what inventory and services the account will use.
Activate the required account foundation before physical inventory intake begins.
Receiving answers what physically arrived and creates the custody/digital record required by the selected workflow. Storage then answers where the item lives, who controls it, how it moves and whether the physical location record still matches reality.
Digitised does not automatically mean published, and physically stored does not automatically mean commercially available.
Match physical handover to the expected inbound.
Create the permanent physical identity and required digital record.
Put inventory into the appropriate physical location and preserve every movement.
Keep the digital location aligned with physical reality over time.
Fulfilment translates approved demand into reservation, picking, packing, dispatch, return and restoration. Publishing translates approved inventory and catalogue data into destination-specific listings, availability and commercial reach.
The two remain connected through inventory truth, but neither should silently overwrite physical custody, holds, condition or owner intent.
Execute approved outbound and return work against the exact inventory.
Keep returnable inventory active until reconciliation and restoration are actually complete.
Prepare destination-specific commercial data without replacing canonical inventory truth.
Synchronise supported state, resolve channel exceptions and expand in controlled waves.
Once commercial and operational activity begins, fulfilment, returns, storage, catalogue and availability continue to update the same inventory record. Scale should reuse the operating controls rather than bypass them.
Set the operating model before deciding who should perform daily physical or digital work.
Assess inventory, sites and systems; configure the future state and implementation baseline.
Onboard identity, users, locations, categories, services and selected connections.
Receive, identify, photograph, measure, classify and preserve exceptions.
Put away, move, count, hold and reconcile the physical inventory state.
Reserve, pick, pack, dispatch, return, inspect and restore against approved demand.
Publish eligible inventory, monitor supported synchronisation and expand while keeping the canonical record authoritative.
Shortages, damage, holds, failed scans, failed publication, stale sync and return discrepancies should create visible work rather than being hidden inside a “completed” state.
Activity, operational, commercial and financial reports should derive from the underlying accountable states instead of reconstructing them after the fact.
The operating model controls who performs the physical work. Seller Central should preserve the responsibility, approval and history regardless of which party executes the action.
The value of the journey is not just the sequence of screens. It is that the same inventory can retain identity, ownership, location, operational history, commercial state and exceptions as responsibility changes over time.
The journey is a framework, not a requirement that every client must use every service, marketplace or Commerce OS module.
No. The seven stages describe the complete operating lifecycle. A storage-only client, a client-operated warehouse or a Commerce OS deployment can use different depths and responsibilities.
Operating Models decides who controls the work. Assess and Configure then turns that decision into the actual inventory, site, workflow, service, system and approval design.
No. Storage can remain storage-only. Catalogue preparation, managed services, commerce and marketplaces are separate choices.
Yes, where the selected software model supports it. Client-operated storage and fulfilment remain distinct from Vault-managed physical services.
No. Digitisation establishes the required identity/data record. Commercial eligibility, publication and availability remain later controlled decisions.
No. Stored is a physical location/custody state. Availability can still depend on condition, owner intent, reservations, holds and destination publication.
Not necessarily. Delivery or collection is a later state, and returnable inventory continues through Return Pending, Return Received/QC and restoration.
No. Connection, destination eligibility, draft preparation, review approval, live publication and availability are separate states.
They are implementation capabilities inside Commerce OS. Data Migration establishes the opening platform state; Integrations maintain ongoing system-to-system exchange after go-live.
The lifecycle continues. New demand flows into fulfilment, returns change condition and availability, storage changes location state, and channel/catalogue information can be updated and expanded over time.
Seller Central can connect client-managed, Vault-managed and hybrid operations through one inventory record while keeping storage, managed services, Commerce OS and marketplace participation separately selectable.
Login