Overview
Fluent Order Management System (OMS) implements a three-layer inventory architecture designed to provide real-time inventory accuracy and prevent order cancellations during high-traffic scenarios. This guide documents the platform's core concepts, integration patterns, and implementation details.
Key Benefits:
- 99.0% inventory accuracy with real-time stock management
- <5% order cancellation rate (down from 50%)
- 35% reduction in cart abandonment
- +$X revenue increase per flash sale
Business Value & Impact
Problem: Traditional Inventory Systems Fail During Peak Traffic

Metrics Before vs After
Metric | Before | After |
Order Cancellation | 50% | <5% |
Cart abandonment | - | -35% |
Revenue per flash sale | - | +$X |
Industry Use Cases
- Fashion: Seasonal variants, store transfers
- Electronics: Launch protection, trade-ins
- Luxury: Limited drops, VIP allocation
Key Concepts: IP, IQ, VP
To make sense of the architecture and flows described in this guide, it's important to understand the core inventory entities:
- Inventory Position (IP): Represents the combination of a specific product and location. It is the foundational data point for calculating real-time stock levels using all associated inventory transactions (IQs).
- Inventory Quantity (IQ): A detailed transaction ledger that records every stock-affecting event — such as LAST_ON_HAND (initial stock), SOFT_RESERVE (cart hold), RESERVED (confirmed order), and other types like RETURNED, SALE, CORRECTION AND DELTA. Each IQ is tied to a specific IP.
- Virtual Position (VP): A channel-specific abstraction that calculates available-to-sell inventory by applying business rules such as buffer percentages or channel exclusions to the onHand value from the corresponding IP.
These entities are foundational to how Fluent OMS models inventory in real time for multiple channels and user journeys.
Core Architecture & Data Model
Fluent OMS uses a three-layer inventory architecture to ensure high availability and transactional accuracy.
Architecture Layers

Key Data Relationships:
- IP → IQ (1:many): Each Inventory Position has multiple IQ transaction records. IQs reference their parent IP via
- IP ↔ VP (loose coupling): Virtual Positions find their corresponding IP by matching
`productRef + locationRef`
, not via direct foreign key - IP is the foundation: All inventory calculations start from IP, which aggregates IQ records to calculate
How IP, IQ, and VP Interact
The three entities work together in a layered approach to provide real-time, channel-specific inventory availability:

Data Flow Summary
- IP aggregates IQ records: All ACTIVE status IQ transaction types (LAST_ON_HAND, SOFT_RESERVE, RESERVED, SALE, RETURNED, DELTA, CORRECTION) contribute to the onHand calculation
- VP applies channel rules: Different channels can have different buffer strategies (Mobile 5%, Web 10%, Store 0%)
- Real-time updates: New IQ records immediately affect all related VPs across all channels
Virtual Position Calculation Example
Step-by-step calculation for ACME Sneaker Black US9 at Main DC for ECOMMERCE channel:

Calculation Breakdown:
- IP Aggregation: 50 (initial) - 2 (soft reserve) - 3 (reserved) = 45 onHand
- Buffer Calculation: 45 × 10% = 4.5 units
- Buffer Rounding: 4.5 → 5 units (round up for safety)
- Final ATS: 45 - 5 = 40 units available to sell
Result: Customer sees "40 units available" on the ECOMMERCE channel
Data Model Examples
Inventory Position (IP)
The foundational record for a product at a specific location
{
"ref": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT",
"productRef": "ACME_SNEAKER_BLK_US9",
"locationRef": "MAIN_DC",
"onHand": 45
}
Language: json
Name: The foundational record for a product at a specific location
Description:
The foundational record for a product at a specific location
Inventory Quantity (IQ) Records
Transaction ledger showing all stock-affecting events
[
{
"ipRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT",
"iqRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT:LAST_ON_HAND",
"type": "LAST_ON_HAND",
"quantity": 50,
"status": "ACTIVE"
},
{
"ipRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT",
"iqRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT:SOFT_RESERVE:FO_1234",
"type": "SOFT_RESERVE",
"quantity": -2,
"status": "ACTIVE"
},
{
"ipRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT",
"iqRef": "ACME_SNEAKER_BLK_US9:MAIN_DC:DEFAULT:RESERVED:FUL_456",
"type": "RESERVED",
"quantity": -3,
"status": "ACTIVE"
}
]
Language: json
Name: Transaction ledger showing all stock-affecting events
Description:
Transaction ledger showing all stock-affecting events
Virtual Position (VP)
Channel-specific availability calculation
{
"ref": "ACME_SNEAKER_BLK_US9:MAIN_DC:ECOMMERCE",
"productRef": "ACME_SNEAKER_BLK_US9",
"locationRef": "MAIN_DC",
"quantity": 40
}
Language: json
Name: Channel-specific availability calculation
Description:
Channel-specific availability calculation
VP Business Rules (applied during calculation):
- Channel: ECOMMERCE
- Buffer Strategy: 10% PERCENTAGE buffer
- Source onHand: 45 units (from matching IP)
- Buffer Calculation: 45 × 10% = 4.5 → 5 units (rounded up)
- Final ATS: 45 - 5 = 40 unit
Data Relationship Summary
Entity | Purpose | Key Fields | Calculation |
IP | Product + Location base | , , | `SUM(ACTIVE status IQ records)`
|
IQ | Transaction records | , , | Individual stock events |
VP | Channel availability | , , | |
Soft Reservation Deep Dive
Soft Reservation is a temporary hold on inventory when a customer adds items to cart. It prevents overselling by reserving stock in real time while ensuring inventory doesn't get locked up indefinitely.
Configurable Timer Mechanism
Timer Configuration:
- Range: 5-15 minutes (configurable per client)
- Flexibility: Can be configured per product, product category, or globally
- Use Cases: High-demand items (5 min), regular items (15 min), luxury items (30 min)
- Example: Flash sale items might use 5-10 minutes for urgency
- Purpose: Automatically releases inventory from abandoned carts
Why the Timer is Essential:
- Prevents inventory lockup: Without timer, abandoned carts would hold inventory forever
- Maximizes availability: Releases inventory back to other customers quickly
- Balances user experience: Gives customers enough time to checkout without being rushed
- Handles edge cases: Browser crashes, network issues, or customer distraction
Soft Reservation Lifecycle

IQ Status Management & ATS Impact
Critical Detail: IP calculations only use
status IQ records. When soft reservations convert to orders, the status changes maintain inventory accuracy.

Example: 2-Unit Cart → Order Flow
Initial State: IP has 45 onHand, VP shows 40 ATS
Step 1 - Cart Add:
- Create: SOFT_RESERVE IQ (-2 units, ACTIVE status)
- Result: IP onHand = 43, VP ATS = 38
Step 2 - Order Confirmation:
- Update: SOFT_RESERVE IQ (-2 units, INACTIVE status)
- Create: RESERVED IQ (-2 units, ACTIVE status)
- Result: IP onHand = 43 (unchanged), VP ATS = 38 (unchanged)
Key Insight: ATS doesn't change during checkout because the same quantity moves from SOFT_RESERVE to RESERVED, both impacting availability equally.
API Comparison: virtualPositions vs fulfilmentOptions
Fluent OMS provides two key APIs for accessing inventory:
and
. Choosing the right one depends on whether you're reading availability or actively managing reservations.

virtualPositions — Use When:
- ✅ You only need to display availability (no hold on inventory)
- ✅ Ideal for product listing pages, search results, and PDP views
- ❌ Cannot prevent oversells in high-velocity or concurrent scenarios
fulfilmentOptions — Use When:
- ✅ You need to reserve stock temporarily (soft reservation)
- ✅ Customer is in add-to-cart or checkout state
- ✅ Required for workflows where inventory accuracy directly affects conversion
Summary Table
Use Case | API to Use | Reason |
Browse/search listings | | Lightweight read, no inventory impact |
Add to Cart | | Initiates soft reservation, prevents overselling |
Begin Checkout | | Ensures held inventory for this customer |
Confirm Order | | Converts soft reservation to firm allocation |
Integration Flow Examples
1. Query (Read-Only)
Used for availability display and product search.

2. Mutation (Transactional)
Used during checkout and reservation creation. FO is an extensible workflow - clients can customize logic including SOFT_RESERVE behavior.

Real-World Example: Flash Sale Success Story
Flash Sale Timeline

Timer Logic Explained:
Each customer gets exactly 15 minutes from when they add to cart:
- Customer A: Adds at 10:15:00 → Timer expires at 10:30:00
- Customer B: Adds at 10:15:05 → Timer expires at 10:30:05
- Customer C: Adds at 10:15:10 → Timer expires at 10:30:10
Different expiry times are correct - each customer gets the same duration, but starting from their individual cart add time.
Visual Story: Race for the Last Item

Final Results:
- 3 soft reservations created simultaneously
- 1 successful order (Customer A won)
- 2 timer expirations (B and C were too slow)
- 0 oversells - inventory accuracy maintained
- 100% customer satisfaction for the successful buyer
Key Insights:
- Customer A was fastest to checkout (1 minute) and secured 1 item
- Customers B and C lost due to slow checkout (15+ minutes) - their items went back to inventory
- 3 items were available - all got soft reservations, but only fastest customer converted
- Soft reservation prevented overselling while allowing fair competition
Demand Signals & Analytics
Key Architecture Note:
FulfilmentOption Ref Creation: The calling layer (your application) owns the
creation for FulfilmentOptions. This design enables:
- Easy Analytics: Use the same ref to query FulfilmentOption status and analytics data
- Seamless Order Integration: Include the FO ref in order payload during checkout
- Automated Cleanup: Efficiently deactivate soft reserve IQ types using the ref
Best Practice: Generate meaningful refs (e.g., "cart-{cartId}-{timestamp}") for easier tracking and debugging.
Platform Scope & Responsibility:
Fluent OMS provides the raw data signals through FulfilmentOptions calls, order payloads, and fulfillment plan responses. The platform captures and stores:
- FulfilmentOption call patterns and responses
- Order correlations via FO refs
- Stock availability and fulfillment plan data
- Timer events and soft reservation lifecycle
The specific analytics, inferences, and business intelligence engines are outside the scope of Fluent OMS. These are typically implemented by:
- Client-side analytics platforms (e.g., Adobe Analytics, Google Analytics)
- Business intelligence tools (e.g., Tableau, Power BI)
- Custom ML/AI engines for demand forecasting
- Marketing automation platforms (e.g., Salesforce, HubSpot)
Fluent OMS focuses on providing accurate, real-time inventory data - the analytics layer is your competitive advantage!
Business Intelligence Flow

Detailed Analytics Use Cases
Completed Purchases → Revenue Analytics
- Detection Method: Correlate FO ref found in order payload with original FO call
- Conversion Tracking: Match soft reservation timestamp to order creation time
- Product Performance: Which SKUs convert from FO call to actual order
- Channel Analysis: CC vs HD success rates by correlating order fulfillment type
- Location Insights: Which locations from fulfillment plans actually fulfill orders
Abandoned Carts → Remarketing Triggers
- Detection Method: FO ref exists but NO corresponding order payload after timer expiry
- Timing Analysis: Track time between FO call and timer expiry with no order
- Product Affinity: Which product combinations are frequently abandoned together
- Recovery Campaigns: Target customers with unfulfilled FO refs
- Price Sensitivity: Correlation between fulfillment costs and abandonment
Out of Stock → Restocking Intelligence
- Detection Method: Empty or insufficient fulfillment plans in FO response (immediate)
- Real-time Alerts: Instant notification when FO returns no viable fulfillment options
- Location Analysis: Which locations consistently show zero availability
- Demand Intensity: Frequency of out-of-stock FO calls per product/location
- Supplier Integration: Automated reorder triggers based on stockout patterns
Channel Preferences → Personalization
- Fulfillment Preferences: Customer preference for CC vs HD by product category
- Location Loyalty: Preferred pickup locations and delivery addresses
- Timing Patterns: When customers prefer to collect/receive orders
- Experience Optimization: Customize UI based on historical preferences
Data Signal Workflow (Fluent OMS Scope):
Cart → FulfilmentOption → Order Flow:
- Cart Creation: Generate FO ref (e.g., "cart-abc123-20240315")
- Soft Reservation: Create FulfilmentOption with client-owned ref
- Data Capture: Fluent OMS logs FO call, fulfillment plans, and inventory events
- Order Checkout: Include FO ref in order payload
- Correlation Data: Fluent OMS provides FO ref → Order mapping
- Cleanup: Deactivate soft reserve IQ using FO ref
Analytics Implementation (Client Scope):
- Query Fluent OMS data via APIs
- Build conversion funnels using FO ref correlation
- Implement ML models for demand forecasting
- Trigger marketing campaigns based on abandonment patterns
Fluent OMS provides the foundational data signals - you build the intelligence layer!
KPIs & Technical Metrics
Important Note:
The metrics below are indicative figures based on typical implementations. Actual KPIs and technical performance metrics vary significantly depending on:
- Client-specific requirements and business models
- Implementation complexity and customization level
- Infrastructure setup and hosting environment
- Transaction volume and peak load patterns
- SLA agreements and performance targets
Contact your Fluent OMS representative for client-specific performance benchmarks and SLA commitments.
Metric | Indicative Value |
Inventory Accuracy | 99.0% |
Fulfillment SLA | 99.5% |
Uptime | 99.99% |
API Response Time | <200ms |
Cart Abandonment Drop | 35% |
Support Ticket Reduction | 65% |