Learning from the frontlines of travel and hospitality

There are only three measurements that tell you nearly everything you need to know about your organisation’s overall performance: employee engagement, customer satisfaction, and cash flow.

– Jack Welch

Imagine having access to detailed, insightful, and ongoing feedback from your most frequent technology product users, culminating in an increase in your profitability. Would you refuse? Many companies inadvertently do.

I’m not talking here about your economic – buying – customers, rather your employees using your technology at an airport, hotel, restaurant or the like. While the somewhat suspect Henry Ford adage of “If I had asked people what they wanted, they would have said faster horses” abounds, the reality is that your customers, whether internal or external, often know what needs to change with your products. While many larger breakthrough innovations have come from labs, Eureka moments, and savants in companies, these are infrequent and unpredictable. The beauty of “small i” innovations is that they fit nicely into agile organisations, enabling product teams to rapidly iterate, test, and scale good ideas while shutting down failed experiments quickly. Too often we are insular in looking for these ideas, put off by the complexity of tapping into large groups of employees, or, unfortunately, arrogant in thinking that the ideas from the corporate ivory towers are the best and only ideas. Your airline attendant, drive-thru crew member, or front desk clerk would disagree.

How is this pertinent in travel and hospitality? Let’s take a hypothetical case study to learn from the common failures I see:

Acme Inc buys a new Point-of-Sale to replace their aging solution. It promises benefits for digital consumers, exciting management with the potential of an AI-driven super-duper loyalty system. Let me tell you the end of this story for too many companies. The system doesn’t quite fit their unique business processes. In fact, there is a reluctance to change existing processes that vary across brands as, after all, it must be easier to change software than people. Numerous change requests are raised for the “off the shelf” solution, delaying deployment by months. Post-deployment, significant challenges are experienced. The whizz-bang ideas that attracted management are outweighed by the many little missing functional components that employees relied on, unbeknownst to the developers. Adoption stalls, business is impacted, and the appetite for future investments is diminished.

Sounds familiar? We often overlook the engagement of our own employees in technology. In fact, it is one of the biggest failure factors for new initiatives. I was often humbled and inspired equally by watching how my technology was used by frontline staff, and their creative workarounds to make a system that sounded good in the office actually work day-to-day. So how can you engage your internal technology users, whether in restaurants, hotels, or airports, in making sure your technology meets their needs? There were a few things that worked for me.

Understanding your employees as your customers

For organisations with younger front line employees, spend time understanding what their technology lifestyle looks like outside of the workplace. Only 30 years ago, technologies such as PCs or email were seen first in the workplace. Leading the way with technology is a role businesses have become accustomed to for the last 100 years. This is no longer the norm. The customer is now in the driving seat, often adopting technology first whether social networking, smart phones, or gaming technology. They thus demand that businesses meet their higher bar. Many of you grew up using text messaging, but look at how children communicate now: with TikTok, Snapchat, Houseparty or similar. These are fundamental, ongoing shifts in expectations in just a generation. While these roles have reversed, many companies still believe they understand and respond to their customers better than they actually do. If mobile phone usage is a proxy for digital usage, how many folks could raise their hand and say their enterprise mobile experience matches their personal mobile experience? To turn an old adage on its head: the consumer is not a moron…she’s your employee. 

Build-Test-Repeat

Part of the reason us Amazonians are so passionate about agile ways of working is because they reflect some basic truths about software development. These include the fact that often our business requirements are normally just our beliefs in what end users want in the next major release. Note the emphasis. By delivering smaller increments of functionality faster into the hands of the same users and considering these requirements as hypotheses instead, we are more inclined to pivot if the data on how the functionality is received or used does not support our hypotheses.

These tests can start simply. I’ve used interactive wireframes to watch how an employee would take a complex order for example. It’s usually low cost, yielding immediate feedback both visually and through discussion with the employee. Qantas demonstrated the efficacy of this approach with AWS with an in-flight application. As confidence grows in direction, involve employees in sprint reviews to get additional feedback. Try to rotate the employees on a semi-regular basis to prevent groupthink setting in. This has an added benefit of slowly growing your base of champions for the product. A diversity of input is really enlightening too. While developing global systems, I’ve stumbled across differences that impact design including average employee heights, colour perception, and hand sizes to name but a few.

Use data to drive insights

I am fortunate to have worked at a company that invested in capabilities such as video ethnography to help us understand how systems were used. While labour intensive to analyse, maturity in technologies such as Amazon Rekognition open up future possibilities of automating the analysis. Instrument your functionality as your build it.

Taking the POS example, metrics of interest could include how often new functionality is used, system reliability including latency or responsiveness, and reboots. You might be surprised by what the metrics tell you such how little some of the “must have” functionality is used. How does this happen? Often because a loud voice in the organisation demands an enhancement because they “know” it is important. This is where empowering product managers is critical, holding them to account for deciding what functionality is the highest priority and measuring the efficacy of their decisions. If the loud voices prevail, hold them accountable for proving through data that their request is needed and then, subsequent to implementation, that it is being used effectively.

Don’t ignore anecdotes

The thing I have noticed is that when the anecdotes and the data disagree, the anecdotes are usually right.

– Jeff Bezos

Don’t just rely on the technology; walk in employees’ shoes too. An hour working in their roles teaches you so much, often particularly how little employees care about some of the things you are passionate about. When you are facing a long drive-thru or check-in queue, the importance of system speed of response and reliability far outweighs some cool feature.

The data you get from systems must be contextualised, and should not be followed blindly. Through working on the front line, conducting surveys, or conducting employee focus groups, anecdotes are likely to be shared. Our knee jerk reaction is normally along the lines of “I can’t recreate that in the lab so I’ve closed the issue.” Collect the anecdotes and dive deep into understanding them. They often reveal some profound challenges or ideas. I’ve seen this multiple times, whether about a POS freezing or slowing down, or orders not appearing correctly when ordered on mobile applications.

Have employees teach employees

A large portion of technology-enabled initiatives still fail because they are not used as intended, whether by internal or external customers. Research indicates that typically 50% of an initiatives budget should be directed towards activities such as training and change management. I don’t believe we abide by this enough. If we don’t invest in building employees’ confidence in systems, adoption suffers. Three insights I have here are:

• Use a train-the-trainer programme. The employees you rotate through the product reviews might be ideal individuals to train the next cohort of employees given their insight and enthusiasm. They are also a great conduit for feedback, as well as coaching your next potential technology employees.
• Use a seed-site concept, taking employees out of their regular location to hotels or restaurants designated as training sites.
• Appoint a technology go-to person at each site, equipping them with additional training on the new system. This builds a sustainable change network for future initiatives and an ongoing source of insight into what is and isn’t working

Be prepared to adjust business metrics short-term to account for the learning curve on new systems too. If you don’t employees are likely to revert to old ways of working to ensure they can achieve the metrics rather than risking new working methods.

While this might be incremental work, isn’t it better to build a good product used well, than an allegedly perfect product no-one likes? I remember all the work my team put into creating a resilient, waterproof handheld order taker for outdoor use in the late 1990s. It was only when one of the end user employees remind us that they themselves were not waterproof that I realised how easy it is to focus on the wrong aspect of system design!

—

Learn more about how AWS is helping transform the travel and hospitality industry.