Menu

· Halsted, Haines & Co.

When a business question needs research before AI

A practical way to distinguish an information task from an unresolved business decision before designing an AI system.

Conceptual branching blue glass research paths converging into a functional bridge

The request can hide two different problems

A team asks for an AI assistant to reduce the time spent responding to customers. The request sounds technical. Yet it might contain two separate problems: staff struggle to find the right answer, and the organization has not decided what the right answer should be.

Those problems need different kinds of work. An assistant could help locate a settled policy. It cannot settle the business question of which customers should receive an exception to that policy. A convincing response generated from an unresolved rule would make the uncertainty harder to see.

Look closely at a recurring question

Imagine a company receiving repeated requests to change delivery dates. Sales staff make informal promises, operations staff assess capacity, and customer service explains the result. Leaders see the volume of messages and propose automating replies.

Before choosing a tool, trace several requests through the business. Were the delays caused by missing information, conflicting priorities, an approval bottleneck, or a genuinely difficult capacity decision? Read the messages alongside what actually happened. A quick answer that creates an impossible commitment would worsen the process.

This investigation does not need to begin with a large research program. Its scope follows the uncertainty. Reviewing representative cases and speaking with the people responsible may reveal a specific information problem, a missing business rule, or several issues that need separate treatment.

Ask what evidence would change the decision

A useful research question has consequences. “How can we use AI in customer service?” permits almost any answer. “Which delivery-change requests can staff resolve using existing rules, and which require an operational decision?” creates a question that can be investigated.

Describe the alternatives before collecting more material. The company could clarify its rules, improve access to order information, change approval responsibilities, introduce an assistant, or combine several changes. Research becomes more useful when it helps distinguish among those choices.

Also name the evidence that would make an attractive option unsuitable. If most requests concern information that is already available, access may be the main issue. If requests regularly require an exception no one has authority to approve, faster retrieval alone will not resolve them.

Separate observation from interpretation

Suppose staff say they spend too much time searching. That is an important account of their experience, but it does not identify every cause. Observe where they search, which answers they find, and when they still need another person. Compare their experience with the cases and records available.

Keep a clear distinction between what was observed and what the team infers. Ten similar requests may suggest a recurring pattern; they do not establish its share of all demand. When the available cases are limited, explain the limitation and identify the next question it leaves open.

Turn the finding into a system boundary

Once the business has defined its rules, the technical role becomes easier to describe. An assistant might gather the order details, retrieve the relevant policy, and prepare a reply for review. Requests outside the rule could go to the person authorized to decide.

That boundary is also useful for evaluation. Test ordinary requests, incomplete records, conflicting information, and exceptions. A system should be judged on whether it helps the organization handle those situations correctly, including when the useful action is to stop and ask a person.

Carry the reasoning into implementation

The research should leave a short account of the decision, the supporting evidence, the unresolved questions, and the responsibilities involved. That gives the people designing and maintaining a system something firmer than a general ambition to automate.

Research earns its place when it changes what the organization chooses to build or how it chooses to operate. Sometimes it supports an AI system. Sometimes it reveals that a clearer rule or a better information source must come first. In either case, the next step has a business purpose people can explain.

Further reading

All articles ↗