Software for an electrifying decade.
Customer platforms, metering data and field operations for energy and utilities — reliability culture meets modern engineering.
- Discovery and estate mapping
- Contracts and architecture
- Build in slices
- Parallel run and peak rehearsal
- Operate, reconcile, extend
Energy is becoming a software industry.
Energy is becoming a software industry with hardware attached: smart meters produce data floods, customers expect digital everything, and the field workforce runs on mobile. We build the customer, data and operations layers — with the reliability culture the sector already lives by. What makes it hard is not the volume on its own; it is that the volume has to be exactly right. A meter read is not telemetry to be sampled and forgotten. It is the basis of an invoice, a regulatory submission and, eventually, an argument with a customer or a regulator about a number from months ago.
Then there is the estate. Billing and customer information systems have decades of tariff logic inside them and a change window measured in quarters. Meter data management, the AMI head-end, GIS, asset management, the market interfaces and the payment providers each have their own identifiers for the same connection point, and none of them agree on the boundaries of a day. Operational technology sits behind a line that must not be crossed casually. And the regulator does not accept “the integration was late” as an explanation for a missed submission. Our approach is to wrap the systems of record in governed contracts, make every flow reconcilable, and build the customer and field surfaces against those contracts — so the parts that need to move quickly can, and the parts that must not move do not.
Reliability is the through-line. Peak is a cold Monday morning or the hour a tariff change is announced, not a marketing campaign we chose the date of. Pipelines are sized from your real meter fleet and its actual late-data behaviour, availability targets are agreed with you according to your needs and measured, and the engineers who design a service can also operate it. GDPR / KVKK compliant, deployed to the region you specify.
Four places we do the work.
Retail, network and metering businesses ask for different things, but the programmes land in these four areas — and they are usually connected.
Customer platforms
Billing-integrated self-service, consumption insight and tariff journeys built to cut call volume. The work is rarely the portal itself; it is making an invoice explainable, showing consumption in a way a household recognises, and letting someone submit a reading, change a payment date or switch tariff without a call. Every journey is built over governed APIs on top of billing rather than a second copy of the customer record, and we design for the day the call centre is closed.
Metering & data
Smart-meter ingestion at scale, validation/estimation flows, and analytics that finance and operations both work from. Interval data arrives late, out of order and occasionally twice; the pipeline is built to expect that, with idempotent writes, explicit VEE rules, and a record of every substituted value and why. Streaming on Kafka, stored in a time-series model our Data Engineering practice designs around your settlement calendar.
Field operations
Work-order and crew mobile tooling — offline-first, because the field has no signal guarantee. Jobs sync down with everything the crew needs, evidence goes up when the connection returns, and conflicts are resolved by rule rather than by whoever synchronised last. Big targets, gloves-on interaction, and a photo and asset-scan trail that stands up as evidence. Built as native or hybrid mobile apps against the same contracts as the back office.
Loyalty & engagement
Efficiency-behaviour programmes on our loyalty engine — engagement economics adapted to regulated retail. Rewarding a shift in consumption is not the same as rewarding spend: the rules read interval data, the incentive has to be defensible to a regulator, and the accrual must reconcile to the same source the invoice used. Loyalty & Retention supplies the ledger, tiers and redemption; we configure the earning rules for energy.
What we build, in detail.
Meter data that survives contact with reality.
A metering pipeline is judged on the days it goes wrong. A concentrator goes quiet for hours and then delivers everything at once. A firmware upgrade changes a timestamp convention. A read arrives for an interval that has already been billed. We build for those cases first: ingestion is idempotent on meter and interval, late and corrected data is accepted within a defined window and reported when it lands outside it, and validation, estimation and editing follow written rules with every substitution recorded, attributed and reversible. Volumes are sized from your fleet and its real behaviour.
- Idempotent on meter and interval, so a replayed file cannot double-count a consumption figure
- Validation, estimation and editing as versioned rules, with the substituted value and its reason kept beside the original
- Backfill and reprocessing tooling with a report of what changed, so a correction is explainable months later
Regulated numbers with a path back to their source.
Billing and regulatory reporting are where a metering estate’s sins surface. Our rule is that no published figure exists without a path back to the reads it came from. Each flow — meter to settlement, settlement to invoice, invoice to regulatory submission — produces a reconciliation report as part of the run, not as a monthly investigation. Differences are surfaced with their cause: missing reads, estimates awaiting actuals, a tariff version applied after a change date. Nothing is quietly balanced.
- Reconciliation as a first-class output of every flow, with variances explained rather than netted off
- Tariff and calendar versions applied by effective date, with the version recorded on each calculated line
- Wrap, don’t poke: governed APIs over the billing core, with writes limited to the interfaces the vendor supports
Work orders that finish without a signal.
A crew in a basement substation or a rural connection has no network, and a tool that assumes one is a tool that gets abandoned. Field applications we build hold the whole job locally: instructions, asset history, safety checks, forms and the photographs already taken. Work completes offline and synchronises when the device reconnects, with conflicts resolved by rule and anything ambiguous queued for a human rather than silently overwritten. Crews are involved from the first prototype and the tool is piloted on real routes before it is rolled out, because adoption is a design requirement and not a training problem.
- Whole job available offline — instructions, asset record, safety checks, forms and evidence
- Deterministic sync with conflict rules; anything the rules cannot settle goes to a review queue with both versions
- Evidence captured at the point of work — photographs, scans, timestamps and location — so a job closed is a job proven
- 01Dispatch
- 02Travel
- 03On site
- 04Complete
- 05Synced
Work-order lifecycle
Three buyers, one platform.
The answer in the app, not on a call.
Contact-centre volume concentrates in a handful of questions: why is my bill this size, when is it due, can I change the date, how do I submit a reading, what tariff am I on. Answering them properly in self-service takes billing integration rather than a content page. We build the journeys over governed APIs on the billing core, keep the explanation of the invoice as detailed as the invoice itself, and measure deflection per question so the roadmap is driven by the queue rather than by opinion.
- Invoice explanation that traces a charge to a reading, a tariff version and a period
- Payment, tariff and meter-reading journeys transacted through the billing core, not a shadow record
- Deflection measured per contact reason, with the next feature chosen from the top of that list
The day’s work, visible and provable.
Network and operations teams need to know what is planned, what is happening and what evidence exists. We build the dispatch and work-management surfaces around the assets in your GIS and asset-management system, keep the mobile app offline-first, and make completion evidence a structured record rather than a photograph in someone’s gallery. Integration with operational technology is done with care and read-mostly patterns — the grid is not a test environment.
- Jobs modelled against the asset record, so history follows the asset rather than the ticket
- Offline-first mobility with deterministic sync and a review queue for conflicts
- OT-adjacent integration through historians and gateways, read-mostly and reviewed with your control engineers
Numbers with lineage your auditor can walk.
The data office is accountable for figures it did not calculate: settlement volumes, loss estimates, consumption reporting, emissions and efficiency claims. We build the governed layer that makes those defensible — one modelled definition per measure, lineage from a published figure back to the interval read that produced it, and reprocessing that reports what changed instead of quietly restating history. Served to Power BI and notebooks from the same warehouse operations uses.
- One definition per measure, versioned, with the owner named
- Lineage from report to source interval, including any estimated or edited values on the path
- Restatements are explicit: what changed, why, and which published figures are affected
The systems a utility actually runs.
Billing / CIS
Customer, contract, tariff and invoice data through the vendor’s supported APIs or staged interfaces — SAP IS-U-class estates included, with writes limited to what the vendor supports and reconciliation on every flow. See our SAP and ERP practice.
Meter data management
Interval and register reads, VEE outcomes and substitutions exchanged with the MDM, with identifiers resolved to a single connection-point key across systems.
AMI head-end & concentrators
Streaming or file-based collection from the head-end with idempotent ingestion, late-data windows and gap reporting per meter rather than per batch.
GIS & asset management
Assets, connection points and network topology synchronised into the work and customer layers so a job, a meter and a premises refer to the same thing.
SCADA / OT historians
Read-mostly integration through historians and gateways, on a segregated path agreed with your control engineers — operational data comes out, application traffic does not go in.
Market & settlement interfaces
Scheduled submissions and responses built from the modelled layer, with calendars, deadlines and reconciliation evidence produced by the pipeline.
Payments & e-invoicing
Card, direct debit and bank channels behind one payment abstraction, with statutory e-invoicing formats generated from the billing record and their acknowledgements tracked.
EV charging & flexibility
Charge-point management and market APIs — OCPP-class protocols — feeding the customer and settlement layers so a session becomes a billable, reportable fact.
What we hold ourselves to in this sector.
- Time-series engineering for utilities. Partitioning, retention and compaction designed around the settlement calendar, ingestion idempotent on meter and interval, and load tested against your real fleet profile rather than an even distribution.
- Regulated-market billing accuracy with reconciliation. Every flow emits a reconciliation report as part of its run. Variances are explained, not netted off, and a published figure has a path back to the reads behind it.
- OT-adjacent integration handled with grid-respecting care. Read-mostly patterns through historians and gateways, on segregated paths agreed with your control engineers and reviewed with our security practice. We do not put application traffic on operational networks.
- Offline-first field mobility as default. Field tools are designed for no signal, gloves and daylight. Sync is deterministic, conflicts go to a queue rather than to chance, and crews are in the design loop from the first prototype.
- Wrap the system of record; modernise behind evidence. Governed APIs go over billing and metering cores first. Replacement, when it is justified, happens behind a parallel run — the approach our modernisation practice uses everywhere.
- Peak is an engineering requirement, not a hope. Capacity is modelled from real curves — cold mornings, tariff announcements, outage events — autoscaling is rehearsed against synthetic peaks, and degraded behaviour is designed so the platform bends before it breaks.
- Every event flow is replayable. Outbox patterns, dead-letter topics and documented reprocessing mean an outage becomes a backlog rather than a hole in a month’s data.
- GDPR / KVKK compliant customer data handling. Consumption data is personal data. Minimisation, retention and access control are designed in, deployments are region-pinned, and the evidence for an audit is a query rather than a reconstruction.
How a utility programme runs with us.
Discovery and estate mapping
We work through the contact-reason list, the metering fleet and its real failure behaviour, and the systems of record — which one owns the customer, the connection point, the asset. Output is a written problem statement, a sizing model built from your data and a slice plan.
Contracts and architecture
Integration contracts over billing, MDM and the head-end; the time-series and settlement data model; the security design for anything near operational technology. Reviewed with your architecture, security and control-room people before code is written.
Build in slices
One journey or one flow at a time, each into a real environment with monitoring, tests and reconciliation from the start. Field tools are piloted with a single crew on real routes; customer journeys go to a limited segment before they go to everyone.
Parallel run and peak rehearsal
New flows run alongside the existing ones until differences are explained and signed off. Load is rehearsed against modelled peaks, failover and restore are exercised, and the runbook is written by the people who will be on call.
Operate, reconcile, extend
We can run the platform: on-call, monitoring, reconciliation reports reviewed with your team, incident reviews written up, and a roadmap updated regularly, at a rhythm agreed with you. Handover to your engineers is planned rather than improvised.
Frequently asked questions
Neighbouring sectors we work in.
Bring us a problem from your industry.
Describe what is going wrong today. An engineer reads it and replies in writing with a concrete path.