How to build a sales agent with WhatsApp and a CRM

In 60 seconds: Build a specialized sales agent, not a general-purpose seller that improvises. WhatsApp receives the conversation; the CRM stores identity, stage, owner, consent, and next step. The agent answers frequent questions from approved content, captures data, classifies intent, prepares a response, and proposes the CRM update. Assign control per action: read, recommend, prepare, or execute within verifiable limits. An out-of-policy price, unknown budget, ambiguous identity, or complaint goes to a person. For two weeks, measure time to first contact, next-step coverage, and escalations by reason. Do not build it if volume is low, there is no source of truth, or nobody owns exceptions.

One person asks on WhatsApp whether a product suits their company. Another requests a quote, another confirms an order, and another complains about a delivery. To the channel, these are four inbound messages. To sales and operations, they are different jobs with different data, permissions, and destinations.

A useful sales agent does not try to close every conversation. It turns each eligible contact into a visible state: answer with approved information, request a missing field, prepare a proposal, create a next step, or hand the case to a person. The conversation remains in WhatsApp; the commercial decision is recorded in the CRM.

This is a build note, not a vendor-specific tutorial. The design extends the KIIA-42 architecture for using the CRM as the source of truth and WhatsApp as the channel. If several business lines or agents share the channel, first apply the KIIA-43 criteria for one WhatsApp number per purpose.

1. Define five jobs and a stopping point

Avoid an objective such as “sell through WhatsApp.” It is too broad to test and too ambiguous for permission design. The first version can cover five concrete jobs:

1. Answer FAQs. Retrieve a current answer about a product, service, coverage, or process and retain the source used.
2. Capture data. Extract required fields without turning an inference into a fact. Ask for clarification when a mandatory field is missing.
3. Classify intent. Route the conversation as a question, quote request, order, or complaint. Classification selects a workflow; it does not decide a commercial term by itself.
4. Prepare the response. Combine an approved template with verified contact, catalog, and CRM data.
5. Leave a next step. Propose or record an action in the CRM with an owner and date, or create an exception with a reason.

Every run should end in an observable outcome:

eligible message
  -> approved response + next step in CRM
  -> clarification requested + pending state in CRM
  -> human handoff + reason and owner in CRM

“The bot replied” is not an end state. If the team cannot later find what happened, who continues, and when, the agent has only moved the work into chat history.

2. Make the CRM the system of record

CRM means any shared, governed commercial record here. It may be a dedicated CRM, an ERP module, or an operational database that meets the contract. WhatsApp provides messages, timestamps, and channel identifiers; it does not replace the opportunity record.

Data or decision	Authorized source	Agent rule
Identity and account	CRM or approved customer master	Use a stable match; if there is more than one, do not merge or choose by intuition
Consent and preferences	Company-approved record	Read current status and stop contact when required
Stage, owner, and next step	CRM	Re-read before acting and write the outcome to the same record
Product and price	Approved catalog and price list	Cite version or validity; do not calculate an unauthorized discount
Conversation	WhatsApp Business platform	Preserve message ID and evidence, but do not maintain a parallel stage
Complaint, order, or collection	Corresponding operational system	Hand off the case and link its ID; do not impersonate the specialist system

Use correlation IDs to join contact, conversation, opportunity, and action. Before a write, re-read the current record version. After a write, read back the result. That verification prevents a late reply from overwriting a reassignment or two events from creating the same next step.

Define retention and access policy for chat content as well. The pilot does not need to copy full conversations into the CRM: it can store the minimum permitted context, a reference to the original message, and a reviewable summary. Do not treat historical conversations as implicit permission to expose personal data to every tool.

3. Assign control to each action

Control is not granted to the entire agent. It is granted to an action, for a population, under observable conditions. The copilot or autopilot framework develops this progression.

Level	What it may do	Verifiable boundary
Read	Query contact, opportunity, FAQ, and catalog	Allowed fields and segments, least privilege, and access logs
Recommend	Classify intent and propose a route or next step	Show evidence, confidence, and reason; do not change the CRM
Prepare	Draft a reply or assemble the exact CRM change	A person reviews the payload; if it changes, prior approval expires
Execute	Send or write a preapproved action	Machine-checkable segment, template, schedule, frequency, amount, and stop rules

A single conversation may mix levels. The agent can read the catalog, recommend opening a quote, and prepare the message while a person approves the price. It may autonomously record a sent FAQ once content and recipient have been verified, but escalate every promise about discount, credit, stock, or delivery date.

Start with a specialist whose boundaries are clear. The comparison between specialized agents and one generalist agent explains why separating sales, support, and operations authority reduces context and permission crossover.

4. Give it four narrow tools

The agent does not need generic database access or permission to browse every system. It needs tools with explicit inputs, outputs, and failures:

1. CRM API. Search by stable identifiers, return stage, owner, last activity, and next step, and accept idempotent writes with version control.
2. Template library. Expose approved FAQs and drafts by intent, language, segment, and version. Separate allowed variables from free text.
3. Approved catalog and pricing. Return SKU or service, currency, validity, reference availability, and applicable rules. A missing or expired result blocks the quote.
4. Human handoff. Create a task or case with priority, reason, evidence, draft, and required decision; assign an owner and return an ID for the CRM.

The WhatsApp adapter sends and receives messages, but it should not contain commercial logic. That lets you change providers without rewriting pricing, classification, or escalation rules.

Before enabling sends, verify and date with Meta and your provider the current rules for consent, templates, conversation windows, opt-out, regional availability, and data handling. These are external conditions that may change; do not turn them into silent constants inside the prompt.

5. Build the happy path as auditable states

Test one intent and one segment first, such as a product question from an existing contact. The minimum flow is:

1. Receive the event and deduplicate it by message ID.
2. Resolve identity and account through an exact match or approved rule.
3. Re-read consent, stage, owner, last activity, and open exceptions.
4. Classify question, quote, order, or complaint and retain evidence for the decision.
5. Retrieve the current template, FAQ, catalog, and price for that route.
6. Prepare the response and proposed change: state, next step, owner, date, and channel.
7. Validate deterministic policy and control rules.
8. Execute only what is authorized or request approval for the exact payload.
9. Write the outcome to the CRM, read it back, and retain message and action IDs.
10. Stop any earlier sequence when a reply, opt-out, complaint, closure, or manual pause arrives.

The pattern for follow-up across WhatsApp, Teams, and a CRM shows how to use Teams for alerts and approvals without making it another source of truth. This agent can reuse that infrastructure, but its responsibility starts with an inbound conversation and ends with a traceable next step.

6. Design exceptions before expanding autonomy

Exceptions are not model failures. They are operational outputs that need an owner and a response time.

Unauthorized price

If the contact requests a discount, an unavailable currency, or a term outside the current catalog, the agent does not improvise. It preserves the literal request, links the consulted price list, prepares a non-committal reply, and creates an approval for the sales owner. Approval is bound to amount, currency, product, quantity, and expiry.

Lead without a budget

An unknown budget does not automatically mean disqualification. The agent may ask for a range or record “budget unknown” and propose a call. The qualification rule must come from sales. If the team decides to pause, record the reason, owner, and reactivation condition; do not confuse missing data with missing interest.

Ambiguous identity

If a phone number matches several accounts, a name is insufficient, or a different person writes from a shared number, the agent limits its response to non-sensitive information and asks for an approved verification detail. It does not reveal history, negotiated prices, or balances until identity is resolved. The handoff includes possible candidates without merging them.

Order or complaint

An order intent can pass to the order agent once required fields are complete; a complaint goes to support immediately and stops the sales sequence. Both outcomes retain an ID in the CRM. The sales agent does not promise resolution or turn the complaint into an upsell opportunity.

Measure these routes with stable reason codes, not a free-form category. The reviewer must be able to correct classification, data, or next step, and that correction returns to the case so rules and evaluation can improve.

7. Run a two-week pilot

Choose one number or purpose, one business line, one language, one schedule, and one contact population. Before day one, capture a baseline using the same eligibility definition the pilot will use.

Week 1: shadow and prepare

• The agent reads, classifies, and prepares, but a person controls every response and write.
• Review identity mismatches, expired sources, corrected classifications, and escalation reasons every day.
• Adjust templates and deterministic rules; do not conceal a missing policy with a longer prompt.
• Test duplicates, out-of-order events, CRM timeout, expired price, opt-out, and manual pause.

Week 2: bounded execution

• Automate only one action that proved repeatable and verifiable during week one.
• Keep approval for pricing, complaints, uncertain identity, and external commitments.
• Review the exception queue and logs every day.
• Rehearse shutdown, restart, and recovery without duplicating messages or next steps.

Use a small metric set with defined numerators and denominators:

Metric	Pilot definition
Time to first contact	Median and high percentile from an eligible message to the first valid response or handoff
Next step in CRM	Eligible conversations with action, owner, and date recorded / eligible conversations handled
Escalations	Cases sent to a person / eligible conversations, split by reason
Human correction	Responses, classifications, or payloads changed before approval / proposals reviewed
Control failures	Duplicates, out-of-segment actions, sends after a stop, or unconfirmed writes

Segment results by intent. A correctly escalated complaint is not a failure, and a fast response that leaves the CRM empty is not success. Two weeks help decide whether the system covers the work and respects its limits. Any ROI, savings, or close-rate claim requires a longer baseline, agreed attribution, and verified data; do not infer it from this pilot.

8. Know when not to build it

Do not build the agent yet when:

• eligible volume is so low that a well-managed inbox solves the work at lower cost;
• no CRM or equivalent record exists, or its stages, owners, and next steps are unreliable;
• nobody owns pricing, approved content, exceptions, or incidents;
• phone, contact, account, and opportunity cannot be linked safely;
• the catalog, FAQs, or policies change without versioning or an owner;
• the team expects the model to decide commercial policy that it has not defined; or
• there is no way to stop sends, revoke access, and correct records.

If the real problem is a portfolio of open opportunities without next steps, start with the playbook for recovering forgotten sales. If the channel mixes inbound, partners, and support, separate purpose, access, and ownership first. Building the agent before those contracts exist only automates ambiguity.

Kiia can map one sales journey, establish its source of truth, and build a pilot with observable permissions and metrics. See our approach to systems integration and bring ten recent cases to the conversation, including the ones that became exceptions: that is where the real design appears.