How to Run a 90-Day Hospitality Robot Pilot That Actually Proves ROI

Most 90-day robot pilots in hospitality end in one of two ways: the vendor extends the pilot indefinitely at no cost to keep the relationship alive, or the robot gets pushed into a corner and quietly stops being used. Neither produces data.

The reason is structural, not motivational. Operators start the clock without defining what "success" looks like, without measuring the baseline they'll be comparing against, and without a written commitment to act on the results. By day 90, they have 90 days of impressions and anecdotes, not a decision.

This playbook structures a 90-day pilot into four phases with defined deliverables, accountable owners, and a decision gate at the end that produces an actual answer: scale, modify, or kill.

Phase 0: Pre-Pilot (Weeks -2 to 0)

This is the most important phase. Nothing should move forward until all five deliverables are complete.

Deliverable 1: Three KPIs in Writing, Signed

Pick three measurable KPIs. The GM and Finance director both sign the document. Verbal agreement is not sufficient — in 90 days, memories of what was agreed will differ.

KPI selection by use case:

Hotel room delivery:

• Deliveries per shift
• Average order-to-door time (in minutes)
• Weekly delivery-related staff labor hours

Restaurant food running:

• Plates delivered per peak hour
• Food-running labor hours per 100 covers
• Average ticket-to-table time during peak service

Lobby/corridor cleaning:

• Square feet cleaned per shift
• Weekly cleaning labor hours (redirected portion)
• Guest complaint tickets related to lobby cleanliness

For each KPI, document: the current baseline value (measured in Phase 0), the target value at day 90, and the threshold below which the program does not proceed to Phase 2.

KPI sheet structure:

Deliverable 2: Two-Week Baseline Measurement

Run operations normally for two full weeks. Measure all three KPIs daily. Log the data.

Do not start the robot until this baseline period is complete. The two weeks must capture at least one weekend cycle and at least one weekday cycle. If occupancy or volume during the baseline period is atypically high or low, note it — you will need to adjust comparisons at day 90 for seasonality.

Deliverable 3: Wifi Heat-Map

Commission a signal coverage map of the deployment zone. A qualified AV or IT contractor can complete this in a half-day. If dead zones exist, get a remediation quote before the robot arrives. If remediation is required and the cost makes the unit economics unworkable, the pilot should not proceed — or should proceed with explicit acknowledgment that you're investing in infrastructure, not just the robot.

If the property's wifi was upgraded in the last 18 months, you may be able to skip this step after confirming coverage with your IT manager. Don't skip it without confirmation.

Deliverable 4: Executive Sponsor

Name one executive sponsor — GM, regional VP, or owner — who has authority to approve Phase 2 spending and to make the kill decision at day 90. This person is not the day-to-day pilot manager. They attend the weekly stand-up, sign off on the KPI document, and make the final decision.

Without an exec sponsor, pilots drift. Department heads avoid accountability. The decision at day 90 gets pushed "up the chain" to someone who doesn't know the data. Name the sponsor before the contract is signed.

Deliverable 5: Kill Criteria in Writing

This feels obvious but is almost always skipped. Write down the specific conditions under which the pilot will be killed at day 90 and not extended. Example:

"If two or more KPIs do not reach their target values by day 90, the program does not proceed to Phase 2. No 30-day extension will be granted without a written amendment to this document signed by [exec sponsor]."

The vendor will almost always ask for an extension if results are mixed. Having a written kill criteria document makes that conversation much easier: either the numbers are there, or they're not.

Phase 1: Installation (Weeks 1–2)

Day 1–3: Vendor On-Site Setup

The vendor should be on-site for the full installation period. Route mapping requires the robot to navigate the actual floor with a technician present. Insist on this — remote setup creates problems that show up on week 3, after the vendor has left.

Key tasks for the vendor during installation:

• Full floor walk and obstacle mapping
• Elevator integration test (if applicable) — run 20 consecutive elevator cycles and log any failures
• Loading station setup and staff walkthrough
• Emergency stop and manual override training for all staff who will work alongside the robot

Day 2–4: Staff Mandatory Demo

Schedule a 45-minute session for every staff member who will work in the deployment zone. Not an announcement. A hands-on demo.

The session covers:

• What the robot does (specific tasks, specific schedule)
• What the robot does not do (tasks that remain human)
• How to load/unload the robot
• How to stop it if something goes wrong
• What to tell a guest who asks about it

The goal is to remove the unknown. Staff who understand exactly how the robot changes their workflow have much less anxiety than staff who've been told "a robot is coming."

Do not show the robot to guests before staff have been briefed. The first interaction a guest has with a robot should not also be the first time a nearby staff member has seen it.

Day 5–10: Spare Parts and Insurance

Before the robot starts regular operations:

• Confirm your vendor's parts lead time for the top 5 most common failure items (wheels, tray sensors, charging contacts). For parts with a lead time over 5 business days, order one spare set.
• Contact your property insurer to add a rider covering the robot. Most commercial property policies can accommodate this. Get the rider active before week 3.

Day 10–14: First Operations

Run at minimum reduced-scope operations (limited hours, limited deliveries) for the last few days of Phase 1 to stress-test the setup before full deployment begins. Log every incident — door sensor failure, elevator timeout, missed pickup, staff override. This is your incident log baseline.

Incident log columns:

Phase 2: Operations (Weeks 3–10)

Weekly Stand-Up (30 minutes)

Every week, the pilot owner runs a 30-minute review covering:

• KPI tracking vs. baseline (the three metrics from Phase 0)
• Incident log review (patterns, recurring failures, unresolved items)
• Vendor SLA check (uptime, response times, outstanding support tickets)
• Staff report (any operational friction, workarounds, behavioral issues)

This meeting should have a fixed agenda and written outputs. If you're not writing down what was discussed and decided each week, you will not have a clean record for the Phase 3 decision.

Uptime Target

Set a daily uptime target of 92% or higher (meaning the robot is operational and completing deliveries for at least 92% of its scheduled operating hours). Below 85% uptime is a vendor SLA issue that should trigger a formal support escalation. Log uptime every day.

A robot that is down 20% of the time is expensive infrastructure, not a workforce tool.

Anonymous Staff Feedback at Week 4 and Week 8

This step is specifically designed to surface the behavioral issues identified in the WSU robot-phobia research (May 2024, International Journal of Contemporary Hospitality Management). That study found that workers who found robots competent and efficient reported higher — not lower — turnover intent. Workers may be routing around the robot not because it's performing badly, but because it's performing well and that's threatening.

Staff feedback survey (5 questions, anonymous, paper or digital):

1. How often in the past 2 weeks did you complete a task the robot was scheduled to complete? (Never / Rarely / Sometimes / Often)
2. When you completed a task instead of the robot, why? (Robot was unavailable / Faster to do it myself / I preferred to / Guest asked me to / Other)
3. Has the robot changed the amount of time you spend on your primary responsibilities? (More time for primary tasks / Same / Less time for primary tasks)
4. How comfortable are you working alongside the robot? (1 = very uncomfortable, 5 = very comfortable)
5. What one change would make the robot easier to work with?

Question 1 is the key diagnostic. If staff are frequently completing robot-assigned tasks themselves, the KPI data will be misleading — you'll see low robot utilization and assume the robot is underperforming, when actually staff are routing around it. This is a change management problem, not a technology problem.

If the week-4 survey shows high rates of staff self-completing robot tasks, address it directly in a brief team meeting before week 8.

Vendor SLA Scorecard (Run Monthly)

Rate the vendor on these 10 line items each month. Use a 1–5 scale. Any item rated 1 or 2 two months in a row is escalation territory.

1. Uptime: actual vs. contracted
2. Response time to support tickets
3. Time-to-resolution for on-site issues
4. Software update communication (advance notice vs. surprise)
5. Quality of software updates (did they improve or regress performance)
6. Parts availability when requested
7. Account manager responsiveness
8. Accuracy of usage/analytics reporting
9. Escalation handling (did the vendor escalate internally when needed)
10. Overall operational reliability

Phase 3: Decision Gate (Weeks 11–13)

KPI Review

Pull the KPI data for the full 90-day period and compare against the signed baseline document from Phase 0. Do this with the Finance director present, not just the operations team.

Adjustments for seasonality: if occupancy or cover counts during the pilot period were substantially different from the baseline period, document that difference and adjust your comparison accordingly. Don't claim a robot-driven improvement if it coincides with a volume increase.

TCO Projection

Using the actual 90-day operating data, build a 3-year TCO projection. Categories: hardware (purchase or remaining lease), integration costs (already sunk), service contract, software, parts, and any staff time spent on robot maintenance/management.

Compare the 3-year TCO against the 3-year labor cost of the work the robot is displacing (or augmenting). If the robot is projected to save $X in labor over 3 years and the TCO is $Y, the economics are clear.

The Decision

Three possible outcomes:

Scale: KPIs met or exceeded, TCO projects positive return. Proceed to Phase 2 with expanded deployment, additional units, or both. Document what worked and why before you expand.

Modify: KPIs partially met. One or two KPIs hit; one missed. Identify the root cause of the miss — was it a technology failure, a utilization problem, a staff behavior issue, or an infrastructure gap? A 30-day modification window may be appropriate if there is a clear, addressable cause. This is the only condition under which extension is warranted. Write down what specifically is being changed and what threshold must be reached by the end of the 30-day extension.

Kill: KPIs not met and root cause is not addressable within the property constraints. Execute the vendor exit plan. Redeploy staff time to other priorities. Write a one-page post-mortem that future decision-makers can use.

The Hardest Discipline

Actually killing a pilot when the numbers don't work. There is always a case for extension. The vendor will make it. The internal champion will make it. "We just need a few more weeks" is the most expensive phrase in hospitality technology.

The kill criteria document you wrote in Phase 0 is your protection. Either the numbers are there, or they're not. Stick to the criteria you agreed on before you had any emotional investment in the outcome.

What This Playbook Produces

At the end of 90 days, you have:

• A signed KPI document with baseline and result comparisons
• 10 weeks of daily incident logs
• Two rounds of anonymous staff feedback
• Monthly vendor SLA scorecards
• A data-backed decision that Finance can audit

Whether you scale, modify, or kill, you have spent 90 days building organizational knowledge about what robot deployment actually looks like at your property. That knowledge — the vendor relationship dynamics, the infrastructure requirements, the staff behavior patterns — is valuable regardless of the outcome.

Most hospitality pilots don't fail because the robots are bad. They fail because the pilot was never designed to produce a real answer.