You want your product to save people time. Perhaps it needs to sort information, direct work to the right person, or decide what happens next. Does your product need AI for that, or could clear rules do the job?
Use rules when reliable information tells your product what to do. Consider AI when the work involves interpreting language or turning varied, unstructured input into something useful.
AI adds running costs and can misinterpret a request or produce an incorrect summary. To decide whether it belongs in your product, weigh the improvement it offers against those costs and the risk and consequences of errors.
Customer request handling is a useful example. Choosing the right support queue is one task. Helping a customer explain the problem well enough for someone to solve it can be more valuable.
Turn a vague report into a useful handoff
A customer submits this message through your product:
“Since we added the new people, some of them can’t get into the project. I’ve sent the emails twice.”
A basic routing system might send it to account access. But the person receiving it still needs to work out what “can’t get into the project” means.
Did the invitations fail to arrive? Can the new users sign in but not see the project? Are they seeing an error?
A large language model, or LLM, could interpret the report, identify those gaps, and suggest a focused follow-up in the request form:
“Have the new users received their invitations, and can they sign in?”
Suppose the customer answers:
“Yes, they can sign in. The project just isn’t there.”
The product can now prepare a more useful handoff:
Issue: New team members can sign in but cannot see the project.
Already tried: Customer reports sending the emails twice.
Still needed: Affected users and project name.
Suggested queue: Account access.The benefit goes beyond classification. The customer has less explaining to do, and your team receives a request with a clearer starting point.
Where AI adds value
You could build a guided form with predefined questions for this problem. If a few predictable issues account for most requests, that may be enough.
AI becomes worth testing when customers describe many different problems in many different ways. It can help connect their wording to the information needed next, without requiring you to write a separate path for every phrase.
In this example, the useful capability is recognising that “can’t get into the project” is ambiguous, then using the answer to narrow the report.
That is a stronger reason to add AI than simply having it choose a queue.
Keep rules around the interpretation
The LLM does not need to control the whole process.
Your application can use rules to supply known account details, require essential fields, restrict the available queues, and decide when a person must review a request.
Give the model a narrow job: suggest a relevant question, summarise what the customer has said, and recommend a destination.
Keep customer statements separate from possible explanations. “Users cannot see the project” is supported by the report. “The project permissions are wrong” is still a hypothesis.
The customer should be able to correct the summary before submitting it. The model should not change permissions or claim it has fixed anything.
Test the improvement, not just the model
Compare the AI-assisted intake with your existing process or a guided form.
Does it collect useful information with fewer exchanges? Do staff spend less time asking customers to repeat themselves? Does it route requests more accurately?
Also check whether it introduces irrelevant questions, incorrect summaries, or extra waiting.
If it saves your team time but makes customers work harder, the overall improvement may be smaller than it first appears.
Your product does not need AI merely because it accepts text. It may benefit from AI when interpreting that text helps people reach a useful outcome with less effort.
Find that opportunity, keep the model’s role specific, and test whether the improvement justifies the added complexity.
