In this episode of Client Horror Stories, host Morgan Friedman sits down with Sheila Butler, a seasoned hospitality and marketing executive, to dissect a project that began with enormous promise — the integration of 20,000 luxury hotel rooms into a global booking system — and ended up colliding with technical failures, mismatched vendor expectations, and, fatefully, the global shutdown of March 2020.
The story unfolds as a cautionary tale about enterprise decision-making, tech integration pitfalls, and the human dynamics that can make or break massive projects. It’s not a story of malice or incompetence, but of how complex organizations — with their silos, assumptions, and optimism — can create perfect storms when too many moving parts align imperfectly.
The Ambitious Partnership
Sheila begins by setting the stage: she was working at a large, heavily franchised hotel corporation when the opportunity emerged to add 20,000 new rooms — roughly 50 properties across Mexico and the Caribbean — into the company’s system. Each property offered high-end, all-inclusive experiences with amenities like 24-hour butler service, swim-out suites, and top-shelf alcohol. The partnership was monumental — both in scale and in what it symbolized for the brand’s growth metrics.
However, there was a structural problem from the start: the corporate entity did not process guest payments. Each franchise hotel handled its own transactions. For this new international partnership, they would have to build an entirely new payment processing infrastructure at the corporate level.
As luck — or misfortune — would have it, another team in the company was already evaluating payment processors for a separate initiative. Leadership “strongly encouraged” Sheila’s team to use the same vendor, on the logic that one company-wide payment platform would create consistency and efficiency. Sheila admits this made superficial sense — “how many payment vendors does one company need?” — but as Morgan quickly observes, being pressured to adopt an inherited vendor is often a major risk factor in enterprise projects. What works for one initiative may fail spectacularly in another.
Technology on a Fault Line
From there, the project became a massive, multi-team endeavor involving dozens of engineers, marketers, and external partners across the U.S. and abroad. Sheila spent long weeks traveling to coordinate with tech teams, vendors, and leadership.
Their primary task: design and implement a payment flow that could handle deposits, refunds, final payments, and time-sensitive triggers for a network of properties in multiple countries. The pressure was high — corporate performance was measured by unit growth, meaning the number of new rooms and properties integrated before the end of the fiscal year.
So they pushed. Hard. Sheila and her colleagues were working through Christmas Eve, aiming to launch by December 27th to meet their corporate metrics.
But when they finally flipped the switch, the launch revealed a spectacular failure.
Instead of displaying luxurious descriptions like “Junior Suite Swim-Out with 24-Hour Butler Service,” the system showed every room as a generic “King Bed, Non-Smoking.”
The bug rendered the properties unsellable. Guests browsing for a romantic getaway or family resort saw nothing to justify the premium pricing. “You can’t expect someone to pay top dollar for a ‘King Bed Non-Smoking,’” Sheila recalls. The team had to halt the rollout immediately, realizing that the system’s architecture couldn’t overwrite certain hardcoded fields. In other words, parts of their tech stack were so deeply embedded in legacy systems that customization was nearly impossible without rebuilding from scratch.
Legacy Systems & Forgotten Knowledge
Morgan highlights a recurring theme in enterprise disasters: technology built on top of technology, with poor documentation and long-forgotten constraints. As Sheila notes, “Unless people have been there for a really long time, you don’t totally remember how it’s built.”
The team spent January and February rebuilding portions of the system, debugging and documenting as best they could. Finally, after weeks of late nights and cross-department coordination, everything seemed ready for relaunch in early March 2020.
That’s when history intervened.
The World Stops Turning
The relaunch went live the week of March 11, 2020 — the same week the COVID-19 pandemic shut down the world.
Almost overnight, international travel collapsed. Borders closed. Hotels shuttered. Some properties decided to use the downtime for renovations. Others simply went dark.
After years of preparation, the 20,000-room rollout never got to shine. Even the subsequent marketing push — a sweepstakes campaign highlighting the brand’s beautiful new resorts — couldn’t revive momentum. To make matters worse, the partner company was soon acquired by another hotel group, effectively ending the collaboration.
Sheila sums it up with bittersweet understatement: “We didn’t really get to realize all of the amount of work that went into this.”
The Payment Processor Problem
Beyond the pandemic, another ticking time bomb was hiding in the project’s foundations: the payment processor that had been “strongly encouraged” by corporate wasn’t ready for international deployment.
The vendor’s technology couldn’t process payments in several of the Caribbean and Latin American countries involved. The company had promised those capabilities were “on their roadmap,” meaning they’d be available soon — but as Morgan wryly notes, “Hope is not a strategy.”
Enterprise sales teams often use roadmaps as vague assurances rather than firm commitments. Sheila’s team bet on those promises, planning their entire go-live around an anticipated capability that never arrived.
It’s a perfect illustration of a common corporate delusion: assuming a vendor’s future development timeline will sync neatly with your project’s immediate needs.
Lessons from the Wreckage
From this painful experience, both Sheila and Morgan extract a cascade of insights — not just about technology, but about organizational psychology, cross-department communication, and the human element of collaboration.
- Stagger Your Launches
Sheila’s team had wisely chosen to launch in phases, which saved them from a total catastrophe. When the first wave failed, only a small portion of the portfolio was affected. Morgan praises this as a textbook example of risk mitigation: if something breaks, it’s better for it to break small.
- Acknowledge the Unknown Unknowns
Both agree that “unknown unknowns” — the things you don’t even know you don’t know — are the silent killers of projects. In Sheila’s case, no one even considered that the system might not support custom room descriptions, or that a payment processor could fail in certain countries. Experience, Morgan says, helps reduce unknowns over time, but humility and curiosity are the best defense.
- Keep Track of Your Tech Stack
Sheila underscores the importance of maintaining documentation as technology evolves. Over time, companies make incremental “band-aid” fixes instead of full rebuilds, leaving tangled systems that no one fully understands. When the original developers leave, institutional knowledge vanishes — setting the stage for failure.
Morgan extends this point with a chilling anecdote: some software developers intentionally avoid documenting their work to make themselves indispensable. It’s a cynical but real-world tactic that traps companies into reliance on a single vendor or team.
- Meet People in Person
In one of the episode’s most human takeaways, Sheila and Morgan discuss how meeting in person changes everything. During the project, Sheila prioritized in-person kickoffs and dinners with cross-functional teams, believing that face-to-face connection builds empathy when tensions rise.
Morgan agrees, adding that even a single meeting transforms a faceless colleague into a real human being. “It’s hard to be mean in person,” he jokes, noting that video calls can at least partially replicate that sense of presence. In his own practice, he insists all Zoom calls have cameras on — a small but meaningful way to preserve human connection in digital collaboration.
- Document, Always
Both guests lament how documentation often falls by the wayside. Morgan notes that developers sometimes see it as optional or even leverage it for job security. Sheila adds that organizations underestimate how much time and pain they could save with simple, consistent documentation protocols — especially in long-term projects that outlive individual employees.
- Find the Balance Between Marketing and Tech
A recurring organizational friction point is when marketing should bring in tech. Too early, and engineers complain there aren’t enough details to act on. Too late, and they say they weren’t consulted soon enough. Sheila describes it as a constant dance — “too soon or too late depends on the project.”
Her takeaway: cross-functional communication should start early enough for tech to flag feasibility issues, but not so early that discussions become hypothetical time-wasters.
- Define the MVP (Minimum Viable Product)
One of Sheila’s most vivid moments comes when she describes sitting in a room with forty people debating obscure “what-if” scenarios — the kind of one-in-a-million cases that engineers love to fixate on.
To break the stalemate, she invoked her favorite facilitation rule: “Elmo — Enough, Let’s Move On.” She even offered $100 to anyone who could prove one of those edge cases would ever actually happen. Morgan bursts out laughing, recognizing this as the classic battle between perfectionism and pragmatism. In software development, these scenarios are called “edge cases,” and knowing when to move past them is crucial to shipping products.
The Emotional Arc: From Whiskey to Elmo
As Morgan quips, the episode begins “with whiskey and ends with Elmo.” It’s a humorous metaphor for the emotional range of large-scale projects — from ambitious adult challenges to almost childlike lessons in communication and patience.
Sheila’s storytelling is filled with humility. She doesn’t blame the payment vendor, the pandemic, or her colleagues. Instead, she frames the experience as a collective effort by good people doing their best in impossible circumstances. That self-awareness gives the story its warmth and credibility — a reminder that most business disasters aren’t born from villainy but from complexity, overconfidence, and the limits of human foresight.
Key Takeaways
By the episode’s end, Morgan distills the conversation into a series of principles that resonate far beyond hospitality:
- Vendor alignment is not the same as vendor suitability.
A shared platform may promise consistency, but context matters more than uniformity.
- Legacy systems carry invisible landmines.
The older and less documented your tech, the higher your project risk.
- Roadmaps are not guarantees.
“It’s on the roadmap” often means “we might do it someday.”
- Empathy mitigates risk.
Humanizing your collaborators — meeting, seeing, and listening — prevents conflicts from escalating.
- MVP thinking saves sanity.
Don’t let edge cases paralyze progress; get the core right first.
- Unknown unknowns require humility.
You can’t predict everything, but you can cultivate curiosity and resilience.
Epilogue: The Real Cost of Complexity
Sheila’s story isn’t about failure — it’s about the cost of complexity in modern enterprises. Every decision — from vendor selection to tech documentation to cross-department timing — ripples across hundreds of people. Even when everyone works hard and means well, a single misalignment can derail years of effort.
In the end, Sheila can look back with hard-earned wisdom and humor. The 20,000-room launch that never reached its potential became a masterclass in collaboration under pressure, the unpredictability of global business, and the humility to admit what you don’t know.
As Morgan puts it, laughing, “From whiskey to Elmo — that’s quite the emotional arc.”
And perhaps that’s the quiet moral of this “client horror story”: Every catastrophe teaches you something, but only if you’re willing to see it not as a failure, but as the tuition fee for becoming wiser.
