AI for Order Management in Energy

A rejection report lands in the registrations mailbox before the team logs on. The enrolment for a new domestic customer has come back unaccepted: the meter point identifier captured at the point of sale belongs to the flat above, the supply address on the market register does not match the one the customer typed into the sign up form, and the start date on the submission has now passed.

Nothing has been picked, packed or shipped. This is still an order, and it is the sort that fills a customer operations week.

The order book inside a retail supplier is made of registrations rather than deliveries: enrolments, switches, change of tenancy, move in and move out, ceases, metering work orders and new connections. Every one is a message to a market system, a counterparty who can refuse it, or a third party whose dates you do not set.

An enrolment is a claim on a meter point

What you submit is a request to be recorded as the registered supplier for one identifier from one date. Everything downstream hangs off it: the reads you are entitled to, the agents appointed to it, the settlement position, and whether billing has any basis to invoice. So identifier, supply address, meter configuration, start date, product and payment method all have to describe the same supply. An agent can assemble the submission from the sale record, the contract and the register, then state which fields are confirmed and which were inferred by someone in a hurry.

Matching the sale to the supply before you submit

Address matching is the quiet source of most of it. Subdivided houses with flats lettered by one party and numbered by another. Farms with several supplies behind one postal address. Register addresses were typed by somebody else years ago and were never meant to be read by a sales channel.

Resolve the sold address to candidate identifiers, show the alternatives with the reason for each, and refuse to choose between two supplies at one address where the evidence does not separate them. The same pass should check the meter against the product: a multi rate meter sold a single rate tariff, a prepayment meter on a credit contract.

What a rejection code does not tell you

Market rejections come back as short codes, and one code routinely covers several causes. The identifier does not exist. Somebody else has a registration in flight against it. The customer details do not match the record held against the supply.

An agent reading the code alongside the submission, the register and the sale notes can state the actual cause and draft the resubmission for a person to release. Clustered by root cause, the day's rejections show that one sales channel captures identifiers from the wrong field and one broker sends truncated ones. Fixing that upstream removes the work rather than speeding it up.

Objections, and the balance behind them

A switch in progress can be objected to by the losing supplier, and the grounds are usually money or term. An unpaid balance. A contract that has not reached its end date. A registration they believe was taken in error.

Each objection has a short window and few resolutions: the customer settles, the balance transfers, the objection is withdrawn, or the order is cancelled and dated later. An agent can assemble the position per objection: the amount, whether it can be transferred rather than paid, the contract end date, and whether the customer has already disputed the debt in a service conversation. Whether to fund a balance to keep a sale stays with a person.

Two parties claiming the same read date

Change of tenancy orders fail because they depend on people's memories. The outgoing occupier says they left on one date, the incoming occupier says they moved in the following week, and the landlord claims the void in between and offers no read. All three send something: a tenancy agreement, a completion statement, a photograph of the meter display.

An agent can build the chronology from that evidence, set the competing reads against each other, and name what is wrong: an overlap where two parties are liable for the same days, or a gap where nobody is. The occupier conversation stays human, because someone will be told they owe more than they expected.

Opening reads and the estimate that replaced them

Opening reads carry the same risk. Digits get transposed, so a meter showing 40821 is read as 04821 and the opening balance is wrong by an amount nobody notices until the next bill. A multiplier on a transformer metered supply is left out, or an estimate stands in until a real read arrives and the account has to be rebuilt. Validating a claimed read against consumption history and meter configuration is arithmetic with context, and an agent can do it on every order.

Metering work raised, appointment never attended

Plenty of orders cannot complete until somebody visits. A meter exchange, a reconfiguration for a new tariff, a de-energisation on a cease. The work order goes to a metering agent, needs an appointment slot, needs access, and sometimes needs a joint visit with the network operator.

So the order waits on a work order that waits on an appointment that was never booked, or was attended and aborted: no access, meter in a locked cupboard, an asset on site that does not match the order. Those outcomes arrive as engineer notes rather than as status, so no report shows them. An agent reconciling work orders against appointment records and visit notes can state which orders are held and who needs chasing.

What a new connection order really waits for

New connection orders break the pattern because the work belongs to the network operator and the programme belongs to a developer. Until the connection is made and the identifier issued, there is nothing to register against: the sale and the contract exist, the start date was agreed with a builder whose programme has slipped twice, and the order has no identifier to put in it. An agent can hold these as explicit dependencies rather than stale orders, read the operator correspondence and the developer updates, and flag the expected identifier date moving past the contract start date, so the contract is re dated before the submission fails.

Live in one place, lost in another

Then there is the disagreement that costs real money. The order says the supply is live, the market register shows another supplier holding the identifier, and billing is invoicing the account anyway. Or the reverse, where a supply you genuinely hold has never been billed because nothing opened an account. The causes are mundane: a loss notification never actioned, a cancelled order left open, a registration reversed in the market but not in billing.

Continuous reconciliation suits an agent because it is scheduled, comparative and dull. Compare registrations against order status against billing accounts and present each mismatch with enough context to work, starting with the identifiers that bill with no registration behind them.

Onboarding a portfolio rather than a customer

Business supply changes the unit of work. A signed contract can cover many sites with different start dates, meter types and existing suppliers, so onboarding it is a schedule of orders rather than an order, and each site carries its own identifier validation, objection risk and opening read. The part completed portfolio is the problem: one site rejects, nobody notices, and the customer is billed partly on the contracted rates and partly on something else, which surfaces as a dispute months later. An agent can turn the signed schedule into a per site order plan and report the sites that have not landed.

Additions mid contract and half hourly sites

Portfolios move during their term. Sites are acquired, closed, or come out of term with a previous supplier and join the existing contract at the rates agreed for additions, so each addition is a fresh order priced and dated against that contract rather than against today's book. Half hourly sites follow a different path again, with settlement arrangements, agent appointments and agreed capacity to confirm before the registration is useful. An agent should route them separately.

The broker site list that does not reconcile

Broker submitted business arrives as a workbook. The columns are the broker's own, identifiers are missing or truncated, and sites are named by branch rather than by address. None of it can be submitted until it is reconciled to the register. This is high volume, low judgement work that rewards automation more than anything on the desk: resolve each row to a real supply, separate the rows that cannot be resolved, flag the site claimed in two brokers' submissions, and hand the desk a load file with its exceptions pulled out.

Where AI fails here

Committing a supply start date stays with a named person. An agent can show what the objection window, the appointment lead time and the registration rules support. The promise stays with a human.

Money decisions are not automatable. Funding a disputed balance to save a switch, waiving a charge after a failed appointment, or settling a read dispute in the customer's favour all bind the company commercially.

Irreversible actions need a human by design. De-energisation, or a cease on a supply that turns out to be occupied, are not undone with a corrective order. The agent should assemble the evidence that the right supply was identified and the right party asked.

An agent cannot repair your register data. Where the address, meter configuration or read history is wrong, it will reconcile confidently against the wrong record and produce a clean looking submission that fails anyway, or worse, succeeds against the wrong supply. Nor can it create capacity: the network operator's queue, the metering agent's appointment book and the losing supplier's willingness to withdraw early all sit outside the system.

Where to start

Take one order type and one report. Domestic enrolment rejections are the best first candidate, because the volume is steady and the causes repeat. Have an agent state the actual cause of each rejection, draft the corrected submission and group the day's failures by root cause. Leave the release with the desk. You will soon know what share of rejections come from capture rather than from the market, which is more useful than any audit of data quality.

Objection handling is the usual second step, because the window is short and the assembly work repeats. Register against billing reconciliation comes next, and pays for itself in invoices never issued against supplies you do not hold.

Adopt AI Partners builds these agents inside the registration, metering and billing systems a supplier already runs, so a resolved rejection lands back on the order rather than in another queue. If you want to talk it through, describe how enrolments and objections reach your desk and send it to hello@adoptaipartners.com.