By C B Mishra • Strategic Technical Project Manager
There is a number that every supply chain director in a product company cares about more than almost any other: cost per shipment. Not gross transportation spend — that’s a budget line. Cost per shipment is an operational metric. It tells you how efficiently your logistics infrastructure converts orders into deliveries.
In 2023, I delivered an Odoo ERP implementation for a mid-size manufacturing and distribution company whose cost per shipment was not just high — it was unpredictable. Same route, same carrier, same product weight. Different cost every week. No one in the organisation could explain why. The logistics team had built their entire carrier selection process on intuition, historical relationships, and a spreadsheet that hadn’t been updated in 14 months.
By the end of the engagement, we had reduced transportation costs by 28% — not through carrier renegotiation, not through volume-based discounting, and not through any change to the physical logistics network. We did it entirely through algorithm-driven carrier selection, route optimisation, and shipment consolidation logic built inside Odoo’s supply chain module and extended with custom Python logic and live carrier API integrations.
This blog is the complete technical and strategic account of how we did it — every algorithm, every data model decision, every integration pattern, and every lesson from the implementation. It is the most quantitatively dense and operationally specific blog in this series, because logistics optimisation is a domain where the details are the discipline.
| 📌 Scope of this blog: The specific implementation was on Odoo 16 with custom modules, DHL Express and Shiprocket API integrations, and a Python-based optimisation layer. The algorithms and principles are platform-agnostic — applicable to any ERP or logistics platform. All cost figures are indexed (28% reduction is the actual number; absolute values are anonymised by client agreement). |
1. Diagnosing the Problem: Why Most Logistics Cost Problems Are Information Problems
The first thing I do on any logistics-related engagement is a cost attribution audit. Not a carrier renegotiation conversation, not a rate card review — an audit of where shipment cost decisions are actually made and what data those decisions are based on. In every case I have encountered, the root cause of excessive logistics costs is not the carrier contracts. It is the decision-making process that selects carriers and routes.
For this client, the audit revealed four specific failure modes in their existing process:
- Manual carrier selection by shipping clerk: The person processing each shipment chose the carrier based on familiarity and recency bias — whichever carrier they had used last, or whichever account manager they had spoken to most recently. There was no rate comparison at point of selection.
- No shipment consolidation logic: Orders going to the same postcode zone on the same day were shipped separately because each order was processed independently, immediately after it was confirmed. Consolidation would have reduced shipment count and carrier cost by an estimated 18% on its own.
- Static rate assumptions: The rate cards used for cost estimation were updated quarterly. Carrier rates fluctuate weekly based on fuel surcharges, peak surcharges, and dimensional weight adjustments. The company was making carrier decisions against rate data that was 2–12 weeks stale.
- No delivery performance feedback loop: The carrier selection process had no input from delivery performance data. A carrier with a 23% late delivery rate in a specific zone was being selected as frequently as a carrier with a 4% late delivery rate in the same zone, because no one had connected the delivery confirmation data to the carrier selection workflow.
| 📖 The number that crystallised the problem: During the audit, I asked the logistics manager what the average cost difference between their cheapest and most expensive carrier for a standard 5kg B2B shipment to Delhi was. She didn’t know. We pulled the data. The range was ₹340 to ₹1,240 for functionally equivalent transit times. The company had been shipping at ₹1,240 on roughly 30% of those shipments, not because the expensive carrier was better — but because the selection process had no cost comparison step. |
The Baseline Measurement Framework
Before any optimisation, you must establish a measurement baseline. You cannot manage what you cannot measure, and you cannot demonstrate savings without a pre-intervention benchmark. Here is the baseline measurement framework I established:
| Metric | How Calculated | Baseline (Pre-Optimisation) | Target |
| Cost per shipment | Total logistics spend ÷ total shipments (30-day rolling) | ₹847 average | ₹640 or below |
| Carrier selection spread | Std deviation of cost per shipment on equivalent routes | High (₹340–₹1,240) | Low (±15% of optimal rate) |
| Consolidation rate | % of orders shipped in consolidated loads | 12% | 35%+ |
| Rate data freshness | Average age of rate cards used in selection decisions | 47 days | Real-time (API-fetched) |
| Delivery performance input | % of carrier selection decisions informed by delivery data | 0% | 100% |
| Zone-level cost variance | Cost variance for same-weight shipments to same zone | High — no control | Within ±8% of optimal |
These metrics became the project dashboard. Every optimisation algorithm we built was evaluated against its impact on one or more of these numbers. This discipline — defining the metrics before building the solution — is what allowed us to demonstrate the 28% saving with precision at the end of the engagement.
2. The Architecture: Four Layers of Logistics Optimisation in Odoo
The optimisation system we built has four distinct layers, each addressing a different dimension of the cost problem. The 28% saving is the cumulative effect of all four layers operating simultaneously. Each layer individually produced a measurable but smaller saving. The combination produced a compounding effect that exceeded what any single intervention would have achieved.
| Optimisation Layer | Problem It Solves | Individual Saving Contribution |
| Layer 1: Real-Time Carrier Rate Fetching | Stale rate data driving suboptimal carrier selection | ~8% cost reduction |
| Layer 2: Algorithm-Driven Carrier Selection | Manual, bias-driven carrier choice | ~10% cost reduction |
| Layer 3: Shipment Consolidation Engine | Individual order processing preventing load optimisation | ~7% cost reduction |
| Layer 4: Zone-Level Performance Scoring | No delivery feedback loop in carrier selection | ~3% cost reduction + service quality improvement |
These contributions are approximate and context-dependent — the relative impact of each layer varies by industry, order volume, and geographic distribution. The principle that the savings compound across layers is consistent across every logistics optimisation engagement I have run.
3. Layer 1 — Real-Time Carrier Rate Fetching: Eliminating the Stale Rate Problem
The foundation of any carrier selection algorithm is the rate data it operates on. An algorithm selecting from stale rates is not an optimisation system — it is a formalised version of the same biased decision-making it is supposed to replace. Real-time rate fetching was therefore the first layer we built, before any selection logic existed.
The Integration Architecture
We integrated three carrier APIs — DHL Express, Shiprocket (which aggregates rates from Blue Dart, DTDC, Ekart, Shadowfax, and others), and a regional 3PL — using a unified rate fetching service built as a custom Odoo module. The service exposed a single internal Python method: `get_available_rates(shipment_params)` which returned a normalised rate list regardless of which carrier was being queried.
| Carrier / API | Rate Types Fetched | Update Frequency |
| DHL Express API | Express, Economy, Domestic Priority — per weight/zone | On-demand per shipment |
| Shiprocket Rate API | 6 carriers aggregated — surface, air, COD variants | On-demand per shipment |
| Regional 3PL (custom) | Fixed zone-weight matrix via REST API | Daily cache refresh |
| Fuel surcharge feeds | DHL + Shiprocket surcharge endpoints | Weekly batch refresh |
| Dimensional weight calc | Internal: L×W×H ÷ 5000 vs actual weight, higher used | Computed at shipment creation |
The Rate Normalisation Schema
Different carrier APIs return rate data in different formats, currencies, and charge structures. DHL returns a base rate plus surcharges as separate line items. Shiprocket returns an all-inclusive rate. The regional 3PL returns rates in a proprietary zone code format. Without normalisation, these rates cannot be compared. Our normalisation schema converted every carrier’s rate response into a standard structure:
- carrier_id: Internal carrier identifier
- service_level: standard, express, economy, same_day
- base_rate: Numeric, in INR, inclusive of all quoted surcharges
- fuel_surcharge_included: Boolean — whether fuel surcharge is in base_rate or separate
- estimated_transit_days: Carrier-quoted transit time in business days
- zone_code: Normalised internal zone identifier (not carrier-specific)
- dimensional_weight_applied: Boolean — whether DIM weight was higher than actual
- quoted_at_timestamp: UTC timestamp of rate fetch — rate validity window varies by carrier
- rate_expiry_seconds: How long the fetched rate is valid before a re-fetch is required
The rate_expiry_seconds field was critical. DHL rates expire in 10 minutes. Shiprocket rates expire in 60 minutes. The regional 3PL’s cached rates were valid for 24 hours. Without tracking expiry, a rate fetched at 9 AM could be used to make a carrier selection at 4 PM — against a rate that had changed three times during the day. Every rate comparison query checked expiry before using a cached rate.
| 💡 Rate caching principle: Fetch rates on-demand per shipment at selection time. Cache only with explicit expiry tracking. Never use a cached rate beyond its expiry window. The 10-minute overhead of a DHL rate fetch is 10 minutes well spent if the alternative is making a ₹400 carrier selection decision against 3-hour-old data. |
4. Layer 2 — The Carrier Selection Algorithm: From Gut Feel to Optimised Logic
With real-time rates available, the next layer is the selection algorithm — the logic that takes all available rates for a given shipment and selects the optimal carrier. ‘Optimal’ is never simply ‘cheapest.’ A carrier that is 15% cheaper but has a 35% late delivery rate to a specific zone is not optimal for a B2B client with contractual SLA obligations. The selection algorithm must balance cost against service quality.
The Multi-Factor Scoring Model
We built a weighted scoring model that evaluated each available carrier on four dimensions for each shipment. The weights were calibrated against the client’s specific business priorities — a different client with different SLA obligations would use different weights:
| Scoring Factor | Weight | Data Source | Calculation |
| Rate (cost) | 50% | Real-time API rate fetch | Normalised: lowest rate = 100, others proportionally lower |
| Transit time | 25% | Carrier API + historical actuals | SLA-relative: meets SLA = 100, each day over = -20 points |
| Zone delivery performance | 15% | Historical delivery data in Odoo | On-time rate for this carrier in this zone (90-day rolling) |
| Carrier reliability | 10% | Shiprocket dashboard + DHL account | Pickup success rate × invoice accuracy rate (90-day rolling) |
The composite score for each carrier is: (Rate × 0.50) + (Transit × 0.25) + (Zone Performance × 0.15) + (Reliability × 0.10). The carrier with the highest composite score is selected. If two carriers score within 5 points of each other, the lower-cost carrier is preferred as a tiebreaker.
The Zone Performance Data Model in Odoo
The zone delivery performance score required a data model that didn’t exist in stock Odoo — a carrier performance ledger tracking actual delivery outcomes per carrier per zone. We built this as a custom Odoo model: `logistics.carrier.zone.performance` with fields for carrier_id, zone_code, shipment_date, promised_delivery_date, actual_delivery_date, delivery_status (on_time, late, failed, returned), and failure_reason.
Every outbound shipment created a performance record at dispatch. Every delivery confirmation — pulled via DHL webhook and Shiprocket webhook — updated the actual_delivery_date and status. The 90-day rolling on-time rate was computed as a SQL view — refreshed every 6 hours — rather than computed on every carrier selection query. This kept selection-time query performance below 200ms even as the performance ledger grew to hundreds of thousands of records.
The Algorithm in Practice: A Worked Example
To make the algorithm concrete, here is a real selection scenario: a 3kg B2B shipment from Mumbai to a Tier-2 city in Gujarat, SLA of 3 business days.
| Carrier | Rate (INR) | Transit (days) | Zone On-Time Rate | Composite Score |
| DHL Economy | ₹520 | 2 days | 94% | 87.4 — Selected |
| Shiprocket (Blue Dart) | ₹480 | 3 days | 88% | 82.1 |
| Shiprocket (Ekart) | ₹310 | 4 days | 71% | 64.8 |
| Regional 3PL | ₹620 | 2 days | 91% | 82.8 |
DHL Economy wins despite not being the cheapest option (Ekart is ₹210 cheaper). The transit time penalty (Ekart’s 4 days exceeds the 3-day SLA) and the lower zone on-time rate (71% vs 94%) produce a composite score that makes DHL the optimal selection. Without the algorithm, a cost-optimising shipping clerk might have selected Ekart — saving ₹210 on the shipment while creating a high probability of SLA breach and the associated customer service cost.
5. Layer 3 — The Shipment Consolidation Engine: The Highest-Leverage Optimisation
Carrier selection optimises the cost of each individual shipment. Consolidation optimisation reduces the number of shipments. For our client, consolidation had the highest leverage of any single intervention — because a consolidated shipment doesn’t just cost less per unit, it eliminates the fixed costs (fuel surcharges, pickup fees, documentation) of shipments that should never have existed as separate entities.
The Consolidation Logic: What Qualifies for Consolidation
Not every order can be consolidated with every other order. Our consolidation engine evaluated five criteria before merging orders into a consolidated shipment:
- Same destination zone: Orders going to the same carrier zone (not necessarily the same address — zone-level consolidation is sufficient for most carriers’ weight-break pricing)
- Compatible shipment window: Orders confirmed within the same consolidation window. We used a 4-hour window — orders confirmed between 8 AM and 12 PM were evaluated for consolidation together before dispatch at 2 PM. A second window from 12 PM to 4 PM dispatched at 6 PM.
- Total weight within carrier weight breaks: Consolidated shipment weight must not exceed the boundary of a carrier’s next weight break tier. Consolidating two 5kg shipments into one 10kg shipment is cost-effective only if the 10kg rate is less than 2× the 5kg rate.
- Compatible product categories: Hazardous goods, refrigerated products, and high-value items were excluded from consolidation with standard goods.
- No conflicting delivery SLAs: If one order has a same-day SLA and another has a 3-day SLA, consolidating them forces the same-day carrier on the lower-urgency shipment, eliminating the cost saving.
The Weight Break Optimisation Algorithm
Carrier rate cards are not linear — they are stepped. A 5kg shipment costs more than 2× a 2.5kg shipment. A 10kg shipment costs less than 2× a 5kg shipment. Understanding where the weight break savings occur and building orders toward those break points — rather than away from them — is the core of weight-aware consolidation.
We built a weight break optimisation function that, given a set of consolidation candidates and a carrier’s weight break schedule, computed the optimal combination of orders to maximise weight break savings without creating consolidated shipments that crossed into higher-cost weight tiers. This is a variant of the bin-packing problem — NP-hard in the general case, but solvable with acceptable accuracy using a greedy heuristic for the order volumes our client handled.
| 📖 The consolidation discovery that changed the scope: During baseline measurement, we found that 34% of the client’s outbound shipments to Delhi NCR were going to within 15km of each other on the same day, processed as separate shipments averaging 2.8kg each. Consolidating these into 4–6 shipment batches pushed the average consolidated weight to 8–12kg — directly into a carrier weight break that reduced the per-kg rate by 22%. The saving on Delhi NCR shipments alone was larger than our entire project fee. This is why baseline measurement precedes algorithm design. |
The Consolidation Holding Queue in Odoo
The consolidation engine required a ‘holding queue’ — a state between order confirmation and shipment dispatch where orders awaiting consolidation partners could be grouped. We built this as a custom Odoo workflow state: `consolidation_pending` — separate from the standard `ready_to_ship` state.
Orders entered `consolidation_pending` on confirmation. A scheduled Odoo server action ran at the end of each consolidation window (12 PM and 6 PM), evaluated all pending orders against the consolidation criteria, grouped qualifying orders, and created consolidated picking records in Odoo’s inventory module. The maximum holding time was configurable per product category — perishables had a 2-hour maximum; standard goods had a 4-hour maximum; slow-moving stock could hold for 8 hours if a consolidation partner was likely to appear.
| ⚠️ The consolidation risk that must be managed: Holding orders for consolidation creates a delivery time trade-off. An order confirmed at 8:01 AM waits until the 2 PM dispatch window — a 6-hour hold. For B2C customers expecting same-day processing confirmation, this creates a service quality issue even if the delivery date is not affected. We addressed this by sending automated ‘your order is being prepared for dispatch’ notifications at confirmation, with expected dispatch time displayed explicitly. Customer service tickets related to order processing delays dropped to near zero within two weeks. |
6. Layer 4 — Zone-Level Performance Scoring: Closing the Feedback Loop
The first three layers optimise cost at the point of shipment creation. Layer 4 optimises the carrier selection algorithm itself over time — by feeding real delivery outcome data back into the selection weights. Without this feedback loop, the algorithm is static. It selects carriers based on their historical performance but never updates those performance scores with new data. A carrier that degrades over a quarter remains in the selection pool at its original performance score.
The Performance Data Pipeline
We built a delivery outcome pipeline with three data sources:
- DHL Tracking Webhook: DHL pushes delivery status events to our webhook endpoint — picked up, in transit, out for delivery, delivered, failed delivery attempt. Each event updated the corresponding `logistics.carrier.zone.performance` record in real time.
- Shiprocket Tracking API: Shiprocket’s tracking API was polled hourly for active shipments (DHL webhook was not available through the Shiprocket aggregation layer for all carriers). Status updates from the poll updated the performance ledger.
- Customer Confirmation: For high-value B2B shipments, delivery confirmation was required from the customer via a confirmation link in the delivery email. Customer-confirmed delivery date was stored separately from carrier-reported delivery date — the delta between them captured carrier reporting accuracy.
The Performance Score Decay Model
Carrier performance is not static, and historical performance should be weighted toward the recent past. A carrier that had a terrible Q1 but has significantly improved in Q2 should not be penalised for Q1 indefinitely. We implemented an exponential decay weighting for the 90-day rolling on-time rate: deliveries in the last 30 days were weighted at 100%, deliveries in days 31–60 at 60%, and deliveries in days 61–90 at 30%.
This decay model was calibrated against the client’s business cycle — quarterly carrier performance reviews meant that a 90-day window with decay weighting toward recent data closely matched the intervals at which carrier account managers were renegotiating terms. The algorithm’s carrier preference and the commercial team’s carrier relationships moved in the same direction, rather than working against each other.
The Zone Blackout Mechanism
When a carrier’s zone on-time rate dropped below a configurable threshold (we set 65% as the default blackout trigger), the carrier was automatically removed from the selection pool for that zone and an alert was sent to the logistics manager. The carrier blackout was zone-specific, not carrier-wide — a carrier that was underperforming in Gujarat but performing well in Maharashtra was not penalised on Maharashtra shipments. This nuance prevented the algorithm from over-reacting to localised carrier problems.
The logistics manager could review and override any blackout with a documented justification — this was essential for preserving the commercial relationship with carriers during temporary performance dips. The override was logged, time-limited (7 days maximum before automatic review), and included in the monthly logistics performance report sent to the supply chain director.
7. The Odoo Implementation: Custom Module Architecture
All four optimisation layers were implemented as a single custom Odoo module: `logistics_optimisation`. The module extended Odoo’s core `stock.picking` (picking/shipment) and `delivery.carrier` (carrier configuration) models without modifying core Odoo code — all extension was done via Odoo’s inheritance mechanism, preserving upgrade compatibility.
The Custom Data Models
| Model Name | Extends | Purpose |
| `logistics.rate.cache` | New model | Stores fetched carrier rates with expiry timestamps |
| `logistics.carrier.zone.performance` | New model | Performance ledger: one record per shipment delivery outcome |
| `logistics.carrier.scoring` | New model | Computed composite scores per carrier per zone (refreshed 6-hourly) |
| `logistics.consolidation.group` | New model | Groups orders in consolidation_pending state within a dispatch window |
| `stock.picking` | Extended | Added: consolidation_state, composite_score, selected_carrier_rationale fields |
| `delivery.carrier` | Extended | Added: zone_blackout_threshold, scoring_weight overrides, API config fields |
The Scheduled Actions That Run the Engine
| Scheduled Action | Frequency | What It Does | Failure Handling |
| Rate cache cleanup | Every 15 min | Purges expired rate records from cache | Silent — stale entries expire naturally |
| Performance score refresh | Every 6 hours | Recomputes carrier scoring SQL views | Alert if computation > 5 min (data integrity check) |
| Consolidation window close | 12 PM & 6 PM daily | Groups pending orders, creates consolidated pickings | Alert logistics manager if any pending orders unprocessed |
| Zone blackout check | Daily at 7 AM | Evaluates 7-day on-time rates, applies/lifts blackouts | Sends blackout report to supply chain director |
| Carrier API health check | Every 30 min | Pings carrier rate endpoints; flags degraded APIs | Falls back to cached rates + alert; never blocks shipment creation |
The carrier API health check and its fallback logic were among the most important reliability decisions in the implementation. If DHL’s rate API was down, we could not block shipment creation — orders still needed to ship. The fallback used the most recent non-expired cached rate with a ‘rate approximate’ flag on the picking record. The logistics manager was alerted to review any ‘rate approximate’ shipments before final carrier confirmation.
8. The Results: Where the 28% Came From
Six months after go-live, we conducted the post-implementation audit against the baseline metrics established in Section 1. Here is the complete results picture:
| Metric | Before | After (6 months) | Change |
| Average cost per shipment | ₹847 | ₹610 | −28.0% |
| Carrier selection spread | ₹900 range | ₹180 range | −80% |
| Consolidation rate | 12% | 38% | +26pp |
| Rate data age at selection | 47 days | < 10 min | −99.6% |
| Zone on-time delivery rate | 81% | 91% | +10pp |
| Carrier API-informed decisions | 0% | 100% | +100pp |
| Shipping clerk decision time | ~8 min | ~45 sec | −90.6% |
| Logistics team escalations/week | 14 avg | 3 avg | −78.6% |
The 28% cost reduction compounded across shipment volume to produce a significant annual saving. The ROI on the development investment was achieved in under 4 months of production operation. The secondary metrics tell an equally important story: decision time dropped from 8 minutes to 45 seconds (the algorithm presents a ranked carrier list; the clerk clicks confirm), escalations fell by 78%, and the delivery on-time rate improved by 10 percentage points despite the cost reduction — because the algorithm was selecting carriers for both cost and performance, not trading one for the other.
| ✅ The metric that surprised the client most: carrier selection spread collapsed from a ₹900 range to a ₹180 range. This meant the cost variance between the best and worst carrier choices for equivalent shipments dropped by 80%. The supply chain director described this as ‘turning a chaotic process into a predictable one.’ Cost predictability was, in hindsight, as valuable to the business as the absolute cost reduction — because predictable logistics costs allow accurate product pricing, which flows directly into margin control. |
9. Applying This Framework: What You Need Before You Can Build It
The logistics optimisation system I’ve described is sophisticated — but it is not uniquely complex. The algorithms are standard. The Odoo extensions are well within the capability of a competent Odoo developer. The barrier to building this is not technical. It is data quality. Every layer of the system depends on historical data that most companies discover they don’t have in usable form until they try to build something like this.
The Data Readiness Assessment
Before scoping any logistics optimisation project, I run a data readiness assessment. Here is what I check:
| Data Requirement | Why It’s Needed | Common Gap Found |
| Historical shipment records with carrier, route, cost, weight, date | Baseline measurement; algorithm training data | Available in ERP but not linked to delivery outcomes |
| Delivery confirmation dates by shipment | Zone on-time rate calculation | Available from carrier portal but never imported into ERP |
| Weight and dimensions per SKU | Dimensional weight calculation; weight break optimisation | Weight recorded; dimensions absent in 60%+ of clients |
| Carrier zone mapping | Zone-level performance attribution | Clients use carrier zone codes; no internal normalisation |
| Order confirmation timestamps | Consolidation window membership | Date only — time not recorded. Blocks 4-hour window logic |
| Carrier rate cards (historical) | Rate freshness calculation; baseline cost reconstruction | Available as PDFs; not structured data |
The most common blocking gap: delivery confirmation dates exist in the carrier’s portal but have never been systematically imported into the ERP. This single gap makes Layer 4 (zone performance scoring) impossible to build until it is resolved. I always run a 2–4 week data remediation sprint before the algorithm implementation sprint begins.
The Implementation Sequence
- Data remediation (2–4 weeks): Import historical delivery outcomes, enrich SKU data with dimensions, normalise zone codes, structure rate card data. No algorithm work until this is complete.
- Carrier API integration (2–3 weeks): Build the unified rate fetching service with normalisation schema and expiry tracking. Test in sandbox against all carrier APIs.
- Baseline measurement (1 week): Run the measurement framework against current data. Establish the benchmark numbers that will validate the final results.
- Algorithm implementation (3–4 weeks): Build scoring model, consolidation engine, and performance ledger as Odoo custom module.
- Parallel run (2 weeks): Algorithm runs alongside existing manual process. Compare algorithm selections against manual selections. Calibrate scoring weights.
- Go-live and monitoring (ongoing): Algorithm takes over carrier selection. Weekly review of zone performance scores. Monthly calibration of scoring weights against new outcome data.
| 🎯 The parallel run is non-negotiable. The algorithm must be proven against real shipments before it takes over carrier selection. In the parallel run for this project, the algorithm outperformed manual selection on cost in 73% of shipments in the first week, and 89% by Week 2. The 11% of shipments where manual selection was better became calibration data for the scoring weights. Two weeks of parallel run data improved the algorithm’s accuracy more than any amount of theoretical weight tuning would have. |
Final Thoughts: The 28% Is Not the Interesting Number
The 28% transportation cost reduction is the headline. It is the number that appeared in the executive summary and the number that justified the project investment. But the more interesting number, to me, is the 90% reduction in decision time per shipment — from 8 minutes to 45 seconds.
That number represents the elimination of a cognitive load that the logistics team carried silently every working day. Before the system, every shipment required a person to make a carrier comparison judgement under time pressure, with incomplete information, against rate data they couldn’t fully trust. That is not a job — it is a systematic stress generator. After the system, the same person reviews an algorithm-generated recommendation, checks the rationale, and confirms. The judgement is still theirs. The research is the algorithm’s.
This is, ultimately, what enterprise software optimisation is about at its best: not replacing human judgment, but giving it better inputs. The algorithm has no commercial relationships to protect, no recent bad experience to overcorrect for, no rate card that’s been sitting in a folder since last quarter. It just computes the optimal answer against the current data. The human then decides whether to take it. In 94% of cases, they did. In the 6% where they didn’t, they were usually right — because they had information the algorithm didn’t have access to.
That 6% is not a failure of the system. It is the system working correctly — preserving human judgment for the cases where human judgment adds value that structured data cannot capture.
C B Mishra | Strategic Technical Project Manager | cbmishra.com
Available for Odoo ERP implementation, supply chain optimisation, and logistics architecture consulting • Book a call