Symptom or Need

The user reports that the activity code used to classify (code) a call does not match the code shown in the Speech Analytics report.

Context / Scenarios

• Affected modules : Reports Module, Data Monitor and Speech Analytics Report.
• Typing methods involved : This incident usually occurs in operations that classify their interactions through multiple channels, whether through the manual option of Coding, automations by Scripting, or data injections via API.
• Integration and flow environment: This occurs in scenarios where the client process interacts with its own databases or consumes external APIs, which is a critical factor, since these integrations could be overwriting the original coding of the call.
• Scope of behavior : The inconsistency may occur massively in the general calls of the operation, or partially, affecting only a specific percentage of calls (for example, those that are triggered exclusively by the speech).
   

Answer / Solution

Minimum information gathering

To manage this incident, validate the following information with the client and document it in the case:

1. Name of the affected operation .
2. Percentage of overall impact of the failure .
3. Name and number of the specific report(s) being consulted by the client and showing inconsistency.
4. Call ID, date and time of the calls that present the inconsistency.

Initial Validations

Perform the following checks to diagnose the problem:

1. Confirm with the client how the calls are being categorized (whether it is done through the Encode option, by Scripting or via API ).
2. Analyze the process the client performs to replicate the incident , including reviewing the flow, the behavior of the client's databases, and whether there is consumption of external APIs.
3. Perform a review of the call IDs shared by the client and validate and compare if the typing matches between the Data Monitor and Speech Analytics .
4. Check if the problem occurs with all calls in the operation or only with a specific agent or activity code. To do this, check a percentage of the operation's total calls.
5. Validate the percentage of calls being triggered by the script. This is to assess its impact on operations.
6. Perform a controlled test on another operation of the same server, encoding via API , to verify if the call's encoding is overwritten under this method.
7. Always extract and include the verbose or details of the calls where the novelty occurs, to attach it as a technical analysis of the case.

Escalation

Once the validations have been carried out and documented, scale the case to Level 2 (Core).

Possible Causes

• Conflicts in the flow or databases: The client's internal process may include cross-referencing with their own databases or consuming external APIs that alter the final code read by the Speech Analytics tool.

Practical Example

• Scenery: An advisor answers a call and uses the manual "Code" option to classify it as Venta Exitosa . However, the customer flow consumes an external API which, upon updating the customer database, returns an event that overwrites the classification to Gestión Administrativa . Consequently, the call ID on the advisor's monitor displays Venta Exitosa , but Speech Analytics shows the API update ( Gestión Administrativa ), creating the inconsistency.

Considerations

• Importance of the detailed record: In order for the technical team to confirm if there is an overwrite, it is strictly mandatory to include the verbose (technical record) of the specific calls where the novelty was detected.
• Identify the scope: Before escalating, consider whether the failure occurs in all calls of the operation or only in the percentage of calls that are triggered by the speech .

Recommendation

• Audit API integrations: Recommend that the client review the logic and code of the external APIs they consume during the call to ensure that they are not sending parameters that reset or overwrite activity codes.