Why we learn your business before we build anything

Your team knows things that do not appear in a procedure manual. They know which attachment usually arrives later, which mismatch needs a phone call and which apparently tidy case deserves another look. Those details are part of how the business works.

If we build before learning them, we risk making the wrong work happen faster. At Pragmatic AI, we start by sitting with the people who handle the cases. Together we work out what can finish on its own, what needs judgement and what a useful handoff should contain.

Learn your business

Learning your business takes days or weeks, depending on your business: its size and how many case types it has. We sit with your team, watch the work and map every case type, step, workaround and exception. You do not need a polished process diagram. We want to understand the work as it happens.

We map every case type the team handles, whether that is a referral, booking, claim or invoice. For each, we establish where it arrives, what completion means and which people and systems are involved. We look at routine cases alongside the awkward ones, because both belong in the design.

Then we ask about the workarounds nobody wrote down. There might be a spreadsheet used to track missing attachments, a note that prevents a duplicate or a particular person everyone asks when two records disagree. These are clues about requirements that the formal process does not explain.

We also separate time spent working from time spent waiting. A case can sit for days while only taking a short period of active handling. Another can move quickly but interrupt several people. Understanding where the hours go helps us choose work that will make a useful difference.

This is a conversation with your team, not an examination of them. They have kept the operation moving around the gaps in its systems. Their experience tells us which checks matter and where an automated action could create more work for someone else.

Write down the exceptions before the rules run

The exception list is a central part of the case map. We record what should stop a routine case, who can decide what happens next and what that person needs to see. An unclear document and a disputed service are different problems, even if both prevent completion.

Consider INV-3318, the NDIS plan-manager invoice. The billed visit duration differs from the service record. The engine can identify that disagreement, gather the evidence and prepare a handoff. It cannot assume which record is correct.

The rule here is an illustrative operating rule, not a statement about every invoice or provider. In your case map, we use your agreed rules and approval responsibilities. People keep the judgement calls, including deciding whether an explanation resolves an exception.

A useful exception list also tells us what to leave alone. Some cases need a conversation, professional judgement or information that is not reliably available. We make that visible early, so each small win has a sensible boundary.

A map that develops as we learn

We build the written case map as we learn alongside your team. It describes the case types, how they arrive, every step they take and where they finish. It records the checks, missing information, workarounds and exceptions that shape the team’s day. We do not wait for the whole map to be finished before delivering useful improvements.

INV-3318’s case map specifies the disagreement, the evidence and the person who can decide whether it is resolved. The handoff keeps the invoice pending while the plan manager seeks clarification.

The map also sets out where human effort goes and which routine paths could run on their own. We distinguish what we observed from what still needs checking. If a useful estimate depends on information we do not have, that uncertainty stays visible.

You should be able to recognise your business in it. We work through the map together, correct anything we have misunderstood and agree what a useful result would look like. Before acting on a particular workflow, we agree its boundaries and rules with your team. Mapping the rest of the business continues alongside that work.

Start with small wins

Along the way, we find small, contained improvements and deliver those first. Each has a clear boundary, rules your team can agree on and a measure taken before and after. These pilots are measured small wins: we prove each improvement on real cases before going further. We examine handling effort, quality and exceptions alongside touchless rate, the share of cases that finish without anyone touching them.

Transform the company, when the results say it is worth it

Sometimes the honest recommendation is not to build yet. A simpler process change may solve the problem, the records may need attention first or the cases may mostly require judgement. The point of learning your business is to make that decision with evidence.

If the small wins show that a case engine is applicable and the results say it is worth it, we go further: a full company transformation, with the engine running across the business’s workflows. If it is not applicable, we say so honestly. Progress depends on what the measured improvements prove.

You work directly with me, Mitch Flindell. I have spent more than 13 years building production systems, including as co-founder and CTO of Bonjoro. I am based on the Central Coast, working across Sydney, Newcastle and the Hunter.

If you would like to talk through where your team’s time goes, you are welcome to a free conversation. We can begin with the work you already know.