Where the projected revenue comes from
Leap pays you for the VPP revenue your enrolled customers earn. Your offer decides how much of that revenue each customer receives. Every figure the builder shows is money you owe a customer, based on a forecast rather than a settled payment. Leap holds a projected revenue figure for each month of the year. It is specific to a combination of program, customer classification, device type, and the commercial terms of your agreement with Leap. Your offer reads the sum of all twelve months. That total is the projected annual revenue. It is already net of Leap’s fee, so it is what you earn. Monthly revenue moves with the seasons, and many programs pay in only part of the year. The annual figure is the true sum across the twelve months, not one month multiplied out. Because your commercial terms feed the projection, two partners quoting the same customer and the same device can see different figures.The two settings that scale the projection
Two controls turn projected annual revenue into a payout, and they multiply together:- Risk buffer: a multiplier from 0.50 to 1.50 on the projection. The builder shows the number alongside a word, so 0.85 reads as
0.85× · Conservative. At 1.00 the offer pays the projection exactly. Below 1.00 you keep a buffer in case the projection proves optimistic. Above 1.00 you deliberately pay more than Leap projects you will earn. The upfront and ongoing payments each carry their own risk buffer. - Customer revenue share: the percentage of the risk-adjusted revenue your customer receives. This is one value for the whole offer, and it scales both payments.
A risk buffer of 0.70 with a revenue share of 80% pays 56% of projected revenue, not 80% and not 70%.
Upfront payment, which buys several years at install
An upfront payment is a single lump paid once, when the install is confirmed. It packages several years of projected revenue into that one amount:
The 1 year factor is exact, because a 1 year lump covers only the undiscounted first year. The other two are shown to six decimal places. So a 3 year horizon is worth 2.783265 years of revenue rather than 3.
Ongoing payment, which the builder quotes as a yearly amount
An ongoing payment repeats for as long as the customer stays enrolled, and the builder quotes it as a yearly figure. It covers one year at a time, so no discount applies:/yr for that reason, and that label holds whatever cadence you set.
The cadence control divides that yearly amount into the payments your customer actually receives. Monthly pays a twelfth each month, seasonal pays a quarter each quarter, and yearly pays the whole amount once. Cadence changes the size of each payment, never the yearly total.
To work out a single payment, divide the yearly figure by the number of payments the cadence makes. That is 12 for monthly, 4 for seasonal, and 1 for yearly.
The method control decides what the amount means:
- Flat rate locks the calculated amount. Your customer receives the same figure whatever the program pays out. Leap recommends a flat amount for all partners.
- Revenue Share promises the percentage instead of the figure. The amount shown is a projection, and the payment settles against the revenue actually earned. Leap reserves this method for commercial arrangements that pay customers on event performance. Revenue Share pays yearly, so the cadence control does not apply to it.
A worked example you can check by hand
This example runs the whole calculation on round numbers. Every revenue figure below is illustrative rather than a real Leap projection. Follow the arithmetic here, then read your own figures from the builder. Take a residential customer with a smart thermostat. The offer runs a 3 year revenue horizon and a customer revenue share of 80%. Its upfront risk buffer is 0.70 and its ongoing risk buffer is 0.80. Rounding is set to the nearest $5. The customer qualifies for two programs, and the two may legally run together, so both count:
Both payments read that combined $120.00:
What happens when a customer qualifies for several programs
Programs are not all compatible, so Leap first works out which of them may legally run together for that customer. It picks the combination worth the most, then adds up what each program in that combination contributes. Programs that cannot legally stack never appear together in one offer. Stacking changes the input to the formula and never the formula itself. Adding a program to a customer’s eligible set raises the payout in proportion to that program’s projected revenue.Why a program you expect may be missing
Both payment types need a revenue projection for the exact combination in front of them: program, customer classification, device type, and your commercial terms. When no projection exists for that combination, the program drops out of the offer rather than quoting $0. One consequence is worth planning for: the same offer settings produce different amounts for different devices and customer classes, and sometimes no amount at all. Run the builder’s test scenarios across the device types you sell before you publish.Round offer to nearest changes the amounts shown in the builder preview. A published offer pays the calculated amount to the cent. Use the control to see figures the way you would quote them, and expect a published payout to carry cents.