Automate Customer Service: what to hand to a bot, and what South African law says must stay human

To automate customer service, hand the bot work that is repetitive, factual and reversible: order status, opening hours, document requests, booking changes. What must stay human is any decision that carries legal consequences for the customer. In South Africa that line is not a preference. POPIA draws part of it for you.

Almost every guide on this subject is a tool comparison or a deflection-rate argument. Those are business questions, and you can answer them any way you like. What most of them miss is that two South African statutes have already settled part of the question, and both have been in force for years. One of them decides what your bot is allowed to conclude on your behalf. The other decides what it is never allowed to decide alone.

This post covers both, read from the Acts themselves, and then the practical part: which jobs actually survive being automated, and how the work gets reduced without anyone re-typing anything.

Your bot can bind you, and the customer might not be bound back

The Electronic Communications and Transactions Act 25 of 2002 calls an automated system an "electronic agent", and defines it as a computer program or other automated means used independently to initiate an action or respond to data messages. A WhatsApp assistant that confirms a booking is an electronic agent. So is a web form that accepts an order.

Section 20 of that Act deals with agreements formed this way, and it is not symmetrical. Three parts matter.

You are presumed bound by what your bot agrees to. Section 20(c) says a party using an electronic agent to form an agreement is presumed to be bound by the terms of that agreement, irrespective of whether that person reviewed the actions of the electronic agent or the terms of the agreement. Nobody at your business read it. You are still on the hook for it.

The customer is only bound if a person could have read the terms. Section 20(d) says a party interacting with an electronic agent is not bound by the terms of the agreement unless those terms were capable of being reviewed by a natural person representing that party before the agreement was formed. Terms buried behind a link the flow never surfaces are terms that may not bind the customer, while yours still bind you.

A bot that gives no chance to fix a mistake can lose the agreement entirely. Section 20(e) says no agreement is formed where a person interacts directly with your electronic agent, makes a material error, and the electronic agent did not provide that person with an opportunity to prevent or correct the error. The customer also has to raise it as soon as practicable, return or destroy anything received, and not have taken any benefit from it. Meet those and the agreement simply does not exist.

There is a matching obligation for anything sold electronically. Section 43(2) requires a supplier to give the consumer an opportunity to review the entire electronic transaction, to correct any mistakes, and to withdraw from the transaction, before finally placing any order. Section 43(3) sets out what happens if you do not: the consumer may cancel the transaction within 14 days of receiving the goods or services.

The practical reading is short. A confirmation step is not a nicety in your chat flow. It is the thing that makes the agreement stick.

What POPIA says must stay human

This is the part that answers the title, and it answers it in statute rather than in opinion.

Section 71 of the Protection of Personal Information Act 4 of 2013 is headed "Automated decision making". Subsection (1) reads:

"Subject to subsection (2), a data subject may not be subject to a decision which results in legal consequences for him, her or it, or which affects him, her or it to a substantial degree, which is based solely on the basis of the automated processing of personal information intended to provide a profile of such person including his or her performance at work, or his, her or its credit worthiness, reliability, location, health, personal preferences or conduct."

Read the list slowly, because it is wider than people expect. Performance at work. Credit worthiness. Reliability. Location. Health. Personal preferences. Conduct. A support flow that scores a customer as a credit risk, or as unreliable, and then acts on that score by itself, is inside this section.

Two words carry the weight. Solely means a genuine human review takes the decision out of section 71, but a person rubber-stamping an output is not a review. Substantial degree means the section is not limited to court-enforceable consequences. Refusing someone service, closing an account, declining a claim or a return: each of those affects a person substantially, whether or not it has legal effect.

Subsection (2) provides exceptions. The decision may be taken where it is connected to the conclusion or execution of a contract and the data subject's request in terms of that contract has been met, or where appropriate measures have been taken to protect their legitimate interests, or where a law or code of conduct specifies such measures. Notice the first one: automation that gives the customer what they asked for is treated differently from automation that refuses them. Approving is easier than declining, in law as well as in practice.

Then subsection (3) defines what "appropriate measures" actually has to include, and this is the sentence worth keeping:

"The appropriate measures, referred to in subsection (2)(a)(ii), must provide an opportunity for a data subject to make representations about a decision referred to in subsection (1); and require a responsible party to provide a data subject with sufficient information about the underlying logic of the automated processing of the information relating to him or her to enable him or her to make representations."

If your automation declines someone on a profile, they can ask why, and you owe them enough about how the system reached that outcome for them to argue with it. "The system decided" is not an answer that satisfies section 71(3). That is a real design constraint, and it is the clearest statement in South African law of where the bot stops.

What to hand to a bot

With the legal line drawn, the rest is judgement, and it comes down to three tests. Automate the work that is repetitive, factual and reversible. A job that fails any one of them is a poor candidate.

1. Status and lookup questions. Where is my order, when is my appointment, what is my balance, has my document been received. These are database reads phrased as questions. They are the highest-volume category in most South African small businesses and the least rewarding for a person to answer.
2. Structured intake. Collecting the details needed to open a request: the reference, the address, the photograph of the fault, the certified copy. A bot is better at this than a person because it never forgets a field, and the fields arrive already labelled instead of scattered through a message thread.
3. Booking, rescheduling and cancellation. Reversible by definition, and the customer usually prefers doing it themselves at nine in the evening.
4. Acknowledgement and expectation setting. Confirming receipt, stating what happens next and by when. Most complaints about service are complaints about silence.
5. Routing. Reading a message, working out what it is about, and putting it in front of the right person with the history attached. This is the highest-value automation of the five and the least visible, because the customer never sees it happen.

Notice that four of those five end with a person, and are still worth automating. The gain is not replacing the person. It is that the person starts from a complete request instead of assembling one.

What must stay human

Beyond the section 71 line, four categories are consistently worth keeping with a person, and each for a practical reason rather than a sentimental one.

• Any refusal. Declining a refund, a claim, a return or an application. This is where section 71 bites, and it is also where a wrong answer costs the most to undo.
• Anything irreversible. Money leaving, data being deleted, an account being closed. If undoing it needs a person, doing it should too.
• An upset customer. Not because a bot cannot form sentences, but because the second unhelpful automated reply is what turns a complaint into a review. Detecting frustration and handing over quickly is itself a good automation.
• Anything the automation has not seen before. The correct behaviour for an unrecognised request is to hand it over and say so, not to produce a confident answer. A system that guesses is worse than no system, which is one of the recurring reasons AI projects fail in South African businesses.

How the work actually gets reduced

A CTA at the bottom of a post is not an answer, so here is the mechanism in specifics.

What gets captured once. The customer's identity, their history with you, and the reference for the thing they are asking about. In most businesses these are re-established at the start of every conversation, by asking the customer for information you already hold. Captured once against the customer record, the assistant opens the conversation already knowing who it is talking to, and the person who takes over does not start by asking again.

What stops being re-typed. The handover. The common pattern is a WhatsApp conversation that gets summarised into an email, retyped into a spreadsheet, and then read back to the customer by someone who was not there. When the conversation writes to the customer record directly, the summary is the record. Nobody transcribes it, and nothing is lost between the two.

Where the reminder comes from. The promise, not a diary. If the flow says a technician will call back by Thursday, that commitment becomes a dated task on the record when it is made. Escalation runs off the same date. Most service failures in small businesses are not refusals, they are promises nobody wrote down.

What gets escalated rather than repeated. A second unresolved exchange becomes a person's task, not a third automated attempt. The rule is worth setting deliberately low, because the cost of an unnecessary handover is a few minutes and the cost of a stubborn bot is the customer.

What stays measured. How many conversations ended without a person, and how many of those came back within a week. The second number is the honest one. A deflection rate on its own tells you how many people gave up.

Most of this rides on the channel your customers already use. In South Africa that is WhatsApp far more often than email or a web widget, which is why WhatsApp Business AI and WhatsApp automation for lead capture tend to be the practical starting point rather than a chat bubble on a website nobody visits after hours.

Before you switch anything on

Three things to have in place, all of which come straight from the sections above.

1. A confirmation step in any flow that concludes something. Review, correct, withdraw, in that order, before the order is placed. That is section 43(2) stated as a screen.
2. Terms a person could actually have read. Section 20(d) protects the customer, not you. Surface the terms in the flow rather than behind a link the flow never mentions.
3. A written record of what the automation is allowed to decide alone. This is what an AI policy is for, and it pairs with your POPIA compliance checklist, since the assistant is processing personal information from its first message. If you are still deciding what these systems can sensibly be asked to do at all, the broader picture is in our overview of agentic AI for South African small business.

Frequently Asked Questions

Is it legal to use a chatbot for customer service in South Africa?

Yes. ECTA section 20 expressly recognises agreements formed by an electronic agent. The limits are on what the automation may decide alone: POPIA section 71 prohibits decisions with legal or substantial effect based solely on automated profiling, unless an exception and appropriate measures apply.

Does POPIA require a human to review every automated response?

No. Section 71 applies to decisions that carry legal consequences or affect a person to a substantial degree, and that are based solely on automated profiling. Answering a question about delivery status is neither. Declining a claim on a risk score is both.

What happens if a customer makes a mistake in an automated chat?

Under ECTA section 20(e), if your automation gave no opportunity to prevent or correct a material error, no agreement is formed, provided the customer raises it promptly, returns or destroys any performance received, and has taken no benefit from it.

Do I have to tell customers they are talking to a bot?

No South African statute states it in those words. POPIA section 71(3) does require you to give enough information about the underlying logic of automated processing for a person to challenge a decision made about them, which is difficult to satisfy if they did not know a system was deciding.

Which customer service tasks give the fastest return when automated?

Status and lookup questions, because they are the highest volume and need no judgement. Routing is a close second: it is invisible to the customer but removes the delay between a message arriving and the right person seeing it with the history attached.

Sources

• Protection of Personal Information Act 4 of 2013, section 71 (automated decision making), subsections (1), (2) and (3). Read directly from the Act as published in Government Gazette 37067 of 26 November 2013, on 15 August 2026.
• Electronic Communications and Transactions Act 25 of 2002, section 20 (automated transactions), section 43(2) and section 43(3), and the definition of "electronic agent". Read directly from the Act as published in Government Gazette 23708 of 2 August 2002, on 15 August 2026.

Both statutory references were checked against the primary document on the date of publication rather than taken from secondary commentary. Legislation and its interpretation change, so verify against the current version before acting on it. This is general information, not legal advice for your specific circumstances.

Where this usually goes wrong

The common failure is not choosing the wrong tool. It is automating the loudest process instead of the most repetitive one, and discovering afterwards that the volume sat somewhere else entirely. If you want to see which parts of your service workload would actually respond to automation, and which need a decision rather than a system, a business autopsy maps the whole flow and ranks it. You can also book a discovery call and talk it through first.