List your candidate AI use cases, score each on business value and implementation friction, and see them plotted where the order of work draws itself. The quick wins to start, the bets to plan, and the ones honestly worth avoiding. No sign up, nothing leaves your browser.
Framework reviewed August 2026
Add each idea and score it one to five. Be honest about friction, it is almost always higher than early enthusiasm assumes. The plot updates as you type.
Scoring your own use cases is a good start, and the axes force a useful conversation. Where an independent view earns its place is in the scoring itself: the value that looks high until you ask who actually benefits, the friction a vendor demo waved away, the use case everyone is excited about that belongs in the avoid corner. A prioritisation session brings that outside eye, and leaves you with a shortlist you can defend to the board. We are independent and vendor neutral, so our shortlist includes the word no.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Two axes decide the order of work. Business value is how much a use case would genuinely move something that matters: revenue, cost, risk, or a real operational outcome, not novelty. Implementation friction is everything between the idea and the value: data readiness, integration, change, governance, and the ongoing cost of running it.
Plotted against each other, four regions appear. High value and low friction is where you start, because these prove value fast and earn the credibility to do more. High value and high friction are the genuine bets, worth doing but only when planned and resourced properly. Low value and low friction are fill ins, useful when capacity allows but dangerous as a flagship because they look like progress while moving nothing. Low value and high friction is the avoid corner, and the honest answer there is usually no, even when the use case is the one a vendor is keenest to sell.
The framework is simple on purpose. The value it adds is not the maths, it is forcing an honest score, because in the early enthusiasm value is overstated and friction is underestimated almost every time. Score conservatively, revisit as you learn, and be willing to move a use case into the avoid corner when the friction turns out to be real.
With the use cases that are high value and low friction: real impact, achievable with the data and tools you already have. Prove value on two or three of those before touching anything that needs heavy data work or integration. Starting with the hardest, most impressive use case is the most common and most expensive mistake.
Ask who actually benefits and by how much, in a number you would put in front of a CFO. A use case that saves each of a thousand people a few minutes a week is worth more than a flashy one that impresses a demo audience and changes no decision. If you cannot state the value in one sentence, it is not a five, it is a question.
Because value not delivered is worth nothing, and friction is what stops delivery. Data that is not ready, systems that will not integrate, a process nobody will change: these turn a high value idea into a stalled project. Two use cases of equal value are not equal if one ships in a month and the other needs a year of data engineering first.
Usually, yes. For most enterprise use cases the capability already exists in a product or an API, and building it yourself means reaching the same outcome later and more expensively while owning the maintenance. Build only where the capability is genuinely core and genuinely not available to buy, which is rarer than it first appears.
Then the scoring is not honest yet, which is the most useful thing the exercise can tell you. Everything cannot be high value and low friction. Force the comparison: rank them against each other rather than scoring each in isolation, and the real order appears. An outside view helps most exactly here.