Warehouse operations intelligence
Your warehouse already recorded what went wrong.
It is sitting in three or four systems that were built to run the floor, not to explain it. ConexIQ takes the exports your team already produces, joins them into one operating history, and answers the questions that cross system boundaries. Then it tells you plainly which questions your data cannot answer.
- Read-only
- Runs offline, on your hardware
- No control-system access
What it does
Your systems record everything.
None of them record it together.
The WMS knows an order line was released. The pick system knows a pick task completed. The material handling system knows a unit moved from one zone to another. Three files, three vocabularies, no key in common. So the questions that cross them go unanswered, and everyone learns to stop asking.
Three exports, three identifiers, no link between them
WMS
Order line 48213 released, 09:14
identifier: order line number
Pick system
Pick task 7F2A completed, 09:31
identifier: pick task ID
Material handling
Unit 920117 moved zone A → B, 09:38
identifier: unit ID
What ConexIQ makes of them: one unit, one timeline
09:14 Order line 48213 released (WMS)
09:31 Picked as task 7F2A onto unit 920117 (pick system)
09:38 Unit 920117 moved zone A → B (material handling)
What you can then ask
Ordinary questions. Finally answerable.
None of these need a new system, a new sensor, or a change on the floor. Each one says which of the three exports it is answered from, and what you would have to add yourself, because no export contains it.
Which orders did a given stoppage hold up, and for how long each?
Exports carry no alarm feed, so the stoppage window comes from you. The delay per order is then measured against that order’s normal dwell.
Where did Tuesday’s backlog start, and in which zone did it build first?
Which zone absorbed the delay, and which one passed it downstream?
What did the worst three shifts last month have in common?
Compared on what the exports hold: pick rate, order mix, zone dwell, number of active operators. Not on who was on shift. Rosters are not in the export.
How much of each picker’s day is between tasks rather than on a task?
Time between tasks is travel, waiting and breaks together. The export cannot split those three.
Which units were handled more than once, and where?
And what it refuses to answer
Every figure states where it came from.
The gaps are named, not filled.
An export contains what it contains. Most tools quietly interpolate the rest, and you find out which numbers were real during the argument that follows. ConexIQ publishes the boundary up front.
Measured
Derived from your rows. Traceable to the source.
- Orders released, picked, packed, shipped
- Completed pick tasks per hour, per operator
- Units picked, and the lines they came from
- Every unit movement, zone to zone, timestamped
- Dwell and queue time by zone
- Which units passed through which equipment class
Not in this source
Named explicitly. The product will not estimate them.
- Equipment utilisation: no telemetry in this export
- Who was on shift: no roster in this export
- Live alarm state: no alarm feed in this export
- Anything after the export window closed
Ask ConexIQ which equipment ran hottest on an export with no equipment telemetry and it will tell you the data cannot answer that, and what feed would be needed. It will not produce a plausible number. That behaviour is enforced in the code, not left to the model’s discretion, because a confident wrong figure in an operations review is worse than no figure at all.
Evidence
One real dataset, checked line by line.
A live European distribution centre’s WMS and material-handling export, run through the pipeline from an empty database on 1 September 2026. Every figure the product reported was then re-derived independently in SQL and compared.
551,827
Rows ingested across three source systems
Verified 2026-09-01
19/19
Reported figures re-derived exactly in SQL
Independent check
0
Personal identifiers reaching storage. Leak gate on every row
All three ingests
11,257
Units matched across two systems with no shared key
Derived join
Stated plainly
That is one customer’s data shape, not a track record. There is no production deployment, no reference you can call, and no case study. The pipeline has been proven against real operational data exactly once, and the number above is what that proof consists of. If a second dataset breaks it, that is worth knowing early, which is the entire reason the first engagement is small.
Where it stands
Three tiers, and the third one is the point.
Software pages usually list features. This one lists what has been proven, what has only been built, and what does not exist, because the third column is the one a technical reviewer will go looking for anyway.
Proven on real operational data
Run end to end against a live DC export and checked figure by figure.
- Ingest and normalise WMS / WCS exports: Excel or CSV, as your team already produces them
- Join records across systems that share no key
- Reconstruct the operating history: orders, pick tasks, unit movements, zone by zone
- Pseudonymise every identifier before it lands, with a leak gate on every row
- Field-level provenance: the coverage contract above
- Export findings to Excel, Word, PowerPoint, PDF and CSV
Built, not yet proven on a customer site
The engineering exists and the maths has been checked. The evidence from a real facility has not.
- Discrete-event scenario simulation: Erlang-C, M/M/c, M/D/1, M/G/1, Little’s Law
- Natural-language questions over the reconstructed data, answers bounded by the coverage contract
- Root-cause tracing from a symptom back through the dependency chain
- On-premise, air-gapped deployment with a local model and no outbound network
Not built, and not claimed
Listed because you would find out anyway, and later is worse.
- A live connection to your WCS or WMS. Today it reads exports, not feeds
- Demand or pick-volume forecasting. It needs a validated history first
- Automated optimisation recommendations
- SOC 2 or ISO 27001 certification. An internal self-assessment exists; a certificate does not
- Multi-site rollout. One site is the honest unit today
Where it sits
Above the stack. Never inside the loop.
No agent on your control network, no API credentials, no vendor to notify. It reads files your team already produces. Adding it changes nothing about how the warehouse runs, which is why nobody has to approve a change to how the warehouse runs.
Event exports flow up, read-only
Nothing flows back down. There is no write path in the code.
Send one export.
Find out what it already knows.
Three weeks, fixed scope, fixed price. No system access, no integration, nothing near your control layer. So there is no security review to schedule and no vendor to involve.