Maslow’s Hierarchy of Hospitality Technology
Imagine a young child who aspired to drive a Ferrari by the age of seven on a public road. Would you let them? Unlikely. You would counsel them on what they need to do, why, and, critically, build a number of steps for them to achieve this goal. After all, who would let a toddler loose on a highway? Crazy! Yet sometimes in business it feels like we are all too quick to pump the accelerator before we’ve checked there are tires on the car.
To address this progressive approach towards competency or appropriateness, I like mental models. They help clarify thinking, and create common frames of reference for teams. I learned a few lessons from leading technology for McDonald’s that formed the basis of a mental model I used when thinking about priorities for restaurant technology. I loosely based this off Maslow’s hierarchy of needs. If you are unfamiliar with this model, psychologist Abraham Maslow looked at what motivated individuals. He postulated that as an individual, while you might want respect or recognition for example, neither would be motivating or important unless precursors such as shelter and security were in place.
So why use this as a model? The travel and hospitality industry works in a similar pyramidal manner. If the foundational needs of customers, employees, or franchisees are not met, whether with technology or other approaches, everything else is of limited value or interest. It can be applied to both aspects we talk a lot about: operational efficiency and customer experience.
Clearly an initiative needs to do something useful, which we’ll come back to as even this is subjective, but beyond this, communication with stakeholders can be challenging as we stray into the architectural territory of what we called the “ilities.” These include affordability, deployability, supportability, configurability, scalability, and so on through the other one hundred-odd non-functional requirements. But how do you simplify these down in a business meaningful way that resonates with customers?
Let’s take a hypothetical project, Project X, which is desired by your business colleagues, probably more the folks who sit in the same office as you rather than necessarily the staff on the frontline.
How can such a model be used to ensure your next project is adopted and used without any unfortunate surprises? Simply by honestly appraising each layer in sequence.
First and foremost, financially does X help me maintain liquidity and is it affordable? As technologists, you’re probably used to being told your technology is “too expensive.” Although I bite my tongue from the normal refrain of “compared to what?” three questions weigh on my mind: does the cost justify the benefit, do you understand the real cost, and does the benefit outweigh your economic buyers’ other investment options?
We do like our predictable projects where detailed business cases are written and then, to no-ones’ surprise, the project takes longer than expected, costs more, and fails to deliver the expected benefits. Much of the effort goes into justifying the money needed to build the initiative, not honestly appraising the Total Cost of Ownership (TCO). It’s usual to find a woeful underestimation of factors such as support, maintenance, training, deployment, and the reams of subsequent change requests.
While not a panacea, the use of agile to deliver initiatives incrementally, allowing regular checkpoints based on tangible deliverables and pivoting where lessons are learned quickly, is fundamental to being successful here. This, coupled with the financial elasticity and pay-as-you-go nature of the cloud, enables investments to pace realisation of benefits versus making large upfront capital investments on the promise of future returns.
A huge opportunity with cloud-based applications is the reduction in capital expenditure possible for a restaurant or hotel. As franchisees reminded me, every capital investment is often another loan they have to take out, and one where they need to consider whether a loan for this new initiative makes more sense than a new grill or refurbishing the building. In today’s volatile environment, the elasticity of being able to scale up or down is a key benefit of cloud-based solutions. The travel company TUI capitalised on this to ramp down costs by 55% as the pandemic impacted business, while also being able to scale up capacity in areas such as the call centre. Melia Hotels International approached the pandemic similarly, saving 58% of its normal spend as a consequence. Alternatively companies can choose to reinvest these savings in differentiated work that can drive business growth as Restaurant Brands International did when it moved their on-premises data centres to AWS.
Assuming you pass the investment hurdle, reliability takes centre stage. There is almost nothing worse in a high-pressure environment than the technology failing, whether in the form of a full outage, impaired functionality, or poor non-functional performance such as speed. In my mind, it encompasses job number one as well: security.
Werner Vogels, the AWS CTO, is widely quoted here: “everything fails all the time.” In the often technologically hostile, distributed environment found with most T&H companies, not every edge case can be easily coded for. I’ve lost count of the number of pieces of technology I’ve found in sinks around the world! This is reality and when this happens there are three main options: fix it, failover, or escalate. Three pieces of advice have helped me appropriately address these issues: train the end user to be knowledgeable, instrument applications, and build in resilience. We train frontline employees to do all sorts of maintenance today, but for some reason often treat technology differently. McDonald’s used the concept of “Operations Technology People” (OTPs) in restaurants who were trained to varying levels to be able to proactive maintain and reactively repair hardware and applications. It went a long way to demystifying the technology and giving the franchisees a degree of self-sufficiency. Instrumenting applications to report on issues and deviations is important, but equally teams need to be positioned to react to this data, prioritising incremental reliability improvements as much as new features. Finally, hardening the system such as with the use of automated failover is important but not to the point of adversely impacting complexity and cost.
Companies such as Jack in the Box have seen the benefits of going all-in with the cloud, in a large part due to the heightened reliability that can be achieved.
If you have an affordable, reliable system, the question arises on whether the system is usable. How obvious, you say! For us, the iPad generation, it does seem obvious, so why don’t we apply the same care and attention to usability when it comes to our own technology? Usability here means the holistic design of technology including the environment it operates in. Take for example a self-order kiosk in a restaurant. Is it obvious before you get to the device what it does? Is the interface intuitive to navigate, or does it trap you in a prescribed method of ordering? After you order, is it obvious how you pay and what you need to do afterwards? Customers (or employees) don’t like to look stupid and will assiduously avoid technology that they feel will counter this. Both the airline and hospitability business have learned this lesson over several decades, and yet there are still too many examples of poorly thought through usability. I’d invite you to go into the average McDonald’s and compare the holistic kiosk ordering experience with the average supermarket. In the latter case as much as I like technology I rarely can get through an order without having to call someone over to help. Push the envelope here. Services such as Amazon Lex and Amazon Comprehend open the door to the most natural interface of all: voice. Taking a steer from Maslow though, only introduce these if they don’t adversely impact cost and reliability.
Qantas focused on usability to simplifying how information on passengers and services is served up to employees, forming the foundation for innovation including areas such as reacting proactively to potential complaints. Similarly Melco Resorts & Entertainment simplified reduced the set-up time of its casino management system from nine months to four weeks, allowing their employees to focus on higher value-add activities, and its customers to take advantage of services sooner.
Finally, before we even think deeply about the “wow” factor, is there a basic, positive impact the new system or feature will make? For T&H I look here for either an improvement in the customer experience such as reduced friction and frustration, or improvements in operational efficiency normally measured in speed or cost. This shouldn’t be based on an opinion or just in a controlled environment that is, rather evidenced through meaningful data in typical operating conditions. How can you prove out your hypotheses here using a Minimum Loveable or Viable Product?
Domino’s Pizza Enterprises grew its business by focusing the impact on predictive ordering to accelerate its ability to satisfy customers. Hyatt Hotels focused on the customer too, using personalisation to elevate the Hyatt experience.
And Now, We Can Wow!
Finally, let’s end where most business cases start. What’s the “wow” factor about the technology? The efficacy of our working backwards process comes into its own here, centring the whole design of an application on the single big customer benefit. While it sounds simple, it is an incredibly powerful process to steer away from death-by-a-thousand-requirements, and to ensure the customer remains at the centre of the design. The defined outcome allows the product team to discover their way to a compelling product, rather than going through the ritual tick box requirements development process with no accountability at the end for the usefulness of the application. After all, it is reckoned that over 40% of features and applications that are deployed are not used. What a waste.
In reality, new initiatives should start with this last step, but the pyramid guides think through the foundational elements that will make or break your success. The reality is that too many business cases are based on made up financials, reliability as an after-thought, and a list of requirements that are often someone’s opinion of what is needed. I’d counter that early thinking on a cost point and reliability for an initiative will help shape an architecture upon which we can test hypotheses. The “requirements” are accepted as a best guess of what is required, but now delivered on the cloud in a way that can rapidly validate or invalidate them. If the requirements turn out to be correct, early thinking about cost and reliability enable them to be scaled quickly to realise early ROI. If they are wrong, pivot.
Am I right? What mental model do you use when thinking through new initiatives?
Learn more about how AWS is helping transform the travel and hospitality industry.
Source: You’re Going Digital – Now What?, MITSloan Management Review, Winter 2020.