How to Build an Internal Business Case for a Robot Project Without Using Vendor ROI Claims

How to Build an Internal Business Case for a Robot Project Without Using Vendor ROI Claims

A supplier sends a one-page ROI calculation with the quotation. The numbers look compelling: a two-year payback period, a 30% throughput improvement, and labor savings that justify the investment several times over. The procurement manager forwards it to finance for budget approval. Finance asks one question: where did the assumptions come from?

The answer is that the supplier wrote them. The utilization rate, the cycle time, the labor rate, the operating hours, the downtime assumption — every input in that ROI calculation was set by the party selling the robot. This is not deception. It is a vendor business case, built to show the best possible outcome under optimal conditions. It is a marketing document, not an investment analysis.

Studies on automation and AI projects suggest that this gap between projected and realized returns is significant. A RAND Corporation analysis of enterprise AI projects found that over 80% failed to deliver expected business value. MIT Sloan Management Review reported that 61% of organizations never measured ROI after project approval. Gartner research on AI projects in infrastructure and operations found that only 28% of projects achieved their expected ROI, while 20% failed entirely. These studies cover AI and automation projects broadly, not industrial robot deployments specifically — but the failure patterns (unrealistic expectations, hidden costs, process evaluation bias) may be relevant to robot procurement.

This article is not about teaching NPV or IRR — those formulas are in every finance textbook. It is about identifying what vendor ROI claims leave out, building a total cost of ownership (TCO) model that captures the costs a vendor calculation typically omits, and establishing a tracking mechanism so the business case can be measured against reality after deployment.

Why Vendor ROI Claims Are Not a Business Case

A vendor ROI calculation is not wrong — it is incomplete by design. Four patterns are commonly observed in vendor ROI presentations:

1. Optimal-Condition Assumptions

Vendor ROI models commonly use ideal operating conditions: 100% equipment utilization, zero unplanned downtime, maximum cycle speed, and continuous operation at rated capacity. Real-world robot deployments rarely sustain these conditions. Equipment utilization depends on demand patterns, changeover frequency, maintenance windows, and upstream/downstream bottlenecks. A robot rated for 100 picks per minute does not deliver 6,000 picks per hour if the feeding conveyor, the packaging station, or the WMS cannot keep pace.

2. Hidden Cost Omissions

Vendor ROI calculations typically include the robot unit price, direct labor savings, and sometimes energy consumption. They rarely include the full cost categories that determine whether the project is profitable. The costs documented throughout this series — compliance certification (see the technical compliance matrix), SOW definition (see the statement of work checklist), change order management (see the change order checklist), SLA coverage gaps (see the service-level agreement checklist), warranty exclusions (see the warranty comparison checklist), software licensing and renewal (see the software licensing checklist), EOL spares planning (see the end-of-life planning checklist), cybersecurity hardening (see the cybersecurity procurement checklist), shipping and customs (see the shipping documentation pack), and risk register mitigation (see the project risk register) — are real costs that the buyer will pay. A vendor ROI that does not account for them is not a complete picture.

3. Benefit Overstatement

Vendor ROI models often use theoretical maximum throughput to calculate benefit. Actual throughput depends on demand variability, product mix changes, seasonal fluctuations, and the robot's interaction with surrounding equipment and personnel. A robot that can process 1,000 units per hour in a controlled test may process 600 per hour in a production environment with variable feed rates, quality stops, and operator interventions.

4. Process Evaluation Bias

Not every process is suitable for automation. Automating an unstable, poorly defined, or highly variable process tends to amplify existing problems rather than solve them. Gartner's research on AI projects in infrastructure and operations identified that targeting highly non-standardized processes for automation is a core risk factor for project failure. The vendor ROI does not ask whether the process is ready — it assumes it is.

What a Robot Project TCO Should Include

A total cost of ownership model captures costs across the full project lifecycle — from procurement to end-of-life. The following cost categories are based on the cost areas identified in the preceding articles of this series. They are not exhaustive — the specific cost items depend on the robot type, application, integration scope, and deployment environment.

Procurement and Delivery Costs

Integration and Deployment Costs

Operations and Maintenance Costs

Personnel Costs

Compliance and Risk Costs

End-of-Life and Exit Costs

How to Build Your Own ROI Model

Building an independent business case does not require a different formula — it requires different assumptions and a complete cost picture.

Use Your Own Assumptions

Replace vendor assumptions with figures based on actual production data:

• Utilization rate: Based on historical demand patterns, not rated capacity
• Cycle time: Based on the actual product mix and process flow, not the best-case single-product test
• Labor rate: Based on actual fully-loaded labor cost (wage, benefits, overhead), not a generic industry average
• Downtime: Based on historical equipment downtime data, not zero
• Ramp-up period: Account for the time between go-live and full production rate — this period may be weeks or months, during which the robot is operating below capacity but costs are being incurred

Include the Full TCO

Use the cost categories above. A vendor ROI that shows a two-year payback based on robot unit price and labor savings may become a three-year or longer payback when integration, training, compliance, cybersecurity, and EOL costs are included. This is not an argument against the investment — it is an argument for making the decision with complete information.

Separate Verifiable from Estimated Benefits

Not all benefits can be verified with the same confidence:

• Direct labor savings: Quantifiable — based on headcount reduction or redeployment
• Throughput increase: Quantifiable — but depends on utilization and demand
• Quality improvement: Estimable — based on defect rate reduction, but requires baseline data
• Flexibility and scalability: Qualitative — valuable but difficult to quantify reliably
• Safety improvement: Estimable — based on incident reduction, but historical data may be limited

The business case should label each benefit by confidence level. A decision-maker who sees that 70% of the projected benefit is direct labor savings (verifiable) and 30% is quality improvement (estimable) can make a different judgment than one who sees a single aggregate number.

Run Sensitivity Analysis

Test how changes in key assumptions affect the outcome. If the utilization rate is 70% instead of 85%, does the project still meet the investment threshold? If the ramp-up period is three months instead of one, how does that affect NPV? Sensitivity analysis does not eliminate uncertainty — it shows which assumptions the business case is most dependent on, and therefore which variables need the most careful estimation.

Set a Tracking Mechanism

The MIT Sloan finding that 61% of organizations never measured ROI after approval suggests that most organizations cannot answer the question "did this investment pay off?" The business case should include:

• Defined metrics to track (throughput, utilization, labor hours, defect rate, downtime)
• A baseline measurement before deployment
• A review schedule (e.g., 30/60/90 days, then quarterly)
• A threshold for corrective action — if actual performance falls below X% of projected performance, trigger a review

Robot Project Business Case Template

The following template combines the TCO cost categories with an ROI calculation structure. It is an illustrative template — the specific cost items, benefit estimates, and financial parameters should be developed by the project team and finance function based on actual conditions.

(Illustrative — no real supplier or product claim. Cost and benefit figures are examples for template structure, not assessments of specific products or suppliers.)

The template above produces a payback period of approximately 2.5 years — longer than the vendor's two-year claim, because it includes integration, training, compliance, cybersecurity, and software renewal costs that the vendor calculation omitted. The difference is not a reason to reject the project. It is a reason to approve it with realistic expectations and a tracking mechanism.

What to Confirm Before Approving the Budget

Before the business case is submitted for budget approval, the project team should confirm:

• [ ] Assumptions are based on actual production data, not vendor-supplied figures
• [ ] TCO includes all six cost categories (procurement, integration, operations, personnel, compliance, EOL)
• [ ] Benefits are separated into verifiable and estimated categories with confidence levels
• [ ] Sensitivity analysis has been run on utilization, cycle time, ramp-up period, and labor rate
• [ ] Ramp-up period is accounted for in the cash flow projection
• [ ] Software license model is clarified (perpetual vs. cloud-validated) and renewal costs are included
• [ ] EOL costs are included (spares, migration, data export)
• [ ] A tracking mechanism is defined with metrics, baseline, review schedule, and corrective action threshold
• [ ] The business case has been reviewed by finance, not just procurement or engineering

This checklist does not replace a formal financial review. It ensures that the business case submitted to finance is built on the buyer's assumptions, not the vendor's.

Source List

1. RAND Corporation. "Root Causes of AI Project Failures and Pathways to Success." Referenced via secondary sources; specific RAND report URL to be confirmed. Note: Analysis of enterprise AI projects. Over 80% of projects reportedly failed to deliver expected business value. Findings cover AI projects broadly, not industrial robot deployments specifically — failure patterns (unrealistic expectations, hidden costs, process evaluation bias) may be relevant to robot procurement.
2. MIT Sloan Management Review. "AI Projects: ROI and Measurement." https://sloanreview.mit.edu/ (accessed September 9, 2026). Note: Survey data on AI project ROI measurement practices. 61% of organizations reportedly never measured ROI after project approval. Referenced via secondary sources; specific article to be confirmed.
3. Gartner. "Automation and AI Project Success Rates." https://www.gartner.com/ (accessed September 9, 2026). Note: Research on AI projects in infrastructure and operations. 28% achieved expected ROI; 20% failed entirely. Referenced via secondary sources; specific report to be confirmed.
4. ScienceDirect. "Total Cost of Ownership — overview." https://www.sciencedirect.com/topics/computer-science/total-cost-of-ownership (accessed September 9, 2026). Note: Reference overview of TCO concept. Procurement price is typically a fraction of total cost; hidden costs can significantly exceed the initial purchase price.
5. ScienceDirect. "Risk Management Plan — overview." https://www.sciencedirect.com/topics/computer-science/risk-management-plan (accessed September 9, 2026). Note: Reference overview of risk assessment methods including sensitivity analysis.