The brief from the head of customer service at Bontebok Furniture Group, a fictional South African furniture retailer with stores and home delivery, was one line long: "We need a chatbot to handle delivery queries." Her contact centre was taking thousands of calls a month from customers asking where their couch was. The agents were tired of answering the same question. A chatbot on the website and on WhatsApp would, she reasoned, take those calls away.
Within a few months, the first thing Bontebok built was not a chatbot. It was a small service that records where every delivery is, a set of messages that tell customers when something changes, and a named person who owns each delivery that goes wrong. Calls about deliveries in the pilot region fell by more than half. A conversational assistant came later, on top of that service, and it was better for waiting.
This series is about the discipline that got Bontebok there. A request for a chatbot, a copilot or an agent is a signal that something hurts. It is not yet a requirement. The work is to find out why the interaction exists at all, and whether the cheapest fix is AI, a process change, an integration or a better message.
The request is a symptom
Bontebok is fictional, and its people, systems and figures are illustrative. It has 38 stores across the Western Cape, Eastern Cape and Gauteng, three distribution centres in Cape Town, Gqeberha and Midrand, its own delivery trucks in the metros, and a contracted carrier for outlying towns. It delivers about 14,000 orders a month. Most are large items: beds, couches, dining sets, appliances bundled with furniture.
The chatbot request was reasonable on its face. The contact centre was busy, the questions were repetitive, and conversational AI handles repetitive questions well. Our earlier article on why a chatbot is not an AI system explains what a chat window leaves out. This series asks a prior question: should the conversation be happening at the start?
The same pattern appears in our Architecture Before Technology series, where a bank asked for cloud and the real problem was approval time. A request that names a technology is a hypothesis about a cause. Discovery tests the hypothesis. And as digitalisation is not moving a broken process onto a screen argues, a new channel laid over an unchanged process tends to carry the old failure with it.
Nine steps from request to AI decision
CloudNala uses a fixed path for requests like this one. It is short, and none of the steps needs a model.
- Request. Record what was asked for, by whom, and the pain they described. Do not argue with it yet.
- Outcome question. Ask what would be different if the request succeeded. Bontebok's answer, after some discussion, was not "customers can chat with us". It was "customers do not need to contact us to find out where their delivery is". Our Production AI Case Study shows how to write an outcome like this so that it cannot be met by ending conversations.
- Demand analysis. Count and classify the contacts the request is meant to absorb, across every channel.
- Process and information map. Trace where the information the customer wants is created, where it lives, and who can see it.
- Root-cause evidence. Connect each common contact reason to a cause you can show.
- Intervention options. List every plausible fix, including the ones with no technology in them.
- Smallest test. Pick the cheapest change that would prove or disprove the leading cause.
- Outcome measurement. Measure the outcome from step 2 against a baseline and a comparison group.
- AI decision. Decide where AI genuinely adds something, now that the underlying problem is known.
Steps 4 and 5 are where most of the value sits, and they are where requests for AI usually skip straight past. Our article on the process map is usually fiction covers how to observe the work rather than trust the documented procedure. Here the emphasis is on information: where it is, and who cannot see it.
What the demand analysis found
Fatima, a data analyst in the customer service team, pulled eight weeks of contacts from the telephony system, the WhatsApp inbox, the website contact form and a manual tally kept for two weeks in six stores. Stores mattered: many customers walk back into the store where they bought the couch and ask the salesperson.
Across all channels, illustratively, Bontebok received about 21,400 customer contacts a month. About 9,600 of them were about delivery: where is my order, when will it arrive, did the driver come, why did only half of it arrive. That is roughly 69 delivery contacts for every 100 orders due for delivery.
Fatima then sampled 600 of those contacts and classified the reason behind each one, not the words the customer used.
| Reason behind the contact | Share of sample | What the customer lacked |
|---|---|---|
| No news since the purchase | 52% | Any update in the two to three weeks between sale and delivery |
| Delivery date moved without notice | 21% | A message when the expected date changed |
| Missed slot or failed delivery | 14% | A clear next step and a person who owned it |
| Part of the order arrived | 8% | An explanation of the back-ordered item and its date |
| Other | 5% | Mixed |
Not one of the main reasons was "the customer could not find the answer we had published". The answers did not exist anywhere the customer, or the agent, could reach.
The information was there, but nobody could see it
The process and information map took Riaan, Bontebok's solution architect, and Johan, the logistics manager, four working sessions. They followed twenty real orders from till slip to doorstep.
The milestones existed. The warehouse management system knew when stock was allocated and when it was picked. The route planner knew which truck and which day. The driver's app recorded proof of delivery or a failed attempt. The carrier's portal had its own version for outlying towns. But none of it flowed back to the order record that the contact centre and the stores could see. That record showed a promised date calculated at the till from a fixed lead-time table, and it never changed.
So when a customer phoned, the agent opened the order, saw the original promised date, and either repeated it or put the customer on hold to email the distribution centre. Store staff had even less. The customer's only message after the purchase was an SMS on the morning of delivery saying the driver was on the way.
Three root causes accounted for almost all of the delivery demand:
- Store and contact-centre staff could not see fulfilment milestones. The data was locked in the warehouse, routing and carrier systems.
- Customer messages omitted the next expected event. The only messages were the order confirmation and the morning-of SMS. Nothing said "your bed has been allocated, expected delivery 14 to 16 May".
- Exception ownership was unclear. Failed deliveries and short-picked items went to a shared mailbox read by whoever had time. No one owned the customer's next step.
A chatbot would have answered the phone faster. It would have had the same stale promised date to read from, and it would not have owned a single failed delivery. It would have made the wrong answer quicker and more polite.
The intervention options, including the boring ones
Riaan's team listed every option before choosing. That list is the point of step 6: an AI option must compete with alternatives, not be the only entry.
| Option | Addresses | Rough effort | AI needed |
|---|---|---|---|
| Delivery status service fed by warehouse, routing, driver and carrier events | Visibility for staff | Medium | No |
| Proactive messages at each milestone and on any date change | No news, moved dates | Low, once status exists | No |
| Exception workflow with a named owner and a response time | Failed and partial deliveries | Low to medium | No |
| Status screen for store staff | Store walk-ins | Low, once status exists | No |
| Chatbot answering from the existing order record | Contact-centre load | Medium | Yes |
| Chatbot answering from the new status service | Self-service for remaining questions | Medium, later | Yes |
The first four options removed causes. The fifth would have automated the symptom. The sixth was worth considering, but only after the first was in place, which is the subject of part 4.
The do-not-automate-yet gate
Before any AI option goes to design, it must pass a short written gate. The gate is not anti-AI. It stops a team automating a process whose cause is still unknown or whose information is still broken.
An AI option is held at the gate if any of these is true:
- The outcome is not written down as something other than activity, such as "fewer calls" rather than "more conversations".
- The demand has not been classified by cause, so nobody knows how much of it should not exist.
- The information the AI would need is missing, stale or invisible to the people who handle the work today.
- Nobody owns the exceptions the AI would hand off.
- A cheaper intervention that removes the cause has not been tested.
Bontebok's chatbot failed on items 3, 4 and 5. That did not kill it. It put it behind the status service in the plan, with a date to look at it again.
A gate like this is only useful if someone with authority signs it. Our article on business discovery before technical discovery describes a signed gate between understanding the problem and choosing a solution; this gate adds what that one does not cover, conditions specific to AI options and a review date for any option it holds. At Bontebok it was the head of customer service herself, the person who had asked for the chatbot. That mattered: she was not overruled by the architects, she was shown her own contact data and changed the request.
The smallest test, and what it showed
Riaan's team did not build the whole platform. For six weeks they ran a pilot in the Gqeberha distribution centre's area only. A small status service received events from the warehouse system and the driver app. Customers in the region received four messages instead of two: allocation with an expected window, a reminder two days out, the morning-of message, and a message whenever the expected date moved. Failed deliveries were routed to a named coordinator who had to contact the customer within one working day.
The Cape Town area, with similar order volumes, was the comparison. Illustratively, delivery contacts per 100 orders due for delivery in the pilot area fell from 67 to 31. In Cape Town they moved from 66 to 64. Part 5 covers how to measure a change like this honestly, including why a comparison group matters more than a before-and-after chart.
The pilot also surfaced what it could not fix. Carrier deliveries to outlying towns were not in the pilot because the carrier's portal had no event feed. Those customers still phoned. That became the next piece of work, and it is an integration problem, not an AI one.
Key points
- Treat a request for a chatbot, copilot or agent as a symptom to diagnose, not a requirement to build.
- Follow a fixed path: request, outcome, demand analysis, process and information map, root cause, options, smallest test, measurement, then the AI decision.
- Classify contacts by the reason behind them. At Bontebok the main reasons were missing information, not unanswered questions.
- Put every AI option through a written do-not-automate-yet gate, signed by the person who owns the outcome.
- Test the cheapest intervention that removes a cause before automating the symptom.
Next: Part 2, Fix the information gap before adding RAG. All parts are on the series page.
How CloudNala can help
CloudNala runs short discovery sprints for teams that have been asked to build a chatbot, copilot or agent. In two to four weeks we classify the demand behind the request across every channel, map where the needed information lives and who can see it, test the leading root cause with the smallest practical change, and leave you with a signed decision on where AI belongs, so that the first thing you build removes a cause rather than automating a symptom.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Start a Digital Discovery Sprint or write to us at consult@cloudnala.co.za