The plan, the EFL and the rating engine are one definition.
A plan in Conduit is not a rate card with a PDF beside it. The Electricity Facts Label is generated from the same definition that rates the usage, so the document and the invoice cannot drift apart.
Off your desk
You stop maintaining the rate card in one place, the EFL PDF in another, and hoping the two still agree.
Without this
What this looks like today.
The rate card lives in one place, the EFL PDF in another, and the rating configuration in a third. They agree on the day they are made. Then an adder changes for one utility, and two of the three are updated.
That is not a cosmetic problem in Texas. The EFL is a regulated disclosure. A label that says something different from what the customer is billed is a compliance issue, and it is discovered by the customer.
Renewals have the same shape. Contracts expire in cohorts, the offers have to go out ahead of the expiry, and the customers who do not respond land on a holdover rate that somebody has to have configured. Miss a cohort and you have a book of accounts on the wrong rate, silently.
How it works
Products & pricing, in detail.
Design a plan, price it per utility, publish its EFL, and renew the customers on it.
Rate structures that match what you actually sell
Fixed, variable, indexed, tiered, time-of-use and seasonal, rather than a fixed rate with exceptions bolted on. Time-of-use windows, tier boundaries and seasonal periods are part of the plan definition and are what the bill run evaluates.
Priced per utility
A plan is priced per TDU, because delivery economics differ across Oncor, CenterPoint, AEP and TNMP and a single statewide rate is a fiction. Adders, bill credits, early termination fees and add-ons are all per-plan and per-utility where they need to be.
The EFL generated from the plan
The Electricity Facts Label is produced from the plan definition itself. Change an adder and the label regenerates from the same source the rating engine reads, which removes the failure mode where the document and the invoice disagree.
Renewals as campaigns
Contracts approaching expiry are gathered into a campaign with the offers you choose, ahead of the date. Holdover and month-to-month outcomes are configured rather than improvised, so the cohort nobody responded to still lands somewhere deliberate.
At a glance
- Fixed, variable, indexed, tiered, time-of-use and seasonal rate structures
- Per-TDU adders, bill credits, early termination fees and add-ons
- Electricity Facts Labels generated from the plan itself, so the document and the rating agree
- Renewal campaigns for expiring terms, including holdover and month-to-month
Connected
What this leans on.
Nothing here is a separate product with an integration between it and the rest. These are the capabilities this one shares a record and a ledger with.
Questions
The ones we actually get.
Which rate structures are supported?
Fixed, variable, indexed, tiered, time-of-use and seasonal, with per-TDU adders, bill credits, early termination fees and add-ons on top of any of them.
How is the Electricity Facts Label produced?
It is generated from the plan definition — the same definition the rating engine uses to bill the customer. That is deliberate: the common failure is a label and an invoice that were correct when they were made and diverged afterwards, and generating both from one source removes it.
Can the same plan be priced differently by utility?
Yes, and it usually has to be. A plan carries a price per TDU along with any utility-specific adders, so what a customer in Oncor territory is offered can differ from CenterPoint without maintaining two plans.
How are renewals handled?
As campaigns against expiring cohorts. Offers go out ahead of the term ending, and holdover or month-to-month treatment for non-responders is configured in advance rather than decided when the cohort has already rolled.
The rest of the platform
One customer record, one ledger, one audit trail.
See it against your own book.
Bring a month of real transactions and a TDSP invoice. Products & pricing is easier to judge against data you already argue about than against a demo tenant.