A Client Horror Story
That time when your big luxurious launch becomes underwhelming after being advertised as basic due to a tech issue…
Watch the full episode →Hey everyone, welcome to the latest episode of Client Horror Stories. I’m excited to have with me bright and early this morning, Sheila Butler. How are you doing, Sheila?
I’m well, bright-eyed and bushy-tailed as they say. Y es, and I’m with caffeine. You know less. I’m excited for the podcast. Doubly excited that you are probably drinking whiskey. At least according to your mug, you never know. I don’t spill every secret.
Well, I’m going to pretend that it is actually whiskey. It’ll make the episode more fun. Okay. And let’s jump right in. I’m excited to hear your client horror story. What happened?
So I was working at a hotel company and, um, it’s, uh, heavily franchised. And so there was a new partnership that I had signed, and it was to add 20,000ish rooms to our system. And if you think about the number of rooms in a hotel like 300ish, whatever. So 20,000 is a significant number of rooms to add into our booking system, right? And these properties were international. And so one of the requirements for this new partnership was that we would be able to take a payment process, a deposit, refund it, trigger out the final, the final payment requirement, et cetera. And it was all timed-based and so forth. And the thing is that the company that was working for, because of their franchise, they don’t actually take payments. The hotels do, but the corporate entity does not. So we had to build this, and we were all fully aware that we would have to build this. We’re like, we got it, that’s fine. And what’s interesting is there were another part of the company that also needed to take payments for another corporate initiative. And so they had already gone down this path of talking to different payment processors about requirements and evaluating who would be the best fit. And so when I got down this path, along with the leadership team, we were strongly encouraged to use the payment platform that had already been selected by the other team in the organization. And for better or for worse, that’s what we ended up doing. So the thing is that we got through so on the marketing side and on the partnership side, you’re driving the business requirements. You’re bringing the tech team along on and here’s what we’ll have to do if we sign this partnership and if we sign this payment platform, here’s all the details, right? So you’re building out the business requirements, the tech requirements. I’m spending a lot of time in another part of the United States with the tech team. And the payment platform people are coming in from California, et cetra. So we’re diving in really deep, and this is a significant project for the organization, so it’s a ton of tech hours.
Pause for a second. Just analyze the detail that you said. Uh, what I think is interesting that you didn’t really choose the vendor because you got pressure from this vendor that was already selected and interestingly, like in my experience, that’s already a huge risk factor as well, they’re like thrust on you these people that may or may not fit.
I would say we were highly encouraged to pick the same platform because of the fact, and if you think about it, I mean, if it’s a payment platform, how many different vendors do you need? If there are two different projects in the company, can’t you just use the same people? So, there are brands if you think about it as a large hospitality company, they may all be buying blenders from different vendors. Can’t you just get the same blender from the same person every time? Like, why do you need different people or different companies? Right? So anyway, that ended up being part of the challenge in all this. So, we get down the path and it’s also complex partnership in that the rooms to describe the guest experience are very different. So, these are junior suite, swim out, 24 hour butler service. So, we’re building all these amenities that we as a hotel brand normally don’t have in our system. We don’t have these types of properties. And we started launching a few of the hotels right around Christmas and years because we’re trying to hit a deadline within our organization. And that deadline is at the very end of the year, and we’re measured by unit growth for the business. Okay and so unit growth, meaning the number of properties and the number of rooms in the system. So, we’re pushing really hard to get this thing going. We’re working Christmas Eve and we’re rolling out stuff on maybe like December 27th, I think is when we first turned things on, and when we turn it on, it says something like king bed non-smoking room. And we’re like, oh my, how is this possible? This is not how we can describe the rooms to be clear in same way. Like you were saying, every room was a King’s bed. So yes, instead of like Junior Suite swim out, 24 hour Butler service, it, you know, shows up as King Bed non-smoking. We’re like that, that’s not what we do. And in part it’s because the tech stack, and I could be, by the way. If there are people who I worked with on this who are listening to this, they’ll be like, that’s not exactly how we remember it because this was several years ago. I think part of the challenge is too, know your technology. And the fact is that when you build technology on top of other technology, unless people have been there for a really long time, they’ve documented all this, you don’t totally remember how it’s built, right? You don’t remember the things that can’t be overwritten. So we end up having to stop and not turn on these rooms. We’re basically like, wait, we can’t sell these like this. And the partner’s frustrated.
Wait, so to be clear, it was like right around Christmas a few years ago, you did this big launch for the 20,000 new rooms. And then, in the system, it just described everything completely wrong as basic room.
Right as of how we as a brand would normally display our rooms. It’s like we don’t describe all the amenities and so forth. Right. And so we’re like, okay, this is not gonna work. We can’t sell these rooms. There is more expensive food and alcohol included in these things. So you can’t just say King bed non-smoking. Exactly. And expect someone to pay this dollar amount. Right. It’s not gonna work.
Oh, I see. Because these are all high-end luxury rooms. Yes, every room in the system was just described as basic rooms. So, like why would someone pay double if it’s right. I see. Right. I wanna know if there’s, if there’s alcohol included.
Yes, the rooms had alcohol included, so we paused and we said, okay, we’re not gonna turn these. Don’t show them in the system as available for the ones because we were staggering out the launch. Right. Which is a good thing to do. So we thought of the ones that we’ve already put in the system, let’s just go ahead and pause and let’s go back, do more tech work and then we’ll turn it on when we’re ready. So, we do all this work in January and in February. We’re finally ready to turn thing on. Question before we talk about turning it back on, did you guys figure out what happened so that everything was described completely wrong, like basic rooms, because this is a huge failing. Did you figure out where that disconnect happened? Yeah, it’s the fact that there were things that were hardcoded in our system, when you tried to overwrite it, you couldn’t overwrite it. So, you would basically had to back out and rebuild parts of the system again and again, I’m not a techie person. Yeah. friend partnership. So that’s my lame. You know, Nove, like someone who isn’t a tech person trying to explain something techy. So, take that with a grain of salt. So, we do all this work, we’re working terribly hard. And again, there are lots like there are easily 40 to 60 people in the organization who are working on this huge initiative. And not to mention the partner, not to mention the payment platform people. And we all have things in our goals that are around the revenue that we’re gonna be driving. The number of. Rooms booked, et cetera. So, we’re just working really hard to deliver this thing. So, fast forward to a couple months later, so it’s now March, and so we finally get everything right. We’re ready to turn on all these properties. It’s more than 50 hotels, right? And the Caribbean and in Mexico. And we pretty much flipped the switch on and that week was the week of March 11th, 2020. Does anyone remember what happened that week? By chance, the world shut down, these properties started shutting down. No one could leave their country. And there you go. So, a couple of months later, when the properties started opening again, and some of them ended up going through a big renovation, they’re like, listen, if we have to shut down, we might as well just renovate the property. So, these properties start to turn back on again. We run a sweepstakes, trying to promote the fact that, you know, or not even trying, but promoting the fact that we’ve got these beautiful properties and some are, you know, for religious couples, some are for families, et cetera, et cetera. And at the end of the day, the partner ended up being acquired by another hotel brand. And we didn’t really get to realize all of the amount of work that went into this, but I will also tell you that part of the challenge, and I mentioned the payment platform is that as we were getting closer, we were realizing that while they worked as the payment platform for this other initiative within the organization, that this payment platform didn’t have the ability to process transactions in certain countries. It was on their tech roadmap, but it wasn’t there yet. And so what I would say, net and all of these things are, even though you can pick the same vendor if they don’t have the ability at the moment to be able to deliver on these things. It’s really sort of sketchy place to be because we were planning on their roadmap is such that they’re gonna be able to get there. So, by the time we’re in need, they’ll be right. The payment processor will be there and they’ll be able to work and process transactions for these properties in different countries. It was a hard project. And they’re beautiful properties. The partner was great. The payment platform people were super nice too. It was a tough gig, I have to say.
Okay, so interesting situation. Let’s talk about it because I think there are a few interesting lessons that we could extract because you are in a situation where you’re a non-techie, but you’re kind of managing or semi-managing or have a key stake in a Tech project. And what happens all the time is like, as you become a manager, you have to manage things that you don’t fully understand as well. So, I think there are a few lessons. So, here we’ll start with the positive lessons. One positive lesson is the importance of staggering launches.
Yes, because staggering, like when you launch it, like piece by piece, if anything goes wrong, you rather then see go wrong for all few hundred thousand hotels at the same time. Only for like one venue, one little part. Right. So that’s something that went well in your story. Another lesson is, you know, there’s this old saying’s like ‘What you don’t know that you don’t know? It’s like, okay I don’t know. The technology will be used, I don’t know when it’ll launch like there are lots of things you don’t know, but then like you don’t even know that you should be thinking about what countries the payment processor actually available in. Well and we knew that they weren’t available at the moment for some of the hotels, but the belief was they had it on their roadmap as well, and so they would be ready by the time we got to that point, we’re like, okay, all right that you know, there were a lot of things that needed to fall together to or to come together that didn’t necessarily come together.
Oh, I see. Okay, I see this. This goes back to the saying, ‘Hope is not a strategy’, say, okay, it’s on the roadmap. They’ll get to it eventually, but in real life, often on the road, I haven’t done enterprise sales, I know. Oh, it’s on our roadmap is a way to say. We’re not doing it at all. But if we really need to one day, then we will rush to do it. So. Yeah.
And it was hard for them. I mean the payment processors, assuming revenue will be driven by this, they didn’t expect the world to shut down either. Right. No one anticipated that. So, it’s difficult when you’ve got multiple brands coming together to bring something to fruition. Right. That’s an enormous project for the organization. So, this is an interesting challenge that big enterprises like consistently face because your point before is completely correct. Like, why do we have 20 different payment processors? Why not just have one? Because when you just have one or like one big vendor for something, you can do things like negotiate to get a better deal. But the challenge with that is local knowledge. Different places and different situations really have different requirements and this thing might be much better for this, but much worse for that. So, this sort of internal pressure, where you are strongly encouraged, can actually be a very substantial risk factor as well. Yeah, it was one size fits most. Right. So, I’ve never heard that before. One size fits most, that’s my new favorite phrase and the details matter. But we knew that going in, we just thought, okay we can figure this out. I mean, I felt so badly. I remember going into the office of the guy on the tech sid who was leading it within our organization. And I walked in and I looked around his office and I fully expected that there would be a dartboard with my picture on it. And I had a colleague and she and I were like ketchup and mustard, like I was the front end of loyalty and partnerships and she was the back end to drive all the tech. And, she worked really closely with them. I thought for sure that there would be something to where they just had thrown darts. Um, on the board with our picture on, because it was a hard project, but they were probably much nicer in person when you met them in person. Everyone’s nicer in person.
This is actually another subtle lesson. Inevery episode, I try to get out one at least one new lesson that’s never come out in an earlier episode, and I think we just got this episode’s one, that everyone is nicer in person.
I like your words. Where something happens, it’s hard to be mean in person, right? You have to be a true asshole to be mean in person, but it’s much easier when you’re like invisible, just typing online.
Exactly. That is a good point. And this goes to one of my favorite team risk mitigation strategies and also client risk mitigation. To avoid client horror stories. Actually, this has never come up before incredibly, but it’s a really good point of meeting them in person. And something I found is even just meeting one time in person kind of changes everything, until you’ve met that one time, it’s just like, here’s just a voice on the other side of the world. And like, you can be a dig, it kind of doesn’t matter, but one time you meet, it’s like, oh my God. Sheila, she’s so nice. She’s like this. She does that. She probably drinks whiskey in her mugs and then suddenly you’re a human and to another real human, there’s just this instinct to like to be nice to them.
Well, and you know, there’s true meaning and importance in business dinners, right? So when we kicked things off interesting, we made sure we brought the teams together and the leadership together so that we all were working very collaboratively. Like we were trying to function as one unit, not separate organizations. And I think that makes a really big difference when you bring the leaders together and on a frequent cadence as well to really try and better understand one another. And for me, I think that part of that is when things get tough be’cause they did. You know that this is a genuine human being and they’re literally trying their very best.
Yes. I agree with that, knowing them in person, it’s easier to see that they’re just a person, doing their best as well, right? By the way, this is a similar reason why I only do Zoom calls or Google meet, et cetera with video. And whenever I have a call and someone’s video is off, first thing I say is, well, we have the honor of seeing you in person today. And the reason why I do that is because while with video, it’s not quite, the power of Sheila is a human that you realize over dinner together, you know, three feet away from each other, but it’s like a step closer to that than just a voice on the other end.
Exactly. Well, and when COVID started, that was, that was the policy that I had with my team, which was everybody’s gotta have a camera on, right? Just to focus and to again, connect with people in a really meaningful way. So, a lot of lessons learned in that one.
Lots of lessons to wrap up, actually, there’s one maybe to wrap up, there’s a lesson I started getting up before. I just wanna clarify and emphasize for the audience of the unknown unknowns, you didn’t even think that the software could not include room descriptions and so on, and when maybe me 20 years younger when I first heard the phrase Unknowns. Unknowns. It was like really theoretical. I was like, okay, whatever, like if I don’t know that, I don’t know it, how can you do anything about it? So I would just ignore, but it’s actually been very helpful in my career to say, what are the things that you don’t even know you should be thinking about and or if you’re changing the software, what are the factors or variables that could affect this software that you don’t know? Oh, I don’t know the tax situation for this. I don’t know. Oh, how stable is the company that’s underlying. What is the speed of their API? Maybe that could cause delay, or all these things that you don’t even know, but it’s worth the exercise to try to figure them out. And I think this is where experience come in because the longer you’ve been around, you’ve just seen the situations more and more and more and more. So, as a result, there are fewer unknowns. Unknowns, and it becomes easier to predict these things.
Yes. And I would add, so I’m gonna do a yes and build upon that. It’s keep track of your tech stack that you have over time. Right? Because think about it, it’s a huge expense to organizations when they think about rebuilding their tech, right? It’s a huge investment. And so what happens typically is I’ve got something and it’s not a great system. I’d love to change it, but when I price it out, I think I’m just gonna instead just sort of like make a tiny little tweak over here and then tweak over here and tweak over here, and then suddenly your tech is basically bandaid together. And then when you ask it to do something new and different, if you haven’t kept track of all of the different changes or the people who knew about it are no longer in the organization. And then it becomes incredibly difficult ’cause you’re trying to ask it to do something and you don’t even realize how far back some of the hard coding goes.
Yeah, that is a great point. And by the way, I’m gonna make your point even more extreme. I’ve known multiple people, some software developer friends of mine, and I’ve also known some software development shops that do this as a policy. As a policy, they do not document anything. And every time someone told me that, I’m like, how can you not document for the reasons you’re saying? Things change. You need to know it’s gonna cause problems and so on. For me, of course, you have to document and share how it works, how it connects. So, like the next people in the job, everyone can know and avoid these sorts of disasters. And every time, I’ve asked a software develop refinery told me that, or someone that runs a dev shop that does it, they always have the same response and they’re always like, Morgan, ’cause it makes us much more valuable. Because when it breaks down, we’re the only people that know how it works. So, they have to come, they have to come back and hire because we’re the only ones we can charge, we can charge much more. And it’s interesting. It’s a terrible attitude. It’s kind of depressing when multiple people and companies have said to me, in defense, I know a lab software develop dev chef. So it’s not the majority, maybe I’d say 20% of the ones that I know have made comments like that. And it’s something to keep in mind because again, this is a good example of the unknown unknowns. Like you might tell, ask your dev, oh, are you gonna document it so we can understand it in the future? And every Devon or Dev team in the world is gonna say, yes of course.. But the unknown unknowns are you are gonna go look at the code and read it. And people have different incentives, and a lot of people, even good people are out there just to make a buck. And this is one of the things you need to deal with.
Well, fortunately, we built really strong relationships between the marketing business side and the technology side, because at the end of the day, we’re gonna work on other projects, right? There’s always something on a tech roadmap that’s either a fix or a new request, et cetera. So it’s really important to bring groups and to have that relationship, especially when things go sideways. Right? What I will tell you is, it’s tricky to figure out when marketing and tech should start talking about a new project. So in this case, as we were negotiating with the partner. We were bringing in the tech team to say, these are the business requirements that we’re gonna have to fulfill, right? So, can we really do this before we sign this partner? We’re like, yes, this is important. We can figure, so now I haven’t done it before, but we can figure this out. And. What I would say is, it’s interesting on the marketing side, a lot of times in different organizations, not just this one company, but in many places they’ll say, marketing, why didn’t you bring us in sooner? Because the tech’s like, we just wanna be there at the very beginning of the onset to make sure totally, or, uh, ears and a voice in the room and we can chime in on things and ask questions and make sure that what you’re signing in a legally binding document that we can deliver, right? So when to bring, when should marketing bring in tech? When should tech bring in Marketing is a very different thing because the next partnership that we’re working on, we brought them in at the very beginning. We’re like talking to X partner. We may pursue it, we may not. And then the tech team, because this is what they need. They’re like, okay, well. What do you need us to do? What are the business requirements? We’re like, well, we don’t know yet. We’re still just exploring this partnership, but you said you wanna be at the very beginning, so we’re bringing you in. And they’re like, but you don’t have the answers. And we’re like. No, we don’t because we’re at the beginning. So, finding that balance of where and when to bring people in within the organization so, that it’s a good use of their time. And when is it too soon and when is it too late? And I think that changes in every project.
You know, I hadn’t thought about that question before, but that’s actually a very good question. I think I personally always have the instincts of bringing everyone in too early. But yeah, I feel like you’ll never bring in people at the right time. So like, thinking about this thing, like who else do I need to talk to? I think what you’re saying also hints at another point that you’re implying that’s also very interesting, which is the importance of going to the experts like, Hey, I’m doing this thing. I know nothing about the technology. Like, let’s get their side. So when you start a new partnership initiative within a company, oh, I know nothing about the legality about this. Okay, let’s bring the lawyer. And it goes back to like admitting the things that you don’t know. So, you can then, in an enterprise context, find the people who will know and then bring them into the fold.
Absolutely, and I would say one piece that we haven’t touched on, but this became critical on the project, you know, so mm-hmm. You’ve got this entire tech requirement and then you’re trying to figure out what’s the MVP, right? What’s the minimum? Yes. Viable product just to get to launch. And then we can layer in the enhancements, right? So what does it truly take at the basic level, just to have this thing turn on and go. So I remember being in a room one day and we were talking through the requirements. There’s like easily 30, 40 people in the room. We’re going through every different scenario and someone, because they’re truly passionate about tech and they just wanna get things right. They said, well, what about this particular scenario happens, and it was like four or five things that could have all like, been tied together and we were down such a rabbit hole with these sort of one-off scenarios that I finally sat there and I call it. Wait, so I have this thing, a friend of mine, call it Elmo, so enough, let’s move on. Right? Oh my God. And if I had an Elmo, I would’ve been like so my friends, when he leads a lot of like brainstorming and design thinking sessions, he lays it out as one of the ground rules, which is enough. Let’s move on. If we’ve gone down the rabbit hole for far too long and we’re not getting anywhere you like, literally can just hold up the Elma. So, we’re kind of an Elma point. And I turned around to this person as nicely as I could, and he’s a good guy and we had a great business relationship even after this. But I said, you know what? I promise that I will give you a hundred dollars if this scenario actually ever occurs, but I’m offering you a hundred dollars because I don’t think this will ever happen. We just need to keep going.
So, I love Elmo. I might adopt that. Or similar strategy, like, please do. We’re in a rabbit hole. A way to signify that you’re in a rabbit hole . All you’ve had to, you just get, and even if you’re on a zoom, you can just slowly just, that is hysterical by the way, in software development, the term for what you’re talking about is called an edge case. An edge case is like this, sort of like, well, if this happens and then at the same time the server goes down, but at that very moment this other thing happens, it’s exactly that. The backup server also goes down. And by the way, and like those are important scenarios to prepare for. But at a later stage in the life cycle, like just to get it live, you don’t need to worry about the one in a million case. But what’s interesting is a lot of the personality of a lot of professionals, including software developers and lawyers, is all about making sure, like you’re basically paid to make sure things work under every circumstance. Right? So, it is like the lawyer equivalent to this is you’re just doing a tiny, little simple project, but the lawyer puts together a hundred page contract because if the company goes bankrupt right in the middle of this and the lawyer’s like, dude, you’re paying me to think through every scenario. That was it.
Exactly. Yes. You nailed it. And I love it.
And I had never thought before about having a symbol to use if we get to a rabbit hole. And I might go buy a model on Amazon. This is great. Sheila, this was a super fun episode. I’ll point out, we started with a probably whiskey getting drunk and we ended up with like children Elmos. So, it’s gone from like very adult to very kid. We’ve had the whole gamut of emotions here. This is great and we had a few new lessons as well. Thank you for your time, Sheila. And. Everyone who’s made it this far to the end, I hope you’ve enjoyed it as much as we have.
Thank you, Morgan. It’s been a pleasure. ©2026 Client Horror Stories by Beloved by Clients – Privacy Policy, Terms & Conditions – Resources – Beloved by Clients