Choose AMR or AGV from the transport mission, environment and traffic rules. Navigation technology matters, but payload interfaces, safety, fleet behavior and production integration decide whether the system works.
The useful question is not whether AMR vs AGV is modern or popular. The useful question is whether it improves a defined manufacturing decision with evidence that operations, engineering and finance can verify. This guide treats the topic as an operating system and an investment. It separates facts from assumptions, identifies the data needed before approval and shows how to run a limited implementation before committing to scale.
What is AMR vs AGV?
AMR vs AGV is a comparison of mobile material-handling systems with different navigation, route-change and infrastructure characteristics.
The core management decision is which system can move the required load safely and reliably at the needed frequency within the plant’s traffic and interface constraints. That decision needs a named owner, a baseline and a time horizon. It also needs a clear boundary: AMR and AGV labels do not define the complete solution; top modules, load transfer, fleet software, doors, lifts and people are part of the system. Without that boundary, project teams often buy overlapping functions, count the same benefit twice or discover too late that an essential interface was outside the supplier’s scope.
Begin with the process as it runs today. Observe normal work, changeovers, failures, material shortages and quality exceptions. Interview the people who operate and support it. Then write the current decision in one sentence: who decides, what information they use, when they decide and what happens if the information is wrong. Technology requirements should be derived from that sentence.
Which facts should be measured before a decision?
Measure a stable operational baseline before asking vendors for return estimates.
A baseline should cover enough time to include normal variation. Segment it by product family, shift and operating condition when those factors change the result. Record the source of every number. A value manually reconstructed from a spreadsheet is not equivalent to a timestamped system event, but both can be useful if their limitations are explicit.
| Area | What to measure |
|---|---|
| Mission | moves per hour and on-time delivery |
| Capacity | payload, load dimensions and queue |
| Traffic | blocked time, reroutes and crossings |
| Reliability | mission completion, intervention and charge time |
| Economics | labor, forklift miles, damage and support cost |
The five measurement groups—Mission, Capacity, Traffic, Reliability, Economics—should not be collapsed into one percentage. A project can improve speed while increasing quality loss, or reduce direct work while increasing maintenance and engineering support. Keep physical measures, hours and money separate until the calculation step. This makes the model auditable and prevents a favorable ratio from hiding a worse operating result.
Use medians and distributions where averages hide peaks or rare failures. For example, a ten-minute average changeover may include a reliable five-minute family and an unstable thirty-minute family. The investment must be designed for the actual mix. Document exclusions such as planned shutdowns, prototype orders and abnormal supplier disruptions so that the post-project comparison uses the same rules.
How should the alternatives be compared?
Compare at least three credible alternatives, including a process-improvement or do-minimum option.
| Decision area | Evidence required |
|---|---|
| Fixed-route AGV | Predictable flow with route infrastructure |
| AMR | Dynamic navigation where routes and obstacles vary |
| Tugger model | Moves trains on repeatable milk runs |
| Unit-load model | Transfers pallets or racks at defined stations |
| Manual handling | Retain when frequency and variability do not justify automation |
Score mandatory requirements separately from preferences. A solution that fails a safety, regulatory, product or continuity requirement should not recover through a high total score elsewhere. For non-mandatory items, use a short scale tied to evidence: 0 for not addressed, 1 for a promise, 2 for a documented design, 3 for a demonstrated result and 4 for a result proven in a comparable operating reference.
Ask every supplier to use the same demand, product mix, shifts, quality definition and site constraints. Record assumptions beside the score. A comparison is misleading when one proposal includes tooling, integration and training while another quotes only the core platform or machine. Use ways to increase manufacturing capacity without expansion to structure commercial and technical due diligence.
What costs belong in the business case?
The business case must include acquisition, implementation, operating and change costs.
The minimum cost model covers vehicles, chargers and fleet software, top modules and transfer stations, network, mapping and facility changes, safety validation, support and spare capacity. Add internal hours by role, production access during installation, test material, launch scrap, temporary parallel operation and contingency for interfaces that cannot be confirmed before design. Treat internal engineering as a scarce resource even when it does not create an external invoice.
| Cost layer | Examples | Cash-flow treatment |
|---|---|---|
| Acquire | vehicles, chargers and fleet software | Initial investment or committed subscription |
| Implement | top modules and transfer stations | Project cash plus internal labor |
| Launch | network, mapping and facility changes | Temporary cost and lost contribution |
| Operate | safety validation, support and spare capacity | Recurring annual or usage-based cost |
| Exit | data export, removal, restoration and residual value | Terminal cash flow and risk allowance |
Build a monthly cash-flow model rather than multiplying a percentage by annual revenue. Benefits should follow a physical chain. Fewer minutes of a documented loss create more good output only when demand exists and the relieved resource constrains the system. Labor becomes cash saving only if overtime, agency hours, vacancies or staffing plans actually change. Inventory reduction releases cash once; it is not recurring profit.
Test a downside case. Reduce adoption, performance and volume. Extend ramp-up. Increase support cost. If a small change destroys the return, management needs a staged commitment or better evidence. For a fuller capital review, use a practical production automation ROI guide; for lifecycle comparison, use cobot and industrial robot selection criteria.
What does a worked financial example look like?
A transparent example starts with operational quantities and shows every assumption.
Assume a project requires $240,000 at approval, $35,000 during implementation and $28,000 each year to operate. The validated improvement releases 900 constraint hours annually. If contribution is $180 per constraint hour and only 70% of released time can serve demand, capacity benefit is 900 × $180 × 70% = $113,400. Add $42,000 of verified overtime and quality savings. Annual gross benefit is $155,400 and recurring net benefit is $127,400 after operating cost.
Simple payback is $275,000 divided by $127,400, or about 2.16 years. A simple five-year undiscounted ROI is (($127,400 × 5) − $275,000) ÷ $275,000, or about 132%. These are example calculations, not a benchmark for AMR vs AGV. The team should replace every number with plant data, include tax and working-capital treatment where material, and calculate NPV using the company’s approved discount rate.
The model also needs non-financial gates. A project with attractive payback can still be unacceptable if it creates an uncontrolled safety function, breaks product traceability or depends on an unsupported component. Conversely, a compliance or resilience project may be necessary even when avoided-loss probability makes a precise ROI impossible.
What implementation plan reduces risk?
Use a gated pilot that produces operational and financial evidence before scale.
- Define the decision. State the problem, scope, owner and consequence in plain language.
- Freeze definitions. Agree units, states, product boundaries and the benefit calculation.
- Measure the baseline. Capture enough normal variation and document data quality.
- Map dependencies. Include people, material, upstream and downstream processes, utilities, interfaces and suppliers.
- Write acceptance criteria. Specify performance, quality, availability, safety, recovery and documentation evidence.
- Test the difficult case. Include peak mix, awkward variants, failures, changeovers and manual recovery.
- Train by role. Operators, supervisors, maintenance, engineering, IT, quality and finance need different competencies.
- Run in parallel where necessary. Preserve a controlled fallback until evidence supports transition.
- Verify benefits. Compare with the baseline using the same definitions and obtain finance sign-off.
- Decide to scale, redesign or stop. Record repeatable cost and unresolved risks before the next site or line.
A pilot is not a small demo. It must exercise the real workflow and produce a decision. Limit scope by line, product family or use case, but keep production variability, cybersecurity, safety and recovery in view. A result achieved by daily attention from the supplier’s best engineer may not survive ordinary support conditions.
What are the main risks?
The main risks are selecting by navigation demo, unknown peak move demand, mixed traffic without rules, incompatible load transfer heights, no degraded-mode plan.
Turn each risk into a test, owner and response. If the risk is poor data, define a reconciliation sample and an acceptable error rate. If it is supplier dependency, require export, documentation, escrow or replacement provisions appropriate to the consequence. If it is workforce readiness, observe trained users performing normal and abnormal work without project-team intervention.
Risk should also affect commercial structure. Hold milestone payments against design review, factory acceptance, site acceptance, documentation and sustained production evidence. Define who pays for rework when performance misses a requirement. Control changes through written impact on price, schedule, safety and acceptance. Do not allow unresolved assumptions to disappear inside meeting notes.
What do published evidence and expert experience show?
Published evidence supports a measured, context-specific decision rather than a universal performance promise.
A NIST MEP case on Indiana Furniture reported a $250,000 investment in mobile robotic equipment and more than 186 miles of forklift traffic saved during the first 11 months. The company used an on-site application assessment and later planned two larger mobile robots for a facility expansion.
“The knowledge and expertise of the Purdue MEP team provided solid confirmation that we were heading in the right direction.”
— Greg Dellinger, Process Engineer at Indiana Furniture
The quotation comes from the cited primary source. It is useful as practitioner evidence, but it does not transfer automatically to another plant. Compare product, process, volume, baseline, staffing, scope and time period before using any case result in a forecast.
What should be included in the final approval pack?
The approval pack should let a person outside the project reproduce the decision.
- one-page problem statement, scope and accountable owner
- baseline dataset with definitions, source and exclusions
- mandatory requirements and an evidence-based option comparison
- architecture or process boundary with interface ownership
- full lifecycle cost and monthly cash-flow model
- base, downside and upside scenarios without double-counted benefits
- safety, cybersecurity, quality and compliance reviews where applicable
- acceptance tests, responsibilities and commercial remedies
- training, support, spare-parts and recovery plans
- post-launch measurement date and scale-or-stop rule
Keep the pack concise enough to use. Link detailed drawings and raw data rather than copying them into a presentation. Record what is known, what is assumed and what remains unresolved. That discipline improves the investment decision even if the final answer is to delay or reject the project.
How should performance be reviewed after launch?
Review technical stability, user behavior and verified economics at fixed intervals.
During the first two weeks, track safety, quality, interruptions, manual overrides and unresolved support calls every day. At 30 days, compare actual volume, mix, staffing and availability with the approval assumptions. At 90 days, finance and the process owner should reconcile physical improvements to cash, capacity or risk outcomes. Separate temporary launch work from recurring support. Record whether benefits came from the technology, a simultaneous process change or unusual demand.
Do not scale because the system is merely running. Scale when acceptance criteria remain stable without extraordinary project-team attention, users follow the intended workflow, recovery has been demonstrated and repeatable deployment cost is known. If results are below plan, identify whether the gap comes from adoption, technical performance, upstream constraints or an incorrect business assumption. Correct the cause, revise the forecast and repeat the gate. This review turns implementation evidence into a controlled portfolio decision.
Frequently asked questions
How much data is needed before approval?
Enough data is needed to represent normal product, shift and failure variation. A short stable process may need weeks; a seasonal or low-frequency process may need months. The important test is whether the sample supports the specific assumption being used.
Should the lowest-cost option win?
No. Compare the lowest risk-adjusted lifecycle cost among options that meet mandatory requirements. A cheaper offer can be worse if it excludes integration, support, acceptance evidence or a costly operational dependency.
Can vendor case studies be used in the ROI?
Only as external context. Vendor and public case studies help identify mechanisms and questions. The forecast should use the manufacturer’s baseline, constraints, demand and cost structure.
Who should own the project after go-live?
The operational process owner should own the result. Technical teams own components and controls, but operations must own the decision, response and sustained use. Finance should verify benefit, and quality or security should retain authority over their gates.
When should the project be stopped?
Stop or redesign when mandatory requirements fail, the baseline cannot be verified, the pilot does not change the intended decision, lifecycle cost exceeds the approved threshold or unresolved risk is greater than the expected value.
