WhatsApp AI, public services

Why a water utility put its service line on WhatsApp instead of a web widget

A resident checks a water bill maybe four times a year. Nobody downloads an app for that, and nobody remembers a portal password. Choosing the channel is most of the project, and choosing WhatsApp pushes the hard engineering into the integration layer where it belongs.

Digiton delivered a 24/7 WhatsApp AI assistant for a Portuguese municipal water utility serving roughly 175,000 residents. It is integrated end to end with a SOAP-based billing platform built in 1996, a system whose variants are still in use for 1.7 million customers nationally. Complete, and in production.

The rest of this page is what that build taught us about the channel decision, the integration underneath it, and the data protection questions that decide whether a public-sector buyer can sign.

The channel decision is the project

Three options were on the table, as they always are. A web chat widget on the utility's site. A dedicated mobile app. Or the messaging app the residents already have open.

A widget only reaches somebody already sitting on your website, and a resident with a question about a bill is not browsing a utility website for pleasure. They want an answer at nine at night. An app is worse. Download, account creation, and a password nobody will remember by the next billing cycle, all to complete an interaction that happens a handful of times a year. The frequency simply does not justify the install.

WhatsApp removes all of it. No install, no account, no password reset, and a message thread that persists so the resident can scroll back to what they were told last time. The best interface for a municipal service is the one nobody has to be taught to use.

The hard part is behind the channel, not in it

Choosing WhatsApp makes the front end easy and moves every difficult problem into the integration layer. In this case the difficult problem was a billing platform from 1996, designed for dedicated terminals on a trusted internal network. No public API documentation. No modern client library. A protocol built for a world that assumed the caller was a person at an authorised workstation.

The architecture that made it safe splits into two layers that never touch each other directly. The conversational layer understands what the resident is asking and decides what needs checking. A purpose-built bridge speaks the old protocol on one side and a clean modern interface on the other, so the language model never handles 1996-era XML and the legacy system never learns anything about conversation state.

That separation is a safety control as much as an architectural one. A thirty-year-old billing platform has no concept of rate-limiting an autonomous agent or recovering from a malformed request built by a model rather than typed by an operator. The bridge enforces validation, retries and fallback behaviour, so the assistant can be genuinely conversational at the front while staying disciplined at the back.

The general lesson we would give any operations team: assume the legacy system will not tell you when something is wrong. Many of these platforms were built for trusted internal users, so their error handling is minimal or actively misleading by modern standards. Treat every response as suspect until validated, log everything, and never let model confidence override a hard rule about what the old system may be asked.

Outage reporting is a different shape from billing

Billing questions are lookups against a record that exists. Outage and issue reporting is the opposite, and utilities that treat them the same end up with an assistant that frustrates people at the worst moment.

Three things make it different. Volume arrives in spikes, because a burst main produces hundreds of reports about one event within minutes, so the system needs to recognise duplicates as a single incident rather than open hundreds of tickets. Location matters more than identity, since the useful field is where the problem is rather than who is reporting it. And the honest answer to most reports is a status rather than a resolution, which means the value sits in acknowledging fast and following up when the state changes rather than in resolving anything conversationally.

The data protection questions that decide the deal

For a public-sector or regulated utility buyer, this is where a promising project stalls. Have the answers ready before the first workshop.

• Lawful basis. Handling a service enquiry for an existing customer is usually contract or public task rather than consent, and getting that classification right early avoids a consent flow that would ruin the experience for no legal benefit.
• Processor position. WhatsApp Business is operated by Meta, so it sits in the processing chain and belongs in the record of processing activities with the appropriate terms in place.
• What crosses the boundary. Decide deliberately which fields ever leave the utility's systems. Answering "your account is settled" needs far less to travel than returning a full statement does.
• Retention. Conversation history is personal data. Set the period, apply it to the transcript store and the logs, and be able to show that erasure reaches both.
• Human handover. Anything outside the assistant's confidence, and anything requiring a human decision, gets handed off cleanly rather than guessed at. Auditors ask about this path specifically.

The same erasure and traceability discipline applies to any retrieval layer sitting behind the assistant, which is covered in GDPR-compliant RAG and where builds break.

What we will not claim

We are not publishing satisfaction scores or wait-time reductions for this deployment. The verifiable claim is delivery: built end to end, complete, in production, running unattended around the clock. The hardest part of the build was never the AI. It was respecting thirty-year-old infrastructure that a lot of people still depend on, without asking anyone to replace it.

That is the pattern most of this work takes. The interesting problem is rarely the model. It is the twenty-year-old system behind it that nobody wants to touch. Digiton builds and operates production AI across 8 countries from Lisbon, and the sector view sits on AI for utilities, with the full build write-up in the legacy billing case study.

Frequently asked questions

Related