Hallazgos

Un hallazgo es un problema estructurado de la organización que agrupa conversaciones con el mismo fallo: un error de guion, una mala pronunciación o una herramienta mal utilizada. Puede crearlo una persona o proponerlo la IA. Tiene título, descripción, prioridad, responsable, etiquetas y llamadas vinculadas. No es lo mismo que los analysis_findings del análisis de conversaciones: aquellos son observaciones de una llamada. El hallazgo es el problema duradero y compartible que el equipo clasifica y corrige, respaldado por las llamadas que vincula.

​

Oportunidades continuas

Abre Hallazgos → Oportunidades para comparar problemas recurrentes de las llamadas a lo largo del tiempo. Selecciona Configurar análisis continuo para crear un monitor compartido que evalúa el tipo de fallo, la intención, el saludo, el motivo de transferencia, el resultado de las tareas, la frustración y la evidencia. La primera etapa booleana mide si un problema observable afectó a la llamada; las demás lo explican.

1. Selecciona los agentes que quieres comparar. Para una prueba de saludos, empieza con 3–4 agentes considerados buenos y 3–4 considerados deficientes.
2. Revisa las instrucciones y prueba el monitor con llamadas de ejemplo. Valida con el equipo las transferencias legítimas, la asistencia fallida y los resultados ambiguos antes de confiar en las tasas agregadas.
3. Guarda y activa el monitor para las llamadas nuevas. Usa sus controles de análisis histórico si necesitas una comparación con llamadas anteriores.
4. Vuelve a Oportunidades, elige un intervalo de fechas y filtra por clínica, agente o metadatos de la conversación.

La vista ordena los grupos de problema e intención con al menos dos llamadas afectadas: primero por volumen y después por cambio de tasa. Muestra el período anterior de igual duración, totales diarios, agentes/clínicas/versiones afectados y hasta tres llamadas de ejemplo por grupo. Los recuentos corresponden a la población seleccionada y la versión actual del monitor desde su fecha de inicio del análisis. Los resultados faltantes o desconocidos aparecen en la cobertura, pero se excluyen de las tasas de resultados conocidos. El muestreo puede afectar a la representatividad; las tasas no estiman las llamadas sin evaluar.

​

Grupos de saludos y contexto operativo

Envía una cadena en metadata.opportunityContext.greetingGroup para comparar grupos con nombre, como revisado-bueno y revisado-deficiente. Sin ella, las llamadas se agrupan según la longitud del saludo observada por el monitor. Las etiquetas se limitan a 100 caracteres en esta vista. Las diferencias son asociaciones: la clínica, la intención y la configuración pueden explicarlas. Úsalas para proponer una prueba, no para atribuir causalidad al saludo. El monitor lee opcionalmente estos campos de metadata.opportunityContext: Aporta también transcripciones, resultados de herramientas, la clínica y identificadores estables de versión. Confirma que la ruta de ingesta transmite esos datos; una integración de telefonía por sí sola no garantiza el contexto de una orquestación interna. Consulta la carga de llamadas personalizada. Los motivos distinguen transferencias obligatorias, solicitudes inmediatas de una persona, escaladas tras intentar ayudar, falta de citas, fallos de herramientas y casos desconocidos. Una transferencia adecuada no cuenta como resolución sin transferencia. En llamadas con varias acciones, la evidencia incluye cada tarea solicitada y su resultado. Las explicaciones siguen siendo hipótesis hasta contar con evidencia operativa; la clasificación no garantiza la causa raíz.

​

De la evidencia al cambio

Los propietarios y administradores pueden Enviar hallazgo para revisión. Se crea un candidato con llamadas representativas y el volumen observado en la descripción; esas llamadas no representan toda la población afectada. Repetir el mismo envío reutiliza el candidato. El proceso de revisión existente publica los hallazgos aceptados. Las llamadas nuevas actualizan Oportunidades, pero no modifican ni se adjuntan automáticamente a un hallazgo ya enviado. Configurar un experimento lleva el monitor y un nombre sugerido a Experimentos. Selecciona dos versiones desplegadas de un mismo agente y revisa la configuración antes de iniciar. Zelto mide los resultados; tu plataforma despliega y enruta de forma consistente a los usuarios. La comparación inicial entre clínicas no es un experimento controlado.

​

Información de un hallazgo

El volumen se fija al crear el hallazgo: llamadas vinculadas dentro del periodo analizado divididas entre todas las llamadas de los mismos agentes en ese periodo. Las cargas posteriores no se vinculan automáticamente y no diluyen ese porcentaje. Es null si no había llamadas de esos agentes con las que comparar.

​

Estados

​

Prioridad

De menor a mayor: none, low, medium, high, urgent. Es independiente del estado: un hallazgo abierto puede tener cualquier prioridad. Asígnala al clasificarlo.

​

Categorías

Puedes elegir uno de estos siete tipos o dejarlo vacío:

• Buzón de voz no detectado.
• Mala pronunciación.
• No sigue el guion.
• Reconocimiento de voz deficiente (ASR).
• No comprende al usuario.
• No utiliza correctamente las herramientas.
• Voz inconsistente.

​

Vincular conversaciones

Las llamadas se vinculan mediante finding_conversations. La operación es idempotente: repetir un vínculo devuelve el existente, sin duplicarlo. La conversación debe pertenecer a la misma organización. A la inversa, su página de detalle muestra todos los hallazgos vinculados para pasar de una llamada al problema general.

​

Anotaciones y comentarios

Cada llamada vinculada tiene sus propios comentarios. Usa annotationStartMs y annotationEndMs para asociar un comentario a un fragmento exacto de la transcripción, por ejemplo una interrupción entre 0:42 y 0:51. Cada comentario guarda autor y type, que distingue comentario simple de anotación.

​

Trabajar un hallazgo

Desde el detalle puedes:

• Definir prioridad, responsable y estado. El botón superior avanza al siguiente estado: Reconocer si está abierto, Resolver si está reconocido; el desplegable permite otras transiciones.
• Editar título y descripción. El editor admite encabezados, listas, diagramas, menciones @ y ejemplos de llamadas. Escribe /call para insertar una llamada vinculada con reproductor, marcas de anotación y fragmento de transcripción dentro de la descripción.
• Copiar un prompt del hallazgo, con título, categoría, estado, descripción, agentes y llamadas, para analizarlo con un LLM o preparar una corrección.
• Enviar a Linear si la organización lo tiene conectado; consulta Linear.

Los cambios vinculados permiten seguir la corrección junto al problema. Consulta Clasificar hallazgos.

​

Acceso programático

La API REST permite: MCP expone list_findings, get_finding, create_finding, update_finding, add_conversation_to_finding y annotate_finding_conversation para clasificar hallazgos con un agente.

​

Relacionado

• Conversaciones: las llamadas que aportan evidencia.
• Monitores: convierte un problema recurrente en comprobación continua.
• Cambios: correcciones de un agente.
• Linear: seguimiento externo.
• REST y MCP: acceso programático.