Category Archives: business

A Bad Mobile Experience is Bad Customer Service

As a travelling consultant, I get insight into a lot of organizations. One theme that I see over and over is a lack of understanding about mobile experiences among decision makers and technical teams. When it comes to interpersonal or written communication, companies have sensible rules and practices about making that exchange great. You’ll hear or read slogans about treating the customer right, or to go beyond and satisfy and impress them. Most organizations have great alignment on that message, and when I walk into an office, I am greeted by friendly security and front office staff who smile, are pleasant and help me get to where I need to go. They want all of us to have a great first impression, so they invest in human-friendly lobbies with art, comfortable furniture, and great lighting. This extends to email and voice communications as well. People try to be professional, pleasant, and make me feel welcome as a customer or consultant. However, that is rarely my first impression of that organization. For me, and millions like me, I get my first impression of that organization through their mobile experience.

In many cases, that mobile experience is the opposite of their interpersonal customer service. They fail to realize that a bad digital experience is just plain old bad customer service. It is the virtual equivalent of a rude call center employee, or an office administrator who tells me to go f— myself when I walk through the door. Instead of feeling valued by the organization, my mobile experience feels like they don’t care. They make me feel confused (what does this company do?), they make me feel frustrated (I can’t solve the problem I need to sort out!) and that they don’t value my time (why do I have to gesture so many times and spend so much time to do a simple task?)

These organizations would be horrified if I was flipped off when I walked in the door, but they have no problem making me feel just like that when I try to interact with them virtually on my mobile device. And they don’t seem to have a problem with it. On the other hand, organizations that realize great customer service extends to digital experiences have alignment on their customer-first values. Instead of worrying about mobile frameworks and handsets and technology development, they seek the solutions that provide a great customer service on virtual mediums. Thankfully, that means we have a lot of examples on how to do it well.

Here is an example of contrasts: airline mobile experiences. I won’t name names, but I will describe 3 different mobile experiences and the technology they are using to either create great customer service, or do the digital equivalent of flipping us off.

I travel a lot, and when I am travelling, I need the following at a minimum:

  1. Ease of use (so I can get my information quickly when under pressure on a trip)
  2. My booking details stored: confirmation number, flight numbers, seating details (this eliminates printing out paper that often gets out of date)
  3. Access to my booking details when I don’t have network connectivity (when you travel, you are frequently without wifi or cellular data, particularly if you don’t want to purchase an expensive data plan during a short trip)
  4. Up to date flight information when I am connected to a network (so I can get out of jams when there are delays or cancellations)
  5. Ability to book or modify or cancel flights
  6. Simple contact to customer service if all else fails on my own

Let’s look at three different mobile experiences from three different airlines:

  • App 1: a native mobile application
  • App 2: a hybrid mobile application
  • Web 1: mobile optimized web-only access

How do they stack up?

App 1 (native):

  1. Ease of use: incredibly easy to use, and it takes 2 gestures to get my current flight information. It takes about 15 seconds to tap the app and get all the info I need to fly
  2. Flight details stored: all my flight information is stored so I don’t need to search elsewhere
  3. Offline access: this app not only displays all my information when I don’t have networking or wireless access, but if I am not connected, it provides a warning message and tells me the data may be out of date. This is useful in cabs, in areas of an airport without connectivity (such as in security) or in an aircraft while in airplane mode so I can check my next flight if I have a connection
  4. Information updates: this app lets me know of gate changes, delays, and even lets me check on in-bound aircraft status and other dependencies. When there are problems, I and others with the app know before official announcements are made, which gives us a jump on the competition for rebooking or making alternative arrangements. This app has helped me get to a client site or get home on time on a number of occasions.
  5. Flight bookings: this isn’t easy to do on mobile devices, but with a few taps and gestures, you can get the job done without feeling frustrated
  6. Easy contact to a real person for help: one or two taps and I am speaking to a customer service rep who can help with a problem I can’t sort out with the app

App 1 overall customer experience: great!

This app has really improved my flying experience and I am growing to like this airline more over time.

App 2 (hybrid – combo of web and native technologies):

  1. Ease of use: not bad, but it is a bit clunky and doesn’t respond as smoothly to input gestures as the native app. I can’t zoom in on some screens, and on others, it takes me out of the app to the website, which is irritating. It feels quite slow, but I don’t have to do a lot of inputs, I just feel like I am waiting
  2. Flight details stored: This is a thin-client app (not taking advantage of local storage that hybrid apps provide), so I have to store my booking reference in a note, leave the app, copy it from a note, paste it in, and then wait for it to load my details. This is frustrating and takes a lot of time. There is no excuse for overlooking this with a hybrid app.
  3. Offline access: The app will not function without a good wireless connection. That means it is useless in many areas of an airport. If I want to check my flight number for a connection while the app is in airplane mode, it crashes. I have to take screenshots of details when they are available as a workaround.
  4. Information updates: The app does not provide updates. I have to navigate to the airline website or airport website and search for details on the flight. This is too time consuming and is frustrating. I get no information advantages and have to get in line with everyone else if there is a delay or cancellation
  5. Flight bookings: Not bad. Nice interface, and few gestures to get the job done. It just feels slow compared to a native app.
  6. Easy contact to a real person for help: I have to do a lot of navigating, and then I get redirected to their corp web site which is slow, cumbersome and frustrating

App 2 overall customer experience: poor.

Every time I use the app I get frustrated and I project that frustration on the airline. In one case, I was having trouble checking in at a kiosk, so I opened up the app. It gave me a cryptic error message that made me feel like my flight had been cancelled. I had to stand in a line up for a half hour to find out from a human to look into the problem and sort things out. This app requires workarounds (save my booking reference in a note or search for an email confirmation and screen shots of up to date data) to be even useful when I fly. They chose hybrid to get cross platform support, yet they don’t even take advantage of the affordances of a hybrid app.

Web 1 (mobile web site):

  1. Ease of use: horrible. I have to open a web browser, and to just enter in their URL is over 20 taps! I probably don’t have 20 taps in a month of using the other apps in total. Once I enter in their URL in my device and fix typos, 30 seconds has passed. I am then redirected to a mobile optimized web site. I can’t get both my flight status and my booking information in the same place, so to get the same information I get with 2 taps from a native app takes me over 50 taps and gestures and can take 2-3 minutes, under ideal conditions. Their image carousel on each page takes forever to load, and gets in the way of my interaction.
  2. Flight details stored: As a web app, there is no local storage, so again I have to store my booking reference in a note, leave the web browser, copy it from a note, paste it in, and then wait for it to load my details. This is frustrating and takes a lot of time.
  3. Offline access: None. I can’t do anything without a good wireless connection.
  4. Information updates: No updates. I have to go to a different website for that, and tap away on the URL, and experience the same pain.
  5. Flight bookings: Not bad. Nice interface, and few gestures to get the job done. Again, it feels slow compared to a native app and there are some inconsistencies from screen to screen.
  6. Easy contact to a real person for help: I have to go to their corp web site, which means I usually have to find the option to go to their full web site (a tiny URL at the bottom of some of the mobile screens.

App 2 overall customer experience: Rage inducing.

When this app lets me down in an airport because it takes too long to get anything done, I look longingly at the competition counters across the hall. This experience is beyond useless and it causes me to lose faith in the organization as a whole. If this is so painful, how is the flight? Also, I found that staff members have very little faith in the mobile experience. Even though I had a PassBook ticket that was valid, they reprint a hard copy when I try to board the aircraft because they “don’t trust the mobile app”. PassBook integration is one thing they do well, but people get so frustrated with an experience that doesn’t fit the needs of customers and staff on the front lines hear about it and try to adjust.

So whose app do I use the most? App 1 of course, and I also fly with them the most. I get a great customer experience with their mobile app, and they also do a decent to please us in their interpersonal interactions. The airlines that supply App 2 and Web 1 actually have better interpersonal interactions – they are friendlier and more helpful, but the mobile digital experiences are not convenient, so I don’t fly with them as often. This has less to do with the technology they have each chosen, but in how they have chosen to implement it and whether they are making technical decisions or customer-serving decisions in how they create mobile experiences.

A great customer experience that enhances convenience goes a long way. In fact, I will put up with less than ideal interpersonal interactions with a company if their mobile experience is convenient and makes my life easier. Next time you are looking at your mobile experience, no matter what the technology, ask the question: are we creating a great customer experience with our technology as well as with our people? The extent to which you use mobile technology to address that means much more to your customers than just “going mobile” and putting something out there. In some cases, no mobile access is better than one that makes people hate your company.

In an upcoming post, I’ll talk about ways our hybrid and web-only airline friends can improve their mobile customer service.

Elisabeth Hendrickson on 15 Years of Consulting

Elisabeth has been in business for herself as an independent consultant for 15 years. She has a great blog post about it here: Happy Birthday Quality Tree Software. In the post, she describes the workload and the challenges. I’ve been an independent for about half as long as she has, about 7.5 years, and my experiences mirror what she describes. I too get queries from aspiring consultants who ask for advice. Elisabeth talks about long hours, hard work, and challenges. This quote in particular resonated with me: “The bottom line is that running a business, any business, is hard.”

If you are curious about going out on your own, this is a good piece to read. As a business owner, you are constantly looking at ways to be profitable, and dealing with challenges and changes in your environment. What do you do when you work very hard at a new revenue stream and it doesn’t work? What happens when a popular source of revenue loses favor in the market and you have to start over with something new? What do you do when people copy you, and your business model and a reliable source of revenue slows to a trickle because of market saturation? It is a balance of looking at your cashflow, looking at your financials and adjusting, taking risks, failing, succeeding, and adjusting some more. Also, a lot of what you do as a business owner is tedious – the logistics of running a business can be a big time sink, so you have to balance activities constantly to keep up with market forces. Elisabeth is correct, when you get it right, it is incredibly rewarding, but be prepared to put in time and effort, and to be able to motivate yourself through the boring parts, the low parts and the really hard parts. And sometimes, you have to reset your business and start over again.

Why Are We in Business?

When I look at my work in software testing, I find myself at the intersection of three disciplines:

  • Technology
  • Philosophy
  • Business

I have business training, with a focus on technology. Sometimes I forget about the business, and focus on testing ideas, technology concerns, and following a process. As a tester, I think about the product, and its impact on users, but I forget about what really keeps us in business: the sale of a product or service. Whether a product might be saleable or not might be a testing question we should ask.

It matters not a whit what our process is if we aren’t bringing in as much or more money than our business is shelling out. I have seen fabulous execution of software development processes in companies that went under. I’ve also seen completely chaotic development environments in wildly successful companies. What was the secret? One group focused on sales, on making the product easy to use, and really listened to the customer. In the end, the difference between the development teams having a job or not did not come down to technology or process decisions, but whether the company could sell the product.

Technology, process and engineering considerations are useful to the extent that they help the company feed the bottom line. If a process helps us deliver a product that customers are happy with, then great. However, we need to be careful on what we are measuring. We need to look at the big picture, and not be self-congratulating because of adherence to our favorite process. If the company isn’t making enough money, it simply won’t matter. In time we’ll be a project team looking for work, lamenting about how great our process was at the last company we were at.

As Deming said, everyone within a company is responsible for quality. I also believe we are all responsible for the company’s success in the market. Focusing only on engineering, technology and process may not help if we are a company that can’t sell our products, and can’t satisfy and impress a customer. If we reward employees for adherence to a process, how long will it take for those rewards to become more important than the goals of the business? At the heart of every business is this equation:

Revenue - Expenses == Profit

Without profits, the business will eventually cease to exist. In software development, it pays to keep this in mind. Too often we are distracted by details in our daily work, and forget the basics of business.

Presenting Testing Activities to Business Stakeholders

Brian Marick’s series on Agile Testing Directions begins with a test matrix that describes testing activities as “Business Facing”, “Technology Facing”, “Support Programming” and “Critique Product”. This resonated with me, but it wasn’t until he pointed out that in my pair work with developers I did both Business Facing and Technology Facing activities that this seemed to click. I think this matrix he has developed provides testers with a common language to identify and communicate these activities.

I recently did presentations to business stakeholders on testing activities in Agile projects. I’ve generally found it difficult to explain the testing activities I engage in to fellow testers, let alone business stakeholders. In one meeting, I thought of the test matrix and brought up the “Business Facing” testing and “Technology Facing” areas of testing while I was explaining how I test on Agile projects. People seemed to understand this, so I started working on it more.

I started thinking of the matrix rotated on its side with Technology Facing on the left and Business Facing on the right. Instead of “support programming”, I went with “support” to capture both areas. The “business support” would involve activities like setting up meetings with developers and business stakeholders after each development iteration to ensure that the working code is what the business expects, and to get people communicating. I also thought that business support would involve helping the business people with acceptance tests and things like that.

I initially thought of naming each quadrant of the matrix, but when explaining it to my wife Elizabeth, she said: “Why don’t you just put that in a tree diagram?” I did just that, and presented Agile Testing activities like this:

I felt that “technical testing” was a simple way to describe “technology-facing product critiques”, and “business testing” would describe “business-facing product critiques”. Keeping it simple seems to work well when communicating testing concepts to non-technical people.

I described some of the testing techniques in each area. For example, a technical testing activity I use involves collaboration with the developers to write tests that can be run in the absence of a user interface. This can involve adding tests to drive a layer of the application at the controller level. Once the developers make this area testable, we co-design and develop a test case. I can then own the test case and run it with different kinds of test data.

Under the programmer support activity, we can pair together to generate testing ideas. In a test-driven development environment, we can pair program to come up with tests that drive the code, or the tester can use a scripting language to write the tests for the developers.

Business people and technical people seemed to understand this tree diagram and the explanations I gave. I heard later that business stakeholders were starting to use this language in other contexts when they were talking about testing.