Delay prediction

Experimental feature

Delivery prediction processing is not available yet. You can save its settings in Scope, but Skrym does not currently generate predictions or likely-delay events from them.

Shipping data is inherently difficult to interpret. Skrym is developing statistical inference and ML models to identify shipments that are likely to be delayed.

Our goal is to give you information as early as possible when a shipment will be delayed, so that you can proactively communicate with the recipient and prevent angry calls to customer service.

Skrym admins can open Settings → Tracking → Delivery predictions in Scope to save preferences for future likely-delay events and their thresholds. The whole card is marked under construction and is shown only to Skrym admins in Scope. These settings do not affect shipments yet. The settings load before the form can be edited; if loading fails, retry before saving. When no configuration has been saved, the API supplies suggested thresholds without creating a database row. Saving writes every setting explicitly. Threshold percentages and significant-delay multipliers accept fractional values. Background refreshes preserve unsaved edits; Cancel discards the draft and restores the latest saved configuration received by the editor. Once a save succeeds, its values become the Cancel baseline even if the confirmation refresh is slow or fails.

The Run automatic delivery predictions switch is a separate, off-by-default retailer opt-in for scheduled inference when that processing is deployed. It does not control manual model tests. When available, Create likely-delay events will add a separate tracking event when a shipment is predicted to be delayed. Skrym admins can save this preference now, but no such events are generated yet.

The form shows a live illustration of the planned likely-delay rule. The threshold measurement and percentage belong together: the percentage is the minimum ordinary probability or strength-weighted probability, depending on the selected measurement. The significant-delay multiplier compares predicted delivery time with the historical average for comparable shipments. The absolute delay threshold adds elapsed calendar hours to that average. Either delivery-time threshold can qualify a shipment, so the earlier time applies. Calendar hours include nights, weekends, and holidays; they are not working hours or working days. The form uses a 48-hour comparable average solely as an example. How the model chooses comparable shipments is still being developed.

Model scope

Each saved model records which data it was trained on. A model with an organization ID was trained for that retailer; a model without one was trained across retailers and can serve as a global fallback. The model's active flag is scoped to its organization and prediction type, so activating one retailer's model does not deactivate another's. An organization can also select a specific model version for each prediction type. Those selections are stored separately from the model so choosing a global version for one retailer does not change what other retailers use. A retailer may select only a global model or one trained for that retailer. The tracking repository validates this when saving a selection; future training tools must use that repository path rather than writing selections directly with SQL.

Stored forecasts distinguish the historical evaluation time (timeline_at) from the time a prediction was computed (predicted_at). Their hours_from_journey_start value counts elapsed calendar hours, including closed days, rather than transporter business hours. For delivery-day forecasts, day_offset is a zero-based position in the forecast horizon and delivery_date is the calendar date resolved for that position. Future prediction writers must use a consistent horizon start and delivery timezone when storing both.

Planned approach

The planned models will use data points related to the time and date of the shipment, as well as:

• Aggregated statistics for the transporter
• Average delivery times between major transport hubs
• Expected event chains and notification spans

Transporter operating hours are stored per organization and transporter, independently of prediction settings. Skrym admins can configure them for the selected organization on the transporter's Skrym-admin configuration tab. Settings endpoints use the organization selected in authentication; the private read endpoint requires an explicit organization ID. The editor uses hour and minute selectors and suggests 08:00–18:00 Monday–Friday when no hours are stored; this is only an editable starting point and is not saved automatically. Unchecked days have disabled time selectors, but their times are retained if the day is checked again. An explicit IANA timezone must be selected from the searchable dropdown before saving hours. Clear saved hours opens a confirmation dialog; confirming removes only the selected organization's schedule and discards unsaved edits. If no hours are saved, the stored-hours query returns an empty schedule. Future prediction processing should ignore business hours when the schedule is missing, rather than assuming UTC hours or treating the transporter as closed.

Saving keeps the submitted hours visible while refreshing the stored schedule. A failed refresh leaves those values in the editor, and edits made while saving or refreshing are preserved for the next save. Business-hours timezones must be explicit, such as Europe/Stockholm or UTC; the host-dependent Local timezone is rejected.

Warehouse cutoff times and fulfilment days are configured separately for each warehouse, transporter, or transport method. Checkout reads those settings through the Locations service's private GetWarehouseMethodConfigsInternal API, which also resolves the warehouse time zone. Delivery prediction does not consume them yet because prediction processing has not been implemented; that future processing should use the same API rather than storing a second copy of the settings.