A few weeks ago, I concluded an article by saying the question is not whether you can use AI in your business, but rather which process will benefit the most from it. And then in the NetAccess interview I came back to this topic, stating that you need to start with the business problem, not the solution. But what I haven’t done is show you how to pick the right business problem when there are five or six candidates on the whiteboard. All too often the winner ends up being the process with the loudest advocate or the best vendor demo, and that’s how a business ends up implementing solutions that don’t have as big an impact as the investment would indicate they should.

I’ve already written about the pieces on either side of this. In February I laid out the fit test for a single problem (fuzzy inputs and judgement calls favour AI; clear rules and provable accuracy favour code), and in March I wrote about the decision gates a project must pass through once it is chosen. Both of those articles assumed you had already picked the process, so this fills in that gap: Five filters applied across several candidates at once to surface the winner.

The filters consist of five questions that you must consider for each project. To show how the filters work, I will run three processes through it: a month-end management report package, an order change process, and a “Where is my order?” inquiry.

Filter 1 - Does it happen often enough to matter?

AI improves one instance of a process at a time, so the obvious corollary is that if there are not many instances, there is not much to improve.

Creating a month-end management report happens twelve times a year. It’s a high visibility item for the company’s decision makers, but that shouldn’t be allowed to cloud the selection process. In the manufacturing world where my background lies, order changes happen continuously, and I have watched a single change run to a dozen emails back and forth before the material moved. Status inquiries arrive all day.

It seems obvious, but all too often this filter is skipped. You must spend the time to identify the frequency and duration of the process being considered to ensure you are targeting something meaningful, not just something that has high visibility.

Filter 2 - Is the input messy and the output a judgement?

AI earns its keep reading unstructured input, weighing fuzzy priorities, and drafting text. If the input is clean and the rule is known, you want code, not a model.

Applying this filter is not necessarily perfectly clean. Processes often have elements that are both “fuzzy” and deterministic. For instance, in month-end reporting, collating the numbers has known sources, known formatting and known rules, and must be right every single time. That points towards a rules-based system, and putting AI in front of it only adds risk. However, the narrative on top of the numbers is a different process: it requires judgement and interpretation, so it is a possible candidate for AI-enablement. However, this is going to be highly confidential information, so it needs to run on a private AI deployment or not at all.

The status inquiry is more clean-cut: It fails to pass this filter because the answer to the question is a field (or set of fields) in your ERP.

In many companies, the order change process is the “messy” kind of process. Managing an incoming order is structured and goes through a standardized process; changes that upset the apple cart often require high levels of manual intervention. A customer messages that another supplier’s material failed inspection on their floor, and they now need your open order pulled forward as soon as possible. That one single email puts in motion a flurry of work. Production schedules need to be rearranged, and the carriers on your approved list, with their pre-arranged pricing, need to be contacted to see who has capacity and can meet the delivery window. The replies come back in five formats and must be weighed against each other, then the truck needs to be booked and delivery windows confirmed with the customer and the carrier. I witnessed the trading-partner side of this traffic for years: structured orders arrived electronically and never touched a keyboard, but the order changes and the logistics were the part that did. This is the type of process that easily passes this filter.

Filter 3 - Can the system reach the data?

The first two filters look at a project through the lens of “should this be AI-enabled?”, but now the filters shift to “can this be AI-enabled?”. If the data behind the process sits in a system or format that can’t be accessed, that needs to be addressed first.

Sometimes looking at a project through this lens provides an additional useful insight. For the status inquiry, once you’ve determined that you can reach the data, the solution should be clear: the data is accessible and in a format that is already useful, so the right delivery mechanism is a portal, an app, EDI, or an API. These solutions are deterministic, better than a chatbot, and none of them need AI. The other two candidates pass without much trouble. The order lives in the ERP and the carrier list already exists, and the month-end numbers are, by definition, already collated.

Filter 4 - Is the logic documented?

If a process is going to be AI-enabled, that implies that the model will be applying logic to the problem it is presented with. For most processes, some rules are documented (e.g., the rules for choosing a carrier). However, it’s not uncommon to have large pieces of logic that are not documented - these are the decisions that your employees use their intelligence and experience to make.

For AI-enablement, this logic needs to be documented, and there’s no hiding it - that’s real work. But it is the logic that the AI model is going to need if it is going to be a part of the process.

This filter isn’t necessarily a go/no-go filter, but it usually indicates a part of the project that must be addressed first before the real work of AI-enablement begins. For the order change, the carrier rules are mostly written down, but the rules for accepting a change (lead time, what can be substituted, carrier selection) might not be. For the report narrative, the undocumented logic is what leadership actually wants said about the numbers, and that has usually never been written down at all.

Filter 5 - Who owns the decision?

This filter looks at who is responsible for the decisions made by the AI process, and to what extent they are involved in reviewing the decision before it turns into real actions. The desired or necessary level of human involvement has a real impact on the payback from AI-enablement and needs to be understood when selecting and ranking projects.

In essence, this is a filter that says, “How much do I trust the decision made by AI?”. At a high level, you can make some assumptions: I’m pretty sure I trust the AI to ask my scheduling department if they can move an order up in the schedule, but I absolutely want to review the AI-generated notes attached to the monthly management report before they’re sent. The distinction that matters is not how much oversight there is, but what share of the saved work it eats. One confirmation at the end of a lot of automated drafting, as with the order change, costs little. Reviewing every output, as with the report narrative, can consume most of what the AI saved. If passing a project through this filter reveals that kind of oversight is required, that project might not be a great candidate for AI-enablement.

It’s also important to note that these assumptions benefit from some real-world testing. The process’s data can be passed into a few different models with appropriate logic to see how the models perform - the results will either validate or revise your assumptions.

What the filters show

The filters should give you a good understanding of the overall impact of AI-enabling each candidate.

In our earlier examples, the month-end management report probably isn’t a great candidate: Most of it is rules based, and the part that would benefit from AI-enablement requires a high level of privacy and human oversight. Similarly, the status inquiry is not a good candidate for AI; there are better solutions for it. However, the order change process is a strong candidate - it has the potential to reduce workload and improve efficiency.

These filters are designed to help you rank and eliminate candidates. If you apply them honestly, they will probably eliminate more candidates than you initially expect. That may be initially disappointing, but that’s actually a great outcome - it means you are not wasting resources on projects that will ultimately disappoint.