“We should be doing something with AI.” It is a reasonable thing to say in a leadership meeting. It is also the sentence that precedes most failed projects.
The advice from people who work on this across the continent is consistent. A consultancy writing about small businesses in Abidjan names the same trap as one writing about Nairobi: the biggest pitfall is launching without clean data or a quantified goal, and the winning move is one specific use case rather than an impressive but useless gadget. Andela’s guidance for African enterprises starts the same way: determine a use case first.
We agree, and we would go further. Make it one.
Why one beats five
Focus is the scarce resource. A small team can finish one thing. Five things become five half-finished things, all competing for the same people and the same Friday.
One result is evidence. A single working system, with a number attached, changes the conversation in your organisation. Opinions turn into a case you can point at.
The second project is easier. You have learned how your data behaves, how your people react and what the review process needs. The first project is the tuition. The second is cheaper.
What makes a good first use case
Run your candidates through five questions.
- Is it repetitive? The same shape of work, again and again, such as forms, claims, tickets or questions.
- Is there volume? Enough cases per week that saving a few minutes each adds up to real hours.
- Does the information already exist? In documents, a system, or a mailbox someone can reach. If the data does not exist, the first project is collecting it.
- Can a person check the result? The best first projects produce something a colleague can review in seconds.
- Does a named person want it? Someone who runs the work today and will feel the difference.
If a candidate scores four or five, it is a strong first project. If it scores two, it is a second or third.
Write it down as one sentence
A usable use case can be written in a single sentence:
“Read incoming supplier invoices, match each to a purchase order, and send mismatches to the accounts team, so the team stops retyping about two hundred invoices a week.”
Notice what it contains: what gets read, what it is checked against, who sees the exceptions, and what it saves. You can measure it. You can tell, after a month, whether it worked.
Now compare: “Use AI to improve finance.” There is no way to fail that sentence, which is the problem.
Choose the measure before you start
Agree three numbers up front. They do not need to be precise, only honest:
- Today: how long the work takes now, or how many people-hours a week.
- Target: what would make it clearly worth doing.
- Quality bar: how often it may be wrong, and what happens when it is. Usually the answer is “a person reviews it”.
Write them down and share them with the owner. When the pilot ends, you will look at the same numbers rather than argue about impressions.
Where organisations like yours usually begin
Four first projects come up again and again in our conversations, and in the work others in the region publish:
- Reading documents: invoices, forms, claims and letters. See document extraction, the unglamorous use case with the fastest payback.
- Answering the same questions on WhatsApp, chat and calls, from your own published information.
- One view of the business across branches or sites, so leaders see the same numbers on the same day.
- Spotting what is unusual, giving a reviewer a short list with reasons.
If you cannot pick
That is normal, and it is the reason we run readiness sprints. We sit with your team for two to four weeks, map how work flows, score the candidates against the five questions above, and leave you with one recommended use case and a plan. You can run it with us, with someone else, or yourselves. See the readiness sprint.
Sources
Related solution: Document intake