From idea to first pilot in 90 days

Operations leaders who have decided to explore their first robot deployment typically fall into one of two traps: they move too fast (sign a purchase contract before infrastructure is assessed) or too slow (the project enters committee review cycles and never launches). Both patterns waste time and money. The first creates a failed deployment. The second creates a pilot that is perpetually "in planning" while competitors move.

The schedule below is calibrated to move neither too fast nor too slowly. It is designed for a single-unit or small-fleet pilot (1–6 robots) in an environment where the readiness gates from the first article in this series have already been cleared. If they haven't, the pre-work described there is the actual starting point.

The schedule assumes the following is already true before Day 1:

• Target process is identified and documented
• Baseline metrics are being collected (or a plan exists to collect them)
• A deployment owner is named with 20% time allocation
• Budget is approved, including hardware + implementation + 90-day operational contingency

Phase 1: Definition and Vendor Engagement (Weeks 1–3)

Week 1: Write the problem specification

Before contacting a single vendor, write a one-page problem specification. This document exists for one purpose: it tells vendors exactly what to quote against, and it prevents scope creep during sales cycles.

The spec should include:

• Task description (in operational terms, not technical terms — "transport pallets from receiving dock to staging area B, 60 runs per 8-hour shift")
• Environment description (facility size, floor type, wifi status, number of floors in scope, any known obstacles or constraints)
• Integration requirements (which systems the robot must communicate with, and the APIs or data formats those systems use)
• Success criteria (the three KPIs that will determine pilot success, with measurement methodology and target thresholds)
• Timeline and budget range

Do not omit the budget range. Vendors who don't know your budget will quote you the flagship version of their product. Give them a range, and ask them to quote within it.

Owner: Deployment owner, with input from operations, IT, and finance.

Output: One-page problem specification, approved by deployment owner and finance.

Week 2: Vendor outreach and RFQ

Send the problem specification to 3–5 vendors in the appropriate category. (The robot type taxonomy article in this series gives you the category framework.)

Request, for each vendor:

• Hardware quote with itemized pricing (robot, base station, fleet management software, training)
• Integration services quote with fixed-price or not-to-exceed pricing
• Reference list: 2–3 customers with similar operations and deployment duration of at least 90 days
• Site assessment availability within 2 weeks

Do not advance any vendor who declines to provide a fixed-price or NTE quote for integration. "Time and materials" integration quotes are open-ended financial exposure on a project that already has limited budget.

Owner: Deployment owner, with IT lead for integration requirements.

Output: RFQ sent to 3–5 vendors; responses expected by end of Week 3.

Week 3: Reference calls and vendor shortlist

Call the references. This is the most underused step in the vendor selection process. Operators are busy; it's easy to skip. Don't skip it.

Ask each reference:

• What was the single biggest implementation challenge you didn't expect?
• How many weeks from delivery to first productive shift?
• What does your vendor relationship look like 6 months in — responsive, or hard to reach?
• What would you do differently?

Shortlist two vendors. Do not shortlist three — you will run parallel site assessments and wasted both their time and yours.

Owner: Deployment owner.

Output: Shortlist of 2 vendors; reference notes documented.

Phase 2: Assessment and Selection (Weeks 4–6)

Week 4: Site assessments

Schedule site assessments with both shortlisted vendors in Week 4. A proper site assessment takes 4–8 hours on your floor and should produce a written infrastructure report covering:

• Specific infrastructure prerequisites (floor markings, charging station placement, wifi coverage)
• Any gaps with remediation requirements and estimated cost
• Integration complexity rating based on your actual systems
• Delivery and commissioning timeline estimate

If either vendor declines to do an on-site assessment and instead quotes based on photos or a video call, eliminate them from consideration.

Owner: Deployment owner + IT lead + facilities lead on-site.

Output: Written assessment reports from both vendors.

Week 5: Contract negotiation and selection

Select one vendor based on: site assessment quality, reference feedback, integration scope and pricing, and support structure in your geography. Do not select on hardware features alone.

Negotiate the contract. Key contract provisions for a first deployment:

• Pilot performance guarantee: Minimum uptime percentage (typically 90–95%) and throughput benchmark (specify clearly) for the pilot period. If the vendor won't sign a performance guarantee, that is informative.
• On-site support SLA: Response time for on-site support during the first 90 days. "Next business day" is acceptable for software issues; "same day" is the standard for hardware failures that halt operations.
• Data ownership: Your operational data, robot maps, and fleet logs belong to you. This should be explicit in the contract.
• Pilot termination clause: If performance guarantees are not met by day 60, you have the right to return the robot at the vendor's expense. This clause is standard in the industry; vendors who resist it are a red flag.

Owner: Deployment owner + procurement or legal.

Output: Signed contract; delivery date confirmed.

Week 6: Infrastructure remediation begins

All infrastructure gaps identified in the site assessment should be initiated in Week 6 — even if remediation won't be complete until Week 8 or 9. The gap you start late becomes the reason the go-live slips by 3 weeks.

Typical infrastructure remediation tasks:

• Wifi access point addition or repositioning (coordinate with IT)
• Floor marking for robot paths (facilities)
• Charging station installation (facilities + electrician)
• Rack clearance adjustments in AMR environments (operations)
• Elevator integration initiation if multi-floor (integrator + elevator maintenance company)

Owner: Facilities lead (physical), IT lead (connectivity).

Output: Remediation schedule with completion dates, all before hardware delivery.

Phase 3: Preparation and Installation (Weeks 7–10)

Week 7: Baseline measurement lock-in

This is the last opportunity to establish a clean baseline before the robot changes the operational environment. In Week 7, formally record baseline metrics for all three KPIs defined in the problem specification.

Baseline measurement protocol:

• Measure for at least 5 operating shifts, across different days and shift patterns
• Record the conditions (staffing level, volume, any unusual events) alongside the metric
• Store in a location that both operations and finance can access
• Have the deployment owner and finance sign off on the baseline numbers

These numbers are the foundation of every business case review for the next 12 months. They need to be credible.

Owner: Deployment owner + finance.

Output: Signed-off baseline measurement document.

Week 8: Integration development

Integration between the robot's fleet management system and your existing operational technology typically begins in parallel with infrastructure remediation. By Week 8, the integration scope should be finalized and development should be underway with the integration team (vendor, integrator, or internal IT).

Integration milestones to hit by Week 10 (before go-live):

• Fleet management software installed and communicating with robot
• WMS or ERP integration tested with synthetic transactions
• Alert and incident escalation pathways configured
• Dashboard or reporting view available for deployment owner

Owner: IT lead + integration team.

Output: Integration acceptance test passed; all systems communicating.

Week 9: Staff preparation program

The change management program begins in Week 9 — two weeks before go-live. The timing matters: too early and staff forget; too late and you're managing anxiety at launch.

Two-session program:

Session 1 (Week 9): Information and Q&A. 45 minutes for affected staff. Cover: what the robot does, what it doesn't do, how their workflow changes, who to contact with concerns. Use concrete examples from your operation, not the vendor's demo video.

Session 2 (Week 10): Hands-on time with the robot (if hardware is on-site). Staff interact with the robot, practice the interaction protocol, and understand what happens in edge cases (robot is blocked, robot is charging, robot enters an alert state).

Designate a staff liaison — not the deployment owner — who receives staff feedback during the first 30 days. The deployment owner is measured on outcomes; the liaison is measured on staff experience. These are different roles.

Owner: Operations lead (content), HR (logistics).

Output: All affected staff briefed; staff liaison designated.

Week 10: Robot delivery and commissioning

Robot arrives. Vendor commissioning team maps the facility and commissions the fleet management software. Integration is live-tested with actual transactions.

Plan for 3–5 days of commissioning time before the robot operates independently. During commissioning:

• Vendor team maps the deployment zone and tunes navigation parameters
• Pilot routes are tested and refined
• Edge cases (obstacle handling, low-battery behavior, emergency stop behavior) are verified
• Integration is tested with real WMS or ERP transactions

Do not accept go-live before commissioning is complete. Rushing commissioning to hit a launch date is how you create the early incidents that erode staff confidence.

Owner: Deployment owner + vendor commissioning team.

Output: Commissioning sign-off; robot is ready for supervised operation.

Phase 4: Go-Live and Pilot Operation (Weeks 11–16)

Weeks 11–12: Supervised operation

The first two weeks are supervised — a staff member assigned specifically to monitor the robot, log incidents, and intervene in edge cases. This is not permanent staffing; it's a temporary role during the ramp period.

The supervisor:

• Logs every incident (navigation failure, integration error, throughput below target)
• Communicates daily with the deployment owner
• Is the first escalation point for any staff concern

Incident volume in weeks 11–12 will be higher than steady state. This is expected. Use this period to tune the robot's behavior and identify integration issues that didn't surface during commissioning.

Owner: Deployment owner (supervision schedule), IT (integration issues).

Output: Daily incident log; week 2 review meeting with vendor.

Weeks 13–16: Independent operation with weekly KPI tracking

The supervised operation phase ends when incident rate drops below a threshold defined with the vendor (typically fewer than 2 navigation interventions per shift). Once that threshold is reached, the robot operates independently with monitoring through the fleet management dashboard.

Track KPIs weekly. Compare against baseline. The week 13–16 data is the first credible evidence of pilot performance — it is far enough from go-live that ramp instability has settled, but early enough to allow for adjustments before the formal 90-day review.

At the end of Week 16, produce a one-page pilot summary for leadership: baseline, current performance, trend, and a preliminary recommendation (proceed, extend, or close).

Owner: Deployment owner.

Output: Week 16 pilot summary delivered to leadership.

Go / No-Go Gates

The schedule above has three explicit decision points:

The extension at Week 16 is not an open-ended deferral. The extension must come with specific conditions: "If throughput reaches X and uptime reaches Y by day 120, we proceed to full deployment. If not, we close the pilot." This is what a well-structured pilot looks like — clear criteria, a defined timeline, and an actual decision at the end.

Most pilots that "fail" do so not because the technology doesn't work but because the evaluation framework was never written down. Write it down before the robot arrives.