What does the Warehouse surface measure?
Two things. Performance: how many orders each packer packed, how long each took, and how that compares over time, from the warehouse or packing integration. And the backlog: which orders are unfulfilled right now, how old each one is, and whether the age has crossed the window the store promises at checkout.
Both are computed from records the engine holds, joined to the orders themselves, so a slow afternoon can be read against the orders it delayed and the tickets that followed.
- Orders packed per packer, per shift, with the time each took from claim to dispatch.
- The composition of each packer's queue, so a slow time on complex orders is read correctly.
- The live unfulfilled backlog, with each order's age against its promised window.
- Stuck orders ranked by money and age, with the customer and order attached for a proactive message.
- The trend over weeks, so a gradual slide is visible before it becomes a customer-facing problem.
Why per packer and per order, rather than an average?
A warehouse average hides the two things worth knowing: which orders took far longer than they should, and whether the difference is the order or the person. Per order finds the outliers, usually multi-line orders, fragile items or lines that needed a substitution. Per packer finds training needs and shift patterns.
The engine reports both without judgement. A packer with slower times on complex orders is doing different work, not worse work, and the surface shows the composition so an owner reads it correctly.
What does getting stuck mean here?
Stuck is a computed state: an order whose age has crossed the expected fulfilment window without a fulfilment event. It is not a guess about warehouse mood; it is a timestamp comparison against the promise the store made at checkout for that shipping method.
Stuck orders are ranked by the money at stake and by age, so the owner sees the largest and oldest first. The list carries the customer and the order, so a proactive message can be drafted for Review & Send before the customer writes in.
How do you read the backlog against support tickets?
Where a helpdesk is connected, the tickets asking where is my order can be read against the backlog that produced them. A spike in tickets that matches a spike in stuck orders is an operations problem, not a support problem, and the fix is in the warehouse rather than in reply templates.
This join is only possible because the engine holds tickets and orders in one database. It is the same reason the returns platform's reasons can be read against products and sizes.
What the engine does not do to your warehouse
It does not assign work, change pick lists, or write anything into the warehouse system. It reads packing records and order events and reports on them. Any action, such as a message to the warehouse manager about a backlog or a proposal to change a cut-off, goes through Review & Send as a message from a person.
That boundary keeps the operational system authoritative. The engine's job is to notice and to explain, not to run the floor.
Which role owns this on ftes.ai?
The Warehouse Officer FTE owns packing performance and the backlog, and is judged on orders fulfilled inside the promised window. It proposes the messages, the cut-off changes and the staffing notes; the owner or the warehouse manager approves them.
A brand that connects a packing integration sees performance and backlog from the first sync. Before that, the surface says the integration is not connected rather than showing an empty chart.
How does a backlog become a decision?
A backlog on its own is a number. The engine turns it into a decision by pricing it: the value of the orders waiting, the age of the oldest, and the share of the day's promise that has already been missed. That figure is what appears on the Morning Brief, ranked against the other decisions of the day.
The decision itself is usually one of three: move hours to the pack bench, message the customers whose orders are late before they write in, or change the cut-off the storefront promises. Each is drafted with the arithmetic attached and waits for a person in Review & Send.