ACS saw that the market was missing an easy way for the utilities and the customers to communicate. An platform that would give the user and utility the needed synergy that public knowledge says does not exist. With that in mind ACS gave that project to one of its product managers, that reached out to me to help him out as an user experience consultant .
The first step we took was to have a brainstorming session with our development team, where we hacked out what the customer wanted and why, what we wanted to sell and why. After registering the employees understanding of what the app should be, we went out to talk to our customers about what they wanted for the platform.
Problem statements:
Utility needs a way to collect meter reads on a regular basis remotely because the utilities want to reduce costs on meter reading (the man power needed to go house to house collecting that information)
Utilities need a way to communicate to the users during outages because the lack of power also knocks out and at the same time outages are the period where opening communications channels with the customers is needed the most.
Utilities need the customers to lower their demand during peak hours because the peak hours define what is the cost of energy for the rest of the year.
We then started a research on the market to see who was doing what we were setting out to do and how. That way we had a clear idea of the results of the competitive analysis before talking to our customers. Once that was done it was clear that we were going to a market that was not mature, the options that existed were not feasible for small or even medium utilities.
Competitive analysis:
Opower
Description:
Customer facing utility app that helps utilities and consumers manage bill pay, outage and load management
Formats;
App/ website
Value:
Utility and customers share outages updates
Strengst:
strong demand response feature – naturally attached to load management solutions such as nest
Limitations:
Cost – expensive for the utility – in the 10s of millions
Support infrastructure is large and complicated.
After several interviews we were able to clearly define what would be important for the utility, and information they needed to be able to gather, what would make their likes easier and what would be irrelevant.
Utilities need to have a good level of customer satisfaction because loyal customers are less prone to look for alternatives
Rural utilities need to find a way to collect money easily because of the high costs of operation of collecting, as well as the possibility of adding auto pay.
Andrew, Utility Operator
Persona: Utility Operator
Goals:
Crew’s safety is his first priority.
90% of its time is controlling the grid for maintenance operations. The other 10% are spent managing the grid during weather events
Attitudes:
These screens are our eyes and ears on the field, but if something goes wrong there is very little we can do – There is nothing worse than going blind in a crisis.
He is aware that his actions keep his coworkers safe.
For the most part he likes the system he’s using, but any flaws quickly become infuriating. He believe in automation as control, but goes through every actions with a fine comb.
His mistake may kill someone. Has been on the other side and knows how and why protocol need to be followed
Behaviors:
Joined the utility as lineman, without a degree and his experience gave him access to his current position.
He goes through the days switch plan and scheduled interventions in the morning. Pending no weather alerts he manages the grid and keeps contact with the crew.
If a weather event happens, he’ll be coordinating the field crews and the most important outages for as long as needed.
Persona: Utility Customer
Goals:
Her family’s well being is her main concern.
She wants to have reliable power, and not have to think about it.
She understands the occasional outage, but she needs feedback from the utility ASAP to manage her life.
Attitudes:
Gets her information about the utility from the social media channels.
“If the power is out at my house, I need to know when is it going to be restored. That will decide if need to leave work early and take my son to my mother in law”.
Sarah, Utility Customer
Behaviors:
Works office Hours 8.00-5.00.
Has an 12 y/o that takes the school bus home. One of the parents tries to be home by the time he arrives, but it’s not always possible.
Her commute is long enough that she wont be able to get home fast if caught on rush hour traffic.
Once this was done we went to talk to the utility’s customers, the end user, to figure out what were the features that would make the lives of the users better.
The next step was to revisit out problem statements that we had from the first interviews with our customer. Some of the statements were still true, but there were things that changed.
User problem statements (second round after first interviews)
Utility users need access to meter reading because it can help know and predict the cost of current and future usage.
OMS users need information about the outages because he needs to know how bad the outage is and learn how to plan for the time without energy.
User needs online access to pay for convenience ( they don’t want to drive or send checks on the mail, and the utilities websites are old and often place the costs of the operation on the user)
Once we were done with this step and in order to have a clear vision of who we were working for we ended up creating two personas for this product. The Utility Persona and the customer. At this time it was starting to be clear that we were going to have to have two different applications much like Airbnb switches from host to traveler.
User Journey:
Outage – Custom realizes power is out / He sees its not only his house / reaches out to friends (happy moment) and relatives int he area – Go online (smartphone) – Check news on utility website – call outage phone number – calls and has to dea IVR (automated phone system) – has to authenticate (often having to give customer number) – report the outage – receive an ETA (happy moment)- wait until the outage is resolved.
We then made started ideating HMW’s, in order to achieve the full pool of product characteristics that solved not only our problem statements but the needs demonstrated by our interviewees. That allowed us prioritize the product characteristics, and reach a consensus on the MVPs that we were going to focus on.
- Forecast adjust / pay bill
- Call in and hear last months statement
- Check the mail – The adjustment is blind they want to budget and cant, all they can do is to make assumptions based on last months bill
- Use tools to manage consumption.
This is when the ideation and definition of what the characteristics of the two sides of the same app starts to shape up.
At this point the project started becoming too large for an investment to be made upright.
Below are examples of the application mock ups
