So far in this Demand Response series, I have provided my thoughts on the primary definitions, so you know what is, and what is not Demand Response. I have talked about the drivers and why you may want to develop a Demand Response capability. I then talked about some of the thinking that should go into designing the services that you will offer to customers. You are to develop these services in a way that delivers your Demand Response capacity requirements with a strong customer value proposition.

As I was giving more thought to what I want to write, it was evident I had been a little optimistic to think I could achieve this in one short post. So I am cheating a little and will split this part of the series into two posts. This post will focus on the back-office capabilities required. The second post will focus on what goes on beyond the meter at the customer’s premise.

As always, this is just a high-level overview of what you need to consider. The capabilities described below are not meant to represent ‘physical’ systems. You will implement differently depending on your application landscape. You may want own and operate these applications; you may use a cloud service, or you may outsource the entire service.

Remotely capture interval consumption data from meters

In the final post, I will talk more about the models that you need to consider to calculate demand cut and the final incentives to pay customers. Regardless of the models you use, they all require interval consumption data from the meters.

Some programs do not rely on interval consumption data from meters. I have concerns about the ability of these programs to accurately calculate demand cut. I know some of you have fairly strong opinions on this, and I look forward to discussing in a future post.

Other reasons such granular data is required include analysing each customer’s load profile to determine if and how you want to engage them. Not all customers have the same demand cut potential, so you need to leverage such insights to get the most from your limited customer engagement resources.

You also need this information to present to customers so they can see what electricity they are consuming. Providing them with feedback so they can relate cause with effect to maximise participation. How close to real-time you do this is another area that I find people have strong views so I will look to write about this in a future post.

Calling and managing a Demand Response event

A Demand Response event has a start date and time, an end date and time, and lasts for a pre-determined number of hours. You may only want certain customer segments to participate in a particular event. One customer segment may have a different incentive structure from another. You may need to notify some customers 8-10 hours before an event starts. Others will have automated plans in place where you control the customers devices, such as building management system so that the notification period may be a lot shorter. You need the capability to manage all of this. Often referred to as a Demand Response Management System. You can own and operate this, run it as a cloud service, or just outsource the whole thing to a demand response aggregator.

Settling the financial transaction

Financial incentive, such as peak time rebates, critical peak pricing, subscriptions, etc. can be quite complex calculations as compared with traditional tariff structures. You must have the ability to calculate and pay the customer. Often the incentives are paid out as part of the customer’s normal billing cycle. To do this, you need to consider the impact on systems such as the meter data management system as well as the customer billing system.

Calculating demand cut, gaining insights from customer load profile, and calculating financial incentives

Unfortunately developing the required analytics capabilities remains an afterthought for many that are exploring Demand Response. Analytics will make or break your Demand Response program. In my final post of this series I will talk about the various models required, all of these rely on a you having a strong analytics capability, or, at least, partnering with someone who can provide this.

Digital channels, especially mobile

As already mentioned, what level of information a customer needs, in what format, and how close to real time is a hot area for debate. In the next post, I will touch on in-home displays. In all cases, you need to ensure the customer can access meaningful information to increase the likelihood they will take part in a demand response event. I say ‘meaningful’ as I am not a fan of providing customers with consumption information, such as kWh. kWh mean nothing to the majority of us, so communicate in dollars and cents.

Also, no-one wants to sit in front of a computer to analyse their energy consumption, so why are you delivering the information via this channel? Provide easy to consume information on smartphones and tablets so people can check when they have downtime such as in queues, in taxis, on buses and trains, etc.

The holistic view

As you can see, developing a Demand Response capability requires a comprehensive view. There is no point running Demand Response programs if you cannot pay the incentives to customers, or you cannot calculate the demand cut, are not accurately segmenting customers, etc.