Image: Elite Event Robotics, via ABC7 News
Why “How Does It Get There?” is a SE Question, Not Just a Shipping Question
I tell my students: if you’re designing a server tower, you might find yourself putting hooks on the top of the rack system. Not for operational reasons, but because you have to get the server to its operational environment. The hooks are used to strap them into the truck that will transport the server. It’s a designed element that’s required when you consider the transition process. The hooks have no operational value but are required for proper deployment.
As a Systems Engineer, you need to always design for the system’s life cycle, not just its operational setting.
I thought about those hooks when I read about Bebop.
On April 30, 2026, a humanoid robot named Bebop tried to catch a Southwest Airlines flight from Oakland to San Diego [1]. Bebop is a 4-foot-tall, 70-pound entertainment robot operated by Elite Event Robotics, a company that rents humanoid devices for corporate events. That’s a sentence I would not have expected to write five years ago, but here we are. Bebop had done its job at a Bay Area engagement and needed to get to Southern California for the next one. The team did what any working professional would do: they bought it a plane ticket.
That’s where things got interesting.
Bebop’s first problem was the aisle seat. Southwest Airlines has a policy about large carry-on items in aisle positions, and a 70-pound robot apparently qualifies. Bebop was relocated to a window seat [2]. Problem apparently solved. Then came problem number two: the lithium battery powering Bebop exceeded Southwest’s maximum allowable size. Federal aviation safety guidelines restrict lithium batteries on commercial flights due to fire risk, and the crew decided the battery had to go [1]. So it did -- confiscated on the tarmac, leaving Bebop to complete the journey fully operational except for the part where it operates. The flight landed in San Diego about an hour late, with one very professionally seated but thoroughly inert robot aboard [2].
I’m not here to mock Elite Event Robotics. They’re clearly entrepreneurial people doing genuinely interesting work in a new space. But Bebop’s Oakland adventure is a systems engineering problem wearing an aviation news story costume, and I think it’s worth pressing on that a little.
Think about what Bebop was designed for. The functional requirements flow from what Bebop does at the event: dance, interact, entertain, and represent the brand. That’s the mission. Those requirements say nothing whatsoever about what Bebop needs to do to get to the event. And that’s the gap.
The INCOSE SE Handbook 5th Edition (SEH5) defines the purpose of the Transition Process as: “to establish a capability for a system to provide services specified by stakeholder requirements in the operational environment” [3]. That framing is easy to read and just as easy to misread. It sounds like it’s talking about the operational environment -- the place where the system does its thing. But the Transition Process is concerned with something prior to that: the move from “system-in-the-lab” to “system-in-the-field,” in the Handbook’s own terms. Getting there is a process, and that process has requirements of its own.
The SEH5 activities for preparing the Transition include analyzing “the intended environment for the system deployment, including the physical sites” and identifying “the requisite enabling systems, controls, products, or services required for the transition” [3]. In Bebop’s case, the enabling system for transition is commercial aviation. And commercial aviation comes with constraints: TSA lithium battery restrictions, airline carry-on policies, weight limits, and seating configurations. None of those constraints show up in a requirements document written for an entertainment robot performing at a tech conference. They were invisible right up until they weren’t.
The Handbook also notes that enabling systems needed for transition should be identified “early in the life cycle to allow for the necessary lead time to obtain or access them” [3]. That’s the note in the margin that Bebop’s handlers needed before they got to the gate in Oakland.
What does good transition planning look like for a robot-as-a-service company? It might look like a battery specification defined not just by what enables Bebop’s best performance, but also by what can legally be carried on a commercial aircraft. It might look like a pre-flight verification step in the standard deployment checklist. At the very minimum, it looks like someone asking “how does it get there?” during the design phase, rather than at the boarding door.
My server rack hooks have no operational value whatsoever. No customer has ever asked for them. They’ll never appear in a user manual. But they exist because, somewhere in the design process, someone considered the full life cycle rather than just the moment of use. That’s the discipline the SEH5 Transition Process is asking of us -- not paperwork for its own sake, but the habit of thinking past the demo to the deployment.
Bebop arrived in San Diego. That’s something. But it arrived without its batteries, which is a bit like a jazz musician showing up to a gig without their saxophone. Technically present. Technically not ready to perform.
The batteries had to be overnighted to Chicago for the next event [2].
Somewhere in that scramble, a requirement was missing from the design documents and was addressed later rather than sooner. Bebop’s battery problem wasn’t a shipping surprise -- it was a design decision that nobody made.
Reflection question: In your current or most recent program, when in the life cycle did your team first identify the enabling systems needed for transition? Was it early enough to actually influence the design?
Optional Reader Resource
References
[1] “Robot Passenger Traveling for Work Causes Southwest Flight Delay.” UPI, 4 May 2026, https://www.upi.com/Odd_News/2026/05/04/Southwest-Airlines-Oakland-California-Elite-Event-Robotics-Bebop/1581777911612/
[2] “Humanoid Robot Named Bebop Causes Southwest Airlines Flight Delay Out of Oakland San Francisco Bay Airport.” *ABC7 San Francisco*, 1 May 2026, https://abc7news.com/post/humanoid-robot-named-bebop-causes-southwest-airlines-flight-delay-oakland-san-francisco-bay-airport/19016906/
[3] INCOSE. *Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities*. 5th ed., Wiley, 2023. Sec. 2.3.5.10: Transition Process.
