Customer Experience Archives - Page 10 of 15 - dancingmango

Joined up experience

Thursday, 8 February, 2007
By: marc

The “customer” agenda has moved beyond CRM. “Customer experience” is being taken ever more seriously; some more enlightened organisations have customer experience representation at the board level. It’s all about thinking in terms of the experience customers have with us- considering every touch point – understanding the journey the customer takes from first becoming aware of our brand, through researching and purchasing our products to developing them as a loyal and profitable advocate of ours.

Sadly the IT that underpins many organisations doesn’t get the customer journey. It is routed in organisational silos and delivery channels that mean everything to the organisation but nothing to the business.

We know how successful our web channel is: we’ve got webmetrics. We know how successful our telephony channel is: we’ve got a sales force motivated to sell, and a dashboard that tell us their success. We know how successful our stores are: we’ve got sales data, we even measure footfall in our stores.

But is it joined up?

I go into a store and a salesperson helpfully shows me the product, but I’m not yet ready to commit. She offers me a great deal, I’m tempted, but I want to check it out on the web. I search the competitors, the salesperson was right, she was offering me a really good deal. So I got to their online shop and there is nothing like the tailored deal I was offered in the store. There’s a number on the website and I get through to the call centre. I start all over again. I get the same sales patter I got in the store and saw on the web. I’m offered a deal that is similar to that in the store. I’m ready to commit… but they don’t have any in stock, I’ll have to wait seven day. So can’t I buy it now and pick it up in the store tomorrow? I don’t think so.

Where is the driver to improve things? Each channel has contributed to the sale but each is a silo that has its own reporting lines. They are in competition with each other, each wanting the sale none of them recognising the other in the journey that led to that sale. Yet ultimately their failure to work together is destroying the brand value.

Tuesday, 30 January, 2007
By: marc

When I was 16 I worked in a bank. Customers would ring up and ask for their account balance and I type on the green screen 809 for a simple balance. I can’t remember the code for a breakdown of transactions. I couldn’t use that system now. One of the benefits of command line prompts is that they are efficient. As a “power user” it would be difficult for a GUI to beat <809 account number>. Because the GUI can be cumbersome and requires mouse movement when only a few keystrokes would suffice. Power users love commands line prompts. But in the hands of a novice the command line is useless.

Cue Google.

A pretty cool feature in Google calendar- the ability to “quick add” an event. Rather than the cumbersome use of date pickers and fields and boxes, the quick add function allows me to create a calendar entry using natural language. I type “meet Fred in the office at 9 tomorrow” (the language I use when describing my intention) and the meeting is set up. No need for fields and boxes and date pickers. So maybe it is time to rethink command line prompts using natural language with forgiving rules. Imagine being able to type “move £50 from my current account to my savings account” rather than the more usual current:

Page 1 – Step 1. Select from account. (Wait)
Page 2 – Step 2. Select to account. (Wait)
Page 3 – Step 3. Enter amount. (Wait)
Page 4 – Step 4. Confirm transaction. (Wait)

(Done).

Is yours a free coffee organisation?

Monday, 22 January, 2007
By: marc

What kind of employee experience do you have? A good customer experience is going to be an extension of a good employee experience. If I feel good about my employer, I am more likely to be a brand ambassador for them. So how do you improve my employee experience? Well there’s all the usual stuff, benefits and bonusses, but the little things are just important. Like the coffee machine.

There seem to be six different approaches to enterprise coffee:

1. Vending machine that serves [quality] coffee on free vend.

2. Kettle and filter coffee / Cafetiere to make my own.

These two make me feel good about the organisation

3. Kettle. I buy my own instant coffee. Usually associated with SMEs rather than corporates.

Not so good. but better than…

4. Vending machine that serves [quality] coffee that I have to pay for.

I have never seen this. Organisations who know coffee don’t charge their people for it. These vending machines are always on free vend. As in above photo.

5. Vending machine that serves [tasteless] cofee that I insert coins into.

6. Vending machine that serves [tasteless] coffee that I insert a vending card into.

This final one insults me as an employee. I’ve got to “charge” my card up. I’ve got to get a card. My coffee consumption can be tracked. More often than not the same machine serves water (because these organisations don’t have water coolers). And the water tastes like tea that tastes like soup that tastes like hot chocolate that tastes like every other concetrated liquid that is squirted into a brown plastic cup.
How much more can it cost to offer free coffee? How much are you saving by doing so? Because tasteless vending machine coffee is a sure way to send your staff out of the office on regular errands to Starbucks.

Consumer driven development

Wednesday, 10 January, 2007
By: marc

One of the things that makes me passionate about agile is the way that it places the customer at the heart of everything we do. The trouble is “the customer” is often wrong. For me, the customer is the person whose life is transformed by the software they use. This is not the person who is writing the cheque, nor is it the person who is defining the requirement. In consultancy speak, they are the client. The “users” are the customer. I don’t like the use of the word “user” because it implies a choice to use the software has already been made. I’m probably going to have to accept that “customer” is never going to change, so why don’t we call our users (my customers) “consumers”.

So enough about semantics. The team are building an on-line banking product. The team ask the customer (client) what she wants. She bases her requirement around what she knows. Often this will be swayed by the development team talking about implementation detail. (Few things make me as uncomfortable as a customer (client) from the business (product owner) talking about APIs).

So the requirement is to log-in. The customer is comfortable with customers (consumers) having system IDs; a unique n digit number that identifies the customer on the legacy database. It has, after all, always been this way. She asks whether the customer’s credit card number could be used, but the developers tell her (via the BA) that these often change (customers loose their cards) and it would be hard to do. She nods her head in agreement (she’s put on the spot by the BA – the iteration is due to start next week…) And the requirement is manifest on the login screen (“please enter your 16 digit customer number”).

In reality, the “customer” bases the requirement on her experience with the organisation and what she knows about it. The consumer (if they were to be invited into the conversation) wouldn’t come to the problem with any of that baggage. She needs a simple login. She needs a user name that is accessible or memorable. She does not want a 16 digit number.

It may take a little longer to listen to the consumers’ need (we need to find consumers to talk to them). It may mean a little up front analysis (I’d suggest pre-project analysis, doing due-diligence if you like). But it will pay dividends downstream. In the login example above, the developers have swayed a simple and cost-effective solution in the short term, but have failed to consider the down-stream costs. How will the customer find their 16 digit number? Do we have to post it out (cost) on a card (cost) and have a support team (cost) and process (cost) for letting customers know their number if they’ve forgotten it?

As agile grows up, I’d ask for us to spend more time thinking about the real customer, the consumer, the person whose life will be changed by what we build. The inconvenience we may incur during development may be nothing compared to the pain we will experience after we have “delivered”.

Nokia and their charger

Tuesday, 9 January, 2007
By: marc

There once was a time that you could go to any office in the world and be able to charge your Nokia phone. Every Nokia phone used the same charger. A small and insignificant thing, yet this small detail in the technical implementation was undoubtedly important in maintaining brand loyalty and the dominance of Nokia in the market place. Nokia built informal communities in workplaces that no other brand did. Communities that shared their chargers. I’ve not witnessed that with other brands.

Then something happened at Nokia. They changed the charger. The plug is now smaller. I presume this can only be down to the ever decreasing size of their phones. But my new Nokia N80 is bigger than my old Nokia that used the old charger. Bottom line? There are half a dozen old style chargers lying around in the office. There are no new ones around. I leave mine at home / it is broken, and combined with the risibly short battery life of the N80, I am stuffed. This will impact my purchasing decision when I change phones. I’ve been loyal to Nokia since I got my first mobile almost ten years ago. No more.

(As a postscript, I recently found myself with three other unlucky souls who owned a Nokia N80. Not one of us had a good thing to say about it. If you are in the market for a new phone, steer clear of the N80. Buy one at your peril!)

Early Learning Centre fail to deliver

Monday, 8 January, 2007
By: marc

Last year I wrote about Early Learning Centre and how impressed I was with their revamped web site. It was recently picked up by About Customer Relations: The New Competitive Edge. Whilst I stand by my comments about the site itself being well designed, the rest of the experience leaves a lot to be desired.

In the summer I bought a product on their website – the product that was delivered was not the same that was ordered. They succeeded in repeating the mistake twice, delivering two toy pushchairs before the pram finally arrived. With no present arriving on time we had to postpone our daughter’s birthday for a day whilst we waited for her birthday present to arrive.

I probably should have learnt from this experience. I didn’t and on 11th December I ordered toys on their website for my daughters and their cousins. The on-line shopping experience was faultless, I received a confirmatory email and the following day, on the 12th I received the following note:

We’re pleased to let you know that the following items from your order of 11 December 2006 have been despatched from the Early Learning Centre warehouse… You can expect your toys by Wednesday 20th December.

That was great, managing my expectations, keeping me informed. Only on Thursday 21st December no delivery arrived at my address. We rang their number and were informed that the delivery would be made, the order would be with us by Christmas. That was a promise.

Friday 22nd and still nothing. I was getting worried, I could postpone my daughter’s birthday, but postponing Christmas because of ELC’s incompetence was not on the cards. I got through to the call centre and was told that sorry, the delivery had not left the couriers warehouse, and would not go out before Christmas. The call centre representative said he’d phone local stores and see if the toys I’d ordered would be available for pick-up. I was put on hold as he rang a local store. All sold out. I suggested another store and was put on hold again. After fifteen minutes on hold I gave up and rang back. This time I was told that the courier firm would be making deliveries on the Saturday morning and I could expect my order to arrive first thing in time for Christmas.

Saturday morning and no delivery. I rang the call centre again. The representative I spoke to said that she couldn’t tell me whether the delivery would be made. I put the phone down. I rang back again and asked to speak to a manager. “Sorry, all our managers are in a meeting” came the response. This was not good enough. I asked for a manager to ring me back when they came out of the meeting. I’m still waiting for a call.

A little later on, the parcel arrived, in time for Christmas, but not in time for me to have anything good to say about ELC’s ability to execute on their web promise.

Central to my experience was a breakdown in communication. The call centre had access to the courier firm’s tracking website (that they wouldn’t share with me), but seemed to have no way to talk to someone on the ground to find out why my gifts were not put on a van before the date they’d promised in the email. I don’t care that the courier company let them down. For me, the courier is ELC. In the call centre it was clear that they’d brought in extra people to handle the Christmas rush. These people probably had a bare minimum of training and were not able to handle queries from disgruntled customers in a consistent way.

The lesson learned here is that having a good website is just part of the total customer experience. You may have the right products at the right price, easily found and simply paid for. My web experience may end with me parting with my credit card details and receiving a confirmation e-mail. But I’m not satisfied until the right goods arrive at my home and they meet my expectations based upon promises made on the website. At any stage of the whole process I expect a consistent and excellent experience. Anything less and I won’t return. Worse, I’ll tell others how bad my experience was.

Blue is the colour. The website isn’t the game.

Thursday, 4 January, 2007
By: marc

So I may support Chelsea on the pitch, but on their website? Oh dear me. It’s as though they got someone who has just learnt flash to build it – to use as many flash animations as possible. And any website designer that incorporates a link on their splash page (why oh why a splash page) that says “check out the site demo” and a first message “learn how to navigate through ChelseaFC.com” needs to be questioned. Learn how to navigate a web site? Oh please!

The nature of football fans is their brand loyalty, but to give them something that visibly takes time to load (page loading status bar), requires instructions to learn how to use, and doesn’t make things easy – support me achieve my goals – is frankly insulting.

Oh, and they’ve got a text only version (the CFC Flash website isn’t going to win awards for accesibility so one can only presume this is the only reason it is provided) but the splashpage requires JavaScript to load up, so no JS and no website, regardless of any text-only goodness that may be there. So not an accesible website then.
Meanwhile the community stuff that supporters care about (beyond the news and match reports, it’s probably going to be the most sticky content) is a seperate site that looks like it was built in the early days of the web. I mean, who uses frames anymore.

Sorry Chels, poor show. Your league status doesn’t extend to your on-line prescence.

Why the number not the user name?

Wednesday, 3 January, 2007
By: marc

User name and password. Ever since setting up my first hotmail account, since buying my first book on amazon these are the two unique peices of information that securely identify me. It’s a pattern I’m used to. Sometimes the username I want will be taken, but I’ll find another one. I remember my user names. Passwords are a little harder, I seem to be forever changing them, but at least with a user name I can usually click on a link to get a password reset emailed to me.

So why do the banks do the whole identifcation thing differently? The majority of banks don’t allow you to have a user name that you define. They allocate you a “customer number” or a “membership ID” or some other randomly generated number that you are almost certainly not going to remember. You are going to write it down. So this number can’t be more secure than a user name. And it is not as if you don’t already have a plethora of numbers with the banks; card number, account number, sort code. Couldn’t they use these numbers as identifiers? With HSBC you can generate your “IB” number from these information, but it is a more lengthy procedure. First Direct have an on-line support ID and an on-line access ID (whatever they are!?)

Security is paramount with on-line banking; as banks renew their security infrastructure they should review the customer experience; how security manifests itself to the end user and how easy it is to use, as well as ensuring it offers the highest level of protection to themselves and their customers.

Success is more than just features

Tuesday, 2 January, 2007
By: marc

All too often there is an assumption that we can deliver a bunch of features and they will provide a benefit to the customer. A simple model and it underlies much of what agile is perceived to be about. Deliver those features that provide greatest (business) benefit at the earliest opportunity.

It is worth looking at the updated DeLone and McLean model for Information Systems (IS) success [pdf]. This is a causal model; if you want to accrue benefits with a system it is not sufficient just to deliver “features”. There are qualities that must be realised; these will drive an intention to use and actually use the application. This is tightly correlated with satisfaction, use will precede satisfaction, but if the outcome is satisfaction then use will increase and this is the ultimate test of how beneficial a system is.

DeLone and McLean model for IS success. Slightly modified.

So taking the “qualities” one by one:

System quality: e.g. reliability, usability, performance, availability, accessibility
Information quality: e.g. usefulness, personalisation, speaking the user’s language, keywords, search terms
Service quality: the overall experience, interface design, emotional impact, trust, security, support

Typically development teams may consider some system quality attributes as “non-functional requirements” but these are generally from a technical perspective (e.g. availability) rather than a human perspective (e.g. usability). Probably this is because this is the language that development teams understand.

Information quality is usually left to someone else, someone from the business, from marketing, to write the copy for example. On the web, where most customer experiences start with search so getting copy right is essential to ensure search engine optimisation. On pages that are not content managed, pages that the developers are coding have meta-tags been identified? Has copy been written with targeted keywords in mind, keywords at the beginning of the page, with repeated use of the keywords etc?

Service quality is something that everybody assumes will be manifest but is rarely explicitly stated as a measurable component. I recently worked with a client that wanted to offer “world class” services. What did this mean? Asking them resulted in different things to different parties. The DeLone and McLean is a little light on “service quality”. Depending upon the application, it is something that looks and feels good, and makes me feel good using it. It is something that delivers a complete and holistic experience from the first point of contact (e.g. hitting the home page) through to realising my goal (e.g. correct products ordered arrive at promised time).

These qualities have a causal impact on use and user satisfaction. These can be measured (e.g. usage patterns/ repeat usage/ surveys) and should be incorporated into the non-functional requirements at the outset of the development.

Get all this right and you will realise net benefits from the project.

What’s the value in changing colour?

Thursday, 14 December, 2006
By: marc

As a registered user, I want to change the colour scheme on the web site so that…

Where’s the value in this story? Agile focuses upon business value, and in doing so it commoditise features. The sponsors of the development are invited to prioritise features based on their “business value”. This means that seemingly pointless gimmicks will slip out. And this may impact the overall experience that the sponsors strive for. Yet by commoditising features the sponsor sees how the costs break down. To have functionality that changes the colour of the site will require effort. It’s not going to come for free. And that means that either scope will increase resulting in either increased cost or increased time. The challenge is when you have a sponsor who knows just a little: “changing colour? Pah! That’s a bit of JavaScript and changes to the stylesheet. I could get the code on hotscripts and knock it up in front of the telly tonight…”

And of the requirement to change colour on a site, in fact that whole customisation thing? Until recently I’ve never seen the value of it. After all, how many people have you seen with a personalised theme on their windows desktop, or even just changing the desktop background? One reason people don’t do this is because they are lazy. The call to action to change it is hidden behind a right click, and it’s not exactly straight forward to do. But there’s a bunch of new sites that challenge the user’s laziness. These seemingly pointless customisation features are part of the overall experience. And they work. And by doing that, they add value to the site.