Loading...

Rank OTD Decline Drivers

When a regional delivery review shows OTD or OTC slipping, the Delivery Operations Manager has to explain the drop before leadership, carrier managers, and dispatch teams start asking for different cuts of the data. This workflow assembles the comparison, isolates the main drivers, and produces a ranked briefing with evidence and next-action guidance.

The manager still decides which interventions to approve, escalate, or defend; the workflow removes the cross-domain querying, baseline calculation, driver assembly, and briefing formatting work. The estimated impact is a 45.9% shift in role time out of execution-layer work.

Interactive Demo

See the Decision Intelligence Workflow in Action

This workflow handles a compound operations analysis task: compare current delivery performance to baseline, separate true carrier performance deterioration from lane-mix effects, and test whether exception composition changed enough to matter. The hard part is not one calculation; it is assembling a defensible explanation across shipment outcomes, carrier-lane behavior, and exception categories quickly enough for an operating review.

👤
Designed for line-of-business leaders — specifically the Delivery Operations Manager who is accountable for explaining OTD/OTC degradation and aligning carrier, dispatch, and customer-facing teams on corrective action. It addresses the recurring execution work behind weekly reviews, monthly scorecards, and incident response. Why this matters: What line-of-business leaders actually need from automation →
Decision Intelligence Playground · OTD Driver Attribution Brief
KWF Runtime
Start with an example
Want to see this workflow in your delivery operations environment?
We will walk through the operating question, the required shipment and exception data, and the exact briefing the workflow generates for OTD/OTC degradation reviews. We will also map the execution-layer steps your team does manually today and show this workflow running on your Databricks environment.
Schedule a Databricks Session
How It Works

What the Decision Intelligence Workflow Does

This workflow handles a compound operations analysis task: compare current delivery performance to baseline, separate true carrier performance deterioration from lane-mix effects, and test whether exception composition changed enough to matter. The hard part is not one calculation; it is assembling a defensible explanation across shipment outcomes, carrier-lane behavior, and exception categories quickly enough for an operating review.

Click any step below to see the business logic, data query, and sample output for that step of the workflow.

Pre-specified logic, not runtime guessing — Most AI agent frameworks work by figuring things out on the fly. These Decision Intelligence workflows work differently. The Knowledge Work Foundry analyzes the cognitive labor pattern before deployment and encodes the decision logic directly into the configuration — which tables to query, which thresholds define a breach, how signals are ranked, and what the output artifact should contain. That analysis happens once. By the time the workflow runs, there is nothing left to figure out.
1
Detect Variance
Compares current-period OTD and OTC against the prior baseline window and checks whether the decline is material.
2
Rank Hotspots
Breaks the decline into carrier-by-lane slices and ranks the largest performance-driven hotspots.
3
Assess Exceptions
Measures shifts in exception categories and flags which issue types materially worsened in the analysis window.
4
Build Brief
Assembles the KPI deltas, ranked drivers, and evidence bullets into a leadership-ready attribution brief.
5
Map Actions
Links the top drivers to recommended operational actions for carrier management, dispatch, and customer communication.
↑ click a step to explore the logic, query, and output
1
Step Detail

                      

                    

The output is a driver attribution brief with overall OTD/OTC movement, a ranked list of the top drivers, supporting evidence bullets, and recommended next actions by driver type. It can also feed an email, dashboard panel, or scorecard-ready summary.

What this workflow does NOT do: It does not decide whether to escalate a carrier into a formal contract or scorecard review, approve temporary capacity shifts across regions, change customer promise windows on long-distance lanes, reprioritize which customer segments should receive proactive outreach first, or rewrite dispatch staffing and scheduling policies.
Under the Hood

Data Warehouse Integration

The workflow depends on warehouse-ready operational facts that can be parameterized by region and time window, then compared to a prior baseline period. It pulls delivery outcomes, shipment volumes, carrier-lane performance, and exception categories into one repeatable analysis so the manager is not rebuilding the same joins and calculations for every review.

The cross-domain requirement matters because the explanation can be wrong if shipment outcomes are reviewed without carrier-lane shifts or exception mix changes in the same frame.

Source system: Transportation and order operations delivery mart  ·  Domain: Delivery Operations
Role in this workflow: This table provides the core shipment-level facts used to calculate OTD, OTC, shipment volume, and carrier-by-lane performance in both the analysis and baseline periods. It is the primary operational signal for detecting whether service has degraded and for locating where the degradation is concentrated. The workflow relies on it first to establish the KPI variance, then again to separate carrier performance issues from changes in shipment mix.
CREATE TABLE ops.ops.shipment_delivery_fact (
  shipment_id STRING,
  order_id STRING,
  region_id STRING,
  lane_id STRING,
  carrier_id STRING,
  promised_delivery_date DATE,
  actual_delivery_date DATE,
  delivered_complete BOOLEAN,
  exception_flag BOOLEAN,
  ship_date DATE,
  delivered_date DATE
);

SELECT
  period_label,
  COUNT(*) AS shipments,
  AVG(CASE WHEN actual_delivery_date <= promised_delivery_date THEN 1.0 ELSE 0.0 END) AS otd_rate,
  AVG(CASE WHEN delivered_complete = true AND actual_delivery_date <= promised_delivery_date THEN 1.0 ELSE 0.0 END) AS otc_rate
FROM (
  SELECT
    string">'analysis' AS period_label,
    *
  FROM ops.ops.shipment_delivery_fact
  WHERE region_id = string">'{region_id}'
    AND promised_delivery_date BETWEEN string">'{start_date}' AND string">'{end_date}'

  UNION ALL

  SELECT
    string">'baseline' AS period_label,
    *
  FROM ops.ops.shipment_delivery_fact
  WHERE region_id = string">'{region_id}'
    AND promised_delivery_date BETWEEN date_sub(string">'{start_date}', {baseline_window_days})
                                AND date_sub(string">'{start_date}', 1)
) x
GROUP BY period_label;
Source system: Transportation and customer operations exception logs  ·  Domain: Exception Management
Role in this workflow: This table supplies the exception-category evidence that explains why service levels changed, such as Late Linehaul or Customer Not Home events. It complements the shipment facts by showing whether the operational failure pattern shifted between the baseline and analysis windows. When exception rates rise materially, the workflow uses this table to support causal attribution and to map the issue to a concrete response playbook.
CREATE TABLE ops.ops.delivery_exception_fact (
  exception_id STRING,
  shipment_id STRING,
  region_id STRING,
  carrier_id STRING,
  lane_id STRING,
  exception_code STRING,
  exception_category STRING,
  exception_ts TIMESTAMP,
  resolved_flag BOOLEAN
);

WITH scoped_shipments AS (
  SELECT
    shipment_id,
    region_id,
    carrier_id,
    lane_id,
    promised_delivery_date,
    CASE
      WHEN promised_delivery_date BETWEEN string">'{start_date}' AND string">'{end_date}' THEN string">'analysis'
      WHEN promised_delivery_date BETWEEN date_sub(string">'{start_date}', {baseline_window_days}) AND date_sub(string">'{start_date}', 1) THEN string">'baseline'
      ELSE NULL
    END AS period_label
  FROM ops.ops.shipment_delivery_fact
  WHERE region_id = string">'{region_id}'
    AND (
      promised_delivery_date BETWEEN string">'{start_date}' AND string">'{end_date}'
      OR promised_delivery_date BETWEEN date_sub(string">'{start_date}', {baseline_window_days}) AND date_sub(string">'{start_date}', 1)
    )
), exc AS (
  SELECT
    s.period_label,
    COALESCE(e.exception_category, string">'No Exception') AS exception_category,
    COUNT(DISTINCT s.shipment_id) AS shipments
  FROM scoped_shipments s
  LEFT JOIN ops.ops.delivery_exception_fact e
    ON e.shipment_id = s.shipment_id
   AND e.region_id = s.region_id
  WHERE s.period_label IS NOT NULL
  GROUP BY s.period_label, COALESCE(e.exception_category, string">'No Exception')
), totals AS (
  SELECT period_label, SUM(shipments) AS total_shipments
  FROM exc
  GROUP BY period_label
)
SELECT
  e.period_label,
  e.exception_category,
  e.shipments,
  (e.shipments / t.total_shipments) AS exception_rate
FROM exc e
JOIN totals t
  ON e.period_label = t.period_label
ORDER BY e.period_label, exception_rate DESC;
Cognitive Labor Analysis

Where the Work Sits in the Labor Stack

Not all cognitive labor is equally automatable. The KWF analysis breaks the workflow into three layers — execution, judgment, and strategic — and maps each step to the layer it belongs to. Execution-layer work is automatable. Judgment and strategic work stays with the manager.

Execution 62% Judgment 33% Strategic 5%
Execution Layer
62%
The execution layer retrieves shipment and exception data, calculates baseline deltas, attributes material movement by carrier and lane, and formats the briefing artifact.
Judgment Layer
33%
The manager still interprets ambiguous drivers, decides which corrective actions fit the operating context, and answers stakeholder challenges or follow-up questions.
Strategic Layer
5%
Strategic decisions such as carrier governance, SLA policy changes, and longer-term lane design remain with leadership.
Value Model

The Business Case for Automation

Time Recovered
45.9% role time shifted
Estimated execution-layer time recovered for this workflow’s share of Delivery Operations Manager work.
Annual Savings
$885,344 net benefit
Planning-model annual net benefit for 4 impacted delivery operations leaders after $40,000 automation cost.
Strategic Upside
Faster Corrective Action
The main upside is reducing misdiagnosis so teams intervene on the right carriers, lanes, and exception patterns sooner.
Kill Question: Without this workflow, the manager falls back to manual dashboard review, spreadsheet cuts, and subjective narrative building across shipment, carrier, lane, and exception data. That usually means slower executive updates, inconsistent explanations across teams, and more ad-hoc requests to re-cut the same analysis before anyone agrees on what to do.

Primary Valuation Metric: % of weekly/monthly delivery performance reviews where the briefing is used as the single source of truth and stakeholders accept the top-3 drivers without additional ad-hoc data pulls.

Next Step

Run your own value estimate for delivery operations — or talk to us about your OTD driver attribution workflow.

The Cognitive Labor Value Calculator models team size, fully loaded role cost, and how much execution-layer work this workflow can absorb. It takes under two minutes to generate a planning estimate.