AI roadmap case study: FinEdge's first 90 days

Seven people. Two using AI heavily, two refusing to touch it, three somewhere in between. That was the FinEdge People team on day zero, with a six-figure AI budget already signed off and nobody assigned to spend it. This AI roadmap case study is what happened next: how that team went from scattered individual ChatGPT use to nine workflows in production in 90 days, sequenced as diagnose, prove, harden and scale. The budget was never the constraint. The absence of a method was. Almost every People function I meet has the same gap, money approved before a plan exists, so this is written in enough detail that another team could run the same play. Names, numbers and one sequencing detail are changed. The shape of the work is exact.

Day zero: a budget with no plan

FinEdge is a 280-person fintech, Series B, payments infrastructure for mid-market merchants. The People team is seven: a CPO, two HRBPs, two TA partners, a People Ops lead, and a learning lead. The CEO had approved a six-figure People AI budget at the previous board meeting. The CPO had that budget and no idea where to point it.

The state of play before we started: individual ChatGPT use scattered across the team, no shared workspace, no policy, no measurement. Two of the seven were heavy users, three occasional, two avoiding it. Uneven adoption, which is the normal starting position, not a failure. What was missing was any read of where the work actually snagged. The instinct in the room was to spend month one buying tools. That instinct is almost always wrong, and the diagnostic is how you prove it.

The four-phase arc we ran against that starting position looked like this.

The diagnostic that redirected month one

We ran the People Ops diagnostic toolkit across three sessions over two weeks. The output was a one-page read of the function: a workflow heatmap, a readiness score across tooling, data and governance, and a shortlist of build candidates ranked by frequency, pain and AI fit.

Two findings reshaped everything that followed. The first was that the team had guessed wrong about its own hot cells. Everyone expected the hottest cells to sit in talent acquisition, because that is where the noise is. The heatmap put them in onboarding (high frequency, high pain, strong AI fit on the document and Q&A steps) and in HRBP request triage (medium frequency, very high pain, very high fit on the routing and first-response steps). This is the value of reading before building: the loudest process is rarely the one with the most trapped time.

The second finding was the readiness gap, and it is the one that saved the budget from being wasted.

The team had been about to spend its first month on tooling, its strongest area. The diagnostic redirected that month to data and governance, its weakest, with a single tooling decision made and then parked. You do not fix a 3-out-of-10 data foundation by adding a ninth tool. This is the same reason so many pilots stall short of production: the model works, the organisation cannot absorb it, a pattern worth understanding before you build anything, covered in why AI pilots stall at production.

Prove value before you harden anything

Days 15 to 60 were about proof, not scale. Three workflows in six weeks, one named champion on each, deliberately small audiences.

The onboarding assistant mattered most because it grounded on real, retrievable context, not a generic model prompted blind. That grounding was only possible because month one had made the handbook and the Slack history reachable in the first place. The triage workflow mattered most to the HRBPs, because a 26-hour median response time was the thing quietly eroding their credibility with the business, and dropping it to four hours changed how the rest of the company saw the function. Interview-loop scheduling was less novel and carried less payoff, but it freed a TA partner from the single most-hated chore on the team, which bought goodwill for everything that came after.

One ritual did more than any of the three builds. A weekly Friday demo, starting in week three, fifteen minutes, one champion shows one thing. It never stopped. It beat every formal training session combined, because it made progress visible and made the shy two-thirds of the team want in. If you take one thing from this AI roadmap case study, take the Friday demo.

Harden and scale

Days 61 to 90 added six more workflows, smaller and more specialised, owned by individual team members rather than dedicated champions. By this point the pattern was legible enough that the rest of the team could replicate it without hand-holding. That is the definition of scale that matters: the capability moved into the team and stopped depending on the person who built the first three.

The harder work in this phase sat outside the workflows, in three pieces of infrastructure that make the difference between nine toys and nine production systems. Together they are what an AI workspace for People Ops actually is.

• A published one-page AI policy covering data, vendors, evaluation and what the team is forbidden to automate. One page, so people actually read it.
• A shared workspace with reusable context and standardised prompts, following the AI workspace setup pattern, so a new build starts from the team's accumulated context rather than a blank box.
• A metrics pack tied to revenue and risk, refreshed monthly and presented at the exec team's business review, so the People function reported its AI value in the same language as every other function.

By day 90: nine workflows in production, an estimated 38 hours a week of sustained team time freed, and a CFO who could answer what is the People AI spend returning? without flinching. Getting that reporting right is its own discipline, and it is what let the function report its AI value in the same language as every other line on the board pack.

The two near-misses evaluation caught

Both happened in the second month. Both were caught by the standing evaluation review, not by luck. Neither reached a single person outside the People team. That is the number that matters most, and it is the one you can only earn by building the review before you need it.

The gate we now run every workflow through before it reaches production came directly out of those two weeks.

What we would do differently

Two things, and both are about timing.

Build the evaluation habit on day one, not day thirty. We added it in week five. Both near-misses formed in weeks six and seven. The five-week lag was very nearly the cost of the whole programme. The review is cheap to stand up and expensive to skip, and there is no reason it cannot exist before the first workflow does.

Resist demoing every new workflow company-wide too early. Once the wider company has seen something, retiring it becomes political, and you will keep a mediocre workflow alive because pulling it looks like failure. Keep the audience small until the workflow has survived a month of weekly evaluation. The Friday demo is the right size of audience for that. The all-hands is not.

What this AI roadmap case study actually transfers

The temptation with a case study like this is to copy the nine workflows. Do not. Your hot cells will sit somewhere else entirely, and the specific builds are the least transferable part. What transfers is the order of operations, and the difference between the version that sticks and the version that stalls is almost entirely about where you start.

The demo-led roadmap optimises the vendor's pipeline. The diagnostic-led roadmap optimises yours. FinEdge got nine production workflows and 38 reclaimed hours a week for the same six-figure budget the demo-led version would have spent on licences and left the team no better off. The money was never the variable. The order was.

If you want to run this shape against your own function, start where FinEdge did, with a read of the operating reality before a single tool decision. That is exactly what the Grain Audit delivers: one process mapped end to end, a ranked automation plan, and a 90-day plan you keep and run yourself.