How to build a post-sale support agent for WhatsApp with human handoff

In 60 seconds: Build a post-sale support specialist for a defined scope: activation, usage, and coverage FAQs, permitted status lookups, and a minimum welcome or activation journey. WhatsApp receives the conversation, but the CRM or back office stores the account, product, case, and resolution; an approved knowledge base stores the guidance. Assign control by action: read, recommend, prepare, or execute within verifiable limits. Ambiguous identity, missing data, a complex case, or a tool outage ends in a human queue with context. For two weeks, measure resolutions without a person, time to first response, escalations by reason, and false resolutions. Do not build it without a system of record, a knowledge owner, and a human channel.

Questions after a sale can look similar in chat but represent different work: “How do I activate my product?”, “Where can I use it?”, “What is the status of my account?”, or “I followed the steps and it still does not work.” One answer may come from a guide. Another requires identifying the person, querying a system, or opening a case. The last one may need judgment and access the agent should not have.

A useful post-sale support agent does not try to contain every conversation. It resolves repeatable work with evidence and gives everything else to a person without making them start over. This differs from a sales agent for WhatsApp and a CRM: sales identifies a need and records the next commercial step; post-sale support helps someone who already has a relationship, product, or active service. Combining the two jobs mixes data, permissions, and metrics.

1. Define the jobs before the channel

“Handle post-sale support” is too broad to test and too ambiguous for permission design. A first version can cover three jobs:

1. Answer activation, usage, and coverage FAQs. Retrieve an approved answer, verify that it applies to the product and audience, and retain the source and version used.
2. Look up account or product status. Return only permitted fields after resolving identity and authorization. An unknown status does not become an invented explanation.
3. Guide a minimum journey. Support welcome, activation, and first use through observable steps, or remain reactive and answer only when asked. Choose one: a proactive journey introduces consent, schedules, retries, and stop rules that reactive support does not need.

Choose one population, product, language, schedule, and a small set of intents. Write down the boundary too: formal complaints, fraud, cancellations, contractual changes, balance adjustments, and coverage decisions may always go to a person or another team.

Every eligible conversation should end in a visible state:

eligible request
  -> approved answer + outcome recorded
  -> clarification requested + case pending
  -> human handoff + reason, priority, and owner

“The bot replied” does not prove that the case was resolved. The output should show what was understood, which evidence was used, and who continues if work remains.

2. Separate the channel, knowledge, and system of record

WhatsApp provides messages, timestamps, and channel identifiers. It should not decide which product a person has, the official state of an activation, or whether an incident is closed. The architecture of using the CRM as the source of truth and WhatsApp as the channel also applies after the sale, even when the operational record is a back office or support platform.

Data or decision	Authorized source	Agent rule
Identity and account relationship	CRM, customer master, or back office	Use a stable match; if there is more than one, limit the answer and verify
Product, activation, and status	Responsible operational system	Query current data and retain the lookup time and result
Activation, usage, or coverage answer	Approved knowledge base	Retrieve by product, audience, language, and version; do not fill gaps
Case, priority, owner, and resolution	CRM, help desk, or back office	Create or update one case with stable reason codes
Conversation and delivery	WhatsApp Business Platform	Keep necessary IDs and minimum context; do not maintain parallel state

The knowledge base does not govern itself. Every item needs an owner, audience, version, review date, and retirement condition. If two current documents conflict, the agent should not choose based on writing style: it blocks the answer and creates an exception for the owner.

Store the minimum permitted context. In many cases, correlation IDs, intent, consulted source, operational summary, and outcome are enough. Copying the entire conversation into the CRM by default increases exposure and does not necessarily improve resolution.

3. Assign control by action

Autonomy belongs to an action, not to the whole agent. The copilot or autopilot framework separates four levels:

Level	What it may do in post-sale support	Verifiable boundary
Read	Query account, product, case, and approved documents	Permitted fields, audiences, and products; logged access
Recommend	Classify intent and propose a reply or destination	Show source, reason, and missing data; do not modify the case
Prepare	Draft the message and assemble the exact update	A person reviews the message and payload; any change invalidates approval
Execute	Send a reply or write a preapproved state	Resolved identity, current policy, idempotent operation, and stop rules

One conversation can mix levels. The agent may read a guide, prepare a reply, and record that it delivered instructions; a person decides a cancellation or adjustment. Do not enable irreversible actions because the draft has high confidence. Changing ownership, balance, coverage, contract, or final status requires the control defined by the responsible system and, during the pilot, human review.

Start with a specialist. The comparison between one generalist agent and specialized agents explains why separating post-sale support, sales, collections, and operations reduces context and permission crossover.

4. Give it narrow, observable tools

The agent needs a small number of operations with explicit inputs, outputs, and failures:

1. Search approved documents. Filter by product, audience, region, language, version, and validity; return a passage, source, and review date. An empty or conflicting result is a useful failure, not permission to improvise.
2. Query systems by audience. Retrieve only authorized account, product, activation, or case fields. The tool enforces access control; a prompt cannot replace that control.
3. Use a template library. Expose approved replies and clarification requests, allowed variables, and tone by language. Keep fixed wording separate from retrieved data.
4. Hand off to a person with context. Create a case in the right queue with resolved or pending identity, reason, priority, evidence, attempted actions, draft, and required decision. Return an ID that can be written to the system of record.

The WhatsApp adapter receives and delivers messages, but it does not contain support policy. This separation lets the team change providers or channels without rewriting identity, knowledge, and escalation rules.

Treat tool errors as flow states. Define timeouts, bounded retries, idempotency, and a circuit breaker. A stale lookup or an unconfirmed write is not a resolution.

5. Build the happy path as auditable states

Test a low-risk intent first, such as an activation question from an already identified person:

1. Receive the event and deduplicate it by message ID.
2. Classify whether it belongs to post-sale scope without deciding the answer yet.
3. Resolve identity, account, product, and audience through an approved rule.
4. Read open cases, current status, and applicable restrictions.
5. Retrieve approved content for that intent, product, audience, and language.
6. Prepare the reply and proposed case update.
7. Apply deterministic controls: validity, permitted fields, compatible state, and no open exception.
8. Execute only the authorized action or request approval for the exact payload.
9. Write the result, source, message, and next state to the system of record; read back confirmation.
10. Stop any earlier sequence when a reply, handoff, opt-out, closure, or manual pause arrives.

For a welcome or activation journey, add explicit milestones: invitation sent, identity verified, activation started, step completed, blocker detected, and handoff. Do not measure progress by message count. If the process is meant to be reactive only, do not send “helpful” reminders without a contact policy.

6. Design exceptions before expanding autonomy

Exceptions are operational outcomes with an owner and a response target, not conversations the model “lost.”

Ambiguous identity

A phone may belong to a company, family, or shared device. If several accounts match or approved verification fails, the agent provides only public or non-sensitive information and requests the minimum permitted detail. It does not expose balances, transactions, contracted products, or history. The handoff includes possible candidates without merging them.

Missing data or conflicting sources

If the back office returns no status, the FAQ is expired, or two documents disagree, the agent says that the answer needs validation and opens a case. It records the queries performed, does not turn “no result” into “does not exist,” and does not blame a system without evidence.

Complex or consequential case

Sensitive complaints, fraud, cancellation, compensation, a coverage dispute, a contractual change, or an upset person require judgment and authority. The agent acknowledges the request, avoids promising an outcome, and hands the right team the context, urgency, and required decision.

AI, channel, or system saturation and outage

Define a degraded mode from day one. It may acknowledge receipt with a deterministic template, create the case, and communicate an approved expectation; it must not repeat messages, close cases, or claim it queried unavailable data. The queue needs capacity limits, alerts, and a manual route. When service recovers, reconcile IDs and states before resuming.

Use stable codes for each exception. The reviewer should be able to correct intent, source, draft, and resolution, and the correction should return to the case so the team can evaluate rules and content.

7. Add human handoff on day one

Handoff is not a generic button at the end of chat. Define:

• escalation criteria: unresolved identity, missing source, out-of-scope intent, high consequence, explicit request for a person, critical sentiment, tool failure, or time limit;
• queue: team, priority, schedule, capacity, owner, age, and reassignment rule;
• context package: what the person requested, which identity was resolved, sources and systems queried, missing data, attempted actions, draft, and required decision;
• user response: clear confirmation that a person has received the case, without promising a response time the operation cannot meet; and
• writeback: case ID, reason, owner, state, decision, sent response, and final outcome in the system of record.

The person should see the context before replying and take ownership without competing with the agent. A human_owned marker blocks new automated replies until an explicit return. When the person closes or returns the case, their decision updates the SoR and, when appropriate, creates a task to correct the knowledge base.

8. Run a two-week pilot

Choose a scope the team can review completely: one product, one population, a few intents, and one schedule. Capture a baseline using the same definitions of eligible conversation and resolution that the pilot will use.

Week 1: shadow and coverage

• The agent classifies, queries, and prepares; a person approves every reply and write.
• Review identity, sources used, failed queries, escalation reasons, and corrected drafts every day.
• Test duplicates, out-of-order messages, expired content, missing data, timeouts, handoff, and human takeover.
• Turn repeated corrections into rules or owned content; do not hide them in a longer prompt.

Week 2: bounded execution

• Automate only one repeatable answer that showed clear sources and low risk in week one.
• Keep approval for uncertain identity, contractual consequences, complex complaints, and irreversible writes.
• Review the queue, false resolutions, and control failures every day.
• Rehearse shutdown, degraded mode, recovery, and reconciliation without duplicating messages or cases.

Use metrics with a defined numerator, denominator, and review rule:

Metric	Pilot definition
Resolved without a person	Eligible conversations closed with a verified answer and no intervention / eligible conversations handled
Time to first response	Median and high percentile from an eligible message to a valid response or confirmed handoff
Escalations	Cases given to a person / eligible conversations, split by reason and age
False resolutions	Cases marked resolved that reopen, are corrected, or fail review / cases marked resolved
Human correction	Intents, replies, or writebacks changed / proposals reviewed
Control failures	Improper exposure, duplicates, messages after handoff, or unconfirmed writes

Segment results by intent, product, and cause. A correct handoff is not a failure; a contained conversation with a wrong answer is not success. Two weeks can validate coverage, operation, and boundaries, not prove ROI. The real cost of an AI agent should include the model, tools, channel, infrastructure, supervision, maintenance, and error using pilot data.

9. Know when not to build it

Do not build the agent yet when:

• there is no CRM, back office, or equivalent system that stores account, product, case, and resolution;
• nobody owns the FAQs, policies, versions, and review dates;
• there is no human channel, operational queue, or exception owner;
• identity cannot be verified safely for the data the team wants to reveal;
• the team cannot define “resolved” or correct a false resolution;
• demand is so low or variable that a well-managed inbox is simpler;
• the process depends on contractual or coverage decisions that are not written down; or
• there is no way to pause the agent, revoke access, and recover manually.

If any of those contracts is missing, begin by organizing the record, assigning knowledge ownership, and designing the handoff. If the real job is capturing and qualifying opportunities, use the sales agent playbook; do not expand post-sale support until it becomes a generalist with mixed permissions.

Kiia can map one post-sale journey, separate the channel from the source of truth, and build a pilot with observable permissions and metrics. See our approach to systems integration and bring ten recent cases, including those that ended in handoff: that is where the real scope and exceptions appear.