How I choose AI use cases
Most teams have more AI ideas than they can sensibly pursue. I help narrow the field: find the problem worth solving, test the money, choose the right way to solve it, and put the work in an order your team can absorb.
The method
A compelling demo is not a business case. These are the questions I use to separate work worth doing from work that can wait.
I don’t begin with a list of things AI can do. I look for the part of the business where time, margin or opportunity is already leaking away. The useful question isn’t “Where can we add AI?” It’s “What is costing us enough to fix?”
A use case needs a baseline: what the problem costs now, what could realistically change, and what has to be true for the investment to pay back. I want the assumptions in the open. If the economics only work in a perfect demo, it does not go first.
Custom is not automatically better. If an existing product solves the problem well enough, buy it. If the value is too small or the workflow is not ready, bin it for now. Build when the way your business works is the thing that makes the system valuable.
The first use case should be narrow enough to make real, valuable enough to matter, and owned by the people who will use it. A system nobody adopts pays back nothing. I would rather prove one working change and learn from it than launch ten disconnected pilots.
From method to a plan
The Where AI Pays library is where you can do that work: explore costed scenarios by industry and department, inspect the model behind each one, and start assembling a plan for your business. The library gives you the options. The method above helps you choose between them.
AI works when your people do.
