How to Design a Customer Ecosystem for Utilities--A lesson from the past
Over 20 years ago, one of our heroes, Tom Morgan, who was then the IT architect for Brooklyn Union Gas, put into place an amazingly customer- and ecosystem-friendly information system (using object-oriented programming on a mainframe!). It included a CRM module that was designed to provide all the information that customers needed to know:
- What’s my energy consumption?
- How much is my bill?
- When is payment due? Have you received my payment?
- I need service?
- When will you arrive?
- What’s the status of my service call?
- What’s going on with an outage? When will my service be restored?
- How do I turn on/off service to this dwelling?
It also provided the information that different stakeholders in the customer ecosystem—dispatchers, customer service reps, field service technicians, billing, operations, planners, policy-makers—needed in order to best serve customers:
- Who owns this unit/dwelling?
- Who rents this unit?
- Who pays the utility bills?
- Who manages this property?
I found this particularly interesting and insightful. I’m sure that most utility companies must have this information stored somewhere. But Tom Morgan knew that the information about all the players in the customer ecosystem needed to be kept up-to-date and accessible in real time. What if there’s a gas leak that impacts the building? Of course you want to evacuate the people who are physically in the building, but you also want to be able to notify the people who own, manage, or oversee the property to alert them to the status of your repair efforts. Otherwise, they’re going to be getting angry phone calls that catch them off guard.
Tom’s team also innovated (this was way before smart phones) in the design of handheld mobile devices for field service technicians. I remember him describing the challenges of insuring that they could transmit and receive signals from inside the basement of a city building. I also recall how impressed I was when he said that the people who were reading electricity meters could also answer customers’ questions from their hand-held devices in real time, like, “has my bill payment been received?” or “when will my gas be hooked up? ”
One of his early innovations was the ability to simulate the impact of different policy changes on the entire delivery and service system. “What if we promised to arrive within 15 minutes or 30 minutes or 1 hr/ of a target time? What percentage of the time would we be able to keep that promise?” He could run data through a model based on past performance, or modify the data with certain assumptions and show graphically where the bottlenecks would occur.
Tom has moved on to other things. The systems he and his team designed are long gone. I wonder if anyone has kept those design principles alive within the world of utilities. Based on Ronni Marshak’s article about the customer experience challenges of dealing with her ecosystem of energy suppliers in the Boston area, I suspect that Tom Morgan’s implementation of a customer ecosystem hasn’t been replicated.