Primero, define el POC (Proof of Concept) como una tarea de negocio concreta y medible.
Las POC (Proof of Concept) deben seleccionarse para tareas que presenten reglas relativamente claras, un volumen de llamadas predecible, resultados que puedan ser verificados desde el backend, y que permitan la corrección en caso de errores. Por ejemplo, la creación de un ticket a partir de la recopilación de datos de reparación es más adecuada que "resolver todas las consultas de atención al cliente". Antes de comenzar, es fundamental definir claramente los puntos de entrada de la llamada, los campos necesarios, las acciones posibles, las acciones prohibidas, las condiciones para la transferencia a un agente, y quién proporciona la API y el entorno de pruebas de la empresa. Si no se pueden definir los límites del alcance, la verificación solo se convertirá en una evaluación subjetiva.
Primero, establecer los criterios para los procesos manuales, y luego discutir cómo la IA puede mejorarlos.
Sin un punto de referencia, es imposible determinar si el POC ha mejorado. Al menos, es necesario registrar quién está a cargo de cada tarea, cómo se define el éxito, los errores comunes, los tiempos de espera, los datos que requieren ser reingresados y cómo se solucionan manualmente. El punto de referencia no tiene que ser un KPI atractivo; un pequeño número de casos reales y verificados es más fiable que las suposiciones de los proveedores. Para una comparación formal, es necesario utilizar las mismas tareas, condiciones de llegada similares y una definición de éxito consistente.
Los casos de prueba con oro deben incluir rutas de ejecución para escenarios normales, ambiguos y de fallo.
Inicialmente, el equipo de ventas, atención al cliente y el responsable del sistema deben elaborar conjuntamente las entradas, las preguntas esperadas, los campos necesarios, las acciones permitidas y el estado final, y luego entregar estas indicaciones al sistema para su prueba. Es importante que los casos de prueba no se basen únicamente en la repetición de frases estándar, sino que incluyan variaciones en el habla del usuario, errores en los datos, palabras homófonas, ruido de fondo, silencio, interrupciones, retrasos en la API y la necesidad de interacción humana. Además, al tratar con nombres, direcciones, cantidades o información de identificación, se debe verificar si la IA repite la confirmación en lugar de simplemente comparar con el texto literal.
Matriz mínima de pruebas para un POC (prueba de concepto) de atención al cliente con IA y voz.| Contexto | Qué observar | Resultados verificables |
|---|
| Completado con éxito | Campos obligatorios, secuencia de preguntas y llamadas a herramientas. | La información de CRM/solicitudes/estado de asignación debe coincidir con el registro de llamadas. |
| Información confusa o alterada. | ¿Se confirma y se sobrescriben los valores anteriores? | Solo se conservarán los datos de confirmación finales, evitando la creación de duplicados. |
| Malinterpretación | Baja autoestima, necesidad de repetir preguntas y adaptación a condiciones laborales específicas. | El error no se ha registrado directamente en el sistema principal. |
| Error de tiempo de espera o rechazo de la API | Respuesta, reintento, pendiente y idempotencia | No se debe anunciar el éxito de forma prematura; es posible rastrear el estado final después. |
| Requisitos para personas reales o situaciones de alto riesgo | La ruta de conexión se establece en función del contexto. | Campos marcados como "confirmados" y problemas sin resolver (según la información proporcionada). |
Los indicadores deben estar relacionados con las tareas, y no solo deben enfocarse en la tasa de precisión.
La correcta identificación de la voz no garantiza el éxito de la tarea; incluso si hay errores en la transcripción, no necesariamente afectará el resultado. La verificación debe incluir la comprobación de la finalización de la tarea, la exactitud de los campos requeridos, el éxito de las llamadas a herramientas, la comprensión, la transición planificada, las actualizaciones inesperadas, la renuncia del usuario, la demora en las respuestas y la corrección manual. Cada uno de estos aspectos debe tener una base clara y fuentes de datos, por ejemplo, utilizando "una llamada de prueba que cumple con los requisitos" como base, y verificando cruzadamente mediante el registro de llamadas, eventos del modelo, registros de API y el estado final del sistema empresarial.
Desde la calidad de la conversación hasta la evaluación de los resultados del sistema.| Indicadores | Definición | Evitar errores de interpretación. |
|---|
| Porcentaje de tareas completadas | Porcentaje de llamadas que cumplen con el rango especificado y que tienen un estado final correcto. | No se puede considerar que la simple realización de una conversación cuenta como la finalización de una tarea. |
| Verificación de la exactitud de los campos obligatorios. | Campo de verificación y grado de coincidencia con la respuesta real. | El promedio no puede ocultar campos clave como la dirección o el importe. |
| La herramienta se ha ejecutado correctamente. | La API ha funcionado correctamente y no ha producido efectos secundarios duplicados o erróneos. | No se puede determinar directamente si una transacción en línea es un éxito o un fracaso debido a retrasos. |
| Malentendidos y estrategias de respaldo | El sistema no puede comprender ni procesar la frecuencia de las preguntas repetidas. | Es importante distinguir entre una indagación razonable y un ciclo inútil. |
| Intervención manual | Planificación de cambios, actualizaciones inesperadas y solicitudes proactivas del usuario. | La automatización no siempre es un fracaso; depende de las causas. |
Los criterios de puesta en producción deben ajustarse al costo de los errores
No existe una línea de corte única que se aplique a todos los teléfonos de IA. El costo de consultar los horarios y corregir los datos de pago es completamente diferente; incluso un error de un solo carácter en la dirección puede ser más grave que un tono de comunicación inapropiado. La estrategia es clasificar los errores en tres categorías: aquellos que pueden ser corregidos automáticamente, aquellos que requieren revisión manual y aquellos que no pueden ser automatizados. Luego, se establece un umbral y se designa a una persona responsable para cada categoría. Si la muestra de datos es insuficiente, solo se puede decir que el POC aún no ha identificado problemas específicos, y no se puede inferir que el entorno de producción cumplirá necesariamente con los requisitos.
La verificación de calidad también debe incluir pruebas de fallos para asegurar que el sistema pueda seguir funcionando correctamente después de una falla.
El servicio formal inevitablemente encontrará problemas como interrupciones de la red, retrasos en los modelos, errores en las API empresariales, falta de disponibilidad de agentes y mantenimiento del proveedor. Durante la fase de prueba (POC), es fundamental verificar qué tipo de fallo causa cada problema, en qué estado se encuentra la información, quién recibe la notificación y si es posible realizar una nueva prueba de forma segura después de la resolución. La interfaz de usuario y el panel de control deben mostrar claramente y de forma comprensible los errores, evitando que se ignoren y que el personal de atención al cliente crea que el problema ya ha sido resuelto.
GoGoCha no puede utilizarse como evidencia estructural, sino como datos de verificación generales.
GoGoCha ha publicado casos de éxito que demuestran que Falcon ha implementado funcionalidades como: acceso a llamadas con IA, backend de reparto compartido, gestión de colas, notificaciones en tiempo real, y la integración con sitios web, LINE, aplicaciones y paneles de administración. Sin embargo, estos casos no revelan métricas como la tasa de reconocimiento, el tiempo promedio de respuesta, la tasa de conexión, el ahorro de personal o los acuerdos de nivel de servicio (SLA) para llamadas. Por lo tanto, estos datos no pueden utilizarse para establecer estándares para otras empresas. La nueva prueba de concepto (POC) deberá ser realizada utilizando el entorno telefónico, el idioma del público objetivo y los datos de tareas de la empresa en cuestión.
¿Qué entregables se deben crear antes de pasar del POC (Proof of Concept) a la versión final?
Al menos, es necesario dejar documentados los siguientes aspectos: casos de prueba con versiones fijas, detalles de los resultados, riesgos no resueltos, arquitectura del sistema, flujo de datos, permisos, mecanismos de supervisión, procesos de intervención y recuperación manual. Además, la versión definitiva debe incluir pruebas de carga, sistemas PBX/SIP reales, redundancia, políticas de grabación y permisos de operación. El POC (Proof of Concept) solo indica que es viable continuar con el desarrollo, pero no implica que se pueda implementar directamente sin modificaciones.
