smartlinks blog

THE TRUCK THAT WAS ALREADY PAID FOR

21 Oct 2026

share

 

6:10 A.M., THE WESTERN PLANT

The phone buzzes before the alarm does.

Meera runs the dedicated fleet for a building-materials manufacturer: 180 trucks on long-term contract, each paid a fixed monthly charge whether it moves or not. The message is from the dispatch supervisor. “14 spot trucks booked for today. Rates up again.”

She opens the GPS dashboard. Twenty-two of her dedicated trucks are standing still. Some are at customer sites, some at a depot forty kilometers away, and two are parked at a roadside Dhaba where the drivers are waiting for someone to tell them where to go.

She is paying twice for the same tonne of cement: once for the truck that is idle, and again for the truck hired to do its job.

Meera is not short of technology. That is the strange part. Over four years the company did everything the transformation playbooks recommend: an ERP for orders and invoicing, a transport management system for trips and freight bills, GPS on every truck, fuel cards, a driver app for proof of delivery, and a BI-layer with a utilization dashboard that is reviewed every month, faithfully, and changes nothing.

So, the real question is not whether Meera has the right tools. It is this: if every system is live, why is the most expensive decision in the fleet still made by hand, and who is accountable for fixing it?

The answer is a role, not a product. The rest of this piece builds that answer from the top down.

The argument at a glance: one governing answer, three supporting arguments, and the implications for leaders.

 

ARGUMENT 1 OF 3 · WHY

The value leaks between systems, at the point of decision

The problem is not a missing system. Every tool Meera bought works. What is missing is anyone, or anything, responsible for the decision that sits between them.

Every system works. The decision does not.

Each system does exactly what it was bought to do. Each go-live was celebrated. And yet the most expensive decision in the fleet, which truck takes which load tomorrow, is still made at 10 p.m. by three planners with a spreadsheet, a WhatsApp group and about forty phone calls.

Figure 1. Every system is live. The most expensive decision is still made by hand at night.

We built systems of record, not systems of decision

I see this pattern again and again. We have built excellent systems of record. We have not built systems of decision. The value does not leak inside any one tool. It leaks in the gaps between them, where a tired person stitches five screens together at night and makes the safest choice rather than the best one.

Meera’s fleet is the industry in miniature

Leaders are losing patience with technology that does not pay back. Gartner reported in August 2026 that 55% of chief supply chain officers were unclear on the return from their AI investments. It is Meera’s six systems, told at industry scale.

That is why a seventh system would not fix it. The gap is not a missing capability; it is a missing owner. Meera needed someone who would come and stay.

 

ARGUMENT 2 OF 3 · WHO

The Supply Chain FDE is the role built to close that gap

Closing the gap takes one accountable person who understands the operation, can build on its data, and owns the result. That role now has a name, and the economics that make it viable have only just arrived.

Someone who comes to the customer, and stays

Arjun arrived on a Monday. No deck, no demo. He asked for three things: a chair in the dispatch room, read access to whatever data existed, and permission to ride along on a truck. He was what the industry now calls a Forward Deployed Engineer.

The role began at Palantir, which draws the distinction neatly: product engineers deliver one capability to many customers; forward deployed engineers deliver many capabilities to one customer. The FDE sits with the customer, builds on the customer’s real data, and is measured on the customer’s outcome, not on hours billed, modules configured or a go-live date. The AI labs have since adopted the model, and demand has followed: a Financial Times analysis of Indeed data found FDE job postings rose more than 800% between January and September 2025.

Three capabilities, one accountable person

A Supply Chain FDE is that role with deep domain roots. Three things must live in one accountable person, or one very tight pair:

  • Supply chain depth. Knowing why a dedicated truck’s fixed cost changes the maths of every allocation, why unloading time at a customer’s yard matters more than transit time, and why planners distrust any plan that ignores a driver’s rest day.
  • Engineering and AI build. The ability to pull data, model it, and put something working in front of users in days, not quarters.
  • Outcome ownership. Owning the number after the build: utilization, cost per tonne, service levels.

 Figure 2. The Supply Chain FDE sits where domain, build and value overlap.

Take away any one and you get a familiar role.

Table 1. How the Supply Chain FDE differs from the roles supply chain leaders already know.

Why the role is viable now

Two shifts have turned the FDE from a nice idea into a practical one.

AI has changed the economics of building. A custom optimizer, a data pipeline or a planner interface used to be a six-month project. Today a small team working alongside AI coding and reasoning tools can prototype one in days. The bottleneck has moved from can we build it to do we know what to build.

Value has moved from configuration to decisions. Module set-up, report building and interface mapping are being commoditized, increasingly by the software vendors’ own AI agents. What appreciates is judgement: which decision to improve, how to measure it, and how to get a planner to trust it.

 

ARGUMENT 3 OF 3 · HOW

A problem-first method turns the gap into measured, reusable value

The FDE’s edge is not a tool; it is the order of work. Understand the decision, frame it with a number, design the logic, and only then choose technology and build. Four rules make up the method, and Meera’s fleet shows each one at work.

The sequence follows design thinking, where the FDE’s work maps onto a loop of five stages, plus a sixth we have learned to add: productize.

 Figure 3. Design Thinking mapped to the FDE loop, with what each stage looked like at Meera’s fleet.

Rule 1. Start with the decision, not the brief

Arjun’s first week had no code in it. He sat in the dispatch room from 9 p.m. to 1 a.m. for four nights. He watched planners allocate orders from memory (“Raju’s trucks know that customer”), call drivers one by one to ask when they would be empty and hire a spot truck whenever a call went unanswered. He rode 600 kilometres with a driver, Suresh, and spent five hours of that trip waiting to unload at a customer’s yard that had no idea the truck was coming.

Three observations came out of that week. None of them was in the original brief.

  1. Nobody knew when a dedicated truck would be free. GPS showed where a truck was, not when it would be empty.
  2. The fixed cost was invisible at the moment of decision. On screen, a spot truck showed a trip rate and a dedicated truck showed nothing. So, the option that looked cheaper was often the more expensive one.
  3. Planners were rational, not careless. With a call unanswered at 11 p.m. and a customer who would escalate at 8 a.m., hiring a spot truck was the safe choice. The process punished risk and never rewarded utilization.

The brief Meera’s team had written said: “We need a control tower with live visibility.” It was a solution disguised as a problem. They already had live GPS. More visibility would have given the planners one more screen at 10 p.m.

Figure 4. From the brief as written, through the root causes, to a problem statement with a decision and a number.

Arjun and Meera rewrote it together over two sessions, and that rewrite turned out to be the most valuable work of the month:

Then they put a number on it. Using ninety days of trip and GPS history, they reconstructed every day: how many dedicated trucks sat idle for more than eight hours on a day a spot truck was hired for a load they could have carried. The leak was large enough that the CFO joined the next meeting. Not because of a slide, but because the number came from the company’s own data, and every day could be traced.

A good problem statement names the decision, the person who makes it, the constraints and the measure. Once you have those four, the technology choice becomes almost obvious.

Rule 2. Solve it on paper, and reuse before you build

Before touching any platform, Arjun solved the problem on a whiteboard and in a notebook, using real extracts with their defects left in. Solving on paper means designing the decision logic end to end, including where AI helps and where it does not, before choosing a single tool.

Figure 5. The paper solution: four AI jobs, a human checkpoint, and one rule that is deliberately not AI.

  • Predict. A model trained on the fleet’s own trip history estimates when each truck will be empty, including the five-hour unloading waits nobody had ever measured.
  • Read. A language model reads the driver WhatsApp messages and scanned trip sheets planners relied on, and turns “unloading done, heading to Kalol” into structured status.
  • Decide. An optimization model assigns tomorrow’s orders to trucks, treating the dedicated fleet’s cost as already paid, so a spot truck is chosen only when it truly wins.
  • Explain. A planner copilot shows why each assignment was made and what was traded off, in plain language. The planner can accept, change or reject it, and every change carries a reason that feeds back into the model.

And one deliberate non-AI element: “dedicated first” is a business policy, not a prediction. It is written as a hard rule, owned by Meera, not learned by a model. Knowing where not to use AI is part of the job.

By the end of week two, the paper solution ran as a rough prototype against the last ninety days. Replaying history showed how many spot hires it would have avoided. That replay became the business case.

Only then did technology come up, and the answer surprised the client. They did not need a new TMS, a control-tower module or another GPS vendor.

Figure 6. Each capability mapped across planning and execution, then marked reuse, extend or build.

Arjun mapped every capability the solution needed across the two worlds of supply chain technology: planning (tonight to next week) and execution (right now to end of day). For each one the question was simple. Does something already do this well? Reuse it. Does something do it partly? Extend it. Does nothing do it? Build it.

Most of the execution layer was already in place. The gap was a thin, sharp decision layer in planning, fleet allocation and return-time prediction, plus an exception agent connecting execution signals to someone who could act on them.

That is what tool-agnostic means in practice. The FDE is not loyal to a vendor; the FDE is loyal to the decision. Existing systems are sources of truth to connect, not walls to rebuild.

Rule 3. Build a thin decision layer, and earn adoption

Over the next six weeks the prototype became a product: a Dedicated Fleet Planner sitting on top of the systems the company already owned. 

Figure 7. The Dedicated Fleet Planner: five layers, with AI in each and no system of record replaced.

At the bottom, the systems of record stay as they are. Above them, a fleet data model (trucks, drivers, trips, lanes, orders, customer sites) gives every system a shared language. The decision layer holds the ETA model, the optimizer, the exception agent and the copilot. The action layer is where people work: a nightly plan screen for planners, a WhatsApp bot that tells each driver tomorrow’s first load before they sleep, and alerts to site managers when a truck is about to wait more than two hours.

The build was the easy part. Adoption was the real work. In the first week of go-live, planners overrode four plans in ten. Arjun did not argue; he read every override reason. Half were constraints nobody had written down: a customer that accepts trucks only before noon, a driver whose village lies on the route. Each became a rule. By week four, overrides were below one in ten, and the planners had started calling it “our plan”. That is the only adoption metric that really matters.

Rule 4. Prove the value, then productize it

Figure 8. Twelve weeks on, measured against a baseline agreed with finance before the build (illustrative) after FDE walked into the dispatch room.

How the numbers were measured matters as much as the numbers. The baseline was agreed with finance before the build, and the same replay method that sized the problem proved the result. Value-driven delivery means the measure is defined before the solution, not reverse-engineered after it.

And Meera’s 6:10 a.m. messages?  Mostly, they stopped.

Proof for one customer is where bespoke consulting stops. It is where the FDE model keeps going. A good FDE is deliberately over-fitted to the first customer and then disciplined about what goes back to product.

Figure 9. What moves into the product, what becomes configuration, and what is deleted.

When the same pattern showed up at other dedicated fleets, the work sorted itself into three buckets. The core (the fleet data model, the ETA model, the optimizer, the copilot) was reused as is. The configurable parts (cost terms, site windows, driver-hour policies) became settings, not code. The scaffolding (a custom import for a paper maintenance register, one-off scripts) was labelled and deleted.

That is the productization of solutions: every deployment makes the product better, and every new customer starts closer to value. It is also where AI enablement in every aspect becomes real. Not a chatbot bolted onto a screen, but AI inside each step: reading, predicting, deciding, explaining, and increasingly acting within guardrails the business sets.

 
 

SO WHAT · THE IMPLICATIONS

What supply chain leaders should do next

If value leaks at the decision, and an accountable builder can close the gap, then supply chain technology must be funded, staffed and measured differently. Five shifts follow, and every reader has a first move.

Table 2. Five shifts every supply chain leader should plan for.

Table 2. Five shifts every supply chain leader should plan for.

TWELVE WEEKS LATER

I asked Meera what had changed. She did not mention the optimizer, or the AI.

That is the job of a Supply Chain FDE. Not more systems, but more value from the ones you already have, and a new product when nothing else will do.

 

About this story

Meera, Arjun, Suresh and the manufacturer are a composite drawn from dedicated-fleet engagements; names are changed and the figures in Figure 8 and the adoption section are illustrative.

Market references: Palantir on product versus forward deployed engineering; FDE postings growth from a Financial Times analysis of Indeed data, as reported by Fast Company (5 November 2025); Gartner survey of chief supply chain officers on AI ROI (August 2026).

SHYAM KUMAR N S SUPPLY CHAIN CONSULTANT

Author

We work faster than
you can even imagine

WhatsApp