A $2.6B US fintech's AI roadmap, costed and funded in six weeks.

The company had already bought AI. It had not decided where AI should go.

Several hundred licenses were deployed, fewer than half the premium seats active. Pilots had run. The chief executive had made AI adoption a standing expectation. None of it answered the question finance kept asking: which processes, and worth how much.

Nobody owned an inventory of how the work actually ran. The documentation described the intended path; the people doing the work had built their own way around it years ago.

Watch the work, then price it.

• Interviews. More than twenty stakeholders across payments, finance, support and corporate systems.
• Observation. Over-the-shoulder sessions capturing how each process actually executes, including the exceptions that never reach a process document.
• Data. A full read of a year of support case data, more than 150,000 cases, so the support picture rested on measurement rather than recollection.
• Systems. More than sixteen systems assessed for what they hold and what would have to connect.

Thirteen processes were mapped without overlapping each other. Not every one warranted AI, and the ones that did not were written up as such.

Five patterns across thirteen processes.

• Capacity ceilings. Payer pricing ran two to four hours a request against a hard ceiling of about fifty a week. Revenue was limited by throughput, not by demand.
• Manual queues. Fifty thousand vendor records sat in a match review queue, against a backlog of 5.9 million needing research and a team of twenty-two to work it.
• Multi-system hopping. Three to five systems per task, the same record rekeyed into each one.
• Duplicated research. Three separate teams researching the same vendors.
• No QA gates. Managers reviewed under five percent of 7,200 calls a day across 120 representatives.

Which of the thirteen warranted AI, and which needed a queue fixed rather than a model, is the distinction the roadmap turned on.

Seven of the thirteen went further, into designs a build team could price.

Each carries the same anatomy:

• The architecture, drawn on the systems the company actually runs
• A per-step cost model, so running cost is known before anything is built
• An implementation timeline and the team it needs
• As-is and to-be metrics for the process, stated as numbers
• The mandatory human checkpoints, named, with everything else automated around them
• Data requirements and a risk assessment

Alongside them sat the prioritized roadmap: what goes first, what each depends on, and what the program costs against what it returns. Roughly $8M to $16M of annual value, against about $2M to build it.

Those are projections, and they are the product. A discovery engagement does not move an operating number; it tells a board where the numbers can be moved, at what cost, and with how much confidence behind each line. The board approved this one and funded the build.

The constraint is almost never the model.

The most expensive step found in six weeks was a sales team setting lead priority with a random number function in a spreadsheet. No amount of assistant licenses would have found it. It surfaced because somebody sat and watched the work being done.

The second lesson is arithmetic. A value range is only as good as the variables underneath it, and several of these were tracked by nobody. Where that was true the report says so and gives the range a confidence level, rather than quietly choosing the flattering end. A board can act on a number with a stated confidence. It cannot act on a hope.