Before you give someone a new tool, find out what their job really is. Then look for the moments where they have to choose something.
Start by writing down what a team actually does, using public job descriptions like O*NET and ESCO as a checklist. Then mark every point where someone makes a choice. Those choices are where AI can help, or where it shouldn't go near.
Build a task inventory per role from O*NET or ESCO, validate it against observed work and system data, then derive a decision inventory scored on frequency, stakes and reversibility. Prioritise AI investment against that inventory, not against tool features.
Why the order matters
If you start with a tool, you'll find uses for it. Some will be valuable, many won't, and you won't have a way to tell them apart. If you start with the work, you can see where time and risk actually go, and pick the few places where a change would matter.
Five steps
- Pick a role. Choose one with enough people that an improvement adds up, such as case managers, service desk analysts or finance business partners.
- Start from a public profile. Find the closest occupation in O*NET or ESCO and copy its task list. It's a checklist, not the truth.
- Check it against reality. Sit with people doing the work for a day. Look at their ticket queues, approval logs and calendars. Cross out tasks that don't happen and add the ones the framework missed.
- Find the decisions. Go through each task and ask where someone has to choose. Write each one as a choice between options.
- Score each decision. Use the inventory template to record how often it happens, what's at stake, and whether it can be undone.
What you end up with
A short list of decisions, each with a rough volume and a rough cost. That list tells you where a decision model could help, where people should stay firmly in charge, and what to measure once something changes. It also gives every later conversation, about tools, risk or budget, a shared starting point.