Case study 03 — Spend analytics · GenAI

Analytics that admits whether it worked.

Most spend tools tell a procurement team what they could save. This one tracks how much of it they actually captured — and holds the gap in view.

Role
Lead → Manager, UI/UX
Design lead
Company
Enterprise Source-to-Pay software
Spend Opportunity Platform
Timeline
2022 — 2024
Users
Procurement, Finance
CFO, Sourcing, Analysts
Surface
Web application
Opportunity discovery screen with savings opportunity cards
01Contract Compliance, Payment Term Analyzer, Category Consolidation, Purchase Price Variance, Demand Aggregation. Each radial reads $1M / $3.2M realised — not a forecast, a completion rate.
01 — The problem

Spend analytics has a credibility problem.

Every tool in the category produces the same artefact: a number describing money the organisation could theoretically save.

The number is usually large, usually accurate, and usually never collected. Identifying a $3.2M consolidation opportunity is analysis. Renegotiating forty contracts across six categories is work — and it happens outside the tool, over months, by people with other jobs.

So the dashboard that reported the opportunity has no idea whether anything came of it. Procurement teams learn to discount the numbers, and the tool becomes a report nobody acts on.

Stop reporting potential. Start tracking realisation.
02 — Defining it

Six users who all wanted a different number.

Before any interface work, I mapped who this served and what each of them was actually trying to decide.

Six primary roles: Procurement Managers, Finance Managers, CFOs, Strategic Sourcing Professionals, Data Analysts, Operations Managers. I scored each against six working traits — analytical thinking, strategic thinking, financial acumen, problem solving, detail orientation, adaptability — then tiered them by impact to decide who the product optimises for when their needs conflict.

Then a user flow per persona, end to end. A Procurement Manager runs Supplier Rationalization; a Finance Manager runs Payment Term Rationalization; a CFO runs Cost Reduction Initiatives. Same engine, three different entry points and three different definitions of success.

Project goals definition document
User research document with persona trait matrix
User flow documentation per persona
02Goals → personas → flows. An honest note: this was desk research — role modelling and prioritisation built from domain knowledge and stakeholder input, not primary user interviews. It shaped who the product was for. It didn't tell me what they'd struggle with.
03 — The decision

Make the unit of the product an opportunity, not a chart.

The conventional structure for this product is a dashboard: filters across the top, charts below, insights left to the reader.

Instead, the home screen is a set of opportunity cards — Contract Compliance, Payment Term Analyzer, Category Consolidation — each one a named savings play with a value attached and a status. Not "here is your spend data." Here are nine specific things worth money, ranked.

The consequence is that the product has a to-do list rather than a reading list. A category manager opens it and sees work, not analysis.

01

Show realised against identified, always

Every opportunity card carries a radial reading $1M / $3.2M — value captured over value found. The gap is the point. It's visible on the home screen, in every card, permanently.

This is an uncomfortable design decision for a vendor: it makes the shortfall between what the software promised and what the customer collected impossible to ignore. That's exactly why it builds trust. A tool that only reports potential is marketing; a tool that reports its own conversion rate is an instrument.

"Kudos! You have realized the opportunities worth $500K"

The banner celebrates captured value — not identified value
02

Every AI recommendation carries its reason

When the system recommends linking a line item to a contract, it doesn't just rank options. Each recommendation shows the supplier, the opportunity worth, and an Item Insight explaining the basis — "Price based on monthly volume," "Quantity discounts available."

A procurement professional will not act on a machine's suggestion about a supplier contract without knowing why it was suggested. The reason isn't a tooltip or a details panel. It sits in the row, at the same level as the number.

Link Contract modal showing AI-recommended contracts with reasoning
03Total spend, total possible opportunity, and realised opportunity pinned at the top — so the decision is framed by its value before the options are read.
03

One engine, six front doors

The persona flows all run the same analysis over the same spend data. What differs is entry point and framing: a CFO enters through "Cost Reduction Initiatives," a Finance Manager through "Payment Term Rationalization," a Procurement Manager through "Supplier Rationalization."

Naming the same capability in each role's own vocabulary costs nothing structurally and decides whether a CFO believes the product is for them.

04 — What I'd do differently

The research told me who. It never told me why they'd fail.

The persona work was thorough and it was the wrong kind of thorough.

Six roles, six traits, an impact tier, a flow each — all built from domain knowledge and stakeholder conversations rather than from watching anybody try to capture a savings opportunity. It produced a confident map of who the users were and told me almost nothing about where they'd get stuck.

The realisation gap the product is designed to expose is the clearest example. I can show a team that they captured $1M of $3.2M. I never learned, from a user, what stopped the other $2.2M — whether it was effort, authority, supplier resistance, or the opportunity simply being wrong. That answer would have changed what the product does next, and desk research was never going to produce it.

Persona modelling tells you who to design for. Only watching someone fail tells you what to design.