A finance team spends its working life in Excel. Somebody builds them an AI tool with a web portal, a login, a dashboard and an upload screen. It is genuinely better than what they were doing. Six weeks later usage has settled at two people, and one of them is the person who commissioned it.
The tool was not rejected on quality. It was rejected on friction, and the friction was introduced deliberately, at the start, by a design decision nobody thought of as a design decision: we will build a new place for this to happen.
The first version should be almost invisible
The useful question at the start of an AI project is not "what interface should this have?" It is "where does this work happen today, and what is the worst step?"
For that finance team, the answer is a spreadsheet that arrives by email, gets checked row by row against something else, and goes back out with a summary. The AI-shaped opportunity is the checking, not the spreadsheet. So the first version looks like this: upload the workbook, validate the rows, identify what is missing, generate the summary, export the updated workbook. Same artefact in, same artefact out, with the tedious middle removed.
Nobody has to be trained. Nobody has to be persuaded. There is nothing to log into. The thing either saves an afternoon or it does not, and everyone finds out within a week.
Three places this plays out
Tender teams. Bid work already runs on PDFs, Excel compliance matrices and email threads. That is not a legacy problem to be solved, it is the format the entire industry submits and receives in. An agent that reads the PDF pack and returns a compliance matrix as a workbook fits the existing process exactly. An agent that requires the bid to be re-entered into a portal has added work in order to save work.
Proposal and architecture support. Pre-sales work happens through briefs, notes, decks and document packs. The material already exists in a shape people recognise. The useful intervention is turning a brief into a first-pass architecture pack that an architect then corrects, not building a new authoring environment that competes with the tools the architect already knows.
Public-sector service delivery. Citizen contact arrives through call-centre logs, WhatsApp, paper forms and the service desk. These are not choices anyone made, they are where people actually are. An assistive layer that summarises, routes and drafts responses inside those channels reaches everybody. A new citizen portal reaches whoever finds it, which in practice is the group that needed help least.
The cost of leading with a new interface
It is worth being concrete about what the "build a portal first" path actually costs, because it is usually presented as the ambitious option rather than the expensive one.
Notice the last box on the top row. Shadow spreadsheets are the most reliable diagnostic in this whole field. When a team is quietly maintaining a parallel copy of the data outside the system, the system did not fit the work, and no amount of further training will fix that. It is information, not misbehaviour.
The bottom path looks less impressive in a steering committee. It also gets used, which is the only quality that matters at this stage.
When a new interface is the right answer
This argument has a limit, and pretending otherwise would be dishonest.
Some workflows genuinely cannot be improved in place. If the current process is six people re-keying the same information into four systems, then wrapping an agent around that process automates a mess and makes it permanent. If the work requires state that a spreadsheet cannot hold, or an audit trail that email cannot provide, or concurrent access that a shared workbook handles badly, a proper application is the honest answer.
The test is whether the new interface is doing work the old one cannot, or whether it is doing the same work somewhere more pleasant for the people who built it. The second is far more common than anyone admits, and it is usually justified with the word scalable.
The sequencing point still holds even when a new interface is right. Improve the existing step first, prove that the underlying capability works and that people want it, and then build the interface with a year of real usage behind the design. That order produces a better portal than the one designed from a workshop.
What good looks like
Start where the volume is. The channel that carries the most work is the one to improve, even when it is the least modern.
Take the artefact in and give the artefact back. A workbook in, a workbook out. A PDF pack in, a matrix out. Format continuity is what makes adoption free.
Do not require a new login on day one. Every authentication step between a person and a benefit costs you a percentage of your users.
Make the improvement obvious in one use. If someone has to use the tool for three weeks to notice the value, they will not get to week three.
Then keep the governance and guardrails attached to the work rather than to the interface, because the work is what moves between channels.
Practical checklist
- Map where the work happens now, including the channels nobody put on the diagram
- Pick the single worst step in that flow, not the most impressive one
- Keep the input and output artefacts unchanged in version one
- Ship without a new login if you possibly can
- Watch for shadow spreadsheets and treat them as design feedback
- Only build the new interface once the capability has proven itself in the old one
How CloudNala can help
A short discovery pass usually settles this faster than a workshop does: we look at where the work actually flows, which channels carry it, and which single step costs the most time for the least judgement. That step is almost always where the first AI workflow belongs, and it is almost never the one in the original scope. From there we build the assistive layer inside the existing tools and leave the question of a new interface until there is evidence to design it from.
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