Glossary
Fulfillment intelligence
Fulfillment intelligence is what a warehouse system can tell you beyond the current balance: why stock is where it is, which orders are holding it, what is about to run out, and how the operation itself is behaving. It is only as good as the ledger under it.
What it is
Fulfillment intelligence is the answer to questions a balance cannot answer. Not how many, but why this many; not where, but why there; not what shipped, but what almost did not. It covers the reports over the ledger (aging, held stock, discrepancies), the reasons behind decisions (allocation, routing), the condition of the system itself (workers, integrations, health), and, at the top, prediction: what will run out, what is dead, what to reorder.
Why it matters
Every warehouse produces these facts and most systems discard them. The allocation that chose bulk over pick face made a decision; if it is not written, the picker’s confusion at the empty shelf has no explanation. The order that has held forty units for three weeks is a decision nobody made; if nobody sees its age, nobody makes it. Intelligence is keeping what the operation already knows and putting it where someone will look.
An example
A product shows twelve available and the store keeps overselling it. The balance is right. The intelligence is elsewhere: nine of the twelve are held by three kit orders that have been allocated for nineteen days, past the customer’s fifteen-day limit, and the reconciliation from last night flagged a two-piece discrepancy in the pick face. Three facts, all in the system, none of them in the balance.
How a modern WMS handles it
In order. First the ledger: no balance stored, every change a row, every writer named and tested. Then self-report: a health endpoint that degrades when something is wrong, alerts with names, errors where the operator looks. Then reports that read from both: aging, holds, discrepancies, decisions. Then, and only then, prediction, because a forecast is a report about the future and inherits the honesty of the reports about the present.
How DockingWare does it
The ledger comes first, and it is guarded: every stock writer is registered and the build refuses one that is not. The health endpoint reports database, cache, migrations, storage and workers and says degraded when it is. Allocation and routing write their reasons. Aging and held stock are reported per customer limit, and kit-held quantities are read from the allocation table, not inferred. Forecasting is not shipped and the commercial page labels it as coming. The executive overview exists and is partial.
Questions
- Is fulfillment intelligence just forecasting?
- Forecasting is one part, and the part most vendors lead with. The rest is knowing your present precisely: which orders hold stock and for how long, why an allocation drew from a bucket, whether the background work is running, where the last discrepancy came from. A forecast built on a balance nobody audited inherits every error in it.
- What should a buyer ask a vendor about it?
- Two questions. Where does the number come from, row by row? And what does the system say about itself when something is wrong? A vendor who answers the first with a dashboard and the second with a status page has skipped the foundation.
- Does DockingWare forecast today?
- No. Forecasting, ABC-XYZ and dead-inventory detection are on the roadmap and recorded as missing in the application's own capability register. What ships is the layer under them: a ledger that cannot be changed without a row, decisions with reasons, and a system that reports its own health.