Order management analytics
Order management analytics includes order and routing data. Use the Explore dashboard navigation to switch to the corresponding page.
You can filter by time frame and select the time granularity (daily, weekly, or monthly). You can also filter by facility for routing only. Once selected, click Apply to apply the filters.
You can download the data to an Excel file using the Download button at the bottom of both pages.
Orders
The Orders analytics page contains various order data, including order time, status, and line items. As this information exists independently of the routing of the orders, there are no references to facilities here.
At the top of the page, you'll see some top-level order figures.
Incoming orders
The number of incoming or created orders is displayed in different ways (total, by date, by time of day, by day of the week). The order date set by the upstream system is used, not the time the order entity was created in fulfillmenttools.
Lines per order
The lines per order chart shows the average number of order lines per order for orders that were created within the selected time span or on a specific date. This value is shown both in total and by date.
Most ordered items
The table lists the items that were present in the most orders created within the selected time span.
It shows the article ID, article name, and how many orders it was in.
Finished orders and order finishing time
Orders are considered finished when the underlying process status is set to finished. Finishing time is the period between order creation and the time the order is considered finished.
The chart below shows three quantiles of the finishing time by date. This allows you to assess both typical and extreme times. In this example, about 5% of orders that finished on 24 July took more than 51 minutes.
Incoming and finished orders are also shown in direct comparison to display how order processing correlates with the incoming order volume.
The incoming orders by latest status chart shows orders by creation date, separated by current status. This helps identify older orders that aren't finished yet. In this example, 167 orders created on 9 August are not yet finished.
Canceled orders
The canceled orders chart shows the number of orders canceled per day via the REST API for order actions or Backoffice.
Orders by service type
The orders by service type chart shows the proportion of created orders that are click-and-collect orders or ship-from-store orders.
Routing
The Routing analytics page shows routing-related figures and key performance indicators (KPIs), such as the number of successful routings, reroutes, and order splits, displayed by date and location. The dropdown menu on the map lets you view some of these values as a scatter plot.
Successful routings
A routing is counted as successful if an assignment to a location has taken place. Due to reroutes and order splits, an order can lead to several (successful) routings.
Usually, a pick job is also generated in each case. An exception to this is locked orders, where a pick job is only created after unlocking.
Reroutes
You can view reroute data in multiple ways.
Firstly, you can use the map dropdown to show the total number of reroutes from which facility it was routed away from. For example, in the chart on the right, 4102 tasks have been removed from the Munich store and routed elsewhere.
You can also see the number of reroutes split by reason. These can be manual, short pick, and inactivity. If a picking task is aborted and rerouted as a result, this is also counted under a short pick.
A manual reroute can occur when an individual task or the entire order is reassigned manually. Even if an order is automatically routed again after resetting the entire process, this is counted as a manual reroute.
In addition to the source location, the chart below also shows the target location of reroutes, together with the associated frequency. In this example, 708 tasks were rerouted from Hamburg to Frankfurt.
You can also view this as a list.
If an order split occurs during the reroute, it's not clear which target facility to display. In this case, only the first facility used during routing is counted as the target facility.
Reroute ratios
A common question is what proportion of routings are later rerouted. However, since these events can happen on different days, this KPI can't be calculated against a selected time period.
For this reason, we use a different definition: the proportion of finished tasks in a facility that ended with a reroute. For example, the manual reroute ratio is calculated as follows:
The denominator has two parts because a reroute can occur before a pick job is created. In the chart below, 1538 tasks were finished in some way on 11 August, 43 of them with a reroute by short pick. This corresponds to a ratio of 2.8%.
A high reroute ratio is less significant if the total number of routings to the location is low. For this reason, we also plot both values against each other in a scatter plot, with each point representing a location. Data points in the top right-hand corner require attention, as they indicate facilities with both a high number of routings and a high reroute ratio. In the example on the right, this applies to Munich.
In the list view, you can see this is mainly due to manual reroutes and time-triggered reroutes.
Unroutable orders and fallback routings
The number of unroutable orders and fallback routings is shown both in total and by date. If an order is split or generates several failed or fallback routings, it can create multiple entries per order.
Because it matters whether orders were temporarily or permanently unroutable, this is displayed separately. In the example below, about 2000 routings on July 10 went into unroutable status, but only 144 remained there ("Last status is unroutable"), while the rest later changed to something else ("Earlier status is unroutable").
Order splits
Order splits are shown separately by how many parts an order is split into. 1 split means a split into two parts.
In the following chart, each order leads to a single entry. On August 5, 61 order routings led to exactly 2 splits (3 parts). We only count routings that have not been rerouted. This means that if there was initially a split, but not after a reroute of the entire order, no split is counted for this order.
Completely picked pick jobs
The Completely picked pick jobs table indicates the proportion of incoming tasks that result in a successfully closed, fully picked pick job. This is split by facility.
You can also see the percentage of successfully closed pick jobs as well as closed partially picked pick jobs. In this example, 1202 pick jobs were completely picked on 3 August, while 1480 tasks ended in some way overall.
The completely picked pick job ratio is calculated by:
Last updated
Was this helpful?