Customer Failure 101 – Or, How to Kill Your Business without Even Knowing It

Trond Frantzen, Managing Partner | The PowerStart Group


A fine lunch indeedA few days ago I made reservations for four of us to have a working lunch. It was a nice restaurant in a beautiful brand new building. I had been there before with Linda, and had liked it quite a bit.

When I arrived, I was seated immediately and a server (who was there faster than you could say “nice day”) immediately had a menu, asked if I would like a drink to start (all the while knowing there would be 3 others arriving) and, when I said “no, thank you” she asked the obligatory up-sell question of whether I’d like some “still water”. Since I had been there before (and enjoyed it) I knew where this would go. If you say “yes”, a lovely large bottle of water imported from Italy arrives, and an additional unannounced $5 shows up on your bill. Since I knew this, I declined this fine offer.

I fully expected to enjoy a wonderful, tasty lunch with my colleagues once they arrived. My anticipation heightened as I patiently waited.

A server came to my table and asked if there was anything she could get for me. I said, “no thanks, my colleagues should be here any minute”. I then told her that we would like to have separate bills.

She looked at me awkwardly, apparently not certain what to say, then finally announced, “We can’t do that. It makes our computer crash.”

For a moment I didn’t quite know what to think or say. Mmm … “We can’t do that. It makes our computer crash.” Finally, I said, “I think you’ve misunderstood your billing capabilities. Certainly you can do that.” She insisted it was impossible, and said she would find the manager.

A manager arrived promptly. She reiterated that multiple bills would be impossible. Once again, she told the tale of “it will crash our computers”. She insisted they’ve had their tech support team look at it many times, and a new system would cost $20,000 so it wasn’t in the works. I felt she was making their problem (which I really didn’t believe) into my problem. As a customer, I really didn’t want their problem, whatever it was.

This isn’t 1966. It’s 2016. We put humans on the moon decades ago. We put rovers on Mars. We’ve had a successful human genome project. There are 1.5 million apps available for smartphones. We’ve invented 3D printers; including those that have been used on the International Space Station to “print out” new tools emailed from Earth. And the “crash our computers” thing is simply nonsense. Do they really think most people today know so little about systems that they would buy that story? Really?

Obviously, this is just an old-school, antiquated system, or they bought one with functionality that was based on faulty requirements analysis. So, let’s look at this logically.

Many old-school POS systems are based on a “Table”, regardless of how many people sit at it. Most newer systems understand that you could have several (separate) orders at a table. They isolate bills by food/drink order, and attach that to a location (i.e., a “table”). Most pubs do this. That pretty well solves everything.

When you look around a restaurant, they have no trouble with separate bills for small or single parties. But that’s only true, for those technology laggards, for individual “Tables”. The problem here is how the payment question has been addressed (I’ll get to that in a moment); and the unusual finger-pointing exercise that goes on when something is missed while testing a system. In this case, I have to put the blame on the analysts and designers of the system. They dramatically failed in two areas.

The question, at business requirements analysis time, has to be: “For a single, specific TABLE [this is an Object], how many PAYMENTs might we receive?” This question is followed by “Might we receive no PAYMENT; a single PAYMENT; or many PAYMENTs?”  Each part of this question must be answered by the client in response to the business analyst. Each answer creates a scenario (“Under what circumstances would this be true?” is the follow-on question after each answer.) Any client who stipulates that only one payment is acceptable (such as the restaurant I visited), has signed off on their own business failure.

For the POS software this restaurant purchased, that question was certainly not asked properly; therefore, it limits the restaurant and probably costs them customers.

The other side of this coin arose when the POS software was first tested. The multiple-payments scenarios wasn’t found, so that tells me the functionality found during business requirements analysis was faulty at best. When the flaw is discovered (possible after several tech support visits), this can only lead to a client-IT faceoff where the software design team says, “You didn’t tell me you needed that …” and the client says, “You didn’t ask me.”

In other words, this restaurant got some crappy old-school software (which miraculously might still be selling well) that was based on the debilitating old concept of TABLEs rather than ORDERs with LOCATIONs.

Will I go back there? When I’m dealing with just one bill, I certainly will. The food is good. The restaurant is nice. But, for those business meetings when we need separate bills … absolutely not.

Trond Frantzen is a business growth, development and marketing strategist, a business analyst, an author, and company executive. Trond has delivered business development consulting to scores of corporate clients across Canada and the U.S., including government and private organizations. He specializes in “challenged” projects.

Tagged with: , , , , , , , ,