Blog: Changing your bank details

Every so often, I bang on about compensating transactions - in essence, they’re the way that you clear up problems in automated systems without upsetting your customers.

So, if you have badly designed computer systems which can't cope with real life, the simplest compensating transaction might be an exit to a real person, empowered to act with common sense. Do this properly and a potentially troublesome, annoyed, customer (every unhappy customer talks to lots of potential customers) will be transformed into a pathetically loyal customer.

At this point, it is often a good idea to interview a real customer with an issue that demonstrates the point, so I will. I’ll interview me. Yes, this is personal, but I can be objective about it, really I can, for the specifics also illustrate in issue that’s emerging as the developers’ role changes. They’re not just producing “IT services” that business users do the best they can with any more; they’re producing end-to-end services that must satisfy general business needs.

So, let's look at Carphone Warehouse and the way it manages an incredibly unusual and difficult transaction - changing my company’s bank details. Strange isn't it - given merely a glimpse of my bank statement and a private letter, the average criminal can, apparently, extract thousands of pounds from my account. However, with a continuing relationship; and details of three bank accounts (including a personal account some six years old and no longer being used), and a direct debit mandate against at least one of them, Carphone Warehouse is unable to extract the money it needs to settle my bill.

The fatal separation between “IT” and “business” these days can also result in a firewall between a company and its customers. For example, staff on customer services and our local Carphone Warehouse shop are very helpful and pleasant (and somewhat annoyed with their employer, I think) but they apparently aren't authorised to fix anything - or even to find out about the progress of clearing the cheque they were given, in person, at their instructions. This is the Open Loop of Unhappiness so far as the customer is concerned, but probably defends business managers against having to answer awkward queries too often.

Eventually, after several weeks mucking about, including blocking and unblocking my phone, Carphone Warehouse did manage to operate its Direct Debate mandate and extract all the money it needed from our account – although there is also a cheque in its favour somewhere that has neither been presented yet nor cancelled.

Who is to blame? Well, I am, for changing my business bank account (but to be fair, this is just implied by the way the systems have been written) and for not wanting to give Carphone Warehouse access to my credit card when it might be extracting duplicate payments via direct debit, which would then leave me with the potentially expensive and time-wasting task of repatriating any overpayment. But what about Carphone Warehouse's IT department (apparently, "computer says no", more-or-less, was a factor). Or, The Data Protection Act (DPA) which apparently says that my company secretary can't pay its cheque in at the shop in person (I really doubt that). Or, simply, Life, the Universe and Everything?

Well, it’s all a PITA and we will probably be claiming for loss of use of the phone on an account paid by valid direct debit and the value of our time (several hours) trying to sort this out - and I suppose we'd better now check our credit ratings. We will be pointing out that by keeping unnecessary bank details (that obsolescent account), Carphone Warehouse may be in breach of the DPA anyway. And I might ask the guy in charge of IT at Carphone if he likes being blamed for its crap process.

And that last point is why I am writing this (it's not just out of malice, Ermintrude, honest). It is so easy to blame IT for a bad user experience and the absence of an effective "dark path" compensatory process. But it usually isn't IT's fault, presuming that it has a reasonable lifecycle development process. Sure, IT should analyse the process it's been told about, and ask questions about situations that seem not to be covered; but the business is responsible for business process and "computer says no" belongs in a TV comedy show.

I can't believe that we're the only people to change our bank account, so a percentage of Carphone's customers are presumably being annoyed (and, the mobile phone business is competitive, with "churn" a major issue). And, discussing this with the Readers of Reg Dev implies a modicum of reputation risk - and perhaps Carphone has other poor processes. I'm a bit worried about the unnecessary personal information it seems to be keeping, so I may be able to report on its DPA procedures soon.

This all represents a bigger issue that IT professionals, even developers, should be aware of. The automated systems they build affect the business, in subtle ways as well as the obvious ones - and developers may well get blamed for failures that aren't really their fault. So developers ought to be interested in making sure that lifecycle processes are in place, which include the business stakeholders as well as the technicians within their scope. Only analysing what is being automated isn’t enough any longer.

Aidan Lawes, the CEO of itSMF UK (the "user group" for ITIL IT service management), recently wrote a germane article for Computer Weekly, "A new ITIL for the integration age", covering just this area.

In it he says:

We should be striving for integration, not alignment. I do not believe that there is such a thing as an “IT service” any more; rather there are business services, which are wholly or partly enabled by technology. This means that those responsible for managing technology components need to understand exactly what end-to-end business processes are underpinned by them, and the scale and importance of those processes to the overall business operations and goals. Only then can the appropriate management approach be decided, which is where service management comes in.”

To my mind, that just about says it all. ®