Respuesta corta
Un chatbot para PQR por WhatsApp recibe la solicitud, identifica el tipo de caso, solicita los datos necesarios, crea un registro y entrega un número de seguimiento. Su función no es impedir que el cliente hable con una persona, sino organizar la conversación para que el equipo pueda resolverla con contexto.
Qué problema resuelve
En muchas empresas las PQR llegan a varios números, correos y chats. Una persona copia los datos en una hoja, pregunta de nuevo lo que ya dijo el cliente y luego busca a quién corresponde el caso. El tiempo de respuesta aumenta y es difícil saber qué ocurrió.
Un agente bien diseñado reduce esa fricción. Puede reconocer si el mensaje es una petición, una queja, un reclamo o una consulta; confirmar identidad cuando sea necesario; reunir soportes; consultar el estado de un caso y escalar situaciones sensibles.
Flujo recomendado
- Reconocer la intención. El agente explica qué puede hacer y pregunta por el motivo principal.
- Solicitar solo lo necesario. Los datos dependen del proceso y de la política de privacidad de la empresa.
- Confirmar antes de registrar. Resume la solicitud para que la persona corrija errores.
- Crear el caso. Envía la información al CRM, mesa de ayuda o sistema de PQR.
- Entregar seguimiento. Comparte un identificador y explica el siguiente paso.
- Escalar con contexto. Si interviene un asesor, recibe el resumen y los datos ya aportados.
Qué no debería hacer
Un chatbot no debería prometer una solución que el sistema no confirmó, inventar estados ni interpretar una política fuera de las fuentes aprobadas. Tampoco debería ocultar la opción de atención humana cuando el caso involucra dinero, seguridad, datos personales o una excepción.
Datos e integraciones
La integración mínima suele incluir WhatsApp Business Platform, un repositorio de respuestas vigentes y el sistema donde se registran los casos. Si la empresa no tiene mesa de ayuda, puede empezar con una base estructurada y reglas de asignación, pero debe definir responsables, estados y tiempos de atención.
Antes de automatizar conviene revisar qué información se solicita, cuánto tiempo se conserva y quién puede verla. La automatización no elimina las obligaciones de privacidad ni las reglas internas.
Cómo medirlo
Empieza con cuatro indicadores: porcentaje de solicitudes correctamente clasificadas, casos creados sin datos faltantes, tiempo hasta la primera respuesta útil y porcentaje de escalamiento. La meta no es evitar todas las conversaciones humanas; es reservarlas para los casos que realmente necesitan criterio.
Primer paso
Reúne entre 50 y 100 conversaciones reales, elimina datos personales y clasifica las preguntas, datos faltantes y motivos de escalamiento. Ese material permite diseñar un prototipo mucho más confiable que una lista de preguntas imaginadas.
Si quieres convertir tu proceso de PQR en un flujo medible, Solventio puede ayudarte a mapearlo, prototiparlo e integrarlo con tus sistemas.
Diseño operativo antes de programar
La calidad del agente depende más de la operación que del modelo de IA. Antes de escribir una respuesta automática, dibuja el recorrido completo de una PQR: canal de entrada, datos mínimos, responsable, prioridad, estados posibles, tiempo de atención y forma de cierre. Señala también qué sucede cuando falta información, el sistema está caído o la solicitud pertenece a otra área.
Construye una matriz con intención, evidencia necesaria, sistema de destino y criterio de escalamiento. Una queja por calidad, una petición de información y un reclamo por cobro no deberían pedir los mismos campos. Si el flujo obliga a todas las personas a completar un formulario idéntico, la automatización traslada la burocracia al chat.
Ejemplo de conversación bien resuelta
Una persona escribe: “Me cobraron dos veces y necesito ayuda”. El agente identifica un posible reclamo de facturación, explica que recopilará datos para registrar el caso y solicita únicamente el identificador de la compra y una forma segura de validar al cliente. Después resume: “Entiendo que ves dos cargos asociados a la misma compra”. La persona confirma, el sistema crea el ticket y devuelve el número real del caso.
Si el registro falla, el agente no dice que quedó creado. Informa el problema, conserva el contexto permitido y ofrece una ruta alternativa. Si aparece una amenaza, un dato sensible o una excepción definida por la empresa, transfiere la conversación con un resumen. Esa honestidad operativa genera más confianza que una respuesta inmediata pero falsa.
Lista de información para el equipo del proyecto
- Catálogo actualizado de motivos y submotivos.
- Reglas para identificar al cliente sin pedir datos innecesarios.
- Campos obligatorios del sistema de casos.
- Horarios, responsables y acuerdos internos de atención.
- Mensajes aprobados para recepción, seguimiento, errores y cierre.
- Casos que requieren intervención humana inmediata.
- Política de conservación y eliminación de adjuntos.
- Canal alternativo cuando WhatsApp o la integración no están disponibles.
Cada elemento debe tener un dueño. El agente no puede mantener vigente una política si nadie en la empresa se responsabiliza de actualizarla.
Pruebas que revelan problemas reales
No pruebes únicamente preguntas perfectas. Incluye mensajes largos, audios transcritos con errores, varios problemas en una sola conversación, datos incompletos, clientes molestos y solicitudes fuera de horario. Repite el mismo envío para comprobar que no se crean tickets duplicados. Cambia de intención a mitad del flujo y verifica que el agente confirme antes de registrar.
Evalúa una muestra con personas del área, no solo con el equipo técnico. Para cada conversación registra si la clasificación fue correcta, si solicitó datos pertinentes, si la respuesta correspondió a una fuente vigente y si el escalamiento entregó contexto suficiente. Los errores deben convertirse en nuevas pruebas de regresión.
Plan de implementación en cuatro etapas
Primero automatiza la recepción y clasificación, manteniendo la resolución en manos del equipo. Luego conecta la creación del caso y valida identificadores. En una tercera etapa habilita consultas de estado con controles de identidad. Solo después incorpora respuestas automáticas para motivos frecuentes y bien documentados.
Este orden permite aprender sin entregar demasiado control desde el inicio. Además, muestra dónde está el cuello de botella verdadero: puede que recibir la PQR sea fácil y que el retraso esté en la asignación o aprobación interna. En ese caso, el siguiente esfuerzo debe mejorar la operación, no añadir más conversación automática.
Preguntas para decidir si estás listo
¿Existe una fuente única de estados? ¿Los responsables aceptan las reglas de asignación? ¿La empresa puede explicar qué datos usa y por cuánto tiempo? ¿Hay una salida humana visible? ¿El sistema confirma cada escritura? Si alguna respuesta es “no”, conviene resolverla en el piloto. Un chatbot de PQR exitoso no es el que habla más: es el que deja cada solicitud mejor organizada, verificable y encaminada que cuando llegó.