I recently was in North America working on overhauling a client’s customer service organization and associated processes. Basically, the customer service organization received and processed customer orders in a common way across the industry: Customer service reps mostly worked on the software-backend, while orders could be submitted via a frontend-portal, similar to a website (automated order submission) and via email (manual order submission). Unsurprisingly, the most time-consuming and error-prone type of work represented this manual order submission, which forced customer service reps to manually retype orders into their backend. Our project thus strongly focused on creating a singular end-to-end process, which also brought with it a revamped customer service reps backend and customer front-end. Nevertheless, a lot of the steps of the automated order submission, which I assumed to be automated right away (such as pre-filling in already know order details such as today’s date), had to be done manually.
That’s when I, sitting in my hotel one evening, came across an article in The New Yorker on a surgeon and his interactions with their digitalized workspace. The surgeon complained about the software not being designed for various user groups, but instead having a one-size-fits-all approach. On top of this, access rights are not handed-out thoughtfully, but users are sprayed with these. As a consequence, data is not input sparingly, but often redundantly from various sources. This in turn, renders a central data repository not lean and clean, but loaded with duplicates and heightens search costs (think each surgeon typing in the same observation in different words). Doctors become disgruntled with their software and subsequently their work, one of the contributing factors to higher burnout and depression rates:
“In 2014, fifty-four per cent of physicians reported at least one of the three symptoms of burnout”.
The reasons the system is being perceived as dysfunctional by doctors, is a disconnect between the system serving the patient, but not keeping the user in mind. While sitting in my hotel, I realized that something similar was happening at my client: the system had been designed to make the customer happy, but no one had ever listened to the people using the system from a company’s viewpoint.
For the next few weeks I kept this insight in mind when working with my client on overhauling their organization, processes and systems. One of our technological recommendations was to implement several front-end layers, based on specific needs of user groups. The idea was that every user group has specific needs that need to be reflected technologically, while limiting servicing and maintenance costs of the standardized backend (very similar to Project Treble on Android, for the more tech savvy users). Moreover, we recommended to empower each customer service rep by letting them choose how they want to filter and slice their customer data. Nevertheless, we also advised to have a default filter in place, as most people tend to go with the default selection and struggle devising their own selection system, unless they’ve graduated to be a power user. The underlying idea here is that people make intelligent decisions, if they are empowered to do so. Our client is currently in the process of implementing our solution and I’m looking forward to accompany them on their journey.
IMPRINT • PRIVACY