Before AI, Understand the Decisions

A company recently approached us with what seemed like a straightforward request: they wanted to use artificial intelligence to automate an important business process. Information was scattered across spreadsheets and other tools, several people were involved, and the work required considerable manual effort. Delays could mean losing meaningful business opportunities, so making the process faster was a reasonable priority.

On the surface, it looked like a promising AI use case. But as we started asking questions, the conversation shifted from the tasks people performed to the decisions they made along the way. Understanding the sequence of activities was only part of the challenge. We also needed to understand how people interpreted information, handled exceptions and determined what a good result looked like.

That distinction changes what should be built.

A workflow can show where work moves without explaining the judgment that allows it to move correctly. If we automate the visible steps before understanding those decisions, we risk building a system around an incomplete picture of the business.

The process on paper is rarely the whole process

Most business processes look relatively simple in a diagram: a request arrives, someone reviews it, information is processed, a decision is made and an output goes back to the customer. The diagram is useful, but much of what makes the process work happens between those boxes.

An employee receives incomplete information and knows which questions to ask. Another notices that two sources contradict each other and knows how to investigate the discrepancy. An experienced manager recognizes an exception that was never documented. A spreadsheet contains some of the rules, while others exist in emails, conversations or habits developed over years of doing the work.

As the request moves between people, each person may interpret the information again. What appears to be a manual workflow can therefore contain a substantial amount of judgment, even when the organization describes the work as routine.

Before automating it, we need to understand which decisions follow clear rules, which require interpretation and which should remain under human responsibility. Otherwise, we may remove steps that were quietly preventing mistakes.

Where does the intelligence actually live?

One question I find particularly useful is: if we gave exactly the same request to two experienced people in the organization, would they produce the same result—and could we explain why?

Different answers are not necessarily a problem. People may have access to different information, exercise legitimate discretion or reach different but equally acceptable conclusions. The concern arises when the organization cannot explain the differences, evaluate the results or determine which criteria should guide the decision.

Some of a company’s most valuable knowledge lives in these judgments. A salesperson knows how to interpret an ambiguous customer request. An operations manager recognizes when the standard process should not apply. An analyst understands why a number in a spreadsheet needs additional context before anyone acts on it.

That expertise is an asset. It becomes a constraint when the business depends on a few people being available to interpret every difficult request, resolve every exception or correct everyone else’s work.

As volume increases, those employees receive more questions and interruptions. New hires need more support, handoffs require more explanation, and customers wait while someone finds the person who knows what to do. Adding people may increase capacity, but it does not necessarily reduce the dependency that is slowing the organization down.

The opportunity is to make that knowledge more accessible and usable while preserving the judgment the business still needs.

Automating inconsistency can make it harder to control

When a process is slow and fragmented, the pressure to automate is understandable. But speed alone does not tell us whether the process will produce a better result. A system can process requests quickly while applying the wrong assumption, overlooking an important exception or generating an answer nobody knows how to evaluate.

This is the risk of committing to a solution too early. Once assumptions become embedded in software, they can affect many more transactions than they did when the work was manual. The organization may then have to spend time and money correcting a system that faithfully executes rules it never properly examined.

Before deciding what to automate, we need to understand how information, rules, decisions and exceptions connect to the outcome. Where does the information come from, and how reliable is it? Which rules are explicit, and where do people interpret them differently? Who has authority when an exception occurs? How does the organization determine whether the final result is acceptable?

These questions help distinguish several kinds of intervention. Some problems require better integration between existing systems. Others need clearer rules, simpler workflows or conventional software. Some steps can disappear after redesigning the process. AI may be useful where interpreting unstructured information, finding relevant knowledge or assisting with judgment would improve the result.

The combination should follow from the constraint we discover and the outcome the business needs.

Better operations are the goal

Saving time on an individual task can be valuable, but the larger opportunity is often improving the organization’s ability to operate as it grows. That might mean reducing rework, helping new employees become productive sooner, making important decisions more consistent or allowing experienced people to focus on the situations that genuinely require their attention.

The expected improvement should be specific enough to evaluate. If delays are costing opportunities, we should examine response times and where those opportunities are lost. If a few employees are becoming bottlenecks, we should understand which decisions require their involvement and whether that dependency can be reduced. If inconsistent outputs are creating rework, we need criteria for assessing quality before we accelerate production.

This also gives the organization a basis for improving the system over time. Recording decisions and outcomes is a useful start, but learning requires more: someone must evaluate results, capture corrections and determine which changes should be incorporated. More data creates an opportunity to improve; it does not guarantee improvement.

For a growing business, the meaningful result is greater capacity and control without coordination, exceptions and executive involvement increasing at the same rate.

Start with the work as it happens

At Soluntech, this shapes how we approach the beginning of a technology project. A client may arrive asking for an AI solution, an automation or a new application. Before discussing features, we want to examine how the work happens today.

That means following a real request through the process, looking at the spreadsheets and emails people use, and understanding where someone has to stop and ask another person what to do. It means examining exceptions, duplicated information and the differences between what an experienced employee knows and what a new employee can find. It also means understanding what happens when the process produces the wrong result.

Those conversations help us separate the requested solution from the underlying problem and identify what we still need to learn before committing to a larger investment. We do not need to document every detail of the organization before acting. We need enough understanding to choose a useful first intervention, test its assumptions and evaluate whether it improves the outcome.

Our responsibility as a technology partner includes helping determine what should be built, integrated, automated or redesigned—and whether the expected benefit justifies the intervention.

When a company says it wants to implement AI, a productive first conversation can begin with a simple request: “Show us how it works today.” The answer reveals more than a workflow. It shows where knowledge lives, which decisions depend on particular people and where the organization is carrying risk.

Understanding those things gives us a better basis for building a system the business can trust as it grows.