PLATFORM COMPONENTS
What OMNI is made of, and what each part decides.
Order, inventory and product data usually live in three to five disconnected tools. OMNI does not replace those tools. It reads from them and adds one continuously updating layer on top, built from four engines that each answer a different question, in order.
Four engines, one chain
Each engine depends on the answer the one before it produced. Read them in this order and the whole platform makes sense.
ENGINE ONE
Aggregator
What do we actually have?
Inventory data arrives from every direction and almost none of it is clean. Aggregator ingests it, parses it and normalizes it, so everything downstream is working from one view of the supply network rather than four arguments about it.
- Ingests from vendor portals, distributor feeds, spreadsheets, APIs, FTP and email
- Parses and cleans raw feeds before anything else touches them
- Lets you add suppliers without losing visibility of what they hold
ENGINE TWO
ATS
What can we actually sell?
On hand is not available. ATS takes the combined picture, applies routing rules, subtracts what is already committed, and returns one number per SKU that you can publish without apologising for it later.
- Combines inventory from every source into a single availability figure
- Accounts for existing commitments rather than raw shelf quantity
- Produces a clear, actionable number per SKU for every channel
ENGINE THREE
Balancer
Who gets to sell it?
One pool of stock, several storefronts, and no way to promise all of it to all of them. Balancer allocates availability across channels by your rules, and adjusts raw vendor quantities before they ever reach a listing.
- Allocates by custom rules, brand priorities and channel strategy
- Protects against oversell with thresholds you set, such as publishing zero when a vendor drops below eleven units
- Syncs on new orders and inventory changes, pushing quantities by API
ENGINE FOUR
Routes
Who ships it?
Every order has a best source and several acceptable ones. Routes picks the best, then guarantees there is always a fallback, which is the part that matters at two in the morning during peak.
- Assigns each order by cost, geography, SLA and margin
- Follows a hierarchy you define: owned stock, then 3PL, then FBA, then dropship vendor
- Mandatory Item and Channel default rules mean no order is left unfulfilled when the primary route fails
A warehouse system, if you need one
Most operators we work with already run a WMS and keep it. For those who do not, or who have a site that never justified an enterprise deployment, OMNI includes one.
OMNI WMS
Light enough to deploy, heavy enough to run a building.
Cloud based, quick to stand up, and configurable without IT involvement. Teams set up locations, zones and pick paths themselves, whether that is one warehouse or several.
- Barcode scanning, lot and serial tracking, real time quantity updates from receiving through shipping
- Batch picking, label generation and carrier rate shopping
- Handles direct to consumer, wholesale, dropship and FBA workflows in one place
- Built for operations running thousands of daily orders without enterprise complexity
Purpose built for how logistics actually works
Two capabilities that exist because real operations are messier than a product diagram.
Multi channel fulfillment
Manages inventory and tracking across fulfillment types that do not normally talk to each other. Use FBA inventory to fulfill non Amazon orders, or route trans ship orders through a warehouse for consolidation.
Principal and Tenant portals
Dedicated portals let a 3PL or marketplace manage their own operation and their clients’ data under one umbrella, with visibility governed by role rather than by habit.
Connectors, turnkey and built
Channels, marketplaces and carriers connect themselves. EDI, ERP and other WMS platforms get built against your stack, then appear in the same list.
Where each piece shows up
These components are the mechanism. Each page below is the argument for what they change in a working operation.
Cash Flow→
Which part of a ninety day billing cycle is contractual, and which part you can shrink.
Billing→
One set of events, two rate cards, and why your client cannot be looking at different numbers than you.
Warehouses→
Counts from your WMS, your client’s WMS, or OMNI, resolved into one list per zone.
Orders→
Every channel and every EDI order in one queue, filterable from any cell.
AI→
Most questions need one number rather than a dashboard, and reports built against your own fields.
Integration→
Turnkey connectors, connections built for your stack, and inventory sync that starts switched off.
Worth a conversation rather than a spec sheet
Which of these matter depends entirely on what you already run. The fastest way to find out is thirty minutes with your actual stack on the table.