Explain the business case for internal AI enablement to a skeptical finance team.

Interviewer's question: "Explain the business case for internal AI enablement to a skeptical finance team." Rustvale Waste & Recycling operates a fleet of collection trucks under municipal contract. Miguel Escalante, VP of Operations, brought HaulSense's business case to Diane Holt, the company's CFO.

How to answer this, stage by stage

Nobody is grading whether your final number sounds impressive. They're grading whether you can show your work well enough that someone could check it themselves.

Let's learn

HaulSense reads a day's collection stops and suggests an optimized route and load plan before a truck leaves the yard.

Before it, Rustvale's dispatchers planned each route from memory and a paper map, factoring in known congestion and seasonal detours by feel. A three-week pilot with 8 drivers measured about 25 minutes saved per driver per day once HaulSense's suggestions were adopted.

The turn: a single number like "$200,000 a year" tells a skeptical CFO nothing about how solid it is. The build-up is what actually earns trust, because each piece can be checked, argued with, or replaced with a better number if one exists.

Same yard, same trucks. What changes is whether the route plan is a guess or a calculation.

At its worst: dispatchers ration HaulSense toward routes that barely needed it, self-routing the genuinely complex, congested routes by hand to "save credits," so the routes where the tool would add the most value are the ones it touches least.

Each of these can be checked against a real source. None of them is asserted from nowhere.

What I would leave alone: the underlying route-optimization model itself doesn't need touching. The problem was never accuracy, it was a pricing decision that pointed usage away from the routes that mattered most.

The lesson: an ROI estimate that survives a skeptical CFO's questions isn't the one with the biggest number. It's the one where every piece of the number has a place it came from.

Now here is the same thing as a story

The short version above is what you'd say in the actual pitch meeting. Read this one for how the credit cap almost undid the whole case.

Miguel Escalante has run operations at Rustvale for eight years. He can tell which routes will back up before lunch just from the day's weather report.

HaulSense rolled out fleet-wide with no usage limit at first, and it earned real trust fast, especially on the tangled downtown routes where a dispatcher's memory could only do so much. Then finance flagged that per-route compute cost was higher than modeled, and operations added a flat daily credit cap per dispatcher to rein it in.

Two costly days happened back to back that spring: fuel costs spiked on the downtown routes specifically, the ones with the most detours and construction. Belen Cruz, Rustvale's dispatch lead, had quietly started saving her team's daily credits for the routes that "felt simple enough to not need it," and self-routing the genuinely hard downtown routes by hand, the way she always had before HaulSense.

The fourth step is exactly backwards from where HaulSense adds the most value.

Miguel found this out by accident, comparing two bad fuel-cost days against the dispatch log. Belen wasn't hiding anything. She just assumed a hard route "deserved" more of the tool's help and a simple one didn't, which meant she was saving her limited credits for exactly the routes that needed HaulSense least.

Here's the decision I'd take back: the flat, per-dispatcher daily credit cap, applied the same to every route regardless of complexity. It made sense as a quick fix when finance flagged rising compute cost. It stopped making sense the moment it quietly rationed the tool away from the routes creating the most value.

Replayed with the cap tied to route complexity instead of a flat count: a genuinely complex downtown route costs less of Belen's daily allotment than a flat system would have charged her, and a simple route costs more, nudging usage toward where it actually helps. The same two costly fuel days don't repeat, because the downtown routes get optimized, not skipped.

I approved the flat credit cap because it was the simplest rule to explain and enforce. It took two expensive days and a dispatch log comparison to see that simple and fair aren't always the same thing, especially when the tool's value isn't spread evenly across the routes it touches.

BOUND, run against one pitchNot a spreadsheet exercise. BOUND is what tells you whether your number survives being questioned.

The credit spent was supposed to be the smallest piece. The flat cap made it the deciding one.

The top-right corner is exactly where the flat credit cap pushed dispatchers away from using the tool.

The recap, one line per letter: break it down is the four-term equation, own the numbers is three sourced assumptions, use a range is $140k to $260k, nail the sanity check is the 2 to 4 percent comparison, and direction is the minutes-saved assumption.

And if you want to be sure it really works, try it somewhere elseSame five letters, a home health agency instead of a waste hauler. Nothing about the two businesses is alike.

Silvermoss Home Health Partners pitched its own visit-routing assistant to its finance director using the same method. Corrado Delgado, VP of Operations, made the case.

Mapped onto BOUND: break it down is caregiver time saved per visit, plus mileage reduction between home visits, minus the tool's licensing and training cost. Own the numbers: 15 minutes saved per caregiver per visit, from a two-week pilot with 12 caregivers; $28 an hour loaded caregiver cost, from payroll's own figures; 8 percent mileage reduction, from the vendor's published range. Use a range: $95,000 to $180,000 a year, not a single number. Nail the sanity check: that's about 3 percent of total caregiver labor and mileage reimbursement spend, comparable to what peer home health agencies have reported. Direction: the minutes-saved-per-visit assumption is the one that would move this estimate most, exactly the same shape of risk as Rustvale's, in a business with nothing else in common.

A different shape of picture than Section 2 used: a branching response plan instead of a route-cost breakdown. The discipline underneath is identical.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "state the equation, own each number's source, give a range, sanity-check it, and name what would move it most," and stop.
Cost: if a full pilot isn't available yet, use a vendor's published range plus your own smallest possible internal sample, and say clearly which parts are borrowed versus measured.
The model gets better, for real: even if HaulSense's routing gets more accurate over time, the estimate's biggest swing factor stays the human behavior number, minutes actually saved, not the model's own performance metric.

Where people run it wrong.
They present one confident number with no visible arithmetic, which reads as either overconfident or thin the moment someone asks a follow-up question.
They build a fair-sounding usage limit, like a flat credit cap, without checking whether it accidentally discourages use exactly where the tool helps most.
They wait for finance to find the weakest assumption instead of naming it first.

How to use it live. When someone asks for a business case, ask yourself first: which single number in this estimate would I least want questioned right now? Name that one before anyone else finds it.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0