There is a version of public-sector AI that is easy to fund and hard to justify: a chat assistant on a departmental website that answers questions about services.
It is easy to fund because it is visible, self-contained and demonstrably modern. It is hard to justify because the citizen's problem is almost never a lack of information. The citizen knows the pothole is there. They know the department is responsible. What they do not have is any evidence that reporting it will result in anything happening.
An assistant that answers quickly and changes nothing does not improve that. In some ways it makes it worse, because it raises the expectation of responsiveness that the service behind it then fails to meet.
Start at the workflow
The seven steps above describe a service, not an interface. Each one is a place where AI can remove friction, and each one is a place where a department's actual capacity constraints become visible.
Intake is where most public-sector service failures begin. Requests arrive incomplete — no location, no photograph, no contact details, no way to tell one issue from another. Everything downstream then either stalls or proceeds on guesswork. AI at this step does something specific and valuable: it checks whether the request contains what is needed to act, and asks for what is missing while the citizen is still present. That single change removes a large share of the cases that would otherwise sit in a queue waiting for clarification that never comes.
Classification routes the request to the right service category using the department's own taxonomy. Done well, this eliminates the multi-week detour through the wrong unit.
Enrichment adds what the department knows and the citizen does not — which ward, which depot, whether three other people have reported the same thing this month, whether this location has an open case already.
Routing sends it to the responsible team with everything they need to act, rather than to a general inbox.
Response acknowledges receipt with a reference and a realistic expectation. Automated acknowledgement is appropriate here precisely because the content is fixed and low-consequence; the substantive response still comes from a person.
Tracking measures against the service standard, and — importantly — escalates when the standard is about to be breached rather than reporting afterwards that it was.
Reporting produces the operational picture: volumes, categories, hot spots, ageing cases, which teams are underwater. This is normally assembled manually, monthly, at considerable effort, and is out of date by the time it is read.
What AI is doing here, precisely
It is worth being clear, because public-sector AI conversations drift quickly.
The agent is reading unstructured input and turning it into a structured case. It is checking completeness. It is classifying against a defined taxonomy. It is matching against existing records. It is drafting text for a human to approve. It is summarising volumes into a view.
It is not deciding whether a service will be delivered. It is not determining eligibility for a benefit. It is not setting priorities between competing citizens. It is not producing policy. Those are decisions with rights attached, and they belong to accountable officials operating under the frameworks that already govern them.
Keeping that line explicit is what makes these projects approvable. A great deal of public-sector AI hesitancy stems from a reasonable fear of automated decision-making about citizens. A workflow designed so that AI does the intake and preparation, and humans do the determinations, addresses that fear structurally rather than with reassurance.
The constraints that are not optional
POPIA. Citizen requests contain personal information. Everything the workflow stores, including the traces, is subject to the Act. Retention periods, access control, and the ability to respond to an access or deletion request all have to be designed in, not added.
Audit trail. Every classification, routing decision and response should be traceable — who or what decided, on what basis, when. Public-sector accountability requires this independently of AI; introducing a system that cannot produce it is a step backwards.
Accessibility and bandwidth. A service that assumes a modern smartphone on a fast connection excludes a substantial share of the people it exists for. Responses should be short, pages light, and the whole journey usable over intermittent mobile data and in more than one language. This is a design constraint with the same weight as security.
No invented policy. The most serious failure mode in a citizen-facing assistant is a confident statement about entitlement, process or timeframe that is not grounded in an actual policy document. This must be an explicit, tested behaviour: cite the source or say it cannot answer. It belongs in the evaluation suite from day one, as we describe in the article on evaluation.
Human escalation. Safety-critical reports — a hazard, a health risk, a vulnerable person — must reach a human immediately, regardless of anything else the workflow is doing. This is a hard-coded rule, not a model judgement.
Where the value shows up
For the citizen: a request that is complete when it is submitted, an acknowledgement with a reference, and a response that arrives from the right team.
For the department: fewer stalled cases, less time spent routing, a real-time operational picture instead of a manual monthly report, and evidence of performance against service standards that can be presented rather than reconstructed.
For the executive: visibility. Most departments cannot currently answer "how many of these did we receive last month, how many are still open, and where are they concentrated" without commissioning work. A workflow that captures structured cases answers it continuously.
How to start small
Take one service with high volume and a clear owner — potholes, water interruptions, licence appointment enquiries, refuse collection. Instrument the current process first so you know the baseline: how many requests arrive, how many are incomplete, how long routing takes, how many are still open after thirty days.
Then build only the intake and classification steps. Requests arrive, get checked for completeness, get classified and routed. Everything else stays exactly as it is. Run it for a month and compare against the baseline.
That is a small enough change to approve, and it addresses the step where most of the loss actually occurs. It also produces the structured data that makes every subsequent step possible — which is the real reason to start there.
We have written more broadly about why public-sector digital services are not websites and about delivering a government MVP in ninety days.
How CloudNala can help
We design public-sector AI around the service workflow rather than the interface — intake that checks completeness before a case enters a queue, classification against the department's own taxonomy, routing with an audit trail, escalation rules for safety-critical reports enforced in code, and a POPIA-aware data design covering the traces as well as the cases. Built for intermittent connectivity and multiple languages, because the citizens who need the service most are the ones with the worst connection.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za