The question we get is almost never "can AI do this". It usually can. The question worth asking is whether doing it will save anyone any real time, and whether the answer stays true once the exceptions show up.
The three ways AI projects die
Almost every stalled AI project we have seen went one of these ways.
It automated something nobody minded doing. Impressive demo, no adoption, because the task it replaced took four minutes a week.
It was right ninety percent of the time in a job that needed ninety-nine. The ten percent generated more checking work than the ninety saved. This is the most common failure, and it is a design problem, not a model problem.
Nobody owned the output. The system produced drafts, summaries or suggestions and they landed nowhere in particular, so people carried on as before.
Choosing a first use case
Poor candidate
- Rare task, high stakes, no tolerance for error.
- Needs judgement your team cannot articulate.
- The person doing it today enjoys it.
- Output has no obvious next step or owner.
- Success cannot be measured.
Strong candidate
- Happens many times a day, in a similar shape each time.
- The rules can be written down, even if they are fiddly.
- Everyone agrees the task is tedious.
- Output goes somewhere specific: a system, a queue, a person.
- You can tell within a week whether it is working.
The pattern is boring on purpose. High-frequency, low-drama, clearly measurable work is where automation compounds. The exciting use cases tend to be the ones that need judgement, and judgement is exactly where the ten percent lives.
Volume is the whole argument
Automation earns back what it costs through repetition, not through sophistication.
What makes a task worth automating
How often it happens
the dominant factor
How consistent each instance is
How tolerant it is of being wrong occasionally
How much time each instance takes today
How complex the task is
matters far less than people assume
This is why the first thing we usually build for a client is unglamorous. Enquiry triage. Document extraction. Getting data from one system into another without a human retyping it. None of it makes a good conference talk. All of it gives back hours every week from the day it goes live.
Guardrails are the product
Anything customer-facing needs to be built on the assumption that it will sometimes be wrong.
That means knowing what the system is not allowed to say, where a human has to approve before anything leaves the building, and what happens when it cannot answer. The concierge on this site works exactly that way. It scopes and qualifies, it does not quote prices or promise timelines, and everything it gathers lands with a person.
If a proposed system has no answer to "what happens when it gets this wrong", it is not ready to be built yet.
How we would start
A first AI system, without the science project
- 1
Find the volume
Look for what your team does many times a day and quietly resents. That is almost always the right first target.
- 2
Write the rules down
Including the exceptions. This is the hard part, and it is useful even if you never build anything.
- 3
Build narrow
One task, real data, guardrails and a human in the loop where it matters.
- 4
Measure honestly
Time saved and error rate. If it is not clearly winning within a few weeks, change it or stop.
What to have ready
Before you scope an AI project
- The task, described as your team actually does it today, exceptions included.
- Roughly how many times a day or week it happens.
- Where the data lives, and whether it holds personal information.
- What a wrong answer would cost, and who would notice.
- Who signs off on output before it reaches a customer.
- What you would accept as proof that it worked.
POPIA applies the moment personal information is involved, which for most useful business automation is immediately. It is manageable, but it belongs in the design from the start rather than bolted on afterwards.
Tell our concierge which task is eating your team's week. It scopes the work with you and passes a proper brief to us.