My daughter, who attends university in the United Kingdom, but works in Vancouver, recently came across a frustrating set of interactions with her UK bank.
It’s getting time to return for another year, except that this year she’s also moving universities, as she’s going to Cambridge for her Master’s degree after having done her undergraduate work at Durham.
Her debit card had also expired, and needed to be replaced. She therefore had to get them to update her address to her Vancouver apartment, not, at the time, knowing what her proper address in Cambridge would be (nor would she be there until the beginning of October).
There’s an eight hour time difference between Vancouver and the UK, so getting through to her bank’s call centre meant making calls in the middle of the night and forgoing sleep.
Five times, when she’d call, “systems were down”, and no one could help her.
Those call centre workers would really like something our phone and tablet apps seem to understand, which is the idea of using the data in the cache when there’s no communications.
Something like a customer’s current security question answers, or their mailing address, doesn’t need real time access, and the change could be journalled and processed later. But all we supply these days are online systems that are either up, or down.
My daughter’s story gets worse. She eventually not only found someone on a day when the systems were working, but who didn’t toss their cookies because all the automated field verification of the screen was rejecting a Canadian address. (UK post codes are in the form LLN(N) NLL, where Canadian postal codes are in the form LNL NLN.)
We build in all this verification, of course, to trap keying errors. Most of the time it’s helpful. But again, looking to spell check on our phones and tablets, we need to be able to say “yes, that is right” even when it won’t pass the test.
The “nice” clerk she dealt with promised the card would be mailed. What the clerk didn’t know was that the group responsible for cards who would receive (electronically) the request only shipped cards to branches. (The call centre was an outsourced operation; so was card production, but to a different firm in a different country.) So the promise was made to ship the card to Vancouver, but it couldn’t be fulfilled.
My daughter, waiting for the card to show up (and worried when it didn’t) finally received a letter from her branch in Durham that her card was waiting for her there.
If we’re going to use outsourced call centres and the like, we need to build into our systems checks that the organization’s procedures will work as promised — alternatively, we need a “special order” approach that allows the procedures in one department to be set aside when a promise to a customer has been made by another unit.
Oh, and she needs her card, because, like our banks, her UK bank won’t do anything for her without her valid debit card in hand, and she wants to wire transfer her tuition and residence money from here to there and know she can get at it on arrival, when the payments are due.
We spend a great deal of time encoding processes into our systems, and developing model users and use cases for all their interactions. All that’s a good thing.
But we need to model how these are used in real life, with real situations (it’s a rare bank, for instance, who doesn’t have a customer who travels, is posted somewhere else on assignment, or goes to school out of the bank’s service zone) in order to make sure we’ve built all the bypasses we need. We also need to know what lines of communication that used to be handled with a quick internal phone call are now blocked because everything is transferred through systems, often between different outsourcing partners as well.
Could your company’s systems pass the simple test my daughter gave her bank? Would you end up paying a customer “for their inconvenience” when it was all done because they don’t? (My daughter did receive £60 — do that a few thousand times and the outsourcing savings start to evaporate!)
This is a good task to set your maintenance team to work on, to keep them sharp and to give you a “to do” list as the next project comes by.
