Retail & eCommerce
Connect customer demand,
product, inventory,
fulfilment and contribution.
DemandFulfilment
For retail and ecommerce businesses where product, price, availability, fulfilment, returns and channel economics decide whether the customer promise is kept. We connect those processes through Microsoft business applications, data and integration, alongside the commerce, POS and specialist systems the organisation has chosen to retain.
Retail performance depends on connecting customer demand to product, stock, fulfilment and commercial contribution.
In short
What retail leadership is actually trying to control.
Before capability, the question is which outcomes need to move. These are outcome areas to baseline, not benchmark promises.
Product confidence
Is the right product information available to each channel the business actually operates?
Price confidence
Is the correct price and promotion being applied, in the right channel, on the right date?
Availability confidence
Can the business genuinely fulfil what the customer sees before they commit?
Fulfilment
Can the order be sourced, picked, packed and delivered as promised?
Return control
Can returns, refunds and the stock consequence be controlled together rather than separately?
Customer service
Can service answer from connected order context rather than from investigation?
Stock
Is working capital invested in the inventory the demand actually needs?
Channel economics
Does demand translate into an acceptable commercial contribution once channel costs are counted?
Peak readiness
Can the whole transaction chain operate under the peak conditions the business expects?
Who this page serves
Retail operating models differ. The capability required differs with them.
Not every retailer needs full omnichannel architecture. The first question is which model applies, because it decides which parts of this page matter.
Ecommerce or D2C
Demand arrives through owned digital channels and is fulfilled from a central warehouse or a fulfilment partner.
Focus: Product content, availability accuracy, order orchestration, carrier performance and returns.
Omnichannel retailer
Digital and physical channels share product, stock, customer and financial consequences.
Focus: Channel governance, availability by location, fulfilment sourcing and consistent financial treatment.
Store-led retailer
Most transactions happen in store, with digital channels supporting rather than leading.
Focus: Store inventory, replenishment, transfers, returns to store and the POS boundary.
Marketplace-led seller
A material share of demand arrives through third-party marketplaces with their own rules.
Focus: Listing, availability, order intake, fees, settlement and reconciliation.
B2B commerce
Accounts, agreements, credit and negotiated pricing sit behind a digital ordering experience.
Focus: Account pricing, credit, order approval, part shipment and account service.
Mixed wholesale and retail
The same inventory serves trade customers and consumers with different commercial rules.
Focus: Shared stock and fulfilment with separated pricing, credit, service and margin views.
Other
Retail models vary. Subscription, rental, concession, franchise and hybrid models each change the operating question.
Focus: Qualified individually rather than assumed to fit an existing pattern.
Not sure
Where the model is genuinely mixed or changing, orientation is the useful first step.
Focus: A short assessment is more honest than a proposal.
What we do not claim
- We do not build ecommerce storefronts
- We do not publish POS implementation experience
- We do not claim payment or PCI compliance
- We do not claim tax compliance on your behalf
- We do not claim named marketplace connectors
- We do not publish retail benchmarks
- We do not claim verified Retail & eCommerce customer outcomes
- We do not promise an implementation duration
Where a requirement sits outside what we can evidence, we say so and qualify it rather than absorbing it into a proposal.
Stores and POS
The store transaction and the commercial backbone are different questions.
Microsoft ERP can control the commercial and inventory backbone while a specialist POS or commerce platform continues to manage the store transaction where appropriate.
Store inventory
Stock by store, transfers, counts and the availability the store can genuinely commit.
Replenishment
Store replenishment triggered from demand, policy and warehouse or supplier supply.
Store transfer
Movement between stores and warehouses with the financial and inventory consequence recorded.
Returns to store
A return received in one channel against an order placed in another, with a controlled refund position.
Click and collect
Reservation, picking, collection and the point at which stock and revenue are treated as committed.
Customer order lookup
Store colleagues seeing the order, delivery and return position without a separate investigation.
Ship from store
Where store stock is a deliberate fulfilment source rather than an emergency workaround.
POS transaction
Scanning, tender, payment and receipt at the till, usually handled by a specialist POS or commerce platform.
We do not publish specialist POS implementation experience. Where the store transaction itself is in scope, we would qualify it openly and, if needed, position a specialist system rather than imply delivery capability we have not evidenced.
Commerce platform position
The website is only the front end of the customer promise.
We do not build ecommerce storefronts. We work alongside the commerce platform the business already uses, or integrate with a platform delivered by a specialist partner.
Dynamics 365 Commerce
Our position on Dynamics 365 Commerce is a commercial decision that has not been confirmed. It could be implemented by InteliSense, integrated by InteliSense, delivered with a specialist partner, or deliberately outside the current proposition. We will not state a position without approved evidence, so this page qualifies commerce as a boundary rather than a capability.
A fast website does not fix a disconnected operating model, and a connected operating model does not require us to own the storefront.
The retail reality
The customer sees one transaction. The business coordinates many decisions behind it.
Product, price, promotion, availability, channel, customer, payment, warehouse, carrier, delivery, return, service, finance and contribution all depend on each other.
One transaction rests on many decisions
Product, price, promotion, availability, channel, payment, warehouse, carrier and finance all have to agree at the moment of purchase.
Availability is a promise, not a number
What the customer sees has to reflect what the business is actually prepared to commit today.
Fulfilment materially influences whether the customer promise is kept
Sourcing, allocation, picking, packing, carrier choice and delivery all shape whether the promise holds.
Returns are an operating process
Return, inspection, disposition, refund and reconciliation carry real cost and real inventory consequences.
Service needs context, not screenshots
Customer service answers properly from a connected view of order, delivery, payment status, return and relevant product information.
Revenue and cost belong in the same conversation
Revenue growth needs to be understood alongside the costs the organisation considers relevant to product and channel performance.
When those processes are disconnected
- Availability becomes unreliable
- Overselling occurs
- Customer service lacks context
- Returns become expensive to manage
- Stock becomes harder to place
- Settlement needs manual reconciliation
- Reporting needs reconciliation
- Channel contribution is hard to see
Retail is not only a sales problem. It is a fulfilment and margin problem too.
Growing order volume creates value only when the business can source the product, hold the right stock, fulfil efficiently, deliver reliably, manage returns and understand what each channel contributes.
One connected commerce flow
Connect customer demand to operational fulfilment.
Twelve stages, resting on four information layers. Retailers may coordinate these stages across several teams, channels and systems.
- Customer
- Inventory
- Product data
- Commercial contribution
Discover
The customer finds the product through a channel the business actually operates.
Product
SKU, variant, attributes, content and status describing what is genuinely being sold.
Price
Base price, channel or customer context, promotion and the rules that decide what is charged.
Order
The commitment captured once, with customer, payment status, delivery expectation and channel.
Availability
What the business is prepared to promise, based on stock, location, inbound supply and lead time.
Source and allocate
Which location and which stock should serve the order, in what priority.
Pick
Work released to the fulfilment location in an order that reflects cut-offs and service commitments.
Pack
Packing, documentation, labelling and consolidation before the parcel leaves.
Ship
Carrier selection, despatch, tracking and the information the customer receives.
Deliver
The promise met or missed, with the exception visible before the customer complains.
Return and service
Return, inspection, disposition, refund, replacement and the service conversation around it.
Finance and insight
Revenue, cost, fees, returns, carriage and contribution by product, channel and customer.
Product, range and content
Product information becomes customer-facing operational infrastructure.
Product record, range and assortment, the PIM boundary and content operations. These decide how much of the operation is spent correcting information.
- Product, variant, category, attributes, images and content describing what is sold
- Supplier, cost, lifecycle status, season, operational dimensions and weight
- Who owns the product record, and where is it edited first?
- Bad product data affects both customer experience and operations.
Pricing and promotions
Price is a chain of decisions, not a single field.
There is no one universal pricing engine. The question is where each decision is made, who is authorised to make it, and how it reaches the channels that need it.
Base price
The starting commercial position for the product, held where price authority sits.
Channel or customer context
Channel, account, contract or segment differences the business genuinely intends.
Promotion
Campaign, offer, multi-buy or markdown, with its own authority and approval.
Discount or agreement
Negotiated account terms, trade agreements and any approved manual override.
Effective date
When the price or promotion starts and ends, across every channel that consumes it.
Order price
The price actually charged and recorded against the order line.
Margin context
Cost, fees and allocations the organisation considers relevant to that sale.
What qualification should establish
- Who holds price authority, and which system is authoritative?
- Who holds promotion authority, and who approves it?
- How are effective dates managed across channels?
- How are customer and account prices handled alongside consumer pricing?
- Which price differences between channels are deliberate?
- What happens when two rules conflict?
- How is price distributed to the commerce platform and marketplaces?
- What does the pricing decision do to financial reporting?
Channel governance
Each channel needs a position, not an assumption.
The objective is not to force every channel to behave identically. It is to preserve a controlled order and financial position while allowing justified channel differences.
Decide for every channel
- Product
- Price
- Promotion
- Customer
- Availability
- Payment
- Fulfilment
- Return
- Fees
- Data authority
Ecommerce website
Owned digital demand, usually the channel with the most visible availability promise.
Marketplace
Third-party rules for listing, price, availability, fulfilment, fees and settlement.
Store
Physical transactions, store stock, collection and returns received in person.
B2B portal
Account pricing, credit, approval and repeat ordering behaviour.
Telesales
Assisted ordering where the operator applies the same commercial rules.
Sales team
Negotiated orders where agreement and approval matter more than browsing.
Partner channel
Reseller, concession or franchise arrangements with their own commercial treatment.
Availability
Availability is a promise, not a number.
Inventory quantity and customer promise are related, but they are not necessarily the same number. The availability rule is a commercial decision the retailer owns.
Potential inputs to the promise
- Physical stock
- Reservations
- Allocations
- Held or unavailable stock
- Inbound supply
- Lead time
- Fulfilment location
- Safety buffer
- Channel
- Cut-off
- Service commitment
- Store reservation where applicable
Overselling is usually a rule problem before it is an integration problem. The business decides what it is prepared to promise, and the platform then has to publish that decision to each channel at a frequency the operation can support.
Order orchestration
The order should enter a controlled operating process while preserving the commercial and fulfilment rules of the channel it came from.
The question is not where an order can technically be stored. It is which system should make each fulfilment decision.
ERP-led order processing
The ERP receives the order and makes the availability, allocation and fulfilment decisions.
Consider: Suits contained fulfilment networks where sourcing rules are simple and stable.
Commerce-led orchestration
The commerce platform holds the customer journey and orchestrates part of the fulfilment decision.
Consider: Requires a clear position on which system is authoritative for the financial and inventory consequence.
Specialist OMS
A dedicated order management system decides sourcing across many fulfilment nodes.
Consider: Justified where node count, sourcing rules and split logic genuinely exceed what ERP or commerce should carry.
Exception states need owners
- No stock
- Back order
- Part shipment
- Split shipment
- Failed payment
- Order creation failure
- Cancellation
- Carrier delay
- Return in progress
Each exception needs an owner, a route and a defined financial consequence rather than a colour on a dashboard.
Fulfilment
Where the order should be sourced from.
Fulfilment materially influences whether the customer promise is kept. Not every retailer requires every source or every collection method.
Potential fulfilment sources
Central warehouse
The default fulfilment source for most ecommerce and wholesale demand.
Regional warehouse
Where service commitments or geography justify more than one node.
Store
Where store stock is a deliberate fulfilment source with its own picking and packing process.
Supplier or drop ship
Where the supplier ships directly and the retailer still owns the customer promise.
3PL
Where a logistics provider executes fulfilment against the retailer's commitments.
Potential customer methods
- Home delivery
- Click and collect
- Store collection
- Split fulfilment
Each combination of source and method changes availability, picking, packing, carrier selection, return handling and the point at which revenue and stock are treated as committed. Adding a method is an operating decision before it is a configuration.
Warehouse and 3PL
Where ERP warehouse capability ends and a specialist system begins.
Where the warehouse requirement exceeds the selected platform's fit, the architecture should change rather than the ERP being stretched. Equally, do not duplicate WMS capability unnecessarily.
Dynamics warehouse capability
Native inventory and warehouse capability in Business Central or Finance and Supply Chain Management.
Consider: Suits operations where the warehouse requirement sits within the selected platform's fit.
Specialist WMS
A dedicated warehouse system for directed work, automation and high throughput.
Consider: Chosen where the warehouse requirement exceeds the ERP fit rather than because volume exists.
3PL platform
The logistics provider's own system executes fulfilment against agreed interfaces.
Consider: Requires clear reconciliation of inventory, shipments and exceptions back to the retailer's record.
What the interface usually has to carry
- Order
- Allocation
- Pick status
- Shipment
- Inventory
- Exception
- Reconciliation
Payment architecture
Hold what controls the order, not what belongs to the payment provider.
The business application should hold the information required to control the order and reconcile the financial event without unnecessarily becoming the payment-card system.
Payment service may own
- Authorisation
- Payment method handling
- Tokenised credentials
- Sensitive payment processing
- Fraud screening where contracted
Commerce or ERP may need
- Payment status
- Amount
- Payment reference
- Settlement
- Refund
- Reconciliation to the ledger
We make no PCI or payment-compliance claims. Payment scope, certification and fraud policy remain with the retailer and its payment providers.
Marketplaces
A marketplace order is a commercial arrangement, not just an interface.
Where marketplaces matter, each dimension needs a defined position before integration is designed. We do not claim marketplace settlement automation or named connectors we have not verified.
- Listing
- Product
- Price
- Availability
- Order
- Fulfilment
- Return
- Commission
- Marketplace fee
- Fulfilment fee
- Promotion contribution
- Settlement
- Reconciliation
Commission, fulfilment fees and promotion contribution decide what the channel actually returns. Settlement and reconciliation decide whether the finance team can prove it. Each marketplace is qualified individually.
Returns and reverse logistics
Returns are an operating process.
Return patterns can expose issues in product information, supplier quality, fulfilment or customer expectations as well as reverse logistics.
Return request
The customer asks to return, through the channel that took the order or another agreed route.
Authorisation
The return is approved against the retailer's own policy, window and conditions.
Receipt
The goods arrive at a warehouse, store or supplier location and are recorded.
Inspection
Condition, completeness and reason are established before any inventory decision.
Disposition
Restock, repair, refurbish, supplier return, write-off or another approved route.
Inventory status
The stock position reflects the disposition rather than assuming the item is sellable.
Refund or replacement
The financial or replacement outcome the retailer has agreed with the customer.
Financial reconciliation
Refund, fee, settlement and ledger positions agree with each other.
Reason analysis
Return reasons connected back to product, content, supplier, fulfilment and channel.
Possible dispositions
- Restock
- Repair
- Refurbish
- Supplier return
- Write-off
- Other approved route
Returned inventory is not assumed to be sellable. The disposition decides the stock status, the cost and the recovery.
Return state
- Requested
- Authorised
- Received
- Inspected
- Disposed
- Closed
Financial state
- No refund
- Pending
- Partial
- Refunded
- Credit
- Replacement
Operational and financial states are tracked separately, using the retailer's own terminology, because a received return and a completed refund are different commitments to different people.
Customer service
Service needs context, not screenshots.
Customer service becomes harder when order, delivery, payment and return context is fragmented. What service needs is a connected service view of order, delivery, payment status, return and relevant product information.
Context may be needed from
- Commerce
- ERP
- WMS
- Carrier
- Payment
- CRM
Connected does not mean duplicated. There is rarely a good reason to copy every transaction into CRM when the service view can read the record that owns it.
Explore CRMCustomer identity
The goal is a trusted customer identity across the processes that need it, not uncontrolled replication of customer data.
Ecommerce identity, CRM relationship, ERP account, loyalty, marketplace reference and service record can all hold a version of the same customer.
Identity
Which systems hold a customer identity, and what each one is actually for.
Authority
Which system is authoritative for the customer record the business acts on.
Matching
How the same person or account is recognised across channels and marketplaces.
Preference
Contact preference, consent and suppression held where they are honoured.
Relationship
Account structure, hierarchy, credit and entitlement where B2B applies.
Transaction context
The order, delivery, payment and return context each process genuinely needs.
Personalisation governance
- Purpose
- Source
- Customer preference
- Permission
- Segmentation
- Channel
- Suppression
- Retention
- Correction
Transaction history cannot be assumed available for every marketing purpose. Purpose, permission and suppression are business decisions, and we make no legal or privacy claims on the retailer's behalf.
Channel economics
Revenue growth needs to be understood alongside the costs the organisation considers relevant to product and channel performance.
The organisation should define which costs belong in each management view before the dashboard calculates the answer.
Management views the retailer defines
Gross margin
Revenue less the cost of goods, defined consistently across products and channels.
Contribution
Gross margin less the directly attributable costs the organisation chooses to include.
Channel contribution
Contribution after channel-specific costs such as commission, payment fees and promotion.
Fulfilment contribution
Contribution after the picking, packing, packaging, carriage and return cost of serving the order.
Other management view
Any additional view leadership uses, defined before the reporting is built.
Potential cost drivers
- Cost of goods
- Discount
- Promotion
- Marketplace commission
- Payment fee
- Pick and pack
- Packaging
- Carrier
- Return
- Refund
- Service effort
- Other approved allocations
Not every cost has to be allocated to an individual order. Some belong at channel or period level, and forcing precision where the data cannot support it creates a number nobody trusts.
Peak and resilience
Peak readiness depends on the whole transaction chain, not only application performance.
Peak conditions can expose capacity and integration weaknesses that are less visible under normal load.
Critical journey
The customer and operational journeys that must keep working, in priority order.
Dependency
Commerce, marketplace, payment provider, ERP, WMS, carrier, CRM and integration layer.
Expected load
The peak volume and pattern the business genuinely expects, not an average.
Failure mode
What each dependency does when it degrades rather than fails cleanly.
Fallback
The agreed manual or degraded process, and who is authorised to invoke it.
Recovery
How the queue, backlog or interface is brought back under control.
Reconciliation
How order, stock, payment and financial positions are proven correct afterwards.
Scenarios worth rehearsing
- Inventory feed failure
- Payment succeeds but order creation fails
- WMS interface failure
- Carrier API outage
- Marketplace lag
- Duplicated message
- Order queue building
- Reporting delay
We do not publish uptime, throughput or recovery figures. What can be agreed in advance is which journeys matter most, what the fallback is, who invokes it and how the position is reconciled afterwards.
Platform fit
Choose the platform for the operating model.
Both platforms can support retail. These are InteliSense qualification patterns, not retailer-size thresholds.
Business Central may fit when the combined requirement across
- Entity, location and channel requirements remain within a contained structure
- Product, range and pricing rules are manageable without specialist merchandising capability
- Order volume, order complexity and fulfilment rules are supportable in the platform
- Inventory, replenishment and warehouse requirements sit within the platform's fit
- Returns, B2B accounts and credit requirements are conventional
- Integrations to commerce, marketplace, payment and carrier are defined and bounded
- Finance and reporting requirements are met without heavy extension
- Peak load can be supported by the combined architecture
Dynamics 365 Finance and Supply Chain Management may fit when
- Enterprise finance, multiple legal entities and intercompany requirements
- Multiple sites, deeper multi-location inventory and enterprise replenishment
- Advanced warehouse management and supply planning requirements
- More complex fulfilment sourcing across a larger network
- Enterprise security, segregation of duties and governance requirements
- Broader enterprise integration across a wider application estate
Platform fit follows the combined operating requirement, not a single order-volume threshold.
Connected platform
Different processes need different systems. The operating model should connect them.
Each part of the trading chain should have an owner. The advantage is not owning more products, but connecting the right capability around the operating model, alongside the Microsoft services and specialist platforms the organisation has chosen to retain.
ERP
Product identity, inventory, cost, purchasing, fulfilment, finance and the transaction record.
Consider: Should not be forced into product content, storefront behaviour or specialist warehouse execution.
Commerce platform
Customer experience, catalogue presentation, digital merchandising and checkout.
Consider: Consumes product, price and availability rather than becoming the authoritative source for all of them.
POS
The store transaction, tender and receipt where a specialist system is in place.
Consider: InteliSense does not publish POS implementation experience. The commercial position is a decision to confirm.
PIM
Product content, taxonomy, digital assets and channel-specific enrichment.
Consider: Justified where content genuinely requires it rather than added by default.
OMS
Sourcing and orchestration across multiple fulfilment nodes.
Consider: Justified where the sourcing decision exceeds what ERP or commerce should carry.
WMS or 3PL
Directed warehouse execution, automation or outsourced fulfilment.
Consider: Integrated deliberately rather than duplicated inside ERP.
Payment service
Authorisation, payment methods and sensitive payment processing.
Consider: The business application holds status and reference rather than card data.
Marketplace
Third-party demand with its own listing, fee and settlement rules.
Consider: Each marketplace is qualified individually rather than assumed.
Power Platform
Fulfilment exceptions, return workflow, supplier interaction, approvals, operational forms and focused merchandising or warehouse workflows. Low code should simplify operations rather than rebuild mature commerce, OMS or WMS functionality.
Explore Power PlatformPower BI and Fabric
Sales, demand, availability, fulfilment performance, returns, carriage, fees and contribution by product, channel and customer, reported from the operating record.
Explore Power BI & FabricIntegration
Commerce platform, marketplace, payment provider, carrier, PIM, WMS and ERP joined deliberately, moving only what each system genuinely needs.
Explore IntegrationCommercial routes
The right route depends on how much is still undecided.
Assessment, Transform, standard implementation, RAPID qualification, Recover, Optimise, Support and Partner Transition are different answers to different starting points. Data & AI is a capability rather than a commercial route.
Standard implementation
Where the target operating model and platform are sufficiently understood and conventional governed implementation is appropriate.
Explore ImplementationRAPID qualification
Only where the scope is bounded and meets the approved strict-fit requirements.
Explore RAPIDPartner Transition
Where the platform remains but partner responsibility changes.
Explore Partner Transition
RAPID, strictly qualified
- 01Operating model fit
- 02Platform fit
- 03Delivery fit
A contained ERP or CRM scope may qualify for RAPID. Complex commerce, marketplace, payment, WMS or omnichannel integration can materially affect RAPID suitability. We do not promise an implementation duration.
Explore RAPIDSupport, Customer Success and Optimise
Support keeps agreed supported capability operating under the contracted service. Customer Success reviews priorities, evidence and future investment. Optimise executes justified improvement. Recovery is used where control or confidence has materially deteriorated. They are separate services with different commercial shapes.
Explore Customer SuccessConfidence gates
Four points where retail confidence is re-confirmed.
A gate is a decision point rather than a milestone to pass. Each one can confirm the plan, pause it, or reduce scope, and each is evidenced rather than asserted.
Gate 1
Before commitment
Retail operating model confidence
Before scope is committed, the operating model behind the transaction should be understood well enough to price and plan responsibly.
Confirmed at this gate
- Retail archetype
- B2B, B2C or both
- Channels in scope
- Stores in scope
- Commerce platform position
- Product and PIM position
- Pricing and promotion authority
- Inventory and availability rules
- Fulfilment model
- Returns policy and process
- Payment architecture
- Peak expectations
- Business outcomes to baseline
Decision
Proceed · Assessment first · Transform first · Narrow the scope
Gate 2
Before build
Platform and architecture confidence
Before configuration begins, each part of the trading chain should have an agreed owner and an agreed interface.
Confirmed at this gate
- Business Central or Finance and Supply Chain Management
- Commerce platform boundary
- POS boundary where relevant
- PIM position
- OMS position
- WMS or 3PL position
- CRM position
- Payment service provider
- Marketplace scope
- Carrier scope
- Data authority by domain
- Integration design and timing
- Security model
- Licensing design
- Reporting model
- First-release scope
Decision
Proceed · Re-scope · Retain a specialist system · Adopt a different architecture
Gate 3
Before go-live decision
End-to-end trading proof
A representative trading chain should be proven with real data, including the exceptions that occur on a normal trading day.
Confirmed at this gate
- Order to payment status
- Availability to allocation
- Fulfilment to shipment
- Delivery confirmation
- Return to refund or settlement
- Finance and reconciliation
- Out of stock and oversell conditions
- Failed payment and order creation failure
- Cancellation, back order and split shipment
- WMS and carrier failure handling
- Marketplace delay and duplicate messages
- Stock discrepancy handling
Decision
Proceed · Remediate · Re-test
Gate 4
Go-live decision
Trading go-live readiness
The final gate asks whether trading can continue and whether the commercial state of orders already in motion is preserved.
Confirmed at this gate
- Products, range and assortment
- Prices and promotions
- Customers and accounts
- Inventory, reservations and allocations
- Open orders, back orders and part shipments
- Returns in progress
- Payments and settlements
- Stores and warehouses
- Channel and marketplace integrations
- Carrier integrations
- Users, roles and licences
- Reporting, support, fallback and reconciliation
Decision
Go · No-go · Controlled deferral
Go-live is ready when customers can continue to order and the business can preserve stock, payment, fulfilment and financial control through the transition.
Shared responsibility
Some of this only you can do.
We can implement the operating model. The retailer has to own the commercial rules behind price, promise, returns and customer treatment.
The retailer owns
- Channel strategy
- Product range and assortment
- Pricing policy
- Promotion policy
- Availability rules
- Inventory policy
- Fulfilment promise
- Cut-off rules
- Return policy
- Payment and fraud policy
- Tax treatment
- Customer data and privacy decisions
- Margin definitions
- Marketplace agreements
- Warehouse rules
- Data validation
- User acceptance testing
- Cutover decisions
- Adoption
InteliSense may provide where agreed
- Process design
- Architecture
- Platform qualification
- Configuration
- Development
- Integration
- Data migration
- Testing
- Reporting
- Delivery assurance
- Cutover support
- Risk visibility
Trading cutover
A retail cutover must preserve the commercial state of orders already in motion.
Opening inventory is not the complete cutover problem. Each position below needs an agreed treatment before the switch, because customers keep ordering while the transition happens.
- 01Product
- 02Price
- 03Promotion
- 04Customer and account
- 05Inventory
- 06Reservation
- 07Allocation
- 08Open order
- 09Part-shipped order
- 10Back order
- 11Return in progress
- 12Refund in progress
- 13Payment
- 14Settlement
- 15Purchase order
- 16Warehouse work
- 17Marketplace status
- 18Carrier status
Foundations
The work that decides whether the operating model holds.
Migration, adoption, security and licensing are not administrative afterthoughts. Each has its own page, and each affects whether trading behaves as designed.
Value realisation
The technology outcome is not that an order exists in ERP.
It is whether the business can keep the customer promise while understanding the operational and financial consequence. Each outcome runs from baseline to evidence, and we do not publish percentage improvements we cannot evidence.
Availability accuracy
- Baseline
- Current oversell, cancellation and availability correction volume from your own data.
- Operating change
- Availability rules, buffers and cut-offs agreed and owned by the business.
- Platform capability
- Availability calculated and distributed to channels at a supportable frequency.
- Adoption
- Merchandising, warehouse and service teams working the same rules.
- Evidence and review
- Observed movement against the baseline, reviewed rather than assumed.
Manual order handling
- Baseline
- Current volume of orders touched by hand and the reason each one was touched.
- Operating change
- Exception categories defined, with an owner and a route for each.
- Platform capability
- Order capture, validation, allocation and release automated where the rules allow.
- Adoption
- Service and operations teams using exception queues rather than inboxes.
- Evidence and review
- Touch volume tracked over time against the same baseline.
Returns and reconciliation
- Baseline
- Current return processing effort, refund lead time and reconciliation workload.
- Operating change
- Return and financial states separated, with disposition rules agreed.
- Platform capability
- Return, disposition, refund and settlement recorded in one connected process.
- Adoption
- Warehouse, service and finance teams working from the same return record.
- Evidence and review
- Processing effort and reconciliation exceptions observed rather than promised.
Channel economics
- Baseline
- Current visibility of commission, payment fees, carriage and return cost by channel.
- Operating change
- The organisation defines which costs belong in each management view.
- Platform capability
- Fees, carriage, promotion and return cost recorded where contribution is reviewed.
- Adoption
- Commercial and finance teams reviewing the same figures in the same context.
- Evidence and review
- Contribution explained by product and channel rather than reconstructed monthly.
AI with accountability
Human oversight should follow financial consequence, customer impact, reversibility and delegated authority.
These are candidate use cases, not claims. We assess the available data first and say plainly where it does not support the idea.
01 Retrieve or summarise
AI may assist within approved information boundaries, such as summarising a service conversation or retrieving product information.
02 Draft or prepare
Drafting product content, customer updates or operational reporting, with human review where appropriate.
03 Exception detection
AI or rules may identify orders, returns or stock positions that need attention.
04 Controlled low-risk automation
May execute inside explicitly approved limits, such as routing an exception or issuing a routine acknowledgement.
05 Commercial recommendation
Pricing, buying, markdown and promotion recommendations stay with human and business authority.
Use the simplest capability that works
- Can reporting solve it?
- Can a rule solve it?
- Can planning solve it?
- Can optimisation solve it?
- Is prediction actually needed?
A lower-risk starting point is often administrative coordination and exception handling.
- Order acknowledgements
- Despatch and delivery updates
- Back order alerts
- Return authorisations
- Replenishment suggestions
- Exception routing
- Supplier chasers
- Reporting preparation
Potential predictive use cases only
- Stock-out risk
- Demand pressure
- Fulfilment backlog
- Delivery exceptions
- Return likelihood
None of these is published as an available retail model. Return likelihood, for example, is only worth assessing when it is connected to a decision someone will actually take: product content, buying, sizing, fulfilment, supplier or service.
Leadership views
Different roles need different views of the same order.
One operating record, read in the way each person has to act on it.
CEO
Whether growth in demand is translating into contribution rather than into cost and complexity.
CFO
Contribution by product and channel, fees, returns cost, carriage, stock investment and cash.
COO / operations
Availability, fulfilment performance, warehouse capacity, carrier performance and exceptions.
Commercial / ecommerce
Product, price, promotion, channel performance and availability accuracy.
CIO / digital
Architecture, integration, peak resilience, data authority, security and AI governance.
Customer service
A connected view of order, delivery, payment status and return, so answers do not require investigation.
Illustrative example
An order is placed.
A simplified walk-through of one order. It describes how the operating model behaves, not a specific customer.
- 01Order placedA customer buys through one of the channels the business operates.
- 02Availability checkedThe commitment is tested against what the business is prepared to promise.
- 03Sourced and allocatedA fulfilment location is chosen and stock is committed against the order.
- 04Picked and packedWork is released against cut-offs and service commitments.
- 05DespatchedCarrier, tracking and customer communication happen from the same record.
- 06DeliveredThe promise is met, or the exception is visible before the complaint.
- 07Returned or servedA return or service conversation carries connected order context.
- 08UnderstoodRevenue, cost, fees and contribution are visible by product and channel.
Evidence
Customer experience of working with InteliSense.
Our current published customer videos evidence Dynamics delivery with InteliSense. They do not currently provide verified Retail & eCommerce sector outcomes. Retail-specific customer evidence will be published when the sector, engagement and approved claims have been verified.
Customer voice
Customer experience of working with InteliSense.
Customer voices
InteliSense customers
Hear our customers talk about InteliSense
Published evidence today covers manufacturing, a membership organisation and general customer voices. We do not infer retail or ecommerce experience from a company name or an approved logo. Future retail evidence will separately verify the customer, the sector, the engagement, the operating problem and the outcome before it appears here.
See all customer storiesWhere to start
Tell us where you are, and we will tell you what the situation supports.
Four questions. The answers are carried into the conversation, so nothing needs repeating. We do not select a platform, a commerce product or an acceleration route from a form.
Indicative signal
Answer the questions and we will show a likely starting point. This is orientation rather than a recommendation, and we do not select a platform, a commerce product or an acceleration route from a form. Please keep answers at business level and do not include payment or credential information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions retail and ecommerce leaders ask.
Connect demand to fulfilment
What does each order actually contribute once fulfilment, fees and returns are counted?
If availability, order handling, fulfilment, returns, settlement or channel contribution are harder to control than they should be, we can help you understand where the constraint sits and which platform and commercial route your situation genuinely supports.