How It Works · Onboard and Connect

Turn the Approved Operating Design into a Live Client Account, Access Model and Connected Operating Setup

Create the client profile, legal and KYC records where applicable, addresses, users, permissions, categories, custody and commercial choices, service scope, fulfilment ownership, marketplace access and required technology connections before physical inventory begins moving through the operation.

Onboard and Connect is the system-establishment stage after Assess and Configure. It records the approved choices in Seller Central and connected platform components, verifies what must be complete before inbound starts and keeps optional commercial or technology connections separate from the core client account.

Client identity and KYC
Locations, users and permissions
Categories and service choices
Channels and system connections
Convert the approved operating baseline into an active account
Identify + authorise + configure + connect
01
Create the Client Record
Capture business type, profile, entity information, required KYC records, addresses, contacts and account ownership.
02
Set Access and Scope
Add users, roles, locations, categories, inventory scope and the selected storage, managed-service or Commerce OS choices.
03
Connect Commerce and Systems
Configure approved marketplaces, client-owned channels, fulfilment responsibility and external-system connections where required.
04
Review and Activate
Resolve missing mandatory information, confirm approvals and mark the client ready for the next operational stage without prematurely receiving inventory.
Account activation should mean the required operating setup is ready—not that every optional service, marketplace or integration has been enabled.
Core account + selected connections
Onboard according to the approved operating scope

Set Up a Core Seller Central Account, a Connected Operations Account or a Wider Commerce OS Deployment

The onboarding path should reflect what was approved during assessment. A storage client should not be forced through unnecessary marketplace configuration, while a connected commerce client may need users, channels, fulfilment ownership and system connections established before launch.

Swipe through the onboarding models
01

Core Seller Central Onboarding

Create the client record, locations, users, categories, custody choices and required account approvals.

  • Business/profile information
  • Addresses and contacts
  • Categories and custody scope
  • Account access and acceptance
03

Commerce OS and Systems Onboarding

Extend the account into selected Commerce OS modules, client-owned websites and supported external-system connections.

  • Selected Commerce OS modules
  • Client website/domain dependencies
  • Data migration and integrations
  • Implementation and UAT readiness
Four connected onboarding components

Establish Identity, Access, Operating Scope and Required Connections before Inventory Intake

Onboarding should make the approved operating model actionable without mixing legal/entity setup, operational permissions, commercial intent and optional technology connections into one undifferentiated form.

Swipe through the Onboard and Connect components
01

Client Identity and KYC

Create the business/profile record, entity information, required verification records, account contacts and acceptance state.

ProfileEntityKYCAcceptance

View identity and KYC

02

Locations, Users and Access

Add addresses, sites, users, teams, roles, permissions and the operational contacts needed to run the selected model.

AddressesUsersRolesAccess

View locations and access

03

Categories, Services and Commercial Intent

Configure inventory categories, custody/commercial choices, selected services and the fulfilment model approved during assessment.

CategoriesCustodyServicesFulfilment

View operating scope

04

Channels, Systems and Activation

Connect approved marketplaces, client-owned destinations and external systems, then resolve readiness gaps before activation.

ChannelsSystemsReviewActivate

View connections and activation

See the Onboard and Connect stage in action

Follow the Client from Profile Creation through Access, Operating Scope, Connections and Activation

Start with the complete onboarding architecture, then move through business profile, verification, addresses, users, categories, custody and service choices, fulfilment ownership, marketplace and system connections, readiness review and activation.

Slide 1 of 10

Complete Onboard and Connect architecture

02
Business type and client profile The screen shows a fictional onboarding record with business type, profile details, primary contact, accountable representative and completion progress.
Step 1 · Create the client record

Start with the Business Structure and Core Account Identity

The selected business type controls which later identity and entity fields are relevant.

  • Business or individual type
  • Profile/business name
  • Primary accountable contact
  • Account owner and progress state
What this screen demonstrates Use fictional data and never expose real personal contact information.
03
Entity, KYC and acceptance The screen shows fictional entity/verification fields, optional settlement information, review status, acceptance and missing-information controls.
Step 2 · Verify the account

Collect Only the Verification Information Required for the Selected Account

Verification adapts to business type and commercial scope instead of forcing one universal document list.

  • Entity/legal information where applicable
  • Required tax or KYC records
  • Optional bank/settlement details where needed
  • Acceptance and review status
What this screen demonstrates Use fully fictional identifiers and never show real PAN, Aadhaar, GST, bank or identity records.
04
Addresses, sites and contacts The screen shows fictional purpose-based addresses and contacts for registered, pickup, return, warehouse and billing use.
Step 3 · Add operating locations

Store Addresses by Purpose So Later Workflows Can Reuse Them Correctly

Pickup, return, billing and operating locations should not be repeatedly re-entered in later requests.

  • Registered/business address
  • Pickup and return locations
  • Warehouse/studio/client sites
  • Operational contacts by purpose
What this screen demonstrates Use fictional addresses and avoid real facility/security details.
05
Users, teams and access The screen shows fictional users, teams, role permissions, site access, approval scope and restricted sensitive fields.
Step 4 · Authorise users

Give Each User the Access Needed for Their Actual Responsibility

Permissions connect the approved operating model to the live application.

  • Client administrator and supervisors
  • Operational and catalogue users
  • Client/site/workflow permissions
  • Restricted financial and KYC visibility
What this screen demonstrates Use fictional users and do not expose privileged administration or real emails.
06
Categories and custody/commercial intent The screen shows fictional searchable category selection and approved storage, rental, sale, subscription, QC hold or client-WMS choices.
Step 5 · Configure inventory scope

Tell the Platform What Inventory Is Expected and What the Client Wants Done with It

Category and intent choices become inputs to later item-intake and catalogue workflows.

  • Searchable multi-category scope
  • Storage-only option
  • Rental/sale/commercial combinations
  • Other approved custody modes
What this screen demonstrates Commercial activation remains an explicit choice and should not be inferred from storage.
07
Services and fulfilment ownership The screen shows fictional selected managed services and default Vault-managed, client-managed or hybrid fulfilment responsibility.
Step 6 · Configure operating responsibility

Apply the Approved Service and Fulfilment Model to the Client Account

Default client-level responsibility reduces repetitive product setup while allowing approved exceptions.

  • Selected managed services
  • Vault-managed fulfilment
  • Client-managed fulfilment
  • Hybrid and per-item exception rules
What this screen demonstrates Only show services actually selected in the fictional assessment.
08
Marketplace and Commerce OS connections The screen shows fictional optional Vault marketplaces, client-owned website and selected Commerce OS modules with selected, pending and connected states.
Step 7 · Connect approved channels

Enable Only the Destinations and Platform Components Included in the Operating Model

Marketplace participation and Commerce OS deployment remain optional account choices.

  • Vault marketplace selections
  • Client-owned commerce website
  • Selected Commerce OS modules
  • Eligibility, selected and connection state
What this screen demonstrates Do not imply that marketplace access is automatic or mandatory.
09
External systems and readiness The screen shows fictional migration and integration requirements, external system owner, readiness, blocker and optional/required status.
Step 8 · Connect required systems

Separate Opening Data Migration from Ongoing Live-System Connections

Onboarding identifies the required system work and routes it to the correct implementation stream.

  • Legacy data migration
  • Accounting, payment or logistics connections
  • ERP, CRM, identity or BI where applicable
  • Required/optional and readiness owner
What this screen demonstrates Use fictional systems and never expose real API keys, credentials or private endpoints.
10
Readiness review and activation The screen summarises fictional onboarding completion, mandatory blockers, optional pending connections, approvals and account activation readiness.
Step 9 · Review and activate

Activate the Account Only after Required Setup Is Complete

Mandatory blockers and optional pending items remain visibly different so unrelated work is not held up unnecessarily.

  • Profile and verification readiness
  • Locations, users and scope readiness
  • Required blocker resolution
  • Optional pending connection visibility
What this screen demonstrates Account activation hands the client to Receive and Digitise; it does not mean physical inventory is already in custody.
Swipe through the Onboard and Connect walkthrough
01
Create the authoritative client and business record

Business Type, Profile, Entity Information, Required KYC Records, Bank Details Where Needed and Acceptance

The onboarding record should distinguish an individual from other entity types because required fields and verification documents can differ.

Only information required for the applicable service or commercial relationship should be mandatory. Bank details, tax records and other verification fields should follow the approved workflow rather than being collected indiscriminately.

Business/profile identity
Applicable verification records
Explicit acceptance and approval state
Swipe through identity and KYC controls

Business Type and Core Profile

Start with the client structure so later fields can adapt appropriately.

  • Individual or approved organisation type
  • Display/business name
  • Primary contact and communication details
  • Account owner or responsible representative

Entity and Verification Information

Collect the records required for the applicable client and service relationship.

  • Entity/legal details where applicable
  • Tax or registration information where required
  • Identity/KYC records according to onboarding rules
  • Verification and review status

Bank and Settlement Information

Keep financial details optional unless a selected commercial workflow requires them.

  • Bank details only where needed
  • Beneficiary/account ownership context
  • Verification status where applicable
  • Restricted visibility for sensitive information

Acceptance and Account Approval

Finish identity setup with attributable acceptance and review.

  • Terms/policy acceptance
  • Submitted-by and timestamp
  • Review or approval state
  • Missing-information or exception reason
02
Connect the client account to the places and people that will actually operate it

Addresses, Sites, Contacts, Users, Teams, Roles, Permissions and Operational Access

Addresses should be structured by purpose rather than stored as one generic address. Pickup, return, billing, registered office, warehouse and client-site contexts may need different records.

User access should follow the approved responsibility model. Operational users should see only the client, sites, workflows and sensitive information relevant to their role.

Purpose-based locations and contacts
Role and team access
Client/site-level permission boundaries
Swipe through locations, users and access controls

Addresses and Site Records

Store locations according to how they are used operationally.

  • Registered or business address
  • Pickup and return address
  • Warehouse, studio or client-site location
  • Billing or other configured address types

Operational Contacts

Identify the people responsible for movement and service decisions.

  • Primary client contact
  • Pickup/drop or logistics contact
  • Operations or warehouse contact
  • Finance or approval contact where relevant

Users, Teams and Roles

Create application access according to the approved operating model.

  • Client administrator
  • Operational/supervisor roles
  • Catalogue, sales or service users
  • Restricted external access where explicitly required

Permission and Access Review

Validate that users can perform required work without seeing unrelated sensitive data.

  • Client and site access
  • Workflow and approval permissions
  • Sensitive financial/KYC visibility
  • Privileged administration kept limited
03
Record what inventory can enter and what the client wants done with it

Categories, Custody and Commercial Intent, Selected Services, Fulfilment Ownership and Operating Preferences

Onboarding should convert the assessed inventory scope into searchable categories and approved operating choices that can drive later intake, catalogue and fulfilment workflows.

Physical custody, catalogue preparation, rental, sale and fulfilment are separate decisions. A client choosing storage does not automatically opt into catalogue services or marketplace publication.

Searchable category scope
Custody and commercial intent
Service and fulfilment ownership
Swipe through categories, services and intent controls

Inventory Categories

Define the broad operating categories expected for the client.

  • Searchable multi-category selection
  • Fashion, furniture, props, equipment or other enabled categories
  • Category-specific intake requirements later
  • Category scope can be expanded with approval

Custody and Commercial Intent

Record what the client wants the inventory operation to support.

  • Storage only
  • Store and rent
  • Store and sell
  • Store, rent and sell or other approved model

Selected Managed Services

Enable only services explicitly included in the approved operating design.

  • Receiving and inventory operations
  • Catalogue or studio preparation
  • Fulfilment, returns or care
  • Add-on/specialist services where separately selected

Fulfilment Ownership

Set the default ownership model with product-level exceptions where the platform supports them.

  • Vault Managed
  • Vendor/Client Managed
  • Hybrid
  • Per-item override where approved
04
Connect only the commercial and technical destinations included in the approved model

Vault Marketplaces, Client-Owned Channels, Commerce OS Modules, External Systems, Readiness and Activation

Marketplace and technology connections should be configured after the core client and access model exists. Each connection needs an owner, status and readiness state so an incomplete optional integration does not block unrelated storage or operational work.

Data Migration establishes legacy opening data; Integrations maintain ongoing exchange. Onboarding records which connections are required and routes them into the appropriate implementation workstream.

Optional marketplace/channel connections
Commerce OS and external-system scope
Readiness review without premature activation
Swipe through channels, systems and activation controls

Vault Marketplace Access

Enable only destinations the client has explicitly selected.

  • CostumePeti where appropriate
  • Vault.Fashion, Vault.Wedding or Vault.Furniture
  • Vault.Productions or Vault.Luxury where applicable
  • Destination eligibility remains separate from physical custody

Client-Owned Commerce and Commerce OS

Record the client-owned technology components included in the implementation.

  • Client-owned commerce website
  • Selected Commerce OS modules
  • Domain or external-account dependencies
  • Implementation/UAT status where required

External Systems and Data

Route the required connection into migration or integration work.

  • Legacy data migration
  • Accounting, payments, logistics or ERP
  • CRM, messaging, identity or BI where applicable
  • Connection owner and readiness state

Readiness and Activation Gate

Activate the account when mandatory setup is complete and explicitly flag optional items still in progress.

  • Required profile/KYC complete
  • Addresses, users and scope confirmed
  • Mandatory blockers resolved
  • Optional connections can remain pending without false failure
Onboard and Connect workflow

Create, Verify, Authorise, Configure, Connect and Activate

The sequence establishes the operating account without mixing physical inventory intake into client setup.

Swipe through the Onboard and Connect workflow
01

Create the Client Profile

Record business type, profile, entity information and the primary accountable contact.

02

Complete Verification

Collect applicable KYC/tax records, bank information only where needed and attributable acceptance.

03

Add Locations and Access

Create addresses, sites, contacts, users, roles, permissions and approval ownership.

04

Configure Operating Scope

Add categories, custody/commercial intent, selected services and fulfilment ownership.

05

Connect Channels and Systems

Enable approved marketplaces, client-owned channels and route required migration/integration work.

06

Review and Activate

Resolve mandatory blockers, preserve optional pending items and mark the account ready for Receive and Digitise.

Assess and Configure decides the model

Onboard and Connect records those approved decisions in the live account. Material differences discovered during onboarding should be returned to the configuration baseline instead of being silently improvised.

Account activation does not mean inventory has been received

The next operational stage is Receive and Digitise, where physical inbound, identification, item intake and digitisation begin.

Onboarding responsibility

Keep Client-Provided Facts, Platform Configuration and External Verification Responsibilities Explicit

The client supplies and approves its factual business information. Seller Central configures the approved account model, while banks, marketplace providers and external systems control their own verification and connection capabilities where applicable.

Onboarding Area
Client / Seller
Seller Central / Commerce OS
External Provider / Vault Managed Team
Business/profile, entity and factual account information
Provide and approve
Capture and validate required structure
External verification where applicable
KYC, tax and bank information where required
Provide accurate records
Restrict, track and route review
Provider/bank/verification capability where applicable
Addresses, users, contacts and permissions
Provide and approve access requirements
Configure approved account access
Vault users only where managed operations selected
Categories, custody, services and fulfilment ownership
Select and approve
Configure the selected operating scope
Accept assigned managed responsibilities where contracted
Marketplace and external-system connections
Authorise accounts and participation
Configure supported connection scope
Control external platform capability and terms
Final onboarding readiness and activation
Resolve client-provided blockers
Confirm system readiness
Confirm required external readiness where applicable
Swipe through the Onboard and Connect responsibility views
01

Client / Seller

  • Business facts Provide
  • Verification records Provide
  • Access requirements Approve
  • Services/channels Select
02

Seller Central / Commerce OS

  • Account structure Configure
  • Permissions Configure
  • Operating scope Configure
  • Activation gate Control
03

External Provider / Vault Managed Team

  • Verification capability Where applicable
  • Marketplace/system account Provider-controlled
  • Managed operations Only if contracted
  • Connection readiness Confirm where required
Onboarding data groups

Structure the Account around Reusable Operating Records instead of Re-entering the Same Information Later

Information established during onboarding should become reusable master data for later inbound, fulfilment, marketplace and support workflows wherever appropriate.

Swipe through common onboarding data groups
Business ProfileBusiness type, profile, entity information, primary contact, account ownership and acceptance state.
Addresses and SitesRegistered, pickup, return, billing, warehouse, studio and other purpose-based locations.
Verification RecordsApplicable identity, tax, registration and bank information with restricted visibility and review status.
Users and AccessAdministrators, operators, supervisors, catalogue users, commercial users, teams and approved permissions.
Inventory CategoriesSearchable category scope that later drives category-specific attributes, intake requirements and workflows.
Custody and IntentStorage, rental, sale, subscription, QC hold, client WMS or other approved custody/commercial model.
Services and FulfilmentSelected managed services and default Vault/client/hybrid fulfilment responsibility with approved exceptions.
Channels and SystemsVault marketplaces, client-owned commerce, Commerce OS modules and required migration/integration workstreams.
Onboard and Connect FAQs

Common Questions before the Client Account Is Activated

The exact onboarding fields and required verification depend on business type, selected services, commercial channels, account structure and the approved implementation baseline.

Start Client Onboarding

Is onboarding the same as Assess and Configure?

No. Assess and Configure decides the operating design. Onboard and Connect creates the actual account and configures those approved choices in the platform.

Is physical inventory received during this stage?

No. Account onboarding is completed before physical inbound. Receive and Digitise is the next stage where shipment receiving, item identification and digitisation begin.

Does every client need the same KYC or company fields?

No. Required information can differ by business type and selected services. The form should adapt rather than forcing organisation-only fields onto an individual account or vice versa.

Are bank details mandatory?

Not for every onboarding path. Bank information should be collected where the selected commercial or settlement workflow requires it and handled as sensitive information.

Can a client have multiple addresses?

Yes. Registered, pickup, return, billing, warehouse, studio and other operating locations can be stored separately according to their purpose.

Can several users access the same client account?

Yes, according to the configured role and permission model. Administrators, supervisors and operational users can have different access scopes.

Does selecting storage automatically enable marketplaces?

No. Storage, catalogue services, marketplace participation and Commerce OS remain separately selectable according to the approved operating model.

Can fulfilment ownership be set at client level?

Yes. A default Vault-managed, client-managed or hybrid model can be established for the client, with product-level exceptions where the platform and approved workflow support them.

What if an optional marketplace or integration is not ready yet?

An optional connection should remain visibly pending without blocking unrelated account activation. Only dependencies required for the selected launch scope should act as mandatory blockers.

What happens after onboarding is complete?

The next How It Works stage is Receive and Digitise, where the approved client account is used for physical receiving, container/item identification, QR assignment, intake and digitisation workflows.

Create the operating account before inventory starts moving

Establish the Client, Access, Scope and Required Connections Once—Then Reuse Them across the Inventory Lifecycle

Complete the client profile, applicable verification, addresses, users, categories, custody/commercial intent, selected services, fulfilment ownership and approved connections so the next stage can receive inventory against an authoritative account.