Handle the enquiry by checking two separate clocks: your team’s opening hours and WhatsApp’s customer service window. A new customer message opens or resets the platform’s 24-hour window, even if your staff have gone home. Acknowledge it where permitted, capture the request and assign follow-up. If that window expires before you reply, switch to an eligible approved template rather than sending free-form text. Missing evidence or sensitive requests should go to a human, not an improvised automated reply.
1. Establish which window has closed
Treat staff availability and platform messaging permission as separate states. Closing your office does not, by itself, close the WhatsApp customer service window.
The Source: WhatsApp Business messaging policy, updated on 23 September 2026, states that each user message opens or resets a 24-hour customer service window. On the Business Platform, replies within that window do not require a message template. Outside it, messages must use approved templates. These platform-specific rules should not be confused with the operating behaviour of the Business App.
The rest of this workflow is a proposed process for a Business Platform integration. Confirm which product and provider your business uses before configuring it.
For example, in a hypothetical business with support hours ending at 17:00 SAST, a customer message at 19:30 creates a platform window even though no agent is available. Conversely, an agent starting work in the morning might find an older conversation whose platform window has expired.
Display both states in the work queue: team unavailable and platform window open, for example. Avoid a single ambiguous label such as closed.
2. Capture authoritative message state before drafting
Build the timing decision from received message records, not from an AI interpretation of the conversation. The customer’s phrase “I sent this yesterday” is not an authoritative timestamp.
A proposed intake record should contain:
- The provider’s inbound message identifier and conversation reference.
- The customer-message timestamp and event receipt timestamp, stored separately.
- The latest confirmed customer-message timestamp for that conversation.
- The calculated window expiry and current routing state.
- Permission evidence, any opt-out record and its scope.
- The enquiry summary, assigned owner and next action.
- Any outbound attempt identifier, status and provider response.
Use a consistent stored time basis and display SAST for the local team. Preserve the original timestamp so a reviewer can resolve conversion or delayed-delivery questions. Define how the integration handles late events before enabling sending.
If message identity or timing is missing, mark the state unknown and hold the reply for verification. Do not substitute the time at which a staff member opened the ticket.
For record-sharing terminology, the AI CRM integration glossary provides context. Linking systems still requires explicit field mapping and access controls.
3. Send an acknowledgement without promising unavailable support
Use an after-hours acknowledgement to explain availability and the next step, not to imply that an agent is working on the enquiry.
A hypothetical acknowledgement for a business reopening on Tuesday could say: “Thanks for your message. Our support team is offline and returns on Tuesday at 08:00 SAST. Your enquiry is queued for review. Please avoid sending sensitive account or identity details here. You can also contact us through the support details on our business profile.”
Only state that an enquiry is queued after the queue write succeeds. If it fails, use an accurate fallback rather than confirming a task that does not exist. Opening hours should come from a maintained calendar, including public holidays, not from generated text.
As a proposed rule, send one acknowledgement for an after-hours intake episode and attach further customer messages to the same work item. This avoids treating every added detail as a separate enquiry while retaining the latest customer timestamp.
Keep the acknowledgement distinct from the answer. A chatbot may collect a non-sensitive reference or classify the request, but payment disputes, account access changes and legal questions need appropriate human judgement.
4. Recheck permission and template eligibility at send time
Choose the reply route immediately before sending. A route that was valid when a task entered the queue may no longer be valid when an agent approves it.
The proposed send gate should read the latest customer-message timestamp, current time, opt-out state and intended message purpose. If the platform window is open, it can consider a free-form reply. If closed, it must check for an approved template suitable for that purpose, with complete and appropriate variables.
Approval alone is not blanket permission. The policy requires opt-in for subsequent contact, respect for opt-outs and template use for the designated purpose. An inbound enquiry should not be treated as permission for unrelated promotional messages.
If permission evidence is unclear, the template is unavailable or the purpose does not fit, hold the outbound message. A human can assess whether another contact channel is appropriate and permitted. Do not move to email or a call simply to bypass an opt-out.
Check current provider pricing separately before adopting a template route. This procedure establishes no price, plan entitlement or regional availability. Human approval must never override the platform send gate.
5. Keep AI extraction separate from sending authority
Use AI to prepare a summary and suggest routing, while application logic controls timestamps, permission checks and outbound execution.
For example, a proposed extraction schema could require enquiry_type, summary, missing_information and human_review_reason. Allow an explicit unknown category so the system does not force uncertain requests into a confident label. Do not let the model infer consent or manufacture an order reference.
Source: OpenAI’s structured outputs documentation describes schema-constrained responses and exceptions such as refusals or incomplete outputs. A correctly shaped record is not proof that its contents are true. Route extraction failures to a recoverable queue rather than dropping the enquiry.
Source: OpenAI’s function calling guide explains that the application executes model-requested functions. In this proposed design, a requested send remains a request: the application checks message state before acting.
This is integration work, not a claim that WhatsApp natively supplies the process. Symaxx’s AI chatbots service is relevant to conversational intake; the broader AI automation service covers connecting intake, queues and review steps.
6. Give exceptions a reachable human owner
Escalate when the request exceeds the approved response scope, when records conflict or when a customer asks for a person. Define who receives the exception and what happens if that person is unavailable.
The WhatsApp policy requires prompt, clear and direct escalation paths when automation responds during the customer service window. After hours, communicate the real availability of those paths. A queue labelled “human support” is not a live transfer if nobody monitors it.
A proposed exception packet should show the customer’s relevant message, the extracted summary, the uncertain field, the proposed response and the current window state. Include only the information needed for review. The policy also restricts asking for full payment card numbers, financial account numbers, personal ID numbers and other sensitive identifiers. Have a responsible person review collection, retention and access arrangements under applicable South African law.
Source: n8n’s human review documentation describes pausing selected AI tool calls for approval or denial. If using that approach, verify the installed setup and approval-channel access. Recheck timing after approval because the reviewer’s delay may change the allowed reply route.
7. Evaluate the routing process before allowing unattended replies
Assess whether the process chooses the correct action, not merely whether the wording sounds helpful. Start with a proposed review-only mode in which staff compare suggested routes with the underlying records.
Include ordinary after-hours enquiries, weekend delays, messages close to expiry, missing timestamps, opt-outs, template rejection and repeated provider events. Also examine a new customer reply arriving while an earlier outbound action awaits approval.
For each case, record the expected route, selected route, evidence used and whether an outbound attempt occurred. A proposed acceptance rule is that uncertain permission or timing must never produce an unattended send. Your operational owner should decide the remaining acceptance criteria and review coverage.
Track incorrect route selection, duplicate attempts, unassigned exceptions and misleading availability statements. These observations can show where the design needs revision; they do not establish improved compliance or time savings in advance.
For wider planning, AI agents for customer service covers the support context, while WhatsApp AI agents for business provides the channel-specific context. This procedure focuses only on the after-hours send decision.
Reusable message-state decision checklist
Use this proposed checklist for each outbound action, including replies approved by a person.
| Check | Evidence to inspect | Proposed action if unclear or failed |
|---|---|---|
| Correct product? | Business Platform integration and provider record | Verify configuration before applying this procedure. |
| Unique inbound event? | Provider message ID and processed-event record | Suppress repeated processing; retain an exception note. |
| Latest customer message confirmed? | Authoritative timestamp and conversation ID | Hold sending and ask an operator to verify. |
| Platform window open now? | Latest customer timestamp plus 24 hours, checked at send time | If closed, assess template route; if unknown, hold. |
| Contact permitted? | Relevant permission evidence and opt-out state | Stop routine sending; request human assessment. |
| Template eligible if needed? | Current approval, designated purpose and valid variables | Hold if unavailable or unsuitable. |
| Content suitable? | Sensitive-data flags, response scope and escalation request | Assign a human owner and approved contact path. |
| Action already attempted? | Outbound action ID and provider status | Reconcile uncertain delivery before retrying. |
| Queue and owner confirmed? | Successful task write, owner and next action | Use operational fallback; do not promise a queued task. |
Record the selected route, reason, owner and actual send outcome. An acknowledgement alone does not complete the enquiry.
Worked walkthrough: a normal enquiry and exceptions
Separate ordinary follow-up from record uncertainty. All times, business hours and records in this walkthrough are hypothetical; the handling rules are proposed.
Normal case: A customer asks about an order on Monday at 19:30 SAST. The team closed at 17:00 and reopens Tuesday at 08:00. Intake confirms the message ID, creates the work item and sends an accurate acknowledgement within the platform window. At 08:15, an agent checks the latest message and answers within that window. The record shows the responsible agent and the outbound result.
Expired follow-up: The agent instead reaches the task on Wednesday. No newer customer message exists. The application blocks the prepared free-form reply. The agent checks relevant permission and an approved follow-up template’s purpose. If either is unsuitable, the task stays on hold for a permitted alternative, not an automatic send.
Duplicate event: The provider delivers the original event again. The stored message ID identifies repeated processing. Under the proposed rule, intake adds no second acknowledgement or task. If an earlier send has an uncertain outcome, an operator reconciles its status before considering another attempt.
Ambiguous record: A forwarded screenshot contains a date but lacks a confirmed inbound timestamp. The system cannot establish the window from the screenshot. A human checks the provider record and leaves the send blocked until the evidence is resolved.
FAQs
Does a customer message after closing time require a template immediately?
No. On the Business Platform, a new customer message opens or resets the 24-hour customer service window. Your office closing time does not determine that permission. Confirm the inbound timestamp and check the window again when sending. An after-hours acknowledgement can be considered within the open window, but it must accurately describe staff availability and offer an appropriate escalation path.
What if an agent approves a reply before expiry but it sends afterwards?
The application should reassess the route at execution time. Approval does not preserve an earlier window state. Under the proposed process, an expired free-form action is stopped and returned for template assessment. Do not silently convert it into a template if that changes its purpose or meaning. Show the reviewer the revised content, relevant permission and current template status before proceeding.
Should every “urgent” message reach an on-call person?
Only if your business has defined and staffed that route. A proposed rule can flag urgency for review, but a chatbot should not promise an emergency response that does not exist. Have an appropriate human define categories involving safety, security, payments or account access. Tell customers the actual availability of support and avoid requesting sensitive identifiers to decide whether their request qualifies.
If your business needs help connecting these checks to its WhatsApp intake, get in touch with Symaxx to discuss the queue, template gate and human handover. Begin with the exception rules and evidence your team needs, then decide which replies are suitable for automation.
Sources
- WhatsApp Business messaging policy, updated 23 September 2026.
- OpenAI structured outputs.
- OpenAI function calling.
- n8n human review for AI tool calls.