Monday, February 17, 2014

How British Airways failed to use the information they have

Having worked with companies a lot in the past few years on how to create a better customer experience and in-particular through MDM to help effectively identify the customer I know just what is possible even in very challenging environments.  The Airline industry is not one of those areas but today with British Airways I received another example of how a company might have all the information required to deliver a good customer service but chooses not to provide that information to where it counts.

I was flying into Heathrow, on a transatlantic flight I booked recently, I'd originally planned to head into London and from then on to Paris via train but checking the prices it turned out flying was cheaper and as I was already at Heathrow it seemed the smart and good corporate citizen thing to do, so I made another booking.

So lets see what BA knew about me at this stage....

  • All of my passport information - the goldest of gold standards
  • My frequent flier, with shiny gold card indicating I need to get out less
  • All my flights with them in the last 10+ years
  • How many times I've missed a flight with them due to my own fault (zero)
  • How many times weather or their issues have caused me to miss a flight (was 3, now 4)

So in the text book of Consumer MDM they have the perfect set of source data to identify the individual (the passport) and a unique number the customer wants to give out (frequent flier ID).  It really couldn't be easier in a world where the ticket (which has the ID) and the gate (which scans the passport) to identify the individual.

They also had two bookings.
One that flew out on a Sunday and was due to land at 2pm on Monday, and a return leg for Wednesday (seriously I need to get out less. 
One that flew from Heathrow to Paris at 15:15 on Monday and returned on Wednesday
 Shared across these bookings are my details, indeed when my iPhone downloaded the two boarding passes it automatically paired them together as a single journey.

So what did BA do?  Well the flight into Heathrow was delayed, but I still had 45 minutes to make the connection.  There were a couple of others on the flight racing for the same flight... I reached the connections check-point first to be told:
You've been taken off the flight
The couple behind me (same inbound, same connection) were let through... this irritated me somewhat but it was only when I got to the rebooking desk that irritation turned into disbelief and outright annoyance.
BA: You missed the conformance check. 
Me: I was on the flight from Phoenix, you knew that
BA: We can't see that its on a separate booking
Me: With your airline, made with your website
BA: Yes but its a separate booking
Lets be clear, I like BA, I like the service from the individuals but this is a great example of how a company fails to leverage the information it has to deliver a decent customer service.  Its not giving its people the right information, information it has, to make the right decisions.

My iPhone automagically recognised that a flight taking off from an airport less than 2 hours after I landed from a previous one was part of a single journey, independent of how many booking IDs there were.  BAs systems have this information, I can see it in my Exec club profile, but at the front line they see only the booking.

Now the smart thing would be for BA to have a very simple check on bookings that says 'if bookings land and take off from the same airport within a set period, say 4 hours, we should consider them as one booking so our airport staff can see what is going on'.  At the very least the people at the airports should have access to all my flight bookings so before they kick a customer, and one they've marked out as a priority customer, off a flight the person can check 'wonder if there is an inbound they are on that we know about?'.

This is truly a great example of a company undermining its excellent customer service by not providing its staff with the information to deliver it.  This isn't about a lack of information, its not even about a lack of good quality information, its about the inability to integrate that information into the business processes where it is needed.

Disclaimer: I actually did a bunch of work for BA several years ago around and other customer facing parts of the business.  

Thursday, February 06, 2014

NoSQL? No Thanks

There continues to be a disproportionate amount of hype around 'NoSQL' data stores.  By disproportionate I mean 'completely and utterly out of scale with the actual problems of the vast majority of companies'.  I wrote before about 'how NoSQL became more SQL'.  The point I made there is now more apparent the more I work with companies on Big Data challenges.

There are three worlds of data interaction developing

  1. Traditional Reporting - its SQL, deal with it
  2. Complex Analytics - its about the tools and languages, R, SAS, MADLib, etc
  3. Embedding in applications
The point here is that getting all those reports, and more importantly all those people who write reports, re-written using a NoSQL approach makes no sense.  Sure Statistical languages and tools aren't SQL, but is it right to claim they are NoSQL approaches?  I'd argue not.  The use of a NoSQL database such as Hadoop or MongoDB is about the infrastructure behind it, its hidden from the users so while it make good technical sense to use such a data store it really doesn't change the way the users are working.

The point in these two areas is that its about the tools that people use to interact with information and supporting the languages they use to interact with that information.  The infrastructural question is simply one of abstraction and efficiency.  Like caring about whether your laptop is connecting over 802.11g or 802.11n, yes I know you care but that is because you are a techy.  The person using their iPad doesn't care as long as the videos stream from YouTube successfully.  Its the end user experience that counts not the infrastructure.

The final case is the world of developers, and here is another shock: business users couldn't care less what developers use as long as they deliver. If you can deliver better using SQL then use that, if you use NoSQL then use that, if you can deliver better by using a random number generator and the force then go for it.  Again however the business doesn't care if you use NoSQL or not and nor should they. What they care about is that it works, meets the business requirements and non-functionals and can be changed when they need it to.

Stop trying to force a technical approach onto the business, start hiding your technical infrastructure while giving them the tools and languages that they want.