Passing SAT is a milestone. Sustaining reliable production is a different achievement.
A robotic transport system can pass an acceptance test and still struggle during the first months of daily operation. Shift patterns change, operators discover workarounds, pallets arrive in unexpected conditions, charging schedules collide with production peaks, and exceptions that were rare during commissioning become routine.
The first 90 days after go-live should therefore be treated as a structured stabilization and performance-verification period, not an informal warranty countdown. The objective is to move from “the system has been accepted” to “the operation can depend on it.”
Define what good performance means before go-live
Select a small set of metrics that connect robot behavior to the material-flow requirement. Make each metric precise enough that two people can calculate it the same way. Without definitions, a dashboard showing “95% success” may hide very different interpretations.
Useful measures include:
Mission completion rate: completed required missions ÷ valid requested missions within the defined reporting window. State how cancelled, invalid or manually completed requests are treated.
Service-level performance: missions completed within the agreed delivery window ÷ eligible missions. This can be more valuable than raw movement count when a production line depends on timed replenishment.
System availability: time the defined automation service is capable of accepting and executing its agreed scope ÷ scheduled service time. Clearly separate robot-specific downtime, fleet-manager downtime and unavailable external interfaces.
Intervention rate: human interventions required per 100 completed or requested missions, with categories for root cause. Use the same denominator over time.
Recovery time: elapsed time between a defined loss of service and restoration, reported by failure class. A single mean may hide the most disruptive outliers.
Cost per completed transport: agreed total operating costs for the period ÷ completed, qualifying transports. Be explicit about whether the calculation includes labor, maintenance, energy, software, amortization and exceptional manual handling.
These are examples of engineering KPIs—not universal contractual targets. The final values and thresholds must follow the business case and acceptance agreement.
Record a baseline, not only the new system's numbers
Before the robot is introduced, measure the manual or existing process against comparable definitions: moves by hour, delivery reliability, labor involvement, waiting time, damage, travel distance and exceptions. Note differences in production volume and shift mix.
A claim that robots improved throughput is weak if the plant simultaneously changed product mix or production schedules. When comparing periods, normalize where justified and disclose changes in demand. Distinguish a process benefit from a transfer of work to another department.
Do not reduce success to robot utilization. A fleet operating at nearly full capacity can be one disruption away from missing critical deliveries. Utilization is a diagnostic metric, not a standalone business objective.
Days 1–30: stabilize and establish visibility
The first month should emphasize safe and repeatable operation. Create an issue register with consistent categories: robot hardware, localization, navigation, load handling, communications, WMS data, charging, operator interaction, infrastructure and process design.
For each event, capture when it happened, the affected mission, immediate impact, recovery action, cause hypothesis, owner and closure evidence. Preserve relevant logs and make sure customer and integrator agree on an escalation route. A daily short review is often more valuable than an elaborate monthly presentation with unresolved failures.
During this period, avoid uncontrolled parameter changes. Speed, traffic zones, pallet tolerances and mission rules should follow change approval and relevant safety revalidation. If the operation needs temporary manual fallback, define it rather than allowing informal workarounds to become the normal process.
Days 31–60: remove recurrent loss mechanisms
Once the data becomes credible, prioritize recurring issues. Is a particular pickup point responsible for most alignment faults? Does mission waiting concentrate at one shared aisle? Do charging queues appear only at shift change? Are operators repeatedly issuing duplicate requests because acknowledgements are delayed?
Use root-cause methods suited to the issue. A Pareto view can highlight concentrated losses, but the most frequent event is not always the highest risk. Rank corrective actions by safety, production impact, recurrence and effort.
Test improvements in a controlled manner: one documented change, expected effect, measured result, rollback plan and updated operating instructions. The aim is to distinguish a robot fault from a weak interface or process rule, not to assign blame quickly.
Days 61–90: prove sustainability and transfer ownership
By the third month, the focus should shift from firefighting to dependable operation. Review trends across representative shifts, load types and production levels. Test the agreed degraded modes: unavailable robot, charger outage, blocked corridor, network interruption and critical manual fallback, using safe and approved procedures.
Confirm that the site team can perform routine recovery without relying on a visiting supplier engineer. Check training records, support contacts, spare-parts arrangements, software-change governance, documentation ownership and preventive maintenance.
The handover package should include updated as-built maps and interfaces, operating procedures, unresolved risks and actions, KPI definitions, support escalation, documented configuration and acceptance deviations. This is the foundation of sustainable production ownership.
How a 90-day review can change a business decision
Consider a hypothetical site where 1,000 transport missions are requested each week. If 940 are completed automatically, the raw autonomous completion rate is 94%. That percentage alone cannot explain what the operation experienced.
If the remaining 60 missions were manually completed within acceptable windows, production impact might be limited but labor savings may be lower than expected. If those 60 were critical replenishments delivered late, the same percentage could represent a serious service problem. If 40 of them originated from incorrect WMS requests, the remedy may belong in process control rather than robot navigation.
That is why KPI reviews must combine outcome, timing, failure classification and business consequence. The number is a signal; engineering interpretation is the value.
Turn operational learning into contract and improvement decisions
Review whether warranty claims, preventive maintenance, software updates, service-level agreements and performance guarantees are actually measurable. Identify who owns every recurring issue and its due date. When evidence supports it, update the business case and fleet-sizing assumptions rather than protecting the original forecast.
A 90-day review should end with three decisions: what is stable and can be handed to operations, what requires a funded improvement plan, and what still blocks formal closure or scale-up. If expansion is planned, the lessons from the first area should be reflected in the next project's requirements and acceptance criteria.
First-90-days checklist
- Baseline and contractual KPI definitions documented
- Mission, downtime and intervention categories consistent
- Daily or weekly issue reviews with clear ownership
- Root-cause actions verified before closure
- Safety-relevant changes controlled and revalidated
- Recovery and manual fallback tested as agreed
- Training, as-built documentation and support handed over
- Evidence-based decision on closure, improvement or scale-up
The engineering conclusion
Go-live is when a robot begins proving itself—not when the engineering responsibility ends. The strongest implementations make the first 90 days transparent, measured and collaborative. A successful deployment is not a robot that worked during SAT. It is an operation that continues to work when the commissioning team has left.
ČAMINSKI — Engineering Advisory & Project Delivery. For post-go-live performance review and operational optimization: office@dimitarcaminski.com.