Requirements and Limitations

The following data requirements and limitations apply to all utilities and customers in the High Bill Alert AMI program.

Utility Requirements

This table lists the utility requirements:

Category Description
Scale Scale restrictions may apply to the number of customers enrolled in alerts. The actual number of communications sent may be affected by attrition, opt-outs, customer eligibility, data availability, and the number of customers whose forecasted usage exceeds configured thresholds.
Language Not all languages and locales are supported at this time. Contact your Oracle Utilities Opower Sales Representative to confirm that alerts are available in your market.
Delivery Window High Bill Alerts AMI must be delivered during waking hours in a utility-specific delivery window. They cannot be delivered during the configured non-delivery window.
Delivery Frequency High Bill Alerts AMI are limited to being sent once per billing period per service point to avoid excessive alerting.
Rate Modeling Utility rates must be modeled by Oracle Utilities for cost information to appear. If rates are not modeled, energy use information is displayed by default. If the utility chooses to display cost information, rate modeling is required during initial program setup for an additional fee. See the Oracle Utilities Opower Rates Engagement Cloud Service Product Overview for more information.
Other Product Requirements

Load Shifting Rate Coach Insights: In order to provide Load Shifting Rate Coach insights within the High Bill Alert AMI emails, the utility must have purchased the Load Shifting Rate Coach Cloud Service, and the customer must have modeled rates.

Water Data: The following requirements and limitations are associated with sending alerts that include water data:

  • Utilities must purchase the Oracle Utilities OpowerDigital Self Service - TransactionsCloud Service.
  • Customer must have metered water service. Wastewater and sprinkler service are combined with standard water service under "water".
  • Water rates must be modeled.
  • A water cost experience is supported for the meter types and meter type combinations below. (A water usage experience is not supported.)
    • Water
    • Electric and Water
  • Budget billing will display a usage experience, but is available only for Water or Water and Wastewater meter types.
  • Water alerts must be run as an opt-in program. Customers must opt-in to receive alerts and also set a personal cost threshold to be eligible.
  • Water alerts are supported in the email and SMS channels only.

Web Portal Requirements: Some of the features listed in this documentation require access to a web portal. For example, to enable customers to set a personal threshold, or to opt into or out of the program from a utility website, the utility must provide customers with access to a web portal. Oracle Utilities Opower provides the following web portal products:

  • Oracle UtilitiesOpowerEnergy Efficiency Web Portal
  • Oracle Utilities Opower Digital Self Service - Energy Management
  • Oracle Utilities Opower Digital Self Service - Energy Management Advanced Metering Infrastructure

Note: Purchasing one of these web portal products is not required to send alerts. A web portal is required only if utilities want to utilize features that require customer access to a web portal. Utilities might also decide to create their own web portal and use APIs to enable customers to access and update their information. For additional information, see the Oracle Utilities REST API documentation.

Customer Requirements

This table lists the customer requirements:

Category Description
Billing Frequency Monthly or bi-monthly.
Data Delivery Frequency Daily. The utility must be able to deliver customer data to Oracle Utilities within 72 hours (48 hours from the last data read of the day). Data must be sent to Oracle Utilities in the right schema and according to the Oracle Utilities Opower Interval Data Transfer Standards.
Data Requirements

Billing Data: Billed usage data from the utility is required.

AMI Data: Daily, hourly, or sub-hourly AMI data is required. High Bill Alerts AMI cannot be sent without this level of data granularity. The customer must have AMI data going back to the beginning of the current billing cycle.

Hourly or subhourly AMI data is required for the Time of Day Module module (otherwise this module is hidden). AMI data is not required for weather insights to appear in the Time of Day module.

Contact Information: The customer must have valid contact information for the channels through which they receive High Bill Alerts AMI.

Data History

AMI data going back to the beginning of the current billing cycle is required.

For customers who do not have a personal cost threshold set, at least a year's worth of billing history is required.

For customers who do have a personal cost threshold set, a year’s worth of usage data is not required.

More information about personal thresholds can be found in the Bill Forecast Module module topic.

Data Coverage

By default, at least 75% of the possible reads for the current billing cycle are required to calculate the bill forecast. Estimated reads count towards this threshold. This threshold is configurable.

At least 75% of possible reads for the current billing cycle is required to calculate the customer's high usage period. If this threshold is not met, the Time of Day Module module is hidden.

Supported Fuels and Services Electricity, gas, and water.

Limitations

The limitations are as follows:

  • Non-Residential (Business) Customers: Non-residential business customers can receive High Bill Alerts AMI. See the Business Customer Engagement Proactive Alerts Product Overview for more information.
  • Dual Fuel Customers: Dual fuel (gas and electricity) customers will receive a single combined fuel alert.
  • Multi-Service Customers: Customers with electric and water service will receive a single combined service alert.
  • Number of Service Points: To avoid over-alerting, multiple service points of the same fuel type (in the same service agreement) are combined and sent in a single alert.