A few weeks after the pilot ended, and some months after the chatbot request was parked, Lerato, head of customer service at Bontebok Furniture Group, asked for it again. Bontebok is a fictional South African furniture retailer with stores and home delivery, and its people, systems and figures in this series are illustrative. This time she brought different evidence. Delivery contacts in the pilot region had more than halved. The ones that remained were not "where is my order?" They were replies.
Customers were answering the delivery reminder on WhatsApp in their own words. "Can they come after two?" "My complex needs the driver to call from the gate." "Only the headboard came, is the base still coming?" "Ek is nie Donderdag tuis nie." Each reply landed in a shared inbox, waited for an agent, and often turned into a phone call anyway.
This series has spent three parts arguing against building a chatbot too early. This part is about recognising when it is no longer too early.
The chatbot was never the problem
Nothing in part 1 said conversational AI was a bad idea. It said that a chatbot placed in front of missing, stale and ownerless information would make the wrong answer faster. Our article on why a chatbot is not an AI system makes a related point: the chat window is the part of the system that does the least work.
Once the work behind the window exists, the calculation changes. Bontebok now had a delivery status service that knew the current state of every order in the pilot region, an exception workflow with named coordinators, a rebooking function in the route planner, and an owned set of delivery and product-care pages. A conversational interface over those is a different proposition from a conversational interface over a stale order record.
A six-question fit test
CloudNala uses six questions to decide whether a conversational interface is the right answer for a particular set of interactions. They are a judgement aid, not a scoring formula, and they follow the do-not-automate-yet gate from part 1 rather than replacing it.
- Is the information right? The gate in part 1 must already be passed: the answers exist, are current and have an owner. If not, stop here.
- Is a push not enough? If a well-timed message, a status page or a better form would stop people asking, do that instead. A conversation is a cost to the customer, however pleasant.
- Are the requests varied in wording but bounded in intent? Conversation earns its place when people express a small number of needs in many different ways. Menus and forms handle a few fixed choices better.
- Does the answer need a short exchange? Some needs cannot be met in one turn: choosing a new slot, explaining an access problem, confirming which item is missing. A dialogue suits these better than a page.
- Is a wrong answer bounded and recoverable? The assistant should only take actions that the customer confirms and that can be undone. Anything else belongs with a person.
- Is there a clear route to a person, with context? Every conversation the assistant cannot finish must arrive with a named owner and everything already said.
A chatbot that passes all six is likely to help. One that fails the first two is likely to automate demand that should not exist.
Applying the test at Bontebok
Fatima, the data analyst, classified the remaining delivery contacts from the last four weeks of the pilot. Illustratively, about 40% asked to change the delivery slot, about 25% gave or asked about access and special instructions, about 15% asked product or assembly questions, and about 20% were complaints about damage, missing items or service.
The test produced different answers for each group.
| Contact group | Test result | Treatment |
|---|---|---|
| Change the slot | Passes all six | Assistant: show available slots from the route planner, confirm, rebook through the workflow |
| Access and special instructions | Passes; question 2 partly | Assistant captures the instruction onto the order; the reminder now asks for access details up front |
| Product and assembly questions | Passes, once content is owned | Assistant answers from approved care and assembly pages, with a link |
| Damage, missing items, complaints | Fails question 5 | Straight to a coordinator, with the conversation and order attached |
The complaints row is the important one. An assistant could have produced a sympathetic reply to a customer whose couch arrived torn. It could not decide on a replacement, a refund or a credit, and pretending otherwise would have made the experience worse. The assistant's job for that group is to recognise it quickly, say that a person will respond and by when, and hand over.
The conversation starts from the message
The most useful design decision was where the conversation begins. Bontebok did not put a "Chat with us" button on its website and wait. The assistant answers replies to the messages Bontebok already sends: the allocation message, the reminder two days before delivery and the date-change message.
That choice has three effects.
The assistant already knows the context. A reply to a reminder about order 4471-882 is about that order. The customer does not need to find an order number or explain anything. Identity still has to be handled properly, but the conversation starts from a known record rather than from a blank box.
It meets customers where they already are. Our article on why good AI agents meet users where they already work makes this argument for staff. It applies to customers too. Bontebok's customers were already replying on WhatsApp; the assistant simply stopped those replies from waiting in a queue.
It keeps demand low. The assistant does not invite new conversations. It handles the ones the delivery messages provoke, and the proactive messages are still doing most of the work.
What the assistant may do
The assistant has three kinds of capability, deliberately separated.
Read state. It reads the order's current status, expected window and items from the status service, for the customer linked to that order. It never searches emails or notes. Part 2 explains why.
Answer knowledge questions. It answers questions about delivery policy, product care and assembly from the owned content collection, citing the page.
Take two confirmed actions. It can rebook a delivery into a slot the route planner offers, and it can add access instructions to the order. Both require the customer to confirm a summary before anything changes, both are recorded on the order, and both can be reversed by a coordinator.
It cannot cancel an order, change an address, issue a refund, promise a date the route planner has not offered or decide anything about damage. Those are coordinator decisions. The separation follows the approach in our article on adding bounded actions, and the handover follows human-in-the-loop is not a button: the coordinator receives the full conversation, the order state and the assistant's reason for handing over, and the customer is told who will respond and by when.
Language matters too. Bontebok's customers write in English, Afrikaans, isiXhosa and a mixture. The assistant was tested on real (anonymised) replies in each, and anything it could not understand with confidence went to a person rather than being guessed at.
When the answer is still no
The fit test is as useful for the cases it rejects. Bontebok considered three other conversational ideas in the same period and declined each.
- A "Where is my order?" chatbot on the website. Rejected on question 2. The status page and the proactive messages already answer that question; a chat window would invite conversations that do not need to happen.
- An assistant for store staff to look up deliveries. Rejected on question 3. Staff ask the same few things; a status screen with a search box answers them faster.
- An assistant to handle damage claims end to end. Rejected on question 5. The decisions carry money and judgement and belong to people.
None of these rejections was permanent. Each was recorded with the reason and a condition under which it could be reconsidered.
Measuring it
The assistant was not measured on the number of conversations it handled or the share it closed without a person. Part 5 explains why. It was measured on two things: whether slot changes and access instructions were resolved without the customer having to contact Bontebok again about the same delivery, and whether failure demand and total delivery contacts per 100 orders due kept falling or started to rise again as the assistant made conversation easier.
Key points
- A chatbot is a poor fix for missing information and a good interface for varied requests over information that is already right.
- Use a six-question fit test: information right, push not enough, varied wording, short exchange needed, bounded actions, clear handover.
- Apply the test per contact group. Some groups pass, others belong with a person.
- Start conversations from messages you already send, so context is known and new demand is not invited.
- Separate reading state, answering knowledge and taking confirmed, reversible actions. Everything else is handed over with context.
Next: Part 5, Measure avoided demand, not conversations. All parts are on the series page.
How CloudNala can help
CloudNala helps teams decide where a conversational assistant genuinely helps and design it on top of information that is already right. We classify your remaining contacts, apply the fit test group by group, define what the assistant may read, answer and do, design the handover to your people, and build a measurement plan that tracks resolved needs and total demand rather than conversation counts.
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