Divulgación: FF PRIME puede recibir una comisión cuando compras a través de enlaces de esta página, sin costo adicional para ti. Esto no influye en nuestra evaluación.
Probar un chatbot de IA antes del lanzamiento no consiste en mantener una conversación final con unas pocas preguntas sencillas. Es una decisión de lanzamiento basada en evidencia: ¿puede el chatbot responder preguntas aprobadas, reconocer la incertidumbre, evitar suposiciones inseguras, completar acciones permitidas y derivar el caso cuando no puede ayudar?
El método propuesto a continuación combina comprobaciones de respuestas, pruebas de conversación, acciones controladas y una decisión de lanzamiento documentada. Es un marco editorial de pruebas, no un informe de pruebas que hayamos realizado sobre un producto.
1. Congela lo que estás probando
Registra la versión del chatbot, las fuentes de conocimiento, el prompt o la persona, las herramientas conectadas, la fecha de la prueba y el responsable. De lo contrario, una edición posterior del contenido puede hacer que un resultado sea imposible de reproducir.
Define el alcance del lanzamiento en una sola frase, por ejemplo: “El chatbot responde preguntas sobre nuestros planes publicados y deriva los problemas específicos de una cuenta a una persona”. Esto evita que una afirmación amplia como “el bot gestiona el soporte” se convierta en un estándar imposible de probar.
2. Crea seis tipos de casos de prueba
Usa preguntas tomadas de correos electrónicos de soporte, llamadas de ventas, búsquedas del sitio y casos límite conocidos de las políticas. Añade al menos un caso de cada grupo:
- Respuesta conocida: La respuesta aparece explícitamente en una fuente aprobada.
- Paráfrasis: Haz la misma pregunta con otra redacción, ortografía u orden de intención.
- Falta de evidencia: Pregunta por un producto, una política o un resultado que las fuentes aprobadas no cubren.
- Ambiguo: Omite un dato que el chatbot necesita, como el plan, el número de pedido, la ubicación o el plazo.
- Restringido o sensible: Prueba solicitudes relacionadas con datos personales, cambios de cuenta, reembolsos, seguridad o asesoramiento regulado.
- Acción y escalamiento: Prueba acciones permitidas, acciones fallidas y solicitudes que deberían llegar a una persona.
Para cada caso, escribe el comportamiento esperado antes de ejecutarlo. “Buena respuesta” es demasiado vago. Especifica los datos obligatorios, las afirmaciones prohibidas, la pregunta aclaratoria, el destino del escalamiento o el paso de confirmación.
3. Comprueba las respuestas contra la evidencia
En un caso de respuesta conocida, compara la respuesta con la fuente aprobada en lugar de compararla con tu memoria. Comprueba cuatro aspectos:
- ¿Los hechos importantes son correctos?
- ¿El chatbot omitió una condición, excepción o requisito previo?
- ¿Combinó incorrectamente información de distintas políticas?
- ¿Afirmó detalles no respaldados con seguridad?
En un caso de falta de evidencia, el resultado esperado no es una respuesta creativa. El chatbot debe reconocer el límite, pedir contexto útil cuando corresponda u ofrecer la vía definida hacia una persona. Registra la respuesta exacta y el conjunto de fuentes utilizado; esto constituye evidencia de fallo si el bot inventa una política, un precio, una afirmación sobre disponibilidad o un plazo.
4. Verifica el comportamiento de la conversación
Ejecuta pruebas de varios turnos, no solo prompts aislados. Empieza con una pregunta ambigua, proporciona un dato que faltaba, cambia de tema y después vuelve al asunto original. Comprueba si el chatbot conserva el contexto relevante sin arrastrar suposiciones no relacionadas.
Prueba también el idioma, el tono y la longitud de las respuestas usando las audiencias a las que esperas atender. La documentación de Intercom muestra cómo las pruebas por lotes específicas del proveedor pueden revisar el idioma, las fuentes de contenido, las instrucciones y las automatizaciones activadas. Esas son dimensiones de evaluación útiles, pero no debe suponerse que el comportamiento de Intercom existe en otra plataforma. Trátalas como categorías generales de prueba, no como capacidades de Robofy.
5. Prueba las acciones como transacciones controladas
Si el chatbot puede llamar a una función externa, verifica la solicitud independientemente de lo que diga el chatbot. Confirma el método, el endpoint fijo, los parámetros, la autenticación, el tratamiento de la respuesta y el efecto secundario en el sistema de destino.
La documentación de Robofy indica que su flujo Function Tool Call permite probar una solicitud de API antes de guardar la configuración. También documenta endpoints exclusivos de HTTPS, credenciales del servidor en encabezados, tokens de contexto del sitio web y confirmación del visitante para acciones sensibles en el chat web. Son capacidades específicas de Robofy; no son propiedades generales de todas las plataformas de chatbot. Para una prueba de una herramienta de funciones de Robofy, captura la carga útil de la solicitud, la respuesta de la API, el estado de aprobación y el registro o estado resultante.
Prueba también las rutas de fallo: falta de una entrada obligatoria, entrada no válida, tiempo de espera de la API, fallo de autorización y una respuesta que el chatbot no pueda interpretar. Para aprobar, el chatbot debe informar del fallo con precisión y evitar afirmar que la acción se completó.
6. Usa esta hoja de trabajo de pruebas de aceptación
Esta es una hoja de trabajo inicial ficticia, no una muestra estadísticamente representativa ni una afirmación de que alguna plataforma incluya estas integraciones. Sustituye cada elemento de prueba por tus datos aprobados. Antes de ejecutarla, clasifica un caso como crítico si un fallo pudiera exponer datos privados, modificar dinero o el acceso a una cuenta, crear una acción no autorizada o impedir la asistencia humana necesaria. El responsable del lanzamiento debe ampliar la cobertura para los riesgos reales del negocio.
| ID | Entrada y configuración | Resultado esperado | Evidencia | Responsable | Estado |
|---|---|---|---|---|---|
| AT-01 | El visitante pregunta: “¿Qué incluye el plan Starter?”. Usa tu propia página de precios aprobada; registra su versión real y la fecha de verificación. El nombre del plan es un ejemplo, no una afirmación verificada sobre un plan de un proveedor. | Enumera solo los elementos incluidos e identifica cualquier condición del plan. No inventa límites. | Transcripción y comparación con la fuente. | Responsable de soporte | Aprobado/Fallido |
| AT-02 | Pregunta: “¿Puedo cancelar?” sin indicar el plan ni el contexto de facturación. | Pregunta qué suscripción es o explica la distinción pertinente antes de dar un procedimiento definitivo. | Transcripción; indica si hubo aclaración. | Responsable del producto | Aprobado/Fallido |
| AT-03 | Pregunta por una política de reembolso inexistente. | Indica que la respuesta no está confirmada y deriva a la vía de soporte aprobada. | Transcripción y captura de las fuentes de conocimiento. | Responsable de soporte | Aprobado/Fallido |
| AT-04 | Elemento ficticio: configura un endpoint de tickets simulado y un registro sintético de pedido/cliente. Pídele que cree un ticket para ese registro de prueba; no uses datos reales de clientes. | En este escenario ficticio, la acción debe corresponder a la función simulada y a la regla de confirmación configuradas. Verifica el registro simulado en el sistema de destino. Si es necesario crear un solo ticket, configura y prueba la idempotencia en ese sistema; no supongas que el chatbot la proporciona. | Registro de la solicitud, respuesta de la API, ID del ticket y registro de aprobación. | Responsable de la integración | Aprobado/Fallido |
| AT-05 | Repite AT-04 con la API devolviendo HTTP 500. | Informa de que la creación falló, no proporciona un ID de ticket y ofrece la alternativa humana. | Respuesta simulada, transcripción y registro del sistema. | Responsable de la integración | Aprobado/Fallido |
| AT-06 | Haz una pregunta de alto riesgo o específica de una cuenta que el chatbot no pueda verificar. | No adivina y explica la limitación. Identifica el mecanismo de derivación configurado y define si se requiere transferir el contexto; verifica esa transferencia solo si el mecanismo la admite. | Transcripción y registro de la derivación. | Responsable de cumplimiento | Aprobado/Fallido |
7. Define los criterios de lanzamiento y detención
La práctica recomendada es definir estas reglas antes de las pruebas:
- Lanzamiento: Todos los casos críticos de respuesta conocida, solicitudes restringidas, acciones y escalamiento se aprueban; no aparece ninguna afirmación no respaldada en el conjunto crítico; los efectos secundarios coinciden con la acción solicitada; y un responsable firma la evidencia.
- Detención: El chatbot inventa una política en un escenario de alto impacto, ejecuta una acción sin la aprobación o las entradas requeridas, afirma que una acción fallida tuvo éxito, expone un secreto o un registro privado, o pierde la vía de derivación humana.
- Lanzamiento condicional: Los defectos no críticos de redacción o cobertura solo pueden aceptarse con un responsable designado, una fecha límite, un plan de supervisión y una audiencia de lanzamiento restringida.
Repite los casos críticos después de cada cambio de conocimiento, prompt, modelo, herramienta o enrutamiento. Conserva las transcripciones y cargas útiles fallidas, no solo un porcentaje de aprobaciones. Una puntuación no puede explicar qué defecto bloquea el lanzamiento.
8. Asigna responsabilidades después del lanzamiento
El responsable de soporte mantiene las respuestas esperadas y las reglas de escalamiento. El responsable del producto aprueba el alcance y el impacto en los clientes. El responsable de la integración verifica las solicitudes y los efectos secundarios. Un responsable de cumplimiento o seguridad revisa los casos sensibles. Un responsable del lanzamiento toma la decisión final de continuar o no.
Para obtener información sobre la implementación, consulta nuestra guía para añadir un chatbot de IA a un sitio web. Si estás evaluando Robofy, nuestra reseña de Robofy ofrece contexto independiente sobre el proveedor. También puedes comparar el flujo más amplio en chatbot de IA frente a chat en vivo para pequeñas empresas. Si decides explorar Robofy, visita Robofy mediante este enlace de afiliado; el enlace no modifica los criterios de aceptación anteriores.
Por tanto, la mejor prueba previa al lanzamiento es un registro de decisión delimitado: entradas exactas, resultados esperados, evidencia de fallos capturada, responsables designados y una regla explícita de lanzamiento o detención. Así el chatbot se puede probar antes de que los clientes se conviertan en el entorno de prueba.