I worked alongside 1 contract visual designer and the CTO of the company.
Lead UX designer. I drove overall product strategy, timelines and end-end design solutions for the version 1 of the product.
The first version was released within 3 months of conception.
Effectively answering high bill queries.
During our initial discussions with the utilities, we found that the number one reason for customers calls, is to inquire and even contest an unexpected high bill. Customers and agents find it equally difficult to figure out the reason for the high bill in these cases. With little understanding of their energy consumption, customers resort to disputing a high bill. These interactions are negative and customers end up blaming the utilities. Even for us, it was challenging to pinpoint the exact reason for high bill. It’s a combination of data science and UX problem to get agents to the closest reason for the shoot-up in the bill.
Finding the reason for high bill.
First things first, we wanted to better find the reason for high bill. So far, we were collecting data about user’s account and could tell user the appliance breakdown of their usage. It was still not good enough to give a close enough estimation - there could be a lot of other reasons for a high bill that we could not figure out. To get all the possible reasons out in a paper, I arranged brainstorming sessions with almost all in the company to find what they think could affect the bill. We were noting down realistic scenarios where a user could face a high bill. We mapped these scenarios to the metrics collected by our engine or the ones we could get easily. Now, we could see the changes in metrics with each of the high bill scenarios.
Working out these realistic scenarios helped us multiple fold. These would guide us throughout development and testing process and eventually fuel our data scientist to create algorithms for pin pointing reason for high bill.
Comparing two bills.
A defining moment in the project was figuring out that comparing bills from similar months like consecutive or same month last year, provide rich insights into the change in usage. Two consecutive months tend to have similar bills unless something drastically changed. I proposed implementing this idea into the application itself, as this is the time when customers actually call the customer care for bill related inquiries. I looked at the metrics that we were gathering and correlated two months to intelligently guess the reason for high bill.
What touchpoints should we focus on?
Though this product was designed for agents, the customers were an important part of the design. I looked at the whole interactions between the customer and focused on the conversation between them. We recognized multiple touchpoint that utilities have with their end customer. These were all part of our design scope.
Initially, this application would work in conjunction with the existing CRM applications. The agents would click on a link where they would be able to look at the energy usage from the user’s account. In order to increase the customer satisfaction, I proposed that we send an e-mail to user’s account after the agent has successfully figured out the reason for high bill along with saving tips. This creates a relation between consumers and the utility.
Coming up with initial designs.
Though never advised, I created the first iteration as a high fidelity mockup. This was intentional to provide the sales team with material that they can show around. In return, UX gets to be part of the sales demo and get first hand reaction from the customers. Overall the reactions were positive as the customers had not seen a tool that could help them figure out the high bill. The feedback helped us focus on the core functionality of the product and take the focus away from the recommendations and collaboration piece right now.
The idea was to keep it simple for the agents so that they do not have to go through the raw data or find trends themselves. Agents want to optimize on call duration and quality. Bidgely Agent would provide them the right insights to help customers understand the reason for high bill. It is done by comparing the bill in question with a bill that reflects normal usage (previous billing cycle or same billing cycle last year).
It is done by comparing the bill in question with a bill that reflects normal usage (previous billing cycle or same billing cycle last year). Agents need to quickly glance over a lot of aspects of energy consumption to locate the exact problem. In order to help, bidgely would highlight areas where it feels that agent needs to pay attention to. These would be areas where something has changed from last month and could provide the answer to high bill.
As part of the workflow, a very important idea was to send e-mail to user once the call is complete. This would allow consumers to go through the analysis of high bill in their leisure. It builds a positive relation between the consumer and the utility. The personalized e-mail would also motivate users to sign-in to the utility usage portal and keep a tap on their usage.
To improve agent efficiency, we wanted to ensure that visualizations can be understood at a glance, without user having to pay much attention. I put that to test by showing each visualization online on www.usabilityhub.com, and asked people to write down the message for each visualization. I worked with the visual design contractor to iterate over the visualization until we stripped off everything except 72%, where users could guess the visualization without any context of the application.
The image below shows all the perspective where system has detected anomoly. We were using color very sparingly to highlight the anomolies. This is where the users will need to focus on.
As Bidgely was working with a number of utilities and account types, any design proposal had to go through the test of these different cases. For example, some customers had time of use account, where their rates would change based on the time of day. While other users may just have tiering based account. These lead to a lot of cases and corner cases for each of them. Thus, design a Bidgely had a long tail. As a rule, I was aiming for 80% of the usecases to begin with.
We were able to push the application to production within three months of inception. Meanwhile, the sales team could already start pitching the value proposition with the customers. Bidgley was able to successfully deploy the high-bill comparison solution in two utility environments. The average handle time (AHT) for the pilot customers went down by ~2 minutes for the high-bill queries. Eventually, Bidgely exposed this solution to end-customers.