Start with the receiving queue, not the chatbot message
Kooya’s operating recommendation is to design escalation backwards. Identify the team that can resolve the issue, the hours it is staffed, the authority it needs and the information it requires. Then connect the AI to that service. A generic support inbox with no accountable owner is an unresolved operational dependency.
Routing systems distinguish these steps explicitly. Twilio TaskRouter describes tasks passing through workflows and queues before being paired with workers through reservations. Its documentation describes events that applications can use to follow routing activity. That is one implementation example, not a requirement to buy Twilio.[1]
Translate your own platform’s events into customer-service states: requested, recorded, queued, accepted, waiting for customer and resolved. Do not label a case as accepted merely because an API returned a successful creation response. Keep an owner for the queue while the case waits for an individual.
Write escalation triggers that a team can operate
Use a small set of explicit triggers: the customer asks for a person, an action exceeds the AI’s authority, required evidence is missing, an integration fails or a repeated answer does not resolve the problem. Consequential categories need their own approved workflow. Do not let a fluent model response override a trigger that the service owner has classified as mandatory.
For Filipino-English conversations, test realistic requests for help and expressions of misunderstanding, including changes of language mid-conversation. This is a test-design recommendation, not a claim that every system handles those inputs. Avoid requiring customers to guess one exact phrase before the handoff option becomes available.
- Write the trigger and destination together: refund exception to the team authorised to review refunds.
- Separate service urgency from the model’s confidence score.
- Set a bounded retry policy for recoverable problems; do not restart the same failed exchange indefinitely.
Transfer an evidence packet a person can verify
The packet should explain the unresolved task and what has already happened. Keep customer statements, system facts and model interpretation visibly separate. An AI-generated summary can help the receiving person, but it must not silently become the authoritative account of a disputed transaction.
In a hypothetical delivery complaint, the customer says an item is missing, the order system says delivered and the AI attempted a tracking lookup. Record those three facts separately. Do not rewrite them as a confirmed delivery failure or a promised refund. The receiving person needs the relevant records and authority to investigate.
- Case identity: one durable identifier, channel and necessary account reference.
- Unresolved request: what the customer wants and why automated handling stopped.
- Evidence: relevant message excerpts and controlled links to source records.
- Action history: attempted operations, confirmed results and unknown outcomes.
- Next responsibility: target queue, urgency reason, current owner and next promised update.
Make failed transfers and closed hours visible
Twilio’s task lifecycle distinguishes pending, reserved and assigned work, followed by wrap-up and completion; it also describes cancellation. This illustrates why routing and resolution should be tracked separately. Your helpdesk may use different labels, so map the equivalent states and verify what each actually guarantees.[2]
Kooya’s recommendation: if the case cannot be recorded, tell the customer that transfer has not completed and offer the approved alternative contact route. If it is recorded but nobody is available, provide the real service hours and next step. Never promise an immediate human response when the destination is unstaffed.
Design retries around the existing case identifier so a timeout does not generate multiple competing cases. If a transactional action has an unknown outcome, reconcile its status before retrying it. A missing response does not establish that the action failed. Put stalled and unmatched cases into a visible exception queue owned by the service operator.
Limit personal data without losing the evidence
The Data Privacy Act’s general principles include transparency, legitimate purpose and proportionality. Section 11 addresses relevance, excessive collection and retention; Sections 12 and 13 set conditions for processing personal and sensitive personal information. A support escalation does not remove these obligations.[3]
Kooya’s practical recommendation is to send the minimum useful packet and provide controlled access to additional evidence when needed. Exclude passwords, one-time codes and unnecessary payment or identity details. Restrict transcript access by role, document retention and deletion rules, and have the responsible privacy lead review the actual workflow and processing basis. A blanket assumption that consent alone settles every processing question is insufficient.
Tell customers how the service uses their information and who may receive it through the applicable notices. When a vendor handles the handoff, confirm the safeguards and responsibility in the arrangement. The law addresses subcontracted processing and the controller’s responsibility for appropriate safeguards in Section 14.[3]
Test the handoff as a complete service
Run a small set of deliberate failure cases before opening the flow broadly. The result to inspect is the receiving person’s usable case, the customer’s expectation and the system’s final state. A bot transcript alone cannot prove that the handoff worked.
Use the AI pilot evaluation checklist to connect these handoff cases to the wider release decision.
- No staff available: the case remains owned and the customer receives accurate service-hour information.
- Queue permission denied: the system reports failure and follows the approved fallback.
- Duplicate callback: one case survives without duplicate customer actions.
- Summary error: the operator can inspect source evidence and correct the summary.
- Shift change: waiting cases keep their ownership and next-update commitment.
- Unknown transaction result: an operator can reconcile the actual outcome before any retry.
Measure whether responsibility survived the transfer
Kooya’s suggested operating measures are time from escalation request to durable case creation, time to human acceptance, the number of cases without an owner, cases exceeding the promised update time and requests reopened after apparent resolution. Segment these by queue, language condition and service hours when the sample is useful and privacy controls permit it.
Review a sample of evidence packets with the receiving team. Ask whether the summary was accurate, the requested action was clear and unnecessary data was included. Use observed failures to improve the routing and packet format. Do not optimise automated containment at the expense of customers who need a person.
This guide describes a design and acceptance framework, not results from a Kooya customer deployment. Kooya provides AI software and workflow engineering; any implementation should define its scope, ownership and service commitments explicitly.