The same artefact appeared session after session: the functional grid. Business functions across the top, support functions down the side, a stack of AI opportunities in every cell.
You know the one. Customer acquisition, underwriting, fraud, collections, contact centre, middle and back office, complaints, developer productivity, recruitment, legal review. Twenty to thirty boxes, laid out clean.
It is good work. A bank with one is ahead of a bank running three disconnected pilots. But the room was treating an inventory as a roadmap, and those are not the same document.
Three questions the grid cannot answer
Which one goes first? The grid ranks nothing. In practice, the sequence defaults to the loudest sponsor, the cleanest data, or the vendor already in the building. None of those is a measure of financial impact.
Which step inside it carries the cost? "Collections" is not a use case. It is a department with a hope attached. The cost sits in a specific handoff, an approval loop, or an unowned exception queue. Point AI at the department and you get a pilot. Point it at the step and you get a number.
How will you know it was worth automating before you automate it? Function-level workshops capture where people believe waste lives. Belief is a fine place to start a conversation and a poor place to commit a budget.
In banking, value-added time averages around 0.7% of total cycle time. If you cannot account for the other 99.3% inside a specific process, you cannot credibly rank thirty use cases against each other. You are ranking guesses.
This is why the ranking exercise stalls. A grid built from function-level workshops has no cost attached to any box, so every box argues for itself at equal volume. The tie gets broken by seniority, not by numbers, and the bank ships whichever use case had the most senior person behind it.
Good use cases are an output, not an input
Top-down naming gives you functions. Process-up naming gives you steps. Only one of those tells an engineer what to build and a CFO what to expect.
Getting to steps means mapping the process as it actually runs. AI process mapping is what makes that affordable at the scale of thirty candidate processes. Baseline the process, measure cycle time, classify every activity. The opportunities then identify themselves. They are the residue left after elimination and simplification: rule-based, repetitive, high-volume, each with a measured cost already attached. That residue is the shape of a defensible business case, because the cost was measured before the build, not estimated after it.
The consequence nobody expects is that the list gets shorter and better. Some boxes do not survive the analysis, because the step should have been eliminated rather than accelerated. Automating it locks a bad design in at scale, then gets reported as a delivered use case.
You do not select AI use cases. You discover them, then rank them by what they measurably cost you today.
This reordering also changes who owns the roadmap. When use cases are named top-down, the roadmap belongs to whoever ran the workshop. When they fall out of measured analysis, the roadmap belongs to the numbers, and numbers are far harder to lobby.
What the grid still cannot give you
The grid is a map of ambition, and that is worth keeping. What it cannot give you is a sequence, because sequence is a measurement question and the grid contains no measurements.
There is also a foundation the grid quietly assumes and almost nobody funds: a single, current, queryable model of how the bank's processes actually work. Without it, neither AI process mapping nor governance has anything solid to stand on. That foundation, and how ESSAM builds it as a byproduct of the same analysis, is the subject of part 2.
For now, the practical move is small. Pick any box. Bring us the process behind it, and we will return the redesign, the ranked opportunities, and the documented standard.
Book a demo on your process. Your actual workflow. No hypothetical use case required. Start at https://apac.essam.ai/contact.
Related reading: