Implementation Tools
Data Inputs & Configurations Guide
About This Guide
This guide is designed to help program administrators and implementers understand the configuration options and required data to support FLEX Program Implementation Tools. It explains the data inputs needed, the configuration options available, and how these elements adapt to support your program needs.
Implementation Tools Overview
FLEX Program Implementation Tools turn complex program rules and data requirements into a reliable infrastructure to support program implementation. Instead of wrangling paperwork, spreadsheets, and ad hoc validations, program & implementation teams gain a single optimized workflow to confirm eligibility, value projects, collect required information, and manage project and payment workflows.
These tools use customer metadata and program rules to consistently and defensibly evaluate each project enrollment. Automated checks reduce manual review effort and lower risk while still giving you full control over how enrollment decisions are made.
With the Implementation Tools, you will know:
- Which customers and projects qualify based on your program design
- How much value each project contributes before it is installed
- Where documentation and required data are missing
- When budgets are on track or oversubscribed
- How much should aggregators be paid for projects enrolled
The tools support transparent program administration by recording every eligibility rule, validation decision, and configuration setting. This traceability means enrollments can be audited, tested, and reproduced with clear explanations of why a project was accepted or flagged. Implementation becomes a repeatable program management process rather than a collection of individual decisions.
Instead of just gathering data, program teams gain a trusted workflow that improves aggregator experience, shortens enrollment cycles, prevents costly errors, and ensures that only qualified, clearly valued projects move forward to measurement and payments. This provides confidence that everything entering the program is ready to deliver savings and value to the grid.
Program Configuration
| CONFIGURATION AREA | DESCRIPTION |
|---|---|
| General | General program design informs configuration options listed below. Configuration: • Program enrollment start & end dates • Accepted population segment(s) • Gas savings for electric projects • Value stream inputs (Avoided Cost Curve, Total System Benefit value curve, etc.) • Incentive multipliers for kWh and/or Therms savings, if applicable, such as for Hard-to-Reach customers, electrification projects, local contractors, etc. • Measure characteristics such as Effective Useful Life (EUL), deemed/standard measure load shapes, and therms profile Net-to-Gross ratios (Ex. Commercial vs. Residential) |
| Budget | Support for configurable budgetary inputs enables automatic checks against an ongoing program budget during each project enrollment. Providing a continuously updated budget tracking value. Fields: • Admin Cost Rate • Aggregator Incentive Rate • Aggregator Upfront Payment Rate • Aggregator Upfront Payment Cap Reservation Multiplier for overperformance payments • Portfolio-level Performance Cap Project Cost Cap for reserved funds • Participant Cost Factors • Reservation Expiration / Extension dates |
| Enrollment Workflow Options | Workflow options for project enrollment review are customizable. Note that both options below leverage Recurve’s automated eligibility validations before enrollment: • One-Stage Program: • Projects are created, reviewed, and moved into tracking • Only requires one set of aggregator paperwork submission, prior to installation • Two-Stage Process: • Projects are created, reviewed, and then later installed, reviewed again, and then moved into tracking • Requires two sets of aggregator paperwork submission, one prior to installation, and then a second set after installation • Aggregator Document Requirements • Customize required documents for one-stage vs. two-stage submission |
| Payments Optional add-on | Whether in a pay-for-performance model or in deemed savings programs, Payments provides a continuous, automated accounting of payment recommendations to aggregators and trade allies, including one-time upfront payments and ongoing monthly or quarterly performance payments. Configuration: • Payment cohort grouping • Aggregator (can include multiple program years) • Aggregator & Program Year (separated by Program Year) • Performance Payment cadence • Payments are always available for draft estimates, based on savings refreshes, typically on a monthly cadence • Recommended payment approval cadence: quarterly • Upfront payment cadence •Weekly, bi-weekly, monthly, quarterly, annually • Draft payment visibility and approval process • Role assignments can be configured for the Program Implementer, the Program Administrator, and Aggregator(s) to offer varying levels of access to certain results (ex. draft vs. approved) and actions (ex. reviewing or approving) |
Eligibility
Below are the data needs to support automated eligibility checks during project enrollment.
| CATEGORY | DESCRIPTION |
|---|---|
| Customer Metadata | Foundational customer and site metadata attributes that enable eligibility validations based on program enrollment design. These fields enable the specification of eligibility criteria such as utility territory, population segments, equity groups, etc. When providing the entire service territory population dataset, metadata should be provided at a minimum monthly frequency to ensure that new accounts, data sufficiency updates, or program changes are reflected. Fields: •Service account ID • Utility’s Premise or location ID • Utility territory Customer class (residential, commercial, industrial) • Tariff or rate schedule • Income or equity flag (e.g., CARE/FERA, low-income indicator) • Building type or NAICS sector code Climate zone Net metering |
| Interval Load Data Optional | If a program design requires data sufficiency, hourly or 15-minute meter data for all participating service points is required. Historical data from up to 1 year prior to the start of the program’s season should be provided. |