Ask one clarifying question when a low-risk request has a single missing detail that will change the next step. Open or update a ticket immediately when the request is urgent, involves a payment dispute, follows repeated failed repairs, needs human discretion, or explicitly asks for a person. If that one question does not settle the ambiguity, or the bot cannot support the next action, escalate rather than start an interview.
For a South African support team, the decision is not whether bots or people are better. It is whether another customer reply is worth asking for. The workflow below is proposed, and all example messages, records and values are hypothetical.
1. Set the escalation boundaries before writing questions
Define immediate escalation first, because a clarification rule must never become a barrier to human support.
A proposed boundary list should cover reported safety hazards, suspected account compromise, disputed charges, ordinary urgent requests, repeated failed repair attempts, complaints needing discretion, and explicit requests for a person. Route these to an appropriate owner without making the customer complete a troubleshooting sequence.
Opening a ticket is not the same as providing urgent assistance. For a reported hazard, the bot should also display the business’s human-approved safety message and relevant urgent contact route. It should not diagnose electrical faults or promise that a technician is on the way.
Separate ordinary urgency from safety urgency. “I need this before tomorrow” may require a service coordinator; “the unit is smoking” requires a different response. Both bypass clarification under this proposed rule, but they need different owners and messages. Preserve the customer’s words so the human can assess severity.
When planning AI chatbots, assign each boundary to a named queue and an operational owner. A generic inbox with no responsible team is not a complete escalation design.
2. Ask only a question that changes the next action
Choose clarification when the answer can unlock a supported response or identify the correct queue, not merely fill an optional field.
For an ambiguous repair message such as “My appliance has stopped working”, a useful hypothetical question is: “Which appliance needs attention?” That answer may distinguish the washing-machine team from the refrigeration team. Asking for purchase date instead would add effort without necessarily changing the first action.
For “I have a billing question”, try: “Is this about understanding an invoice or disputing a charge?” An invoice explanation may be suitable for a grounded answer. A disputed charge belongs with a person who can investigate it.
Avoid disguising a form as one question. “Please send your model, serial number, invoice, address and fault description” is several tasks, even if it ends with one question mark.
Before approving a question, write down what happens for each plausible answer. If every answer opens the same ticket in the same queue, open that ticket now. Collect optional detail after the handover, without delaying it. If no useful question exists and the request cannot be answered safely from approved information, send it to the human intake queue.
3. Ground the response before treating the case as resolved
Answer directly only when the team has an approved, relevant source that supports the response.
The clarification branch needs more than an intent label. If the customer identifies an invoice line, the bot still needs the applicable explanation. It should not guess why a charge appeared or infer that a refund is due. A clear request can still be unsupported and require a person.
OpenAI’s Source: file search documentation describes retrieval from uploaded files using semantic and keyword search. That capability can support a knowledge lookup, but it does not establish that a retrieved document is current, applicable to the customer, or sufficient to settle the issue.
A proposed content register should record the document owner, review date, scope and permitted use. Keep general explanations separate from account-specific facts. Where sources conflict or no applicable source exists, route the issue to a person rather than select whichever answer sounds convincing.
The wider customer-service agent use cases can help frame the project, but this triage decision should remain narrow: ask, answer from an approved source, or hand over.
4. Turn the decision into an application-controlled action
Let the model propose a route, while application code checks permissions and executes any ticket action.
OpenAI’s Source: function calling guide describes a flow in which the model requests a function and the application executes code. Ticket creation in this workflow would be a custom integration, not a native promise that a model can fulfil by writing a confirmation message.
Use a proposed decision record containing: route, reason, customer wording, urgency evidence, clarification used, missing information, source reference and existing ticket reference. Allow explicit values such as unknown rather than encouraging invented details.
OpenAI’s Source: structured outputs guide explains schema-constrained output. This can help keep fields consistent, but the application must still check whether the proposed route and supplied facts are valid. Correct structure is not proof of correct judgement.
Before writing to the support system, check customer access, allowed fields and duplicate status. The AI CRM integration glossary provides context for connecting conversation data to customer records. Keep payment adjustments and security decisions outside the bot’s authority and with authorised humans.
5. Use this reusable triage decision tree
Apply the branches in order, with a human fallback whenever a request cannot reach a supported answer or valid route.
Proposed triage decision tree
- Human requested, hazard reported, security concern, payment dispute, ordinary urgent request, repeated failed repair or complaint needing discretion? Escalate immediately to the relevant owned queue. Safety urgency also gets the approved urgent contact route; ordinary urgency goes to a coordinator. Do not wait for optional details. Continue duplicate checking without delaying escalation.
- Existing case confirmed through an authorised lookup? Add the message and escalation reason to that case and notify its owner. If the match is uncertain, route to human intake for matching without merging records.
- Request clear and supported by an approved source? Answer within scope and offer a human route if it does not help. Otherwise continue.
- One missing, non-sensitive detail would change the answer or queue? Ask one short question, explain why, and allow “I’m not sure”. If not, escalate to the owned human intake queue, including clear but unsupported requests and any unmatched case.
- Clarification reply enables a supported answer or valid queue? Answer or route accordingly. Otherwise escalate to human intake, whether the reply is clear but unsupported, missing, ambiguous, contradictory or refused. Do not ask another diagnostic question.
- Ticket write or update confirmed? Share the returned reference and actual next step. If writing fails, explain that and offer a working alternative contact route.
Handover fields: customer wording; verified context or “unverified”; escalation reason; urgency evidence; clarification history; unknown fields; source used; existing case match; owned queue; confirmed reference or failure state.
Completion check: every request reaches a supported answer, an owned human queue, or an explained working fallback. Unsupported and unmatched cases escalate before or after clarification; no branch requires another diagnostic question.
Treat this tree as a starting specification, not a tested policy. Have support, privacy and security owners approve it before a pilot. A required field in the ticket system should not force the bot to invent a value. Agree an intake queue that accepts incomplete cases and lets a person collect remaining information safely. Duplicate checking should change where the context is stored, not whether an urgent request gets attention.
6. Make the handover usable across chat and WhatsApp
Carry the existing context into the ticket and explain what will happen next without inventing a response time.
The customer should not have to repeat a fault description simply because the conversation changes channel. A proposed handover summary should distinguish what the customer said from what the bot inferred. “Customer reports two charges” is safer than “Customer was charged twice”, unless an authorised record confirms it.
For WhatsApp, channel rules affect follow-up. The Source: WhatsApp Business messaging policy, updated on 23 September 2026, requires clear escalation paths for automated responses. It permits non-template replies within the 24-hour customer service window and requires approved templates outside it. It also restricts requests for full payment card numbers, financial account numbers and personal ID numbers.
A proposed WhatsApp handover should therefore record the permitted follow-up route and avoid collecting sensitive identifiers in chat. Consult the WhatsApp agent use-case resource when planning the channel. Responsible staff must assess consent, privacy obligations and any sector restrictions; a ticket reference alone does not establish permission to send future messages.
7. Compare customer effort with actual resolution
Evaluate clarification against immediate ticketing within similar cases, rather than assuming fewer tickets means better support.
Start with human-labelled scenarios. Include straightforward repairs, invoice explanations, payment disputes, urgent requests, repeated failed repairs, complaints needing discretion, short replies and customers who decline to answer. Include clear requests with no approved source and clear clarification replies that still cannot be supported. Reviewers should record the intended route and its evidence.
For a limited pilot, a proposed review set could contain 60 eligible low-risk conversations. That number is hypothetical, not a recommended statistical sample. Compare clarification and immediate-ticket cases by issue type and account for differences in complexity. Do not delay urgent cases merely to create a comparison group.
Record resolution, repeat contact about the same issue, customer replies required, and whether the human received enough context. Define an appropriate review period before collecting results.
Inspect unnecessary questions, wrong queues, unconfirmed ticket claims, missed boundaries and duplicates. A proposed pause rule is any observed missed safety escalation or incorrect account disclosure. Human reviewers should decide corrective action before further testing. Broader AI automation planning should follow this evidence, not replace it with assumed savings.
Worked walkthrough: normal routing and exceptions
The tree should handle straightforward and incomplete requests without making the customer restart. All cases and references below are hypothetical.
Normal repair case: A customer writes, “My machine will not start.” No escalation boundary or existing case is found. The bot asks, “Which appliance needs attention? This helps me choose the repair team.” The customer replies, “A washing machine.” Under the proposed process, appliance type determines the repair queue. The application creates a ticket in that queue and returns hypothetical reference R-214. The bot shares the reference without promising a visit date.
Ambiguous reply: Another customer answers, “The one you fixed.” The bot does not ask for a serial number next. It routes the conversation to human intake with the appliance marked unknown. A coordinator checks authorised repair history and assesses whether this is a repeated failed repair needing priority handling.
Clear but unsupported reply: A billing customer identifies an invoice line, but the approved register contains no explanation. The bot escalates to billing rather than guessing or asking another question. The reviewer checks the account and applicable terms.
Duplicate billing case: A customer says, “I already reported this invoice charge.” A possible case match has a different invoice reference. Human intake receives the message for matching; the bot neither merges records nor approves a refund.
Urgency exceptions: “The unit is smoking” bypasses clarification and receives the approved urgent route plus escalation. “I need a repair before tomorrow” also bypasses clarification, but goes to the service coordinator for scheduling judgement, without a promised appointment.
FAQs
Use these proposed answers to settle operational edge cases before building the workflow.
What if the customer does not answer the clarifying question?
Do not treat silence as resolution. Agree a channel-appropriate waiting period with the support owner, then route the incomplete request where follow-up is permitted and contact details are available. Record the question as unanswered, not refused. If no valid contact route exists, retain the unresolved state according to the approved retention process. Do not send repeated reminders automatically or assume WhatsApp permission continues indefinitely.
Should the bot ask for an invoice number before escalating a billing dispute?
Not as a condition of escalation. An invoice reference may help a human locate the issue, but it should remain optional at intake under this proposed workflow. Pass an incomplete dispute to billing and explain that verification may be needed through an approved route. The bot must not request full financial account details in WhatsApp, confirm liability, approve a refund or make a payment adjustment.
What if the clarification reply is clear but the bot still cannot answer?
Escalate to the relevant owned queue, or human intake if the correct specialist is unknown. Clarity does not establish that an answer is supported. Include the original request, the clarification reply and the missing or conflicting source information. Do not ask another diagnostic question to cover a knowledge gap. A human should determine the explanation or next action and refer any proposed knowledge-base update to its content owner.
Choose the next step
Start by agreeing the immediate-escalation list, approving the decision tree and labelling representative exceptions. If your business needs help turning that specification into a scoped chatbot integration, get in touch with Symaxx to discuss the queues, data access and human review required before a pilot.