Tony Leventhal received a shock in 2007 when his credit card company called to ask him about a rather large payment to the electricity company. It turns out a reasonable £170 bill had turned into one for a massive £17,000. Source BBC News. Full story.
The price of electricity is on the rise
How might this have come about? Well we’ll put this one down to human error. There are a few scenarios I can see that may have caused this error. Firstly, let’s look at the mistakes that could have occurred whilst reading the number to be entered. So the operator who was typing in the amount (at whatever stage in the process) is fairly new at this job and is working on transcribing bill amounts into the system. He’s a little distracted thinking about lunch whilst working. He sees the amount £170.00 and does one of two things. He might misread the number, by ignoring the decimal (making it £17000) or he reads the decimal point as a comma, albeit misplaced (reading it as £170,00). Both of these instances result in him inputting an amount 100 times larger than intended. How can we solve this issue? Well it all comes down to how this information was presented to the operator. Was it printed neatly? Was it scribbled down on some paper from a customer’s home meter reading when their electronic gadget went wrong? Who knows, but there are a few conventions we can take from the medical domain to help people read decimal numbers more accurately. One of which is to make the decimal point large. Don’t hide it at the bottom of the text, we don’t need things to look pretty, we need them to look readable. Another convention that works in conjunction with the large decimal is writing the decimal portion of the number in smaller numbers (see the Design for Patient Safety page). With these simple additions, reading and transcribing numbers can be easier and a lot more accurate.
Now let’s think about the possible slips whilst typing. In the following cases the operator has correctly read and knows the right number he is to enter. An error occurs however, due to the keyboard or display, and the operator is not aware when he makes a slip. I don’t actually know what the input layout is like on screen but let’s take a quick look at two possible form layouts and the associated error causes.
The first layout theory is simple and probably what you’d expect:
In this situation the operator may have aimed to type in £170.00 and accidentally missed the decimal key for whatever reason (he was distracted by something, the keyboard was still sticking from that time he spilt coffee on it etc.) Without the all important decimal place, the operator inputs the huge amount of £17000. As far as the operator knows, there’s no reason the decimal point hasn’t been inputted, he thinks he typed it and so does not double check the number. How could we prevent or protect against this error? One way would be to assume and check that every number typed into the system has a decimal point, even if the amount only comprises of pounds and not pennies. With this check in place the operator, upon entering the erroneous number with no decimal point, will be presented with an alert requesting they add a decimal point to the number. At this point hopefully the operator will look at the number they entered, the one they thought they typed a decimal place in, realise and correct their mistake.
Another way of fixing this problem might be to separate the pound and penny fields. This layout looks a little silly but who knows, this might be how it works! I’ve seen crazier input systems.
So this layout ensures that pounds and pennies are split. The operator doesn’t have to worry about decimal points! Hooray, hurrah! But really this doesn’t actually solve the problem. Now the operator has the option of accidentally not pressing an entirely different key, this time the tab key. Now our operator goes to type in the amount but doesn’t press the tab key, again for the same reasons, resulting in the first field being filled with 17000. And again, this problem is solved by having the system check the second field is filled with some value.
In both possible input systems, the small check to ensure that there is a decimal portion of the number would prevent the error we see above. It seems like this system could add a bit of time to the number entry process with operators having to type in the penny amount even if there are none. But only one in every hundred bills will be a round pound amount. If the operator is used to typing in the pennies then typing the two trailing zeros will mimic their usual typing pattern (type the pounds the ‘decimal/tab’, ‘digit’, ‘digit’).
I can’t say for sure that this error did occur by human error but I think the evidence and suggested scenarios are compelling and plausible. Let me know if you have any other suggestions for what happened and ways to prevent it. Or if you have any inside information about how this process actually works!