Every discussion about automated customer service in Brazil arrives at the same place: WhatsApp. It is where the customer already is, it is where they expect a fast answer, and it is where most companies still operate with a queue of people replying by hand. Putting an AI agent there looks like the obvious decision. What this text covers is what separates the obvious decision from an operation that works.
First: official or unofficial
There are two ways to automate WhatsApp, and the choice defines everything that follows. The official API (Meta's WhatsApp Business Platform) requires a verified number, uses approved templates for outbound messages and obeys conversation window rules. Unofficial integrations emulate a handset and ignore all of that.
The second looks simpler, and it is where many operations start. The problem is that it violates the platform's terms and the number can be blocked without warning, taking the entire conversation history with it. For a company operation, with history that has to be kept and volume that has to scale, the only solid foundation is the official one. The rest of this text assumes that.
Three rules of the official API that change the agent's design:
- The 24-hour window. After the customer writes, the company can reply freely for 24 hours. Outside that window, the only way to start a contact is with a message template approved by Meta. An agent that has to resume a conversation the next day needs to know that.
- Message templates. An outbound message (a collection notice, a confirmation, a campaign) goes through prior approval and follows categories. The agent does not improvise the first message; it picks the right template and fills in the variables.
- Number quality. Meta measures how customers react (blocks, reports) and caps the volume of anyone whose quality is low. An agent that sends too many messages, or sends them at the wrong hour, brings down the whole company's capacity, not just its own.
Where the agent pays off, and where it does not
WhatsApp does not change the general rule: an agent pays off where there is a decision and a system to query, and it does not pay off where the answer is always the same. The channel only makes the difference more visible, because the customer writes the way they speak.
| Case | Does it pay off? | Why |
|---|---|---|
| Pre-sales and qualification | Yes, a lot. | Every contact arrives different, time to first response decides the conversion, and the agent queries the CRM and books the appointment. |
| Order status, delivery, scheduling | Yes. | It requires querying a system and answering with the real data, not with generic text. |
| Collections and renegotiation | Yes, within limits. | The agent queries, proposes within a defined range and stops where the range ends. Approving an exception is a human's job. |
| Tier 1 technical support | Yes. | It resolves what has a procedure and hands over what does not, with the context attached. |
| Opening hours and FAQ | An agent is not needed. | A simple flow resolves it, more cheaply. Putting an agent here is paying for a decision where there is none. |
| A complaint with high emotion | Not on its own. | Detecting and handing over fast is worth more than trying to resolve it. The agent's value is shortening the path to a person. |
The design that works: AI and person in the same conversation
The most common mistake is treating the agent as a layer in front of human service, a triage the customer has to get through. It works badly, because the customer feels the barrier and the person who receives the conversation receives it with no context.
The design that works is different: the AI and the human agent work in the same conversation, in the same inbox. The agent resolves what it can. When the case requires a person, the conversation goes to the right department's queue with the full history, and the human picks up where the agent stopped. The customer does not notice the switch, and repeats nothing.
Four decisions make that design work or fail:
- An explicit handoff criterion. The agent has to know when to stop: out of scope, low confidence, a request for a human, a word that signals risk. With no criterion, it insists and the customer gives up.
- A queue per department, not a single queue. Collections, sales and support are different people. An agent that has already understood the subject routes to the right queue, and the wait falls.
- Context that crosses the boundary. The human sees what the customer wrote, what the agent looked up and what has already been answered. If they have to ask again, the design failed.
- A way back to the agent. Once the point that required a person is resolved, the conversation can return to the agent for the rest. That is what keeps the human free for the next case.
What breaks in production
- An agent that does not know when to stop. It insists on resolving what is not its job, and the customer asks for a human three times before getting one. It is the most frequent defect and the easiest to measure: count how many times the word "agent" appears before the handoff.
- Outbound messages with no rules. A campaign fired at someone already in an open conversation, a collection notice sent to someone who paid yesterday, a reminder at the wrong hour. Each one brings the number's quality down.
- Context lost in the handoff. The customer explains everything to the agent and explains it all again to the person. A sign the handoff happened outside the conversation.
- A generic answer dressed up as a specific one. The agent says "your order is on its way" without having looked the order up. Worse than not answering, because the customer trusts it and the information is wrong.
- Nobody watching after go-live. The catalog changed, the policy changed, the agent keeps answering with the old one. Without somebody reviewing a weekly sample, the quality falls quietly.
The metrics that matter
The volume of conversations handled by the agent is the metric every dashboard shows and the one that says least. The ones that separate automated service from resolved service:
- Resolution without handoff, by type of case. It is the number that shows what the agent actually takes out of the queue.
- Time to first response, before and after. In pre-sales it is what moves conversion.
- Handoffs by reason: out of scope, low confidence, customer request, risk. Each reason calls for a different fix.
- Requests for a human before the handoff. If the average is above one, the stopping criterion is wrong.
- Number quality at Meta. If it falls, nothing else matters.
How Runflow does it
The Conversation Hub is the implementation of this design: agents serving on Meta's official WhatsApp, in the same thread as the human agent, with a queue per department and handoff by context. The AI resolves what it can and passes to a person when the case requires it, without the customer noticing the switch. Outbound messages use Meta's approved templates, and the supervisor orchestrates the specialists (sales, finance, support) according to the subject of the conversation.
Behind it, the platform's same connectors: the agent that answers about the order looked the order up in the ERP, and the one that books the visit wrote it to the CRM. Every execution is recorded and reproducible, which is what makes it possible to review the weekly sample and tune before the quality falls.
