Global airline / Ground operations / Experience strategy
The Bags Moved. The System Didn’t Know How.
Designing ground operations around the judgment that kept them moving.
A driver worked around the route on the device, delivered the bags, then confirmed the steps afterward. The job got done. The system missed the part that made it possible.
I established and directed the Below the Wing experience effort through its maturation and handoff, with a dedicated team and some leadership shared with Above the Wing. I connected operational research to more coherent workflows, tools and design priorities. Our research and design team developed the foundation for change across baggage movement, ramp activity and the handoffs between them. The ambition was an operation whose tools could support the judgment keeping it moving.
BRIAN DAVID HENDERSONTHE PROOFFollow the Story
The workaround was doing the work
Field research exposed people completing the job while the software lost track of their judgment.
In the Atlanta field notes, a transfer driver described a routing problem. The prescribed sequence could send a driver past work that needed doing, only to bring them back later. Confirming steps on the device added further friction.
The response was practical. Do the work in a more useful order. Confirm it afterward.
That is an uncomfortable finding for an organization trying to understand its operation through a system. A completed task can look perfectly compliant while concealing the judgment, route changes and extra effort that got it completed.
At Minneapolis, a dispatcher described a different version of the same problem. They would intervene to improve an assignment, then automated scheduling could change it again. The research notes preserve the request:
“If you take anything else from this meeting, don't let [the scheduling system] make changes to a flight once I've intervened.”
The dispatcher was asking the software to respect a decision already made with operational knowledge.
Elsewhere, agents described waving scanners to find reception, manually counting bags when scanning failed, and relying on paper instructions that could become obsolete after a flight change. One agent had discovered a rerouting application on the desktop without anyone explaining its arrival.
This was what the research team brought back from the operation. The people were compensating for the tools while the tools supplied an incomplete picture of the people’s work.
Automating more of that arrangement without understanding it could make the contradiction faster.
Eight airports. More than one reality.
Research across roles and stations revealed why a local screen improvement could leave the wider operation broken.
61 subprocesses mapped across 10 core processes
The original research readout represented eight airports and 67 role-count interview entries across the ground operation. The roles included ramp agents, aircraft load agents, dispatchers, baggage drivers, trainers and baggage-service staff. Those entries describe research coverage, rather than a verified unique-participant count.
The variety mattered. Equipment, staffing and working practices differed between stations. One operation used a device to assign transfer work; another relied on a manual “gopher yard.” At Cancún, outsourced ground crews and the absence of RFID scanning created different conditions from those at domestic hubs. Training arrangements varied too.
The team documented more than 32 station variations. A standardized experience would have to accommodate meaningful operational differences or be accompanied by a deliberate change in how the station worked. Simply declaring one location’s practice universal would push the difference back onto the employees.
The mapping extended across 10 core processes and 61 subprocesses. Following a bag exposed decisions and handoffs that an application-by-application review could miss: assignment, loading, transfer, rerouting, claims, resource scheduling and the preparation needed before an agent could begin.
Some of the most important failures began above the wing. A passenger could be rebooked without a corresponding baggage update. Ground staff then inherited the discrepancy. A successful transaction in one part of the operation could create a problem in another.
From the passenger’s side, a rebooking means being sent on a new journey. The bag needs to make that journey too. The handoff is part of the customer experience, even when the customer never sees the employee responsible for it.
That relationship gave the experience work its real scale. A driver’s route, an agent’s screen and a dispatcher’s assignment were connected decisions. Improving one while leaving the handoff ambiguous could move the burden without removing it.
Our design direction had to account for the work between the screens. I kept that cross-process ambition central to the experience strategy. The team’s process maps made it concrete enough for operations, product and technology colleagues to examine together.
Research captured station-specific operating practices and constraints across eight airports. The historical comparison is not exhaustive.
Design for the moment the signal disappears
Our team translated 40 opportunities into workflows that accounted for connectivity, exceptions and human decisions.
The team developed 40 improvement opportunities, connecting operational findings to target workflows and the measures the business cared about. On-time departure, baggage handling, safety, communication and resource use gave those choices consequence.
The design work had to earn trust under ordinary airport conditions: interruptions, changing assignments, imperfect connectivity and tasks that did not politely wait for the application to catch up.
Consider scanning. A future flow that works only with a continuous connection offers very little reassurance to someone already waving a scanner in the air. The target designs included an offline mode and later upload, allowing the workflow to account for loss of connectivity rather than pretend it away.
Or consider the driver. The proposed routing experience allowed manual adjustment when the suggested sequence was unsuitable. That gave operational judgment a place in the system, instead of forcing it into an invisible workaround.
The concepts also addressed the handoffs around the aircraft. Clearer task feedback could distinguish baggage types. Multiple belt-loader pairing could support the operation more coherently. Digital inspection and load-workflow concepts could make state, responsibility and confirmation easier to follow. A device could move from an arrival workflow into departure work without making the employee rebuild the context from scratch.
These proposed design decisions changed what the experience needed to know. Who has accepted the assignment? Has the task actually been completed? What changed after the instruction was issued? Can the person doing the work see the exception and act on it?
I directed the experience work around those connected questions as research became design. A clean screen could still conceal an incomplete operational model. Our designers supplied the detail that mattered: how a person would continue when the ideal sequence broke. Researchers and client specialists gave that work the operational grounding a screen review alone could not provide.
The resulting design foundation covered three major flows: ramp arrival, ramp departure and baggage transfer, with more than 20 high-fidelity target-state screens reported in the final readout. Subsequent foundational designs explored the work in greater detail, including offline upload and the difference between a passenger’s itinerary and a bag’s location or intended movement.
The operation began to appear in the experience as a sequence people could understand, question and complete, including the moments when the normal path was no longer available.
Proposed handheld transfer-task designs, shown as design evidence rather than deployed functionality or measured outcomes.
Foundational design concept for uploading offline task data after connectivity returns. This is proposed behavior, not production-reliability evidence.
The economics of doing the same work twice
Separate historical scenarios describe $15M–$20M in annual cost opportunity and $10M in retained revenue, both unvalidated projections.
$15M–$20M in estimated annual cost-reduction opportunity Owner-reported historical business-case projection presented to the airline to help secure the initial engagement; not achieved savings or a verified client-approved financial forecast. A separate $10M annual retained-revenue opportunity scenario appears in Chapter 4; the figures are not additive.
The cost of fragmentation can be easy to overlook because it arrives in small units: a repeated login, a return trip, a manual check, a message relayed through someone else, a task completed once in the operation and again on the device.
The historical internal case study described an estimated $15M–$20M annual cost-reduction opportunity associated with less manual handling, rework and operational delay. It also described a separate $10M annual retained-revenue opportunity associated with operational performance and customer experience.
These figures are retrospective business-case scenarios, not measured financial results. Their underlying assumptions and calculation detail were not independently validated. The cost and revenue categories are presented separately because their effects may overlap; they should not be added into a combined benefit claim.
The figures show the scale of value contemplated, while the research shows the concrete work through which value would have to be pursued. Reducing unnecessary movement, improving task state and making exceptions visible could create operational capacity. Translating that into lower expense, avoided cost or retained revenue would depend on implementation, adoption and actual operating changes.
The team’s 40 opportunities were organized against 12 operational metrics. That connected design priorities to the business decisions behind the investment. A clearer loading workflow could be assessed against departure and baggage objectives. Better resource visibility could be assessed against scheduling needs. An offline recovery path could be assessed against the disruption caused when connectivity failed.
The economic argument was therefore connected to specific operational mechanisms, even where the historical financial estimates remained provisional. The work established where improvement might come from and what a future implementation would need to prove.
Give the operation a place in the system
Research, target flows and detailed design established a foundation for implementation, with frontline judgment at its center.
The engagement progressed from field findings and process maps into target workflows, a prioritized roadmap and detailed design concepts. The final readout reported the three major flows and more than 20 screens; the later foundational-design deck carried that work further.
The organizational boundaries mattered. The delivery organization’s experience and research work informed the design direction. The airline’s internal workflow-framework and platform teams had their own responsibilities. Making the work executable required those contributions to meet, with clarity about what the design specified and what implementation still needed to resolve.
The documented outcome was a research and design foundation for implementation. Production deployment and realized financial benefits are not established by the available record.
The more lasting leadership insight sits in the opening incidents. A driver had found a better sequence. A dispatcher had already made a better assignment. In both cases, the system struggled to recognize the intelligence already present in the operation.
The researchers made that intelligence visible. Our designers gave it structure in workflows and interaction details. Client and technical partners brought the realities those designs would have to survive. My responsibility was to direct the experience strategy so that knowledge stayed connected as the work moved toward implementation.
The next experience needed to make the real work visible: the decision, the exception, the changing conditions, the person responsible for what happened next. It needed to help people exercise judgment and let the organization learn from that judgment.
The bags were already moving. The opportunity was to build a system that understood how.
Foundational baggage and passenger-itinerary design for the proposed reroute workflow, not a shipped release.
What is your operation accomplishing despite its tools?
Let’s find the decisions and workarounds that deserve a place in the experience you build next.