Uplight wants to make it easier for utilities to do more for their customers—and for IT teams work with their solutions on the back end.
By now the word has gotten out on the formation of Uplight, born from the merger of Simple Energy and Tendril. With $53 million in investment from AES and an undisclosed backing majority from private equity investor Rubicon, Uplight has one of the most wide-ranging portfolios of applications that address the changing customer landscape—both in heightened expectations on customer experience and the need to deliver less expensive, cleaner energy.
We spoke with two key players in Uplight’s strategy and product development teams: Justin Segall, chief strategy officer, and Jeff Woodward, VP of Product Development at Uplight. Our goal: to find out how they stack up against a deeper level of questions—those held by IT and analytics-oriented utility professionals.
LC: What types of scenarios or needs did you see in the market that led you to pursue the acquisitions and partnerships that resulted in Uplight?
JS: The key thing we see with utility customers is that their expectations are shifting; customers essentially expect their feedback to be received and acted upon instantly, on-demand, and in a personalized manner. They want easy access to solutions and tools that save them money and make them more comfortable, but not in the way that they are typically receiving them today from energy providers.
Utilities are in a tricky place, trying to keep up with customer needs and expectations while meeting regulatory needs. At the outset of looking at this space, we saw two main options available: enable a series of small innovative applications that effectively put the utility in the role of system integrator, and large, horizontal companies that provide a single, overarching platform to manage the customer. We didn’t like either.
LC: Tell me more about how you saw utilities acting like system integrators for more targeted applications.
JW: Within the market today, there is an ecosystem of innovative products that add value to utilities—support of energy efficiency and demand-side management, bill analysis, program enrollment, marketplace, etc. But at the end of the day, most utilities need to adopt an entire portfolio of these applications to meet customer and regulatory needs. That puts the utility in the role of system integrator, where they are bound to all those integrations and stitching data together on the back end. In one case, we had a customer that was integrating nearly 75 different customer-facing applications. IT teams simply don’t have that luxury of time and resources today to maintain all of that.
We also looked at how this impacts the customer experience. We audited the customer journey at several utilities and found that some were offering as many as 350 different customer experiences once you strung together the multiple applications that were being utilized to do things like enroll in a program or sign up for a new service—which all require essentially the same set of actions.
But it’s not as if utilities have always had much choice in the matter. The regulatory construct for things like energy efficiency (EE), demand response (DR), time-of-use (TOU), etc., are all different, and in the past, the only way to fulfill the need is to adopt solutions from many different companies, and to carry all that complexity down to the customer.
We work with >75 utilities today, and if we invest in R&D to develop a product, it’s easier for us to deploy that at other existing accounts.
On the opposite end, we knew that we didn’t want to be a big, monolithic solution that would essentially need to be customized for every utility. We see those already in the marketplace, and what we didn’t want to approach people with was an initial large cost to deploy, and then all the complexity involved in large, custom implementations.
LC: One common challenge with analytics solutions on the market today is the notion of the “black box”, or a solution where data goes in and answers come out, with no insight provided as to how those answers were determined – how do you address that?
JW: there are a few different pieces here. Our overarching goal in terms of the specific outcomes for a utility-related to our products is to provide something useful end-to-end. For example, things like energy efficiency, kilowatt-hours (KwH) reduction, or demand savings, are paired with monitoring tools and customer service functions so a program manager can understand what is happening at all points of their program, and not just the basic outcomes.
But then there are a lot of cases where additional value can be derived from the data and information that we work with and produce. In the solutions that we deliver today, we want to provide (our) customers with insights and data that they or others can extract more value from, and we do this by offering standard APIs.
Some customers may want an API simply for the case of building a custom mobile app, or something similar. Other times we provide APIs and data specifically for internal analytics teams. We designed our solutions so that in the case where a utility decides to invest buy in a turnkey solution, they get access to all the data analytics underneath that too.
LC: What are some ways that you see analytics teams utilizing your data and insights outside of customer engagement and EE/DSM/DER adoption?
JS: Part of our goal is to alleviate challenges with the consistency of data that analytics teams get stuck with when there are multiple different applications touching the customer. Then, there is the bit about providing useful data for applications that sit outside of our domain. This includes revenue protection, bad debt, rate analysis, or managing capacity.
JW: It’s especially cool when we can run an analysis of how various programs that our solutions manage on things like bad debt—like, this action might add to bad debt, or another might minimize it. We also envision this being helpful for regulatory filings, simply by making it easier to get access to consistent data for informing these documents.
LC: “Revenue opportunities” is turning into a buzzword that vendors throw at utilities with little to no substance. How can your platform specifically enable new revenue opportunities, on a residential and C&I level?
JS: With flat growth, competition growing, every utility executive is asking how solutions can produce or enable new revenue streams. In general, realizing new revenue opportunities starts with the mindset shift from commodity provider to a retail provider of products and services, with a focus on customer lifetime value (CLV) and all the metrics that support that. If (utilities) don’t do that, (they) can have all the business aspirations in the world, but they won’t be able to operate in a way that will result in lasting success.
If the experience isn’t there, and if customer value can’t accurately be measured or quantified, then what’s the point in talking about new revenue opportunities?
In the marketplaces that we have deployed with utilities, the goal is to offer a great, personalized experience and streamlined transactional process. Following that, we ensure that customers can experience the value of marketplace solutions in multiple areas. This builds on the willingness to continue engaging, resulting in a higher overall CLV. We have already seen this at utilities like Baltimore Gas & Electric, PSE&G New Jersey, and Xcel Energy.
C&I is a really exciting area, where we can look at things like reducing electrification costs simultaneously with a company’s carbon footprint. What’s important in these cases is that the business opportunities tie into the local regulatory construct. If these incentives are on par with investing in poles and wires, there is already an opportunity for a utility to realize material earnings.
There is a relationship between investing in value for customers and grid and infrastructure investments. The problem is that utilities struggle to tie this back to the rate case with founded examples and data. This is the single thing that we, as a company, do best.
