Este artículo es para compañeros de soporte y cualquier persona responsable de configurar o mantener Fin que quiera usar Monitors como parte de un workflow de aseguramiento de calidad (QA) para problemas de respuestas de Fin. Cubre qué hacer después de que un monitor comience a mostrar conversaciones: cómo interpretar resultados, aplicar juicio humano y convertir hallazgos en mejoras.

Si buscas instrucciones de configuración, consulta la guía de configuración de Monitors.

El aseguramiento de calidad para Fin solía significar revisar una pequeña muestra de conversaciones, buscando cualquier cosa que pareciera fuera de lugar, y esperando detectar los patrones importantes. Ese enfoque funcionaba cuando el volumen de conversaciones era manejable. Hoy, no escala.

Fin ha cambiado lo que es posible. En lugar de revisar manualmente una fracción de conversaciones, puedes evaluar miles. El desafío ya no es encontrar problemas, sino saber cuáles realmente importan.

Por eso los workflows de QA más efectivos no reemplazan a los compañeros humanos con IA. Combinan la capacidad de Fin para detectar patrones con el juicio humano para interpretar esos patrones y convertirlos en mejoras significativas.

Un monitor evalúa continuamente las conversaciones según los criterios que defines, ya sea una muestra aleatoria para QA continuo o conversaciones específicas basadas en señales como puntuaciones bajas de CX (tu calificación de experiencia del cliente en Intercom), escalaciones repetidas o calidad de respuesta. Esas conversaciones pueden ser revisadas usando una scorecard por Fin, un revisor humano o ambos.

Intercom incluye plantillas para workflows comunes de QA, incluyendo revisiones semanales de Fin, baja calidad de respuestas, manejo de escalaciones, problemas recurrentes y más. También puedes crear Monitors desde cero para ajustarlos a las necesidades de tu equipo.

Piensa en Monitors como la capa de filtrado. Toman un número abrumador de conversaciones y las reducen a las que probablemente necesiten atención.

Un monitor no solo señala que una conversación tuvo una mala puntuación. Para criterios evaluados por IA, te muestra exactamente por qué, hasta el criterio específico y el razonamiento de Fin detrás de la puntuación.

Lo que no hace es conectar los puntos entre conversaciones.

Podrías tener diez conversaciones con baja calidad de respuesta y diez explicaciones diferentes generadas por IA. Pero si miras más de cerca, siete de esas conversaciones podrían rastrearse hasta el mismo artículo desactualizado.

Fin puede decirte por qué cada conversación individual tuvo mala puntuación. No puede decirte que siete de esos “porqués” son en realidad el mismo problema subyacente que aparece de diferentes maneras.

Reconocer esa diferencia requiere conocimiento del producto y contexto. Es la diferencia entre estas dos conclusiones:

Sin ese paso, QA se convierte en una lista de conversaciones señaladas. Con él, QA se convierte en una lista de mejoras accionables. Esa es la diferencia entre ruido y conocimiento.

El workflow tiene cuatro pasos:

Aquí es donde Monitors hacen el trabajo pesado. En lugar de muestrear manualmente conversaciones y esperar encontrar algo útil, Monitors evalúan continuamente cada conversación que cumple tus criterios y muestran las que probablemente necesiten atención.

Este es el paso que Fin no puede reemplazar. Monitors pueden decirte que diez conversaciones tuvieron mala puntuación, pero no te dirán si todas son síntomas del mismo problema, si el problema es contenido desactualizado o si Fin está siguiendo una guía que ya no refleja tu producto.

Tus expertos humanos en producto son quienes conectan esos puntos.

Una conversación señalada no es un ítem de acción. Compara estas dos conclusiones:

La segunda da al equipo algo concreto para arreglar. Siempre que sea posible, identifica el artículo, procedimiento o regla de guía de Fin específica que está causando el problema, en lugar de solo describir el síntoma.

Los conocimientos solo crean valor si alguien actúa sobre ellos. Una brecha de conocimiento podría pertenecer al equipo responsable del contenido del help center. Un problema de procedimiento podría pertenecer a las personas que mantienen la guía o el diseño de conversación de Fin.

No todas las organizaciones tienen equipos dedicados de Gestión del Conocimiento o Diseño de Conversaciones. Los equipos pequeños pueden tener una persona con múltiples roles. La distinción importante no es quién posee el trabajo, sino identificar si estás viendo un problema de contenido o de procedimiento, para que se haga la mejora correcta.

Cuanto más específica sea tu recomendación, menos tiempo alguien más pasa redescubriendo el problema y más tiempo pasa resolviéndolo activamente.

Puedes hacer esto directamente dentro del Monitor usando Issues.

Desde la barra lateral de Review de cualquier conversación, puedes crear un ticket de Issue con un título, tipo (Content, Guidance, Procedure, Escalation y más) y asignado, sin salir de la conversación. El mismo Issue puede vincularse a múltiples conversaciones donde apareció el mismo problema, para que tu equipo tenga un ticket por causa raíz en lugar de uno por conversación. Todos los Issues se recopilan en una vista central en Fin AI Agent > Analyze > Monitors, donde puedes seguir el estado desde la presentación hasta la resolución.

Para detalles completos de configuración, consulta Rastrea y actúa sobre issues encontrados en revisiones QA de Monitor.

Cuando un monitor sigue mostrando el mismo problema, suele ser señal de que algo más grande necesita atención: un artículo del help center, un procedimiento de Fin o una guía que debe ajustarse.

Monitors son excelentes para identificar patrones en miles de conversaciones, pero no pueden decirte qué patrones realmente valen la pena actuar. Ahí entran los expertos humanos en producto. Usan su conocimiento y contexto para identificar la causa raíz, convertir esos hallazgos en recomendaciones accionables y asegurarse de que lleguen al equipo responsable de solucionarlos.

A medida que Fin mejora en encontrar patrones, el rol del experto en producto evoluciona. En lugar de pasar tiempo buscando problemas, pueden enfocarse en entender lo que los datos les dicen, decidir qué es lo más importante y promover mejoras significativas.