Utilities
Where your product writes into every billing and customer system a utility runs, with one API.
Built for customer-service AI, billing and metering products.
The systems, by name.
Every one starts with a short assessment. Name the system and the action, and we tell you within a week whether and how it can be opened.
Billing and CIS
Customer-service AI, billing and collections products
- SAP IS-U
- SAP S/4HANA Utilities
- Oracle Utilities CC&B
- Kraken
- Gentrack
Utility systems, DACH
Service portals, voice AI and move-in products
- Schleupen CS
- Wilken ENER:GY
- SIV kVASy
- powercloud
- Somentec
Grid and metering
Smart-meter, outage and field products
- SAP IS-U/EDM
- Oracle Utilities MDM
- Itron
- Landis+Gyr
- robotron
Grown systems
Document AI and back-office automation
- Custom systems on Oracle
- Custom systems on MS SQL
- Older Schleupen, Wilken
- Access and Excel
- Portals, no API
Not on the list? Most are not. Name it anyway.
Move-in taken. Then keyed in by hand.
Your assistant takes the move-in on the phone. Nothing can write it into the billing system. Deepdock writes it in, confirmed by the system.
See how a write travelsOne API. Every system your customers run.
Integrate Deepdock once. Every utility after that is a setup, not a project.
Write back, everywhere
Meter readings, moves, tickets and payment plans land in the utility's system, confirmed by its own rules.
Every installation, the same call
Another billing system, another release, another tariff logic: your product calls the same endpoint.
The system says yes
A write is done when the system says so. The call reaches the system, passes its checks, and the answer comes back the same way.
The actions your product needs
Each one is a single call. Deepdock performs it inside the customer's system, through the system's own rules, and returns the confirmation. Choose a system and an action.
SAP IS-U, S/4HANA Utilities, Oracle CC&B, Kraken
- Today
- The agent types it in after the call, screen by screen.
- With Deepdock
- Booked while the customer is still on the line, confirmed.
The call
POST /v1/move-ins{ "customer": { "name": "...", "address": "..." }, "meter": "M-7731", "reading": 48812, "start": "2026-11-01", "tariff": "T-basic" } 201 { "id": "MI-48812", "contract": "V-20311", "booked": true }// confirmed by the systemREST API and MCP tools, one model across systems, every call logged.
Why providers build on Deepdock
We do not sell a connector. We sell the action: performed inside the customer's system, confirmed by its rules, the same at every customer.
API first. The screen last.
An official interface where it exists, the system's own data paths where it does not, the screen only when nothing else works.
Confirmed, not assumed
Every write goes through the system's own validation and comes back confirmed, logged with its request, per customer.
Customer data stays in the building
The client runs inside the customer's network. No record is copied out, nothing is installed on the system, approval per write.
A managed connector, not a project
We open the system, run the connector and keep it running through updates. The next customer on it is a setup.
Start with the deal that is blocked.
Not a platform rollout. One customer, one system, one action that is in the way today. We tell you within a week whether we can open it, then run it for you as a managed connector.
One action, end to end
confirmed- requestPOST /v1/move-ins0 ms
- routeUtilities · SAP IS-U4 ms
- checkvalidated by the system's own rules120 ms
- approvalcheckpoint passed · optional2.1 s
- result201 · confirmed2.4 s
- logrequest and response kept, per customer2.4 s
1. Name the action
The system, the action and the customer where it is blocking you. One call, one week to an answer.
2. We open it
The client goes on a PC in that customer's network. You get the action as an endpoint, confirmed and logged.
3. The next customer is a setup
The same system reuses what we built; a different system gets the same API. Days per installation.
4. Priced per connected customer
A platform fee plus a fee per connected customer, and a setup fee for a new system. No per-call charges.
Questions from utilities teams
What software and AI providers ask before the first utility connects.
We do, together with you. The Deepdock client runs on a PC inside the customer's network, nothing is installed on the system itself, and we bring the technical and data protection documentation their IT asks for.
Every system on this page is assessed on request: tell us the system and your action, and we tell you within a week whether and how it can be opened. We name a system as supported only once it runs at a customer.
We use them wherever a system supports the action you need. Most of the actions providers ask us for sit outside what they cover: writes, older releases, grown installations, the system nobody has an interface for.
Deepdock maintains the connector. Every action goes through the system's own validation, so a change is caught at the action, not weeks later in a support ticket.
Nothing simulates typing. Deepdock uses the system's own interfaces and data paths first, validates every write with the system's own rules, and returns a confirmation your product can rely on. The screen is the last resort, not the method.
A platform fee, plus a fee per connected customer, plus a setup fee when we open a system for the first time. No per-call charges, no per-seat licences: the price follows what we run for you, not how often your product calls it. Early partners can start on a revenue share instead. The numbers are part of the first call.
Book a call and bring one blocked case: the system, the action, the customer. We tell you within a week whether we can open it and, if we can, we start.
Show us the system that is blocking you.
- Building a product?
- One API for every billing and customer system your utility customers run.
- Already building integrations yourself?
- Keep what works. Hand us the systems that are still in the way.