Case Study · Public Infrastructure

A WhatsApp AI Assistant Wired Into a 1996 Billing System

A Portuguese municipal water utility needed a 24/7 WhatsApp AI assistant that could talk to a billing system built in 1996. Here is how I approached the integration.

By Brandon Da Costa, Founder, Digiton Dynamics

The brief

A municipal water utility in Portugal, serving roughly 175,000 residents, needed a WhatsApp channel where a resident could check a bill, report an issue or ask a question at any hour, without waiting for a call center to open. Simple enough to describe. The complication was everything underneath it.

The real problem: a billing system from 1996

The utility's billing platform is a SOAP-based system built in 1996. It was never designed for anything outside its own internal terminals, let alone a conversational AI assistant. That system is not a small internal tool either: variants of it are still in use for 1.7 million customers nationally, which meant I was not building an integration for a quirky one-off, I was building something that had to respect a piece of infrastructure other people's entire operations still depend on.

There is no public API documentation for a system like that. There is no modern client library. There is a protocol built for a world of dedicated terminals and trusted internal networks, and my job was to make a WhatsApp conversation, running on a resident's phone, talk to it safely and reliably.

How I approached it

I split the problem into two layers that almost never touch each other directly. The conversational layer is where the AI lives: it understands what the resident is asking, in natural language, and decides what to check. The integration layer is a purpose-built bridge that speaks the old SOAP protocol on one side and a clean, modern interface on the other, so the AI never has to understand 1996-era XML directly, and the legacy system never has to understand anything about WhatsApp, language models or conversation state.

That separation mattered for a second reason: safety. A legacy billing system has no concept of rate limiting an AI agent or recovering gracefully from a malformed request built by a language model instead of a human operator. The bridge layer enforces strict validation, retries and fallback behavior, so the assistant can be genuinely conversational on the front end while staying disciplined and predictable on the back end.

Why WhatsApp, and not a custom app

It would have been technically simpler, in some ways, to ship a dedicated app or a web portal instead of building inside WhatsApp. I did not recommend that, because the residents this utility serves already have WhatsApp installed, already trust it for everyday communication, and were never going to download a new app for something they interact with a few times a year. The best interface for a municipal service is the one people do not have to be taught to use. That constraint pushed the hard engineering work into the integration layer instead of the front end, which is exactly where I want it: invisible to the resident, disciplined behind the scenes.

What I would flag to anyone attempting similar work

If you are looking at a legacy integration like this, the first mistake to avoid is assuming the legacy system will tell you when something is wrong. Many of these platforms were built for an era of trusted internal users, so their error handling is minimal or misleading by modern standards. I built defensive assumptions into every call the bridge layer makes: treat every response as suspect until validated, log everything, and never let the AI's confidence override a hard rule about what the legacy system is actually allowed to be asked. That discipline is unglamorous, and it is the entire reason this integration is trustworthy enough to run unattended, 24 hours a day.

What the assistant does

Residents can ask about a bill, a payment, or a service issue in plain language, in Portuguese, at any hour, and get an answer sourced directly from the live billing system rather than a static FAQ. Anything outside the assistant's confidence, or anything that needs a human decision, gets handed off cleanly rather than guessed at. The whole thing runs 24 hours a day, seven days a week, which is the entire point: municipal services rarely fit inside office hours.

Where it stands

The project is complete and in production. I am intentionally not quoting satisfaction scores or wait-time reductions here, because the honest, verifiable claim is about delivery, not a marketing number pulled out of context. What I can say with confidence is that the hardest part of this build was never the AI. It was respecting a piece of thirty-year-old infrastructure that a lot of people still depend on, without asking anyone to replace it.

The pattern, beyond one utility

This is the shape of a lot of enterprise AI work that never makes it into a slide deck: the interesting problem is rarely the model, it is the twenty-year-old system sitting behind it that nobody wants to touch. If your business has one of those systems and you want a conversational AI layer on top of it instead of a rip-and-replace project, that is exactly the kind of work Digiton does. The best next step is a conversation about your specific system, not a generic proposal.

Frequently asked questions

Related