A shopper sees a delivery promise that wins the order: today, tomorrow, or within a tight pickup window. The promise is a conversion tool, but it is also an operational commitment. Once the order is placed, the retailer has to find the item, route the order, pick it, pack it, hand it off, and keep the customer informed.
Share: A fast delivery promise is only good if the network can keep it. Inventory accuracy, routing, store labor, carrier capacity, and substitutions decide whether trust survives. #Causality #RetailAnalytics #Fulfillment
Synthetic teaching model
This article uses a synthetic retail model. It is not pricing, legal, financial, operational, compliance, or merchandising advice. The sources below justify why some variables belong in the model. The probabilities are invented so the reasoning path is easy to inspect.
The Operating Problem Is Usually Wider Than The Metric
Omnichannel fulfillment can make retail feel seamless, but the costs arrive behind the scenes. A promise that is too fast for the network creates late deliveries, substitutions, cancellations, support contacts, refunds, and trust damage. The causal problem is not whether speed is good. It is whether speed is being promised under conditions that can support it.
Why The Dashboard Can Mislead
The dashboard can mislead if it treats a fast promise as a pure conversion feature. Speed can lift orders while increasing late deliveries, substitutions, or margin pressure. The useful metric is not the promise alone. It is the promise under the current capacity and inventory state.
Plain-language modeling note
A Bayesian belief network, or BBN, is a graph for asking conditional questions. Each node is a condition, each arrow says one condition informs another, and each probability is explicit. You do not need to know the SDK to read the graph: the SDK code is only there when we need a repeatable action query.
The Question For This Example
This example asks how promise-failure risk changes after observing inaccurate inventory, a fast promise, low carrier capacity, and low store-picking capacity, and what changes if the promise is measured, routing improves, and inventory is accurate.
The target outcome is PromiseFailure, which means fulfillment promise failure in this teaching model.
A Small Model Of The Situation
The model treats fulfillment as a promise system with inventory, routing, capacity, disruption, and customer-trust paths. It leaves out actual carriers, delivery zones, labor contracts, routing algorithms, product dimensions, and service-level agreements.
The graph has 16 nodes:
InventoryAccuracy: Inventory accuracy (accurate / inaccurate)PromiseSpeed: Promise speed (measured / fast)CarrierCapacity: Carrier capacity (adequate / low)StorePickingCapacity: Store picking capacity (adequate / low)WarehouseLoad: Warehouse load (low / high)WeatherDisruption: Weather disruption (no / yes)OrderRoutingQuality: Order routing quality (good / poor)SubstitutionPolicy: Substitution policy (clear / unclear)LateDeliveryRisk: Late delivery risk (low / high)CancellationRisk: Cancellation risk (low / high)ContactCenterLoad: Contact center load (low / high)RefundCost: Refund cost (low / high)TrustDamage: Trust damage (low / high)RepeatOrderRisk: Repeat order risk (low / high)FulfillmentMarginPressure: Fulfillment margin pressure (low / high)PromiseFailure: Promise failure (no / yes)
What Is Sourced And What Is Synthetic
Deloitte’s retail outlook supports real-time inventory visibility, fulfillment options, delivery profitability, and omnichannel pressure. NRF’s supply-chain discussion supports uncertainty, network design, inventory flow, forecasting, and transparency as active retail concerns. Fulfillment allocation research supports connecting assortment, inventory allocation, and local fulfillment.
Inventory visibility and fulfillment- Deloitte identifies real-time inventory visibility and multiple fulfillment options as central omnichannel capabilities.
Supply-chain uncertainty- NRF’s supply-chain discussion motivates including disruptions, network design, inventory flow, and collaboration.
Local fulfillment- Recent fulfillment research supports modeling inventory allocation and local fulfillment as profit and availability drivers.
Boundary of the evidence
The sources support the general mechanisms in the graph. They do not estimate this article’s node states, thresholds, or conditional probability values. Those are synthetic teaching values.
The Query The Graph Cannot Show By Itself
The visual graph is the best way to inspect the structure. The code-backed query is there for a narrower reason: we want to separate what is learned by observing a messy retail case from what changes if one condition is set differently.
Using the Darkstar Python SDK, a subscribed SDK user can load the same BBN JSON, ask for the target probability after evidence is entered, then run the action query by setting a node before querying again. The download includes this as illustrative SDK code, while the standalone query_example.py reproduces the article numbers without shipping the SDK.
import json
from darkstar import DiscreteModel
TARGET = "PromiseFailure"
OBSERVED_EVIDENCE = {
"InventoryAccuracy": "inaccurate",
"PromiseSpeed": "fast",
"CarrierCapacity": "low",
"StorePickingCapacity": "low"
}
INTERVENTION_CONTEXT = {
"CarrierCapacity": "low",
"StorePickingCapacity": "low"
}
INTERVENTION = {
"PromiseSpeed": "measured",
"OrderRoutingQuality": "good",
"InventoryAccuracy": "accurate"
}
def probability_after_observing(model, evidence):
query = {"nodes": [TARGET], "evidence": evidence}
result = json.loads(model.pquery(json.dumps(query)))
return result[TARGET]["yes"]
def probability_after_setting(model, setting, evidence):
changed_model = model.intervene(json.dumps(setting))
return probability_after_observing(changed_model, evidence)
with DiscreteModel(model_json) as model:
observed = probability_after_observing(model, OBSERVED_EVIDENCE)
acted = probability_after_setting(model, INTERVENTION, INTERVENTION_CONTEXT)
That is the article’s main modeling distinction. Observing a pattern is not the same as setting one part of the system differently.
The standalone query code gives this synthetic result:
Baseline fulfillment promise failure: 23.4%
Observed scenario (fast promise with weak inventory and capacity): 33.8%
Action scenario (measured promise with accurate inventory and routing): 20.8%
Same context with the action left unfavorable: 36.3%
Synthetic reduction versus the observed scenario: 13.0 percentage points
What We Learn By Observing The Situation
The observed scenario sets:
- Inventory accuracy = inaccurate
- Promise speed = fast
- Carrier capacity = low
- Store picking capacity = low
The observed scenario raises promise-failure risk because a fast commitment is paired with inaccurate inventory, low carrier capacity, and weak store picking. The graph treats that combination as a fragile service promise.
What Changes If We Set One Condition Differently
The action scenario sets:
- Promise speed = measured
- Order routing quality = good
- Inventory accuracy = accurate
The action query changes the promise to measured, improves order routing, and makes inventory accurate. It does not remove weather or warehouse load. It tests whether the promise becomes more credible when the upstream information and routing paths are fixed.
What This Example Cannot Prove
This model cannot optimize fulfillment routing, price delivery, or estimate real service levels. It is a teaching model for why customer promises need operational evidence behind them.
Try this in the shared model
Open the companion model, change one upstream condition at a time, and watch the target probability move. Start with the observed scenario above, then reset one condition that looks actionable. The point is to compare stories, not to treat the toy probabilities as a forecast.
Try The Model
Open the companion Darkstar model: Open Omnichannel Fulfillment Promise BBN
In the shared model, keep PromiseSpeed fast but set InventoryAccuracy accurate. Then keep inventory inaccurate and improve routing. The comparison shows where speed depends on truthful inventory.
Download the teaching package: Omnichannel Fulfillment Promise BBN ZIP
The download contains synthetic model files and examples only. It excludes order data, carrier contracts, workforce schedules, routing systems, SDK binaries, and chart-generation code.
Leave a Reply