Most AI projects in South African organisations start with the same sentence: "Can we add a chatbot?"
It is an understandable place to start. Chat is familiar. It demos well. It gives a steering committee something visible to react to, and it converts a vague ambition — "we should be doing something with AI" — into a scoped piece of work someone can be accountable for.
The problem is not that the chatbot is a bad idea. It is that the chat window is the part of an AI system that does the least work, and teams routinely spend eighty percent of a budget on it.
What you are actually buying
Strip the interface away and ask what the organisation needed. Almost always, it is one of three things: people spend too long finding information that already exists somewhere; people spend too long doing a repetitive process that follows known rules with occasional judgement; or decisions get made late because the inputs arrive slowly and inconsistently.
A chatbot addresses the first of those, partially, and only if it has been connected to the right documents with the right permissions. It does nothing about the second or third, because answering a question and completing a task are different problems.
The top row is the project most organisations approve. The bottom row is the one that changes an operating cost. Note that the model — the part everyone argues about, the part that determines whether you are on the current version of some vendor's flagship — is a single box in both.
The four things the chat window does not include
Trusted knowledge. A model does not know your tender documents, your standard operating procedures, your fee structures or last year's board pack. Left to itself, it will produce a confident, well-written answer assembled from general knowledge and the shape of your question. Connecting a model to your own content is a specific piece of engineering — retrieval, permissions, extraction, freshness — and it is where most of the difficulty actually lives. We cover it in the next article in this series.
The workflow. "Which documents does this tender require?" is a question. "Check this tender against our document library, tell me which certificates have expired, and draft the request to the compliance officer" is a workflow. The second one saves real hours. It also requires the system to know what a document library is, to be allowed to read it, and to have somewhere to put the draft.
A human decision point. Every AI workflow worth deploying eventually produces something that carries consequence — a submission, a payment, a message to a citizen, a commitment to a client. Where that decision sits, who takes it, and what they see before they take it, is a design question. It is not a feature you add afterwards.
Evidence that it works. A chatbot with no evaluation is a system whose accuracy you find out about from complaints. A workflow with a golden set of test cases is a system whose accuracy you can state, defend, and improve.
The mistake this creates
The specific failure pattern is worth naming, because it repeats.
A team ships a chatbot into an internal portal. Usage spikes for two weeks — everyone tries it — then settles at a handful of people. The organisation concludes that either the technology is not ready or the staff are resistant to change.
Neither is usually true. What happened is that the chatbot asked users to change their behaviour in order to get value: to remember it exists, to switch to it, to phrase a question well, and to then go and do the actual work themselves in the system they were already in. That is a poor trade for the user, so they stop making it.
The workflow version inverts the trade. The work arrives already done — the summary is attached to the record, the checklist is populated, the draft is waiting for review. The user does not have to remember anything. Adoption stops being a change-management problem and becomes a default.
What this means for your first project
None of this argues against starting small. It argues against starting at the interface.
The useful first question is not "where could we put a chat window?" but "which repeating process in this organisation costs the most time, follows mostly-known rules, and produces an output someone else waits for?" That question tends to surface the same handful of candidates in South African organisations: tender and bid qualification, invoice and document intake, first-line service requests, proposal and report drafting, and the weekly scramble to assemble a status view from four systems.
Pick one. Map it as a sequence of steps, on one page, with the decision points marked. You will usually find that four or five of the steps are mechanical, one or two require judgement, and one is a commitment that a named person must own. That map is your architecture. The chat window, if you build one at all, is an entry point to it.
There is a second benefit to working this way. A mapped workflow gives you something to measure against — cycle time before and after, error rate, rework, how often the human overrides the machine. A chatbot gives you a usage count, which tells you almost nothing about whether the organisation is better off.
What can go wrong
Even with the right framing, three failures are common enough to plan for.
The first is scoping the workflow too widely. "Automate procurement" is not a project. "Extract the mandatory requirements from an incoming tender and produce a compliance checklist" is. Narrow scope is what makes evaluation possible.
The second is skipping the permissions question. An AI system that can read across the whole document estate will happily answer an HR question with content from a legal folder. Access control has to be inherited from the source systems, not bolted on at the chat layer.
The third is treating the pilot as the product. A workflow that runs on one person's laptop with a hand-curated set of documents proves the concept and almost nothing about production. The gap between those two states — ownership, monitoring, cost control, failure handling — is the subject of article ten in this series.
How to start small
Take one workflow. Instrument the current version so you know what it costs today in hours and in delay. Build the smallest thing that removes the most mechanical step in it — often extraction or summarisation — and leave every decision with the person who already owns it. Run it alongside the manual process for a few weeks and compare. Then extend it one step at a time, keeping the human approval where the consequence is.
You will end up with a chatbot eventually, in some form, because people do want to ask questions. It will just be the last thing you build rather than the first, and by then it will be sitting on top of something worth asking questions about.
How CloudNala can help
We help organisations work out which workflow to start with, and what the smallest useful version of it looks like — mapping the process, identifying where trusted data actually lives, marking the decision points that must stay human, and designing the architecture around that rather than around a demo. That work usually takes days, not months, and it is the difference between an AI project with a measurable outcome and one with a usage dashboard.
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.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za