securing crypto
All customer queries were being routed to the level 1 customer support team. This level had limited access to customer data, so they couldn't resolve most cases. Many queries had to be escalated to colleagues with higher clearance, keeping customers waiting for longer.
The initial request?
The design team was tasked to create a system whereby all customers would categorise their own problems before it reached the support team.
design thinking facilitation
I decided to hold a design workshop (Luno calls them Moonwalks in reference to Google's design sprints) with the data scientists, designers, engineers and product managers involved. I arranged for lightning talks (quick 10min sessions) with business experts and stakeholders so we could truly understand the problem statement.
In doing so it became clear that self-categorisation would be a bad customer experience with the product limitations as it was. But more importantly, the team realised we were solving the wrong problem.
Digging into the data
In our Q&A session with one of our policy makers we discovered that most customers would still have go through the level 1 support team. Only 16% of customers needed to be urgently helped by someone who could access their full account details quickly: people who were experiencing security issues.
the real problem
How could we help the right customers report suspicious activity directly from their app, without having to wait? This waiting period was a vital factor in these cases where some customers could be under malicious attack.
designing the solution
The original CONTACT US screen provided options to chat to a real person (this was still in testing), send us an email, and check existing messages. The product designer and I introduced an extra option that stood out and allowed customers to take immediate action if they suspected something suspicious.
writing the flow
While most tickets would still be routed to level 1 in our support team, customers who wanted to report a security breach could do this by categorising their suspicions.
When customers choose to "Report suspicious activity" they would see a list of categories, each clearly explaining what the customer might have experienced, to help guide them choose the option that's closest to their situation.
After choosing the category, the customer could provide a more detailed explanation of "what happened".
The error messaging urged customers to provide a short description before continuing. This prompts customers to be descriptive so the team really knows how to help them.
We then prompted customers to attach a file in case they took screenshots of the suspicious conversation or message they received. We kept this optional.
We ended off with an explanation that their account would be locked, thereby negating any actions an attacker might take, while we investigate.
The end of flow screen would reassure the customer that their account has been locked to ensure no activity can take place during the investigation.
We also let them know that we will contact them to follow up and provide them with the reference number.
lessons
While I trust that stakeholders make requests of my team from solid data, it always helps if I investigate the data myself. In this instance it ensured that my team understood what it was we were actually solving.
By shifting the focus and redefining the problem statement in our design sprint, we created a solution for less than a quarter of our customers, while preventing the poorer experience of having 100% of our customers categorise themselves before they could get a reply to a simple question.