The whole back office, laid out.
9 capabilities sharing one customer, one service point and one ledger. 5 are core and always on; 4 switch on when they start earning their place. Each one below is a job your team stops doing by hand.
CRM
Customers & enrollment
Every prospect, customer, service address and ESI ID in one book of business — from first quote to an active account.
Off your desk
You stop keeping a spreadsheet of who was sold what, and re-keying it into a second system to enroll them.
Core platform · always on
How customers & enrollment works- Prospects and customers with fields you define yourself, no schema change required
- Address entry that normalises to a real USPS deliverable address before it becomes an enrollment
- Bulk import with column mapping, validation and a dry run before anything is written
- The enrollment funnel wired straight to the market: quote, enroll, 814, activate
Texas SET
Market transactions
The full ERCOT document inventory, sent and received, with every chain tracked end to end.
Off your desk
You stop paying an EDI vendor to hand you files that someone then has to match against accounts by hand.
Core platform · always on
How market transactions works- All 44 Texas SET 5.0 transaction types across the eight families — 650, 810, 814, 820, 824, 867, 997 and T-series
- Inbound and outbound legs correlated into one chain, so a switch reads as a story rather than a log
- Automatic retries with a dead-letter queue you can inspect and replay, not a support ticket
- A simulated market for testing: run a switch, a move-in, a rejection or a permit hold before you go live
ERCOT
MarkeTrak
Issue resolution that matches ERCOT's own taxonomy, so a case you open is a case they recognise.
Off your desk
You stop tracking disputes in a shared inbox and hoping somebody remembers the one that ages out this week.
Module · switch on when you need it
How marketrak works- All 10 case types and 47 subtypes, each with the fields its workflow actually requires
- Inadvertent gain and loss handled as a loop: dispute opens the case, the regain 814 goes out, the result comes back
- SLA clocks, assignment and aging so nothing sits unworked
- Bulk import for the backlog you are migrating in
Financials
Billing & the ledger
A real double-entry general ledger under the bills — every invoice, payment, deposit and adjustment posts to it.
Off your desk
You stop closing the month by exporting three systems into a workbook and arguing about which one is right.
Core platform · always on
How billing & the ledger works- Invoices assembled from usage, rate structure, delivery charges and taxes in one pass
- Payments, deposits, refunds, NSF returns and adjustments, each with its own journal entries
- Levelized and average-monthly payment plans, including the true rolling-average method
- Trial balance and AR aging that reconcile, because they are read from the same ledger the bills wrote to
Dunning
Collections
The path from past due to disconnect, encoded once as policy instead of relived every month.
Off your desk
You stop running the aging report by hand and deciding, account by account, who gets a notice this week.
Module · switch on when you need it
How collections works- Dunning policy you configure: thresholds, notice timing, grace periods, fees
- A worked operator queue rather than a report someone remembers to run
- Disconnect and reconnect bridged to the market as 650 service orders
- Weather moratoriums and a global pause switch, because some months you must stop
Wholesale
Settlements
Check what the wires company charged you. Conduit reprices every TDSP invoice from tariff and meter read.
Off your desk
You stop paying delivery invoices unchecked because nobody has the hours to recompute them line by line.
Module · switch on when you need it
How settlements works- Delivery invoices recomputed line by line against the published tariff
- Variances opened and tracked automatically — duplicate charges, wrong demand, wrong rate class
- The exposure quantified, so you know what is worth disputing before you spend the hours
- Every recomputation kept, so a dispute has its working shown
Products
Products & pricing
Design a plan, price it per utility, publish its EFL, and renew the customers on it.
Off your desk
You stop maintaining the rate card in one place, the EFL PDF in another, and hoping the two still agree.
Core platform · always on
How products & pricing works- 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
Texas
Tax & tariffs
The Texas bill stack, calculated rather than estimated — and the same engine behind your quotes.
Off your desk
You stop maintaining tax tables in a spreadsheet and discovering the exemption was wrong at audit.
Core platform · always on
How tax & tariffs works- Sales tax by ZIP and jurisdiction, with the residential exemption applied where it belongs
- TDU delivery tariffs by utility and rate class
- Miscellaneous Gross Receipts Tax and the PUC assessment
- A bill estimator that quotes from the same rates that will invoice the customer
Collaboration
Support & collaboration
Notes, assignments and conversations that live on the record they are about, not in someone's inbox.
Off your desk
You stop forwarding email threads to explain an account to the next person who picks it up.
Module · switch on when you need it
How support & collaboration works- Notes and assignments attached to any record — an account, a case, an invoice
- Notifications that route to the person who owns the work
- A support centre where your team reaches ours, with the account context already attached
Runs without you
The jobs that happen whether anyone logs in or not.
Screens are where you check the work and handle exceptions. This is the work itself — scheduled, automated, and only interrupting a person when something genuinely needs a decision.
- Every cycle
The bill run
Reads land, usage is rated against the plan, delivery charges and taxes are applied, and the invoice posts to the ledger. Exceptions are queued for a person; the rest just bills.
- Daily
The dunning sweep
Every past-due account is measured against your policy. Notices go out on the day they are due, fees apply where you said they should, and anything reaching disconnect becomes a 650.
- On every 810
Settlement recompute
The moment a delivery invoice arrives it is repriced against the tariff and the meter read. Where the two disagree, a variance opens itself with the working attached.
- Continuous
Market polling
Inbound documents are collected, correlated to their chain and applied to the account. Failures retry, then land in a dead-letter queue you can inspect and replay.
- Ahead of expiry
Renewal campaigns
Contracts approaching their term are gathered into a campaign with the offers you chose. Nobody has to remember which cohort expires in March.
- Every change
The event backbone
Each change publishes an event inside the same transaction that wrote it, then relays to whoever subscribed — your webhooks included. A consumer being down costs a delay, never a record.
Architecture
The parts nobody demos, and everybody depends on.
Retail energy platforms tend to fail in the same handful of ways: a lost message, a leaked row, an edited history, a permission that was really an honour system. These are the answers to each.
- One event backbone
- Domain events are written to an outbox inside the same database transaction as the change that raised them, then relayed as CloudEvents. Consumers deduplicate through an inbox, so a retry is safe and a redelivery is a no-op.
- Isolation you can point at
- Every business row carries a tenant key. Application-level query filters sit over Postgres row-level security, so a bug in one layer is still caught by the other. Retailers who need their own database get one without a different codebase.
- History that cannot be edited
- Row-level change history records what changed, from what, to what, and who did it — with secrets redacted. Operator intent is logged separately. Both tables revoke UPDATE and DELETE at the database.
- Permissions that match your org chart
- Roles and granular permissions are yours to define. A collections clerk sees the queue and not the general ledger; an owner sees both. Capabilities you have not licensed do not appear at all.
Developer platform
An API first, screens second.
The product calls the same endpoints you do. That is the only way an integration stays current — there is no second-class public API to fall behind.
- Org-scoped API keys, each with the permission set you grant it
- Signed webhook deliveries with retries, a dead-letter queue and manual replay
- An OpenAPI document per service, so a typed client generates itself
- The same CloudEvents the platform runs on internally
Bring us a hard month.
A messy migration, a backlog of MarkeTrak cases, a TDSP invoice you have never been able to check. Those make the better demo.