"I will be brief. If this project does not make financial sense I cannot support it regardless of the operational benefit. I will need to understand the return before we go any further."
That sentence ends more technically correct projects than any engineering flaw ever will. The best sorter on the market, sized right, guarded right, validated right, still dies in the finance review if it can't pencil out against the company's threshold. Tom isn't being difficult. He's telling you the rule the whole room runs on.
So the business case isn't a sales flourish you tack on at the end. It's engineering. You build it from confirmed inputs, you defend it line by line, and you're honest about what it does and doesn't include. The engineer who can do the system math and the money math is the one who gets the project built.
By the end of this lesson you can build a simple payback the way you build a calculation, from confirmed inputs and not guesses; model labor, chargebacks, and throughput into an annual savings number; and put a real price on a product outlier so the customer can decide whether it's worth carrying.
Annual savings isn't one number the customer hands you. You model it from three sources, and you confirm every one of them in writing, the same standard you'd hold for a belt speed.
Add the three and you've got annual savings. Here's the discipline that separates a real business case from a hopeful one: each input is confirmed with the customer, in writing, before it goes in the model. A payback built on a labor number nobody confirmed is a payback built on an assumption, and assumptions aren't wrong until they're wrong. When they're wrong, the number you defended in the finance review falls apart in front of the people you least want to lose.
The formal place where you disclose these inputs as assumptions and exceptions is the proposal, and that document is Lesson 30. Here you build the model. There you write it down so the customer sees exactly what it rests on.
Tom Ruiz tells you the threshold is a three-year payback and that labor is the primary savings driver. He doesn't tell you how many associates are on manual sorting or what they cost. You can't build the payback without those two numbers. What exactly do you ask him for, and why can't you defensibly assume it?
Quoting an industry-standard payback. There isn't one. Payback runs from under two years for simple mechanization to five or more for full AS/RS, and the approval threshold is a number each company sets for itself. Tell a customer the industry expects a three-year payback and the first finance person in the room who knows better stops trusting the rest of your numbers.
Simple payback is total investment divided by annual savings. That's it. Three years of savings measured against the install cost tells the finance chair whether the project clears their threshold.
Say a system installs for $600,000, and you've confirmed $225,000 in annual savings: $170,000 in labor, $40,000 in chargeback reduction, $15,000 in avoided peak overtime.
$600,000 ÷ $225,000 per year = about 2.7 years
Against a three-year threshold, this clears, with room. Change the install cost or any input and the answer moves. These numbers are here to show you the arithmetic, not to stand in for Riverside's real figures, which nobody has confirmed yet.
Now the honesty layer, and it matters as much as the arithmetic. There's no industry-standard payback number, and no standards body sets one. Payback varies by the kind of automation. Process and mechanization improvements often pay back in under two years. Semi-automated systems, which is where conveyor and sortation and AMRs sit, typically pay back in two to four years. Complex fully integrated automation like AS/RS typically takes three to five years or more, offset by fifteen to twenty-five year equipment life. Those are ranges by technology tier, not a rule.
The approval threshold itself is a company decision, set from cost of capital and a hurdle rate, not a law anyone can look up. So you never tell a customer "the industry standard is a three-year payback." You find out what their threshold is, and you build the case against it. Tom's three years is Riverside's number, its own capital hurdle. It isn't the industry's, and treating it like a universal law is how you get caught by the one person in the room whose whole job is knowing better.
If the customer hands you a payback threshold, then build the case against their number and confirm every input that feeds it in writing before you present it. Tradeoff: it's slower than quoting a rule of thumb, and finance people ask hard questions. Verify: when Tom asks where the labor number came from, you have the email that confirmed it. A business case you can source is a business case you can defend.
Every project has input parameters from the customer, and the unusual ones drive cost in ways the customer may not see. A very small product or a very tall one, at a small fraction of the volume, can force the entire system to be designed around it. That single outlier may be driving the size, the speed, and the cost of the whole system while the customer thinks it's a rounding error on their volume report.
So you call it out. Explicitly. You show the customer what the outlier is doing to the design and what the system would look like without it, and you put a number on it. When the design isn't yet drawn both ways, an early estimate is fine. A per-foot price difference between two conveyor widths is enough to start the conversation, and the point of the early estimate is that it saves you from drawing the system twice. And the timing isn't negotiable: you raise this in discovery, early, not for the first time at the proposal review. The proposal is a confirmation document. It writes down what you already discussed, it never springs a new cost driver on the customer, and an outlier that first surfaces at proposal review is itself a failure, a sign it got missed upstream and a customer harder to close. The two-column view below is the whole protocol on one page.
| Include the outlier | Exclude the outlier |
|---|---|
| System is designed to handle everything the customer ships today. | System is optimized for the core volume that carries the operation. |
| Customer doesn't have to manage exceptions manually. | System may be smaller, faster, or less expensive. |
| Future product changes within the outlier range are handled automatically. | The outlier gets a documented manual exception path, which someone has to design and run. |
| Cost reflects the full product range. | Customer makes an informed business decision about the outlier. |
Include the outlier and the system handles everything the customer ships today with no manual exceptions. Exclude it and the system may come out smaller, faster, or cheaper, but the outlier then needs a documented manual exception path. That exception path is real work, and where it gets designed is Lesson 30 and the execution lessons in Part VIII, not here. Here you name that an excluded outlier needs one. The envelope logic underneath all of this, what the system handles automatically versus what falls outside it, is the design envelope you built back in Lesson 6. Either way the customer makes an informed business decision. That's the job.
If a product outlier is driving the whole system in an expensive direction, put a number on it. Show the customer what it costs with that outlier in and what it costs with it out. You don't even have to draw it twice to start the conversation. A per-foot price difference between two conveyor widths is enough to show them the trade, and it can save you from drawing the whole system twice. Give them the information and let them make the call. That's their decision to make, not yours.
Build Riverside's business case against Tom's three-year threshold. You're building the structure, not a finished dollar figure, because Tom gave you the framework and held back the numbers on purpose.
Start with the three savings sources. Labor comes from eliminating the manual sort and staging that jams up at peak wave releases. Chargeback reduction comes from cutting the roughly three percent misdirect rate that already has two of five clients issuing chargebacks. Throughput headroom, the room between the current 18 cartons per minute and the 20 CPM design target, only counts if Dana can tell you it converts to revenue or avoided overtime.
Now write the formula: total investment divided by annual savings. Then mark what's still open. You don't know the headcount on manual sorting and staging, the fully loaded cost per associate, or the chargeback cost per incident. Every one of those is a confirm-with-Tom-in-writing item, not a number you get to assume.
Then price the two outlier candidates both ways. The Small Case at 4 percent drives tighter roller centers and the after-sort takeaway. The Tall Case at 12 percent drives the tumble risk on the mezzanine decline and is the harder call of the two. For each, show the cost of carrying it against a documented manual exception path, and where the design isn't drawn both ways, use the per-foot estimate to show the trade.
Write the ask-Tom list. Exactly which numbers do you need from him before this payback is defensible, and what's the one sentence you'd send to confirm each one in writing?
Every lesson before this one built the system: the flow, the rates, the technology, the controls, the safety case, the drawing. This is the lesson where all of that has to answer one question a finance chair asks in plain English, does it pay for itself. The math is simple on purpose, investment over savings. What's hard is the honesty around it: confirming every input instead of assuming it, building to the customer's own threshold instead of an industry number that doesn't exist, and pricing the outlier both ways so the decision stays where it belongs, with the customer. Do that and the engineering you spent six parts building finally gets funded. Skip it and the finished design stays on paper.