Case Study: Logistics Client Losing Money on Deliveries

A client who has already chosen the fix

When a client tells you exactly what to build, should you build it? Often, yes. The interesting cases are the ones where the thing they asked for would work and still leave them losing money. A logistics client is losing money on deliveries, and you have to find the root cause from the data it already has: Ophy's Palantir guide and Aced's list of candidate-reported questions both carry a version of this decomposition prompt (Ophy's Palantir interview guide, Aced's Palantir FDE guide). Those are second-hand reports and the exact wording varies.

The fictional version below adds the detail that makes the prompt hard: the client has already decided what it wants to buy. All numbers are made up for this lesson.

Fernway Freight, a fictional regional carrier, runs three depots and about 140 vans delivering for some 60 business customers. Last quarter it lost an average of €40,000 a month on roughly €1.2M of monthly delivery revenue. The operations director says: "Our routes are a mess. We need a route optimizer. Can you build one?"

The client named a solution. The interviewer wants to see whether you build it or check first, and whether you can check first without leaving the operations director feeling overruled.

Where does the €40,000 actually go?

The literal ask is a routing optimizer. What the director needs is to stop losing €40,000 a month. A routing optimizer is one hypothesis about where that money goes, the one most visible from the dispatch office. It might be right. It might also address a small slice of the loss while the large slice sits in pricing, failed deliveries or one unprofitable contract, all of which would look like "our routes are a mess" from the dispatch office.

Losing money also has two sides. Margin is revenue minus cost, and a cost-only investigation never notices a customer whose contract price is below the cost of serving them. So the first move is to turn the complaint into a cost model that can be broken down along the dimensions the business controls, with revenue in it from the start.

A strong opening, said aloud: "I'd like to find out where the €40,000 goes before choosing a fix. If routing is the biggest controllable loss, I'll build toward the optimizer. Can I ask what data you keep on each delivery attempt?" Those three sentences respect the director's hypothesis, commit to testing it, and ask for data in the vocabulary of the business.

Costing every delivery attempt

The unit of analysis is one delivery attempt. Each attempt has revenue, which is zero for a failed attempt under most contracts, and a cost: driver time at the stop plus a share of drive time on the route, fuel, and a vehicle cost per kilometre. Allocating route-level driver and fuel cost to individual stops is a modelling choice, and more than one rule is defensible (by time at stop, by distance, or evenly). Pick one and say which, because when someone disputes a number later you want the argument to be about the rule.

With attempts costed, the loss can be cut four ways. Each cut answers a different question and needs slightly different data.

Which of these does the client already record? The candidate asks, and Fernway turns out to have quite a lot: route logs from its telematics provider, fuel-card transactions, an attempt table with outcome and a driver-entered failure reason, and contract rates in the billing system. A first pass at the per-customer cut fits in one Postgres query (the FILTER clause is Postgres syntax), assuming an attempts table already carries allocated costs.

SELECT c.customer_name,
       COUNT(*) FILTER (WHERE a.outcome = 'delivered') AS delivered,
       COUNT(*) FILTER (WHERE a.outcome = 'failed')    AS failed,
       SUM(a.revenue)                                  AS revenue,
       SUM(a.driver_cost + a.fuel_cost)                AS direct_cost,
       SUM(a.revenue - a.driver_cost - a.fuel_cost)    AS margin
FROM attempts a
JOIN customers c ON c.customer_id = a.customer_id
WHERE a.attempted_at >= DATE '2026-07-01'
  AND a.attempted_at <  DATE '2026-10-01'
GROUP BY c.customer_name
ORDER BY margin;

The most negative margins sort to the top. With about 60 customers, it fits on one screen.

One furniture contract and half the failures

The candidate had planned to start with the per-route cut, since that is where the director suspects the problem. Before drawing it, they ask about failed deliveries, and the interviewer reveals: "About 4 percent of all attempts fail. Half of all failures come from one customer, a furniture retailer. Its contract pays a flat €14 per completed delivery and nothing for failed attempts."

Now run the numbers, still made up. Fernway makes about 60,000 attempts a month, so 4 percent is 2,400 failures, and the retailer accounts for 1,200 of them. Say the retailer gets 6,000 completed deliveries a month, so it generates 7,200 attempts, and one in six fails. Bulky two-person deliveries cost about €16 per attempt.

That one contract explains €31,200 of the €40,000 monthly loss, which is 78 percent. Look at its shape: the contract is priced below the cost of completing a delivery even before failures, and the failures make it worse. A routing optimizer would have to cut the cost of these bulky deliveries by an eighth (€2 of €16) just to break even on the successful ones, and it would do nothing about the 1,200 failed attempts.

The candidate says so plainly: "Then I'd change the plan. A routing optimizer could shave some cost per stop across all customers, but it can't fix a contract that loses €2 on every successful delivery and €16 on every failed one. The largest controllable loss is this contract and its failure rate. I'd take that to the director first, and keep routing as the second investigation."

One more check comes before trusting the story, and it concerns the failure reasons themselves. If drivers mostly choose "other" from the dropdown, the reason codes need fixing before anyone relies on them. In that case a sample of the retailer's failures can be checked against delivery-window data instead: were customers told a window, and did the van arrive inside it?

A four-week pilot with a comparison depot

The pilot makes two changes for the retailer's deliveries, run on a few routes from one depot for four weeks. The first is to confirm the delivery window with the end customer the day before, by text, with an option to reschedule. The second is to give the director a costed case for repricing the contract or adding a failed-attempt fee at renewal. These are different kinds of work. The text confirmation is an operational test Fernway can run without the retailer's permission, while the repricing is a commercial conversation the FDE supports with numbers and does not lead.

How would you know the texts worked? Failure rates can move with season or demand, so a before-and-after comparison on its own might credit the pilot with a seasonal dip. Use the same routes' last eight weeks as the "before", and the retailer's deliveries from another depot over the same four weeks as a comparison group. Success is a failure rate on pilot routes clearly below one in six, and the value per failed attempt avoided (€16 each) makes the result easy to report: every 100 failures avoided is €1,600.

After that, the per-route and per-driver cuts on the remaining €8,800 a month decide whether the optimizer is worth building. The director still gets an answer to the original question. It just arrives second, behind the one that was costing more.

Why the optimizer is the tempting first move

Building a routing optimizer before establishing where the money is lost is the failure this prompt is designed around. It is attractive for honest reasons: it is a real engineering problem, the client asked for it, and it demos well. On this brief it would have spent weeks attacking at most the €8,800 not explained by the retailer contract, and the director would still be losing money. On the rubric, that costs "data reasoning" (the loss was never decomposed) and "scoping" (the largest build was picked instead of the largest loss). It also misses the end user, whose real decision is what to fix first with limited people, a question an optimizer does not answer.

Two quieter failures sit nearby. A cost-only view, without contract revenue per attempt, finds expensive routes and never notices the underpriced customer whose deliveries fill them. Trusting driver-entered reason codes without a look is the other: if 70 percent of failures say "other", the per-reason breakdown is an artefact of the form, and building on it repeats that artefact at scale.

How this shows up in the interview

Per the research file, Palantir's decomposition round is reported as 60 minutes on a whiteboard with minimal code. Its reported rubric is structured breakdown, end-user anchoring, data reasoning, MVP scoping, and iteration with success metrics, and the interviewer injects constraints as you go (Aced, Ophy). The research file's cross-company summary lists "jumping to a tech stack" and "boiling the ocean" as the bad signals in decomposition rounds generally.

This prompt tests whether you will push back on the customer's chosen solution politely and with numbers. Expect the interviewer, playing the client, to insist: "We already know it's routing. Just build the optimizer." A reply that holds the line without refusing goes like this: "I can start on it this week. Before I do, give me two days with the attempt and billing data. If routing is the biggest controllable loss, the analysis tells us which routes to optimize first. If it isn't, we've saved a few months." Notice where the credit came from in the walkthrough above. The contract fact arrived only because the candidate asked about failures, and a candidate who asks only about routes gets only route data.

Check yourself

• Why should the cost model include revenue per attempt, not just cost? Answer: Loss is revenue minus cost. A contract priced below the cost to serve looks like ordinary busy routes in a cost-only view, so the biggest loss can be invisible.
• In the worked numbers, how much of the €40,000 monthly loss does the furniture retailer explain, and how? Answer: €31,200, or 78 percent: €84,000 revenue minus €96,000 for completed deliveries minus €19,200 for 1,200 failed attempts at €16 each.
• Why does the pilot need a comparison group as well as a before period? Answer: Failure rates can move with season or demand. A comparison depot over the same four weeks separates the effect of the day-before confirmation from whatever else changed.
• The director insists on the optimizer. What do you say? Answer: Agree to start, and ask for a short, bounded look at the attempt and billing data first, framed as choosing which routes to optimize. That keeps the relationship and still tests the hypothesis with numbers.