How can our WhatsApp bot remember which branch the customer already selected?

Your WhatsApp bot can remember a branch by saving the customer’s selection against the current request in your application. Load that saved choice before every reply, and use it until the customer confirms a change or starts a different request. The model can help interpret messages, but your application should control what gets saved and where the request goes.

The workflow below is a proposed design, not a native WhatsApp branch-memory feature. All example branches, records and operating rules are hypothetical. The goal is to keep one request tied to one confirmed branch without asking the customer for their location repeatedly.

1. Define what the branch choice belongs to

Attach the branch choice to a request, rather than treating it as a permanent preference for everyone using that WhatsApp number.

A customer might ask about collection in Durban today and a repair in Pretoria next week. A shared household or business phone can also represent different people. Neither situation justifies silently carrying the previous branch into every new conversation.

Create a request identifier when intake starts. Associate it with your business account and the sender’s messaging identifier. Keep the request open while staff or the bot are handling that particular enquiry.

Use a proposed lifecycle with open, awaiting clarification, handed over and closed states. A handover does not necessarily close the request. A new message about the same unresolved enquiry should still retrieve its branch.

When the customer introduces another task, ask whether it belongs to the current request. For example: “Is this also for your Durban North collection enquiry, or a new request?” This distinction matters more than how much conversation history the model receives.

2. Store a small, explicit branch record

Save a stable branch ID and its confirmation status in a durable application record, such as a database or suitable CRM field.

Do not use a free-text label as the routing key. Customers may write “Durban”, “the north branch” or a shopping centre name. Maintain an approved directory that maps accepted labels to a branch ID, display name, active status and responsible queue.

For this proposed design, the request record should contain:

• request_id: the current enquiry identifier.
• confirmed_branch_id: the accepted branch, or null.
• pending_branch_id: a proposed change awaiting confirmation, or null.
• branch_status: missing, confirmed or change pending.
• selection_message_id: the message supporting the saved choice.
• updated_at and version: update history and conflict control.
• handover_status: whether a person owns the next action.

Store the business and sender identifiers alongside the request, not as values supplied by the model. Limit staff access to what their role needs. A privacy and security owner should decide retention, access and notices before use.

The AI CRM integration glossary provides context for connecting these records to customer systems. The request’s branch should remain distinct from any general customer preference.

3. Read saved state before interpreting each reply

Retrieve the request record first, then give the bot the confirmed branch and the latest customer message.

A proposed processing sequence is:

1. Receive the message and check whether its identifier has already been processed.
2. Find the relevant open request.
3. Load its branch record and current directory entry.
4. Interpret whether the message continues the task, selects a branch or proposes a change.
5. Validate any proposed update in application code.
6. Save an accepted update before acknowledging it.
7. Generate the reply using the resulting saved state.

Source: OpenAI’s function-calling documentation describes a model requesting a tool call while the application executes the underlying code. That supports an architecture in which the model proposes an action, but the application checks and performs it. It does not provide durable branch storage by itself.

If the record cannot be loaded, avoid guessing from a fragment of chat history. Pause branch-specific routing and explain that the saved selection cannot currently be checked. Repeatedly asking the customer to choose again is not a reliable substitute for fixing a storage failure.

4. Separate interpretation from permission to update

Let the model identify a possible branch selection, but require application checks before saving it.

A proposed interpretation result could contain an action such as continue, select, propose change, clarify or request human help. Include a candidate branch ID and a reference to the supporting message. Use null when the message does not identify a branch clearly.

Source: OpenAI’s structured-output documentation describes responses constrained to a supplied JSON schema. This can make an interpretation result easier for code to consume. A correctly shaped result still does not establish that the customer meant the branch selected.

Validate the candidate against the current branch directory. Check whether the message expresses a choice, merely asks about a branch, or mentions a place for another reason. “Does Umhlanga have parking?” is not permission to move an existing Durban North request.

For a clear initial selection, save the branch and acknowledge it. For a changed selection, preserve the existing branch while awaiting confirmation. Treat customer text as data, never as authority to alter internal identifiers, bypass confirmation or change another customer’s request.

5. Confirm changes without restarting intake

Ask one targeted confirmation question when the customer appears to change branch, rather than repeating the whole location menu.

A proposed reply is: “You selected Durban North for this request. Would you like to change it to Umhlanga?” Save Umhlanga as pending, not confirmed. Keep the existing routing choice visible to staff, but hold any new transfer that depends on resolving the change.

Tie “yes” or “no” to the outstanding question. If another question has since been asked, a bare “yes” may no longer be enough. Repeat the branch names instead of guessing which question the customer answered.

After confirmation, update the branch and clear the pending value in one controlled operation. Acknowledge the saved result: “This request is now linked to Umhlanga.” Do not say it has been transferred unless the routing system confirms that step separately.

If staff already own the request, notify the owner and require review of any operational consequences. A branch change should not automatically cancel a booking, move stock, approve a refund or alter a payment. Those actions need their own permissions and appropriate human judgement.

6. Carry the branch through routing and handover

Route from the saved branch ID and give the receiving staff member the same record the bot used.

The proposed handover should show the request reference, confirmed branch, pending change if present, reason for escalation and a short task summary. Include the supporting selection message where staff have permission to view it. This helps a person resolve the remaining question without asking the customer to repeat the whole conversation.

Keep message permission separate from branch memory. The Source: WhatsApp Business messaging policy, last updated on 23 September 2026, sets out opt-in requirements, Platform template rules, the 24-hour customer service window and clear escalation paths for automation. A saved branch does not extend that window or grant permission for later contact.

Have a responsible person assess notices, consent, data handling and any South African legal obligations. Do not collect a full identity number merely to remember a branch.

For broader planning, see WhatsApp AI agents for business and AI agents for customer service. Branch persistence is one small part of that wider operating design.

7. Evaluate exceptions before widening use

Test whether the saved branch remains correct across interruptions, retries and human intervention, not just whether the bot sounds natural.

Build hypothetical conversations covering a clear selection, a vague place name, a branch question without a change request, a confirmed change, an abandoned confirmation, a closed branch and two open requests. Include an application restart and a failed database write.

For duplicate messages, use the incoming message identifier to prevent the same event from applying an update twice. For simultaneous updates, use record versions or another controlled concurrency mechanism. If a staff edit wins the conflict, reload the record rather than overwriting it with an older bot decision.

Review saved records alongside replies. Count unnecessary branch questions, incorrect changes, unresolved clarifications and handovers missing context. These are proposed evaluation measures, not claimed improvements.

A proposed release condition is that every agreed test case produces the expected stored branch and routing state, with no unresolved silent overwrite. Your team should set additional acceptance criteria for its risk level. Any potential reduction in repeated questions needs evaluation in actual use.

Reusable branch-state decision table

Use this proposed table as the routing contract for the application and the staff team.

Completion check: the stored record, customer acknowledgement and staff routing view must agree before a branch-dependent action proceeds.

Hypothetical walkthrough: selection, ambiguity and retry

A normal selection should survive later replies without another location question.

In this hypothetical example, request REQ-A begins with “Collection at Durban North, please.” The directory resolves that label to fictional ID BR-DN. The application saves it as confirmed, records the selection message and replies: “I’ll use Durban North for this collection enquiry.”

The customer then sends an item description. The bot loads REQ-A, sees BR-DN and continues intake without asking where the customer is. If the application restarts before the next reply, it retrieves the same record rather than depending on model memory.

An ambiguous case begins with “Can I use the Durban branch?” The hypothetical business has both Durban North and Durban Central entries. The application leaves the branch unset and offers those two names. If the customer’s next reply still does not distinguish them, a staff member reviews the exchange and asks a specific follow-up. Staff should not choose whichever queue is quieter.

Later, the customer asks to switch to Umhlanga. The bot proposes the change and receives a clear confirmation. A duplicate delivery of that confirmation must not trigger a second update or transfer. If staff have changed the request meanwhile, the version check stops the overwrite and sends the conflict for review. The staff member confirms the intended branch with the customer and records the resolution.

FAQs about remembering branch selections

Keep the saved request record authoritative when these less obvious situations arise.

Should the bot reuse a branch from last month?

Not silently for a new request. Under this proposed approach, the bot may offer the previous branch as a convenience: “Would you like Durban North again?” Save it against the new request only after a clear answer. A previous choice is context, not proof of current intent. Your privacy owner should also decide whether keeping that historical preference is appropriate.

What should happen if the customer sends a location pin?

Treat it as location information, not an automatic branch selection. It could indicate a delivery address, the customer’s current position or a suggested meeting place. Ask what it means if that affects routing. If your business offers a nearest-branch suggestion, label it as a suggestion and obtain a choice. Do not overwrite an existing confirmed branch merely because the pin is elsewhere.

Can staff change the branch while the bot is replying?

Yes, if the application manages conflicts and staff have the right permissions. In this proposed design, staff edits increment the record version. Before saving a bot update or performing a branch-dependent action, check that version again. If it changed, reload the record and pause any conflicting action. The bot should not announce success based on an outdated snapshot.

Turn the routing rule into a clear brief

Start with request-scoped storage and a small exception set before adding wider personalisation.

If your business needs help defining this workflow, Symaxx’s AI chatbots service and broader AI automation service are relevant starting points. Bring your branch directory, current intake questions and examples of unclear replies, with customer information removed where appropriate. You can get in touch to discuss a scoped design covering persistence, change confirmation and staff handover.

Sources

• OpenAI function calling
• OpenAI structured outputs
• WhatsApp Business messaging policy