First, let's define the conditions under which AI must be stopped.
Users can be assigned based on clear requests for human intervention, instances of continuous miscommunication, inability to verify required fields, involvement of financial transactions or sensitive information, high-risk keywords, API responses indicating an error status, or abnormal behavior of models or phone services. The criteria should be defined as recordable reason codes, rather than relying solely on the model's own judgment. This allows customer service representatives to understand the reason for the call, and also enables the operations team to identify issues related to process design or model quality.
Manual intervention and expected handling| Causes | Things AI should do | Key takeaways from the presentation |
|---|
| Users require a human operator. | Please confirm your details and join the appropriate queue immediately. | Status: Identity confirmed and awaiting further instructions. |
| Recurring misunderstandings or lack of confidence | Stop guessing and explain the purpose of the adapter. | Original problem, failure field, and number of times re-asked |
| Sensitive or high-risk matters | Do not perform irreversible actions. | Risk classification and related case data |
| Corporate system failure | Do not claim success; instead, maintain a state of pending completion. | API status, request identification, and retryability |
| Artificial seating is not available. | Offer options for queuing, calling back, or creating tasks. | Contact information, hours, and tracking identification |
It is important to measure the impact of both planned upgrades and unexpected surges separately.
The planned transfer is designed to be handled by humans, such as AI collecting data and then passing it to a specific agent. An escalation occurs when the AI is unable to understand, the system fails, or the user is dissatisfied. When these two situations occur together, the team may mistakenly believe that all transfers to humans are failures of automation, and it may also obscure the true underlying problem. Google Cloud's virtual customer service metrics also distinguish between planned transfers, escalations, resolved cases, and abandoned cases.
PBX, SIP, and call queuing systems are responsible for the actual routing of phone calls.
AI applications can propose routing goals and reasons, but features like call forwarding, call transfer, group calls, operating hours, queueing, overflow handling, and voicemail are typically managed by PBX systems, SIP platforms, or contact centers. Before implementing, it's crucial to verify features like blind transfer, consultation transfer, keeping the original number, cross-system call identification, and handling failed transfer scenarios. Simply stating "supports SIP" is not sufficient to demonstrate that the existing phone system can handle all routing requirements.
The handover will only include the necessary materials required to complete the assigned task.
The system should at least require the user to provide the purpose of the call, information already confirmed, unresolved issues, results of queries to corporate systems, actions taken, and the reasons for failure. Whether the original recording, complete transcript, or sensitive fields are displayed should be determined based on the user's role and purpose. If the work can be completed using summaries and essential fields, all data should not be exposed. The screen should also clearly indicate which values the user needs to confirm and which are simply model predictions.
Suggested minimum handover content| Data | Applications | Control methods |
|---|
| Reason code for connection | Prioritize tasks and determine the next steps. | Use fixed categories to prevent the model from generating arbitrary commands. |
| Confirmed fields | Prevent users from answering the same questions repeatedly. | Confirmation time and source information |
| Unresolved issues | Enable the system to directly continue the conversation. | Present the model summary separately from the main text. |
| System Status | Avoid redundant queries or creating duplicate entries. | Includes unique request identifier and final status. |
| Safety Summary | Quickly grasp the context. | The mask obscures personal information and restricts access to the original text. |
Regardless of whether the connection is successful, fails, or is interrupted, there must be a next step.
If all seats are occupied, users can choose to wait, request a callback at a specific time, or create a support ticket. If the API call fails, the original call should be retained, retried to a backup queue, or clearly explain the next steps. Before attempting to call back after a disconnection, it's important to verify the purpose of the call, the validity of the number, and company policies. Each fallback path should generate a case ID and display a visible status on the front-end, and errors should not be logged for the user to manually re-enter.
Evaluating the effectiveness of manual intervention requires considering both the reasons and the outcomes.
The transfer rate can only indicate the extent to which requests are routed to manual intervention. It cannot be used in isolation to determine whether a process is good or bad. It should be considered in conjunction with other metrics, such as the number of planned transfers, the frequency of abnormal escalations, misrouting, requests abandoned due to queuing, the first resolution rate, the total processing time, and the proportion of user explanations. If a particular intent results in a high number of planned transfers, it may indicate that the process design is correct. However, if a specific field consistently causes abnormal escalations, it signals that the dialogue, data, or model needs to be revised.
GoGoCha has not provided any public evidence of its complete call center transfer capabilities.
GoGoCha's publicly available content demonstrates the integration of a phone entry system, a shared dispatch backend, real-time notifications, and integration with websites, LINE, apps, and operational interfaces. However, it does not disclose information about specific PBX models, call queue management skills, full-line strategies, or transfer SLAs. This information, which Falcon can customize for specific business environments and validate through a proof-of-concept, cannot be packaged as a complete and validated customer service solution as demonstrated by GoGoCha.
