# Do We Need AI, or Are We Solving the Wrong Problem?

> Late water deliveries expose a problem with AI projects: faster complaint handling can improve call-centre metrics while leaving the customer’s problem unsolved.

> **TL;DR:** AI can help a business respond to complaints faster. But if the problem behind those complaints continues, better call-centre performance does not prove that the service has improved overall. Product and project managers need to examine the problem they are solving as carefully as the speed at which they can build a solution. Sometimes the first job is to fix what makes customers call in the first place.

I order water through a mobile app. I normally expect it to arrive within two hours. Sometimes it takes two days. Sometimes it never arrives. I call the customer service line and make a complaint. They tell me they have passed it on to the local distributor. Then I wait again.

This has happened repeatedly, and it is still happening. I will call the company “Bayat Su” rather than use its real name. I have experienced these delivery problems myself. The AI project I am about to describe is hypothetical: I am not claiming that this company uses such a system or has achieved the results in this example.

Suppose Bayat Su introduces an AI system that gives order updates over the phone, automatically notifies the distributor when a delivery is more than two hours late, and answers complaints on WhatsApp. I no longer have to wait for a customer service representative. The system replies within seconds.

But if the water I order today can still arrive tomorrow afternoon, how much of my problem has it actually solved?

## Better call-centre metrics can coexist with late deliveries

Three months into this hypothetical project, a presentation could show some impressive results. More enquiries handled by AI. Shorter telephone waits. Fewer calls passed to staff. Lower staffing requirements might also appear as a saving.

Those gains could be real. Spending less time on hold helps me too, and employees benefit from not having to answer the same order enquiry repeatedly. None of those measures, however, tells us whether the water arrived on time.

The call-centre team may have met its targets while I am still wondering whether my order will arrive and whether I will need to call again. If answering the complaint also gets the ticket marked “resolved”, the company's record of success moves even further away from my experience.

Answering a complaint, completing an order and giving the customer certainty need to be tracked separately. The first can improve while the other two remain unchanged.

## What makes the customer call?

I do not know what causes the delays at Bayat Su. Does the order reach the distributor late? Is there too little delivery capacity? Does the delivery time shown in the app reflect what is possible on the ground? Does anyone take responsibility for an overdue order? These are possibilities to investigate, not a diagnosis.

The answers change what is worth doing. If orders stall at a particular stage, the business needs to establish why they are not moving. If the app shows a delivery time the operation cannot meet, the promise to the customer also needs attention. Establishing who has the authority to act, or accepting orders according to available capacity, may sometimes address the problem more directly than a new AI system.

The same applies to automatic notifications. More messages to a distributor may not speed up delivery if nobody has decided what the recipient should do, what authority they have, or who takes over when they cannot resolve the problem. A notification becomes useful when it triggers action. Automating “we have passed it on” is not enough.

When we prevent a delay, we may also prevent the call it would have caused. That reduces the call centre's workload by addressing the customer's problem. Delivery data should show how often we actually manage to do this.

## A fast prototype does not settle the priority

AI can help us put together a working interface or voice-response demo in less time. We can show it in a meeting, try it out and discuss a budget. Changing a distributor's capacity, the division of work or a delivery commitment may require several teams to agree on what to do.

When building a visible piece of software is easier to organise than fixing a messy operational problem, the software can become the priority. Product and project managers need to pause and ask what it will change.

A product manager should examine how much of the customer's need is met by getting an order update faster. A project manager should track both whether the system launches on time and whether the intended business result follows. Another team may own the delivery changes, but that dependency still belongs in the project plan.

For example, starting with “reduce late orders and the need to contact us repeatedly about the same order” opens a different discussion. A voice-response system is then one option among others. A process change, a small adjustment to existing software, or a combination can be assessed against the same goal.

## What would I want to see in the results?

Alongside response times, I would want to see the proportion of orders delivered on time and how long late deliveries take. Repeat contacts about the same order, undelivered orders and cancellations would also help explain what has changed for customers.

These figures need to be read alongside order volumes. Fewer calls in a period with fewer orders do not establish that the project worked. A customer may also stop calling because they no longer expect a useful answer. When calls fall, we need to find out what happened to the orders and the people waiting for them.

A small trial could start with one area or distributor: investigate the cause of the delays, change the process and observe what happens. If customers still lack information, we can then assess whether AI would help meet that need. Not every trial has to become a large transformation programme.

## How do we decide where AI belongs?

Fixing delivery problems can take time. In the meantime, giving customers accurate information, offering a realistic delivery time or processing a cancellation are useful services. AI can help with them. But without reliable information and the authority to act, the system cannot offer a dependable resolution either.

My concern is treating faster replies as sufficient evidence of success while the customer's problem persists. It is like relying on painkillers without treating an infection. Relief is useful; we still need to know whether the infection is being treated.

The product roadmap should also record why we chose a solution. If the intended result, responsible team and conditions for reconsidering the decision are clear, the next impressive demo is less likely to pull us off course.

AI can reply to a customer within seconds. But unless we ask why that customer had to contact us, we may have built a more efficient way to handle complaints while leaving the problem untouched. Success should be measured both by how many complaints AI handles and by how many customers no longer have a reason to complain.

## Further reading

[Reforge's discussion of product management in the AI era](https://www.reforge.com/blog/more-valuable-less-protected) examines why problem definition and a shared understanding across teams matter as prototypes become easier to build. Published on 31 July 2026, it is an event recap connected to a training promotion, not an independent measurement of productivity. It offers further perspective on prioritisation; it is not evidence for my water-delivery experience or the hypothetical project described here.

---

Language: English
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/do-we-need-ai