Every AI conversation in a Ugandan factory starts in the wrong place. Someone has seen a chatbot, the discussion becomes about customer service, and the plant manager quietly stops listening because customer service is not where the money is lost. The money is lost in downtime, in quality variation, and in the gap between what the production records say and what actually happened on the floor. None of those problems are solved by a chat window, and all three are legitimate AI problems.
Key Takeaways
- The three highest-value uses in a plant of this size are documentation and shift handover, quality record analysis, and maintenance history. None of them is a chatbot.
- All three work on data the plant already produces and mostly throws away.
- Computer vision on the line is the exciting option and usually the wrong first project, because it needs infrastructure most plants here do not yet have.
- The binding constraint is rarely the technology. It is that the records are on paper, in three handwritings, in a file nobody has opened since the last audit.
- Start with the boring task that runs daily, has a number attached, and does not stop the line if it fails.
Why the chatbot instinct misleads
Chat assistants are the visible face of this technology, so they anchor the conversation. But a plant’s economics are driven by throughput, yield and downtime, and a customer-facing assistant touches none of them. Worse, the mismatch teaches the management team that AI is a marketing tool, which delays the projects that would actually pay.
The useful frame in a manufacturing environment is not “what can a chatbot do”. It is “what do we already write down, in what quantity, that nobody has time to read”. That question points directly at the three uses below.
Use one: shift handover and production documentation
Every plant runs on handover. Night shift writes what happened, morning shift reads it, and in most operations of this size the record is a book, the handwriting varies, and the reading is partial. When something goes wrong three weeks later, reconstructing what happened means someone physically going through the book.
What changes: shift notes captured digitally, in whatever mixture of English and local language the supervisor actually uses, then summarised into a consistent structured handover. Recurring issues surface because the same complaint written six different ways over two months becomes visible when something is reading all of it.
Why this is the right first project. It is daily, high volume, low judgement, and failure does not stop the line. If the summary is wrong, the underlying note is still there. The measurement is straightforward: time spent producing and reading handover, and how long it takes to answer “when did this first start happening”.
What it requires: a tablet or phone per shift supervisor and the willingness to change one habit. That is a smaller change programme than it sounds, and smaller than any of the alternatives on this page.
Use two: quality records that nobody currently reads
Most plants collect far more quality data than they analyse. Batch records, in-process checks, reject logs, customer complaints, returns. It accumulates because an auditor might ask for it, and it is analysed at best monthly, at worst never.
What changes: the accumulated record becomes searchable and comparable. The questions that were previously too expensive to ask become cheap. Do rejects cluster by shift, by line, by supplier batch, by ambient temperature, by day of the week. Did the complaint rate move after the raw material supplier changed. Which three defects account for most of the loss.
None of that is exotic analysis. It is the analysis a good quality manager would do if they had two spare days a week, and the reason it does not happen is that they do not.
The precondition, and it is a real one. If the records are on paper in a filing cabinet, the first project is not AI. It is getting three months of records into a consistent digital form so that a pattern can be seen at all. That work is unglamorous, it is often the majority of the project, and any proposal that skips it has either not looked at your records or has decided to discover the problem after you have signed.
Use three: maintenance history and downtime
Ask a maintenance supervisor which machine costs the most and they will tell you immediately. Ask them to prove it with numbers and it becomes an evening’s work with a logbook. That gap is the whole opportunity.
What changes: maintenance logs, breakdown reports and parts usage become one searchable history. Which machine has the highest unplanned downtime. Which failure recurs. Which spare is always out of stock when it is needed. How long between the symptom first appearing in a log and the failure.
This is deliberately not predictive maintenance. Predictive maintenance in the sense the vendors mean requires sensors, continuous data capture and a stable connection, which is a considerable infrastructure investment. What is described here is retrospective analysis of records you already keep, and it captures a meaningful share of the value at a fraction of the cost. Plants that do this well often find that the case for sensors becomes obvious and specific, aimed at two machines rather than the whole floor.
The one everyone asks about: cameras on the line
Computer vision for defect detection is the use case that sells. It is genuinely powerful, and in a Ugandan plant it is usually the wrong first project for four reasons that have nothing to do with the algorithms.
| Requirement | Why it bites here |
|---|---|
| Consistent lighting and camera mounting | Needs a physical installation on a working line, with the associated downtime and cost |
| Labelled examples of defects | Someone has to photograph and classify hundreds of real defects. That is weeks of a person’s time before anything works |
| Stable power | An outage mid-run is not a pause, it is a gap in the record and a restart |
| Someone to maintain it | When it drifts, and it will, somebody has to notice and correct it. Without that person it silently degrades into an expensive light |
None of this makes vision projects a bad idea. It makes them a second or third project, undertaken once the plant has demonstrated it can run one of these to completion and has a person who owns it.
How to choose the first one
Four tests, and the task should pass all four:
- It runs daily or several times a day. Weekly tasks produce too little evidence in a month to decide anything.
- It has a number attached that somebody already cares about. Handover time, reject rate, unplanned downtime hours.
- Failure does not stop the line. First projects should be reversible in a shift.
- The records exist in some form. If they do not, digitising them is the project, and that is a legitimate and valuable project in its own right.
The measurement discipline that decides the outcome
Time the task before you touch it. Three real runs, timed, done the way it is actually done rather than the way the procedure says. Then time it again after four weeks, and count the verification time as part of the total, because a supervisor who now spends fifteen minutes checking a generated handover has given back some of the saving.
And agree in writing, before starting, what would make you stop. The most common way a plant AI project dies is not failure. It is drift: a pilot that did not quite work becoming a phase two, becoming a line in next year’s capital budget, with nobody able to say what the original measure did.
The constraint that is not on any vendor’s slide
In most plants of this size in Uganda, the binding constraint on all three of these projects is the same: the records are on paper, in several handwritings, in a file that has not been opened since the last audit. That is not a technology problem and no tool solves it.
It is, however, a solvable problem, and the plants that solve it get a second benefit they did not budget for. Once three months of records are digital and consistent, a great deal becomes visible that has nothing to do with AI. Several operations we have seen recovered the cost of the digitisation from what they found in the records alone, before any model touched them.
Start there. It is the least exciting sentence in this article and the most useful one in it.