Your chatbot should split a mixed request into separate tasks while keeping one shared conversation. A refund, an address correction and a technical fault need different evidence, owners and completion checks. The customer should not have to restart the conversation for each problem, but the bot must not treat one resolved issue as proof that everything is sorted.
The workflow below is a proposed operating model for a South African support team, not a native product feature or a tested implementation. Its routing rules and examples are proposals to assess against your own systems, policies and staff responsibilities.
Identify outcomes before assigning departments
Split the message according to what the customer wants done, rather than where the message might eventually go.
For example, “Please refund my subscription, fix my delivery address and help with the app crashing” contains separate requested outcomes. Start with provisional task labels: refund request, address correction and technical fault. Do not send the whole message to billing simply because “refund” appears first.
Preserve the original message alongside the extracted tasks. Each task should point to the wording that supports it. This gives a support agent a way to check whether the bot missed a request or invented one.
Distinguish the outcome from its supporting explanation. “The app crashes, so I want my money back” could justify both a fault report and a refund request, but it does not necessarily mean the customer wants troubleshooting. Ask whether they want technical help as well.
For an AI chatbot, this is an intake design decision: identify the work first, then apply your service boundaries and routing rules.
Keep shared context separate from task details
Store verified customer context once, then attach only the relevant details to each task.
The shared record should hold the conversation reference, permitted customer identifier, verification state, preferred reply channel and links to existing cases. Task records should hold their own order or subscription reference, evidence, missing information, owner and status.
Do not copy an order number into every task merely because it appears somewhere in the message. A customer may want a refund for an earlier purchase and an address correction for a different delivery. Use an explicit relationship such as “customer confirmed this task concerns this order”. Until that relationship is established, leave the task reference unresolved.
Also distinguish customer statements from checked records. “Customer says delivery has not left” is not the same as a dispatch-system result. Include the source and retrieval time for checked information where relevant.
The AI CRM integration glossary provides context for connecting conversation records with customer systems. Shared context should support continuity, not grant every department access to every personal detail.
Confirm the split and ask only useful questions
Give the customer a short summary of the identified tasks, then ask for information that changes the next step.
A proposed opening response is: “I’ve noted a refund request, an address correction and an app fault. Are these about the same purchase? For the address, do you mean your account address or a delivery already in progress?” This confirms the split without pretending that any action has happened.
Ask a shared question once when its answer genuinely applies across tasks. If verification is required for account-specific work, use the approved verification process rather than collecting separate identity details for every issue. Do not request passwords or payment credentials in chat.
Keep clarification local. Missing device information should not stop a refund request from reaching its reviewer. An unclear delivery reference should block that address task, not erase the technical report.
For short-message channels, present a compact task summary and let the customer answer one question at a time. The WhatsApp AI agents for business resource is relevant when planning that conversation format, rather than assuming customers will complete a long intake form.
Check dependencies before tasks move forward
Allow independent tasks to progress separately, but hold tasks whose next action depends on another decision.
Write dependencies explicitly. An address correction for a replacement delivery may depend on whether a replacement will be arranged. A technical investigation may provide evidence for a refund review, but it should not automatically become a compulsory step unless your approved policy requires it.
As a proposed routing rule, prioritise deadlines and consequences over message order. If a delivery change may become unavailable after dispatch, route that task promptly for a dispatch check. Do not claim the parcel can still be redirected until the responsible system or person confirms it.
Record the reason for a hold: “Awaiting confirmation of which delivery”, not simply “pending”. Give the held task an owner who can obtain that confirmation.
Refunds involve payment consequences, and address changes may affect account security or personal information. Appropriate staff should judge exceptions and authorise consequential actions. Customer urgency is useful context, but it is not an approval mechanism or permission to bypass those checks.
Ground each task in the right evidence and tools
Use separate evidence checks for each task, even when the tasks share a conversation.
The refund task needs the relevant purchase record and applicable policy. The address task needs the intended address type and fulfilment state. The fault task needs symptoms and relevant support guidance. A document about troubleshooting cannot establish whether a refund was paid.
Source: OpenAI’s structured outputs documentation describes schema-constrained responses and handling for refusals or incomplete output. A schema could organise the proposed task records, but a correctly shaped record does not establish that the extracted facts are correct. Validate task references and preserve unknown values.
Source: OpenAI’s function calling documentation explains that the model requests a function call and the application executes it. In this design, application code should check permissions, task identity and approval before any consequential action, then record the actual result against the correct task.
Source: OpenAI’s file search documentation describes retrieval from uploaded knowledge files. That could support policy lookup after preparing the knowledge base. It does not replace live order checks or prove that a policy applies to the customer’s circumstances.
Use this reusable multi-issue intake model
Use a parent conversation record with linked task records, plus a clear decision for each task. The following template is a proposed model that your team can adapt before connecting it to live systems.
Proposed multi-issue intake template
Shared conversation record
- Conversation reference:
- Original customer message and message reference:
- Customer identifier and verification state:
- Permitted reply channel:
- Existing case references:
- Confirmed shared facts, with sources:
Repeat for each task
- Task reference and requested outcome:
- Supporting customer wording:
- Confirmed order, subscription or product reference, or unknown:
- Task-specific evidence and source:
- Missing information and exact clarification question:
- Dependency on another task, or none established:
- Named owner or responsible queue:
- Proposed status: needs clarification, ready for review, in progress, waiting externally, resolved or withdrawn:
- Required approval and authorised reviewer:
- Latest checked result and customer-facing next step:
- Completion evidence:
| Condition | Proposed handling |
|---|---|
| Independent and sufficiently clear | Route to its owner; retain the shared conversation link. |
| Required detail missing | Hold only this task and ask a targeted question. |
| Possible duplicate | Link the existing case for review before creating more work. |
| Consequential action requested | Obtain the required human judgement and approval. |
| Conflicting records or uncertain tool result | Stop the affected action; assign a human to reconcile it. |
Completion check: Every requested outcome has a task, owner, next step and supported status. Close the conversation only when all tasks are resolved or explicitly withdrawn.
Keep status changes traceable. Record who changed the status, what evidence supported it and whether the customer was informed. If your case system uses different labels, map them to the template rather than allowing the bot to invent new statuses in each conversation.
Walk through a normal request and its exceptions
A normal request should produce a task-by-task plan; an unclear request should produce targeted clarification, not guessed action.
In this hypothetical example, a verified customer says: “Please refund subscription SUB-A, change the delivery address for order ORD-B to the address in my secure account form, and help with the app closing when I open invoices.” All references are fictional.
The proposed workflow creates a refund-review task for SUB-A, an address-review task for ORD-B and a technical task for the invoice screen. It links each to the same conversation without treating the subscription and delivery as one purchase. A billing reviewer checks the refund request. A fulfilment agent checks dispatch status and the confirmed destination. Technical support asks for the device type and app version through the approved channel.
The bot reports those separate next steps. It does not say “refunded” or “address updated” merely because a task was submitted.
Now consider a hypothetical follow-up: “Use the other address, and I already reported the crashing.” The address destination is ambiguous, while the fault may duplicate an existing case. Hold the address change and ask which destination the customer intends. Link the earlier fault case as a possible match. A human checks the affected product, symptoms and case status before merging; a new symptom may require separate work.
If an address tool times out, mark the result uncertain. The fulfilment agent should check whether the change took effect before any retry that could repeat the action.
Evaluate the split before expanding the workflow
Evaluate task coverage, linkage and truthful status reporting before measuring speed or increasing automation.
Create a labelled set of hypothetical messages covering unrelated purchases, shared references, vague pronouns, repeated complaints, changed instructions and partial tool failures. Ask support staff to identify the expected tasks, missing details, dependencies and human decisions independently of the bot’s output.
Compare the bot’s records with those labels. Count omitted outcomes, invented tasks, incorrect reference links, unnecessary holds, duplicate cases and unsupported completion statements. Review the customer-facing reply as well: a correct internal split is not enough if the reply hides an unresolved issue.
As a proposed release gate, require human review of any test case containing an unapproved consequential action or a false success statement before enabling that action path. Your team should set acceptance criteria according to the actual risks, rather than adopting an arbitrary accuracy percentage.
The customer-service agent resource can support broader planning. Keep this narrower trial focused on whether mixed requests remain understandable and actionable. Potential benefits need evaluation; vendor capabilities alone do not establish fewer errors or faster resolution.
FAQs about mixed-issue chatbot requests
Should the chatbot create a separate ticket for every issue?
Create a separate logical task for each distinct outcome, but let your case system determine whether those become child tickets or task entries. Splitting sentences into tickets can create duplicates. A useful proposed rule is to create separate work when ownership, evidence or completion differs. Keep one conversation coordinator so the customer receives a joined-up summary rather than disconnected departmental replies.
What if the customer answers only the address question?
Apply the answer to the address task and leave the other tasks at their existing statuses. Do not treat the reply as consent for a refund or confirmation that the fault is resolved. Restate the remaining next steps briefly. If the answer changes shared context, such as which order is involved, recheck affected task links before proceeding and preserve the earlier interpretation in the record history.
Can the conversation close when the refund is approved?
Not while an address request or fault remains open, unless the customer explicitly withdraws that remaining work. Refund approval also differs from confirmed payment completion. Use the evidence appropriate to each status, and keep uncertain outcomes visible. If your system must close a channel session, retain the unresolved tasks and an approved follow-up route rather than presenting the whole request as resolved.
Plan a bounded first workflow
Start with one supported mixed-request pattern and named human owners before extending the design to more departments.
If your business needs help defining that intake pattern, Symaxx’s AI automation service is a starting point to discuss the task model, system boundaries and review requirements. Get in touch with a hypothetical mixed request and your current routing process so the discussion stays focused on a practical decision.