Missouri S&T's Campus Robot Delivery: A Pilot Playbook

Did Missouri S&T sign a robot delivery partnership in June 2026?

Not according to the sources reviewed for this article. No June 2026 announcement of a new Missouri S&T and Starship partnership turned up. What the record does show is a sequence that matters more to a campus dining team: a launch in late 2022, a service that drew praise in 2023, and a June 24, 2026 dining update reporting that the Starship robot delivery service on campus had ended.

That update said dining staff were exploring alternative delivery options and that it was not yet clear whether a new robotic service would run by fall. This article therefore does not describe a partnership. It uses the S&T timeline as a case study and sets out what a dining operator should define before any robot pilot starts.

How did the S&T robot service start and stop?

Starship launched robot food delivery at Missouri S&T in November 2022 with a fleet of 16 robots, working with S&T Dining Services. Students placed orders through the Starship app, and the university said no university funds were used. Those details come from S&T news and a Starship release.

In April 2023, St. Louis Public Radio reported that the service was described as a success after six months, and that S&T viewed the robots as a recruiting tool. A success report after six months is not the same as a durable arrangement, though. By August 2026, St. Louis Public Radio reported that Starship was ending service on college and industrial campuses to concentrate on grocery and hot-food delivery to residential areas. A KY3 report from August 19, 2026 said Missouri State had pulled its delivery robots from campus.

The sources do not give S&T's reason for ending the service, and they do not name the replacement option dining is exploring. Anyone writing about this case should say so plainly rather than fill the gap.

Which routes should a campus define first?

Start with the origin and the destinations, not the fleet count. A route is a mapped path from a fixed pickup point, such as a dining hall window or a cafe counter, to a fixed drop point, such as a residence hall lobby or a study lounge. Each leg should be walked and timed before any robot runs it.

Count the physical obstacles on each route: doors that need a card, elevator waits, curb cuts, stairs, crowded crosswalks and construction zones. A route that looks short on a campus map can carry three crossings and a staffed door the robot cannot pass without help. Routes with predictable traffic and few decision points usually make the best first pilot.

Keep the first route list short. A pilot with two or three well-understood routes produces cleaner data than one that tries to serve every building on day one.

How should service hours be set?

Service hours answer two questions: when students order, and when walkways are quiet and safe enough for robots to run without trouble. Those two windows rarely line up perfectly. A lunch-only service has very different economics from one that runs until late evening, and the team should decide which one it is signing up for before the first order.

Write down the first and last run of each day, weekday and weekend differences, term breaks, holiday closures and weather holds. Snow, heavy rain and large events all change what a sidewalk looks like to a robot's sensors, so the hold rules belong in the operating document, not in someone's memory.

Where do handoffs happen, and who fixes a stuck robot?

A handoff is any point where responsibility passes between people and machines: the kitchen window where food is loaded, the arrival at a destination door, the lid opening, the confirmation that the right person received the order, and the procedure if no one collects it. Each handoff needs a named person or a named system, and the procedure should be posted where staff can read it during a rush.

Fault handling is the part most pilots leave vague. Decide who is called first when a robot stops in a doorway, how remote triage works, when a technician comes on site, and what the response time is for a blocked route versus a dead battery. A campus with a spare unit or a backup robot program can keep orders moving while a repair is scheduled, which is far better than a robot sitting in a corridor for hours.

This is where a single integrator helps. Service Robot Co. is an OEM-neutral integrator: we select robots that fit the route, then offer them to customers through financing on a 3-year lease with one fixed lease payment quoted after a site assessment. We deploy, integrate, train and service each unit through a nationwide US engineer network, so a dining team has one partner for remote triage, on-site dispatch and go live support instead of separate contacts for the robot, the kitchen and the network.

What should a pilot agreement cover before launch?

The S&T timeline makes exit terms the most important part of any agreement. A robot pilot can run for years and still end, so the document should settle what happens before anyone commits to a term. Put the following in writing:

Settling these items up front matters because each one would otherwise be answered during an outage, when the dining team is short-handed and pressure is highest.

• An exit clause stating what happens to the hardware, the mapped routes and the ordering integration if service ends early.
• Response times for each fault category, with one named party responsible for each category.
• Handoff rules for the kitchen window and every destination door, including what happens to an uncollected order.
• Custody of order logs, route history and incident records, and how the campus can export them.
• Go or no-go criteria, tied to delivery counts and staff hours and agreed before the first run.