Cómo hacer un agente de postventa por WhatsApp con handoff humano

En 60 segundos: Construí un especialista de postventa para un alcance concreto: FAQ de activación, uso y cobertura, consultas de estado permitidas y un journey mínimo de bienvenida o activación. WhatsApp recibe la conversación, pero el CRM o back office conserva la cuenta, el producto, el caso y su resolución; una base aprobada conserva el conocimiento. Asigná control por acción: leer, recomendar, preparar o ejecutar dentro de límites verificables. Identidad ambigua, dato ausente, caso complejo o caída de una herramienta terminan en una cola humana con contexto. Durante dos semanas medí resoluciones sin humano, tiempo a primera respuesta, escalados por motivo y falsas resoluciones. No lo construyas sin sistema de registro, owner del conocimiento y canal humano.

Después de una venta llegan preguntas que se parecen en el chat y no en el trabajo: «¿cómo activo mi producto?», «¿dónde puedo usarlo?», «¿qué estado tiene mi cuenta?» o «seguí los pasos y no funciona». Una respuesta puede salir de una guía. Otra requiere identificar a la persona, consultar un sistema o abrir un caso. La última quizá necesite criterio y acceso que el agente no debe tener.

Un agente de postventa útil no intenta contener todas las conversaciones. Resuelve lo repetible con evidencia y entrega lo demás a una persona sin obligarla a empezar de cero. Es distinto del agente comercial de WhatsApp y CRM: el comercial identifica una necesidad y deja un próximo paso de venta; postventa atiende a alguien que ya tiene una relación, un producto o un servicio activo. Mezclar ambos jobs cruza datos, permisos y métricas.

1. Definí los jobs antes del canal

«Atender postventa» es demasiado amplio para probarlo y demasiado ambiguo para conceder permisos. La primera versión puede cubrir tres jobs:

1. Responder FAQ de activación, uso y cobertura. Recupera una respuesta aprobada, comprueba que aplica al producto y audiencia, y conserva la fuente y versión utilizadas.
2. Consultar estado de cuenta o producto. Devuelve solo los campos permitidos después de resolver identidad y autorización. Un estado desconocido no se convierte en una explicación inventada.
3. Guiar un journey mínimo. Puede acompañar bienvenida, activación y primer uso con pasos observables, o limitarse a reaccionar a preguntas. Definí cuál de las dos funciones existe: un journey proactivo introduce consentimiento, horarios, reintentos y reglas de parada que el soporte reactivo no necesita.

Elegí una población, un producto, un idioma, un horario y unas pocas intenciones. Escribí también el límite: reclamos formales, fraude, cancelaciones, cambios contractuales, ajustes de saldo y decisiones de cobertura pueden ir siempre a una persona o a otro equipo.

Cada conversación elegible debe terminar en un estado visible:

consulta elegible
  -> respuesta aprobada + resultado registrado
  -> aclaración solicitada + caso pendiente
  -> handoff humano + motivo, prioridad y owner

«El bot respondió» no demuestra que el caso quedó resuelto. La salida debe decir qué se entendió, qué evidencia se usó y quién continúa si todavía falta trabajo.

2. Separá canal, conocimiento y sistema de registro

WhatsApp aporta mensajes, hora e identificadores del canal. No debería decidir qué producto tiene una persona, cuál es el estado oficial de una activación ni si un incidente se cerró. La arquitectura de CRM como fuente de verdad y WhatsApp como canal aplica también después de la venta, aunque el registro operativo pueda ser un back office o una plataforma de soporte.

Dato o decisión	Fuente autorizada	Regla del agente
Identidad y relación con la cuenta	CRM, maestro de clientes o back office	Usar un match estable; si hay más de uno, limitar la respuesta y verificar
Producto, activación y estado	Sistema operativo responsable	Consultar el dato vigente y conservar hora y resultado de la consulta
Respuesta de activación, uso o cobertura	Base de conocimiento aprobada	Recuperar por producto, audiencia, idioma y versión; no completar huecos
Caso, prioridad, responsable y resolución	CRM, help desk o back office	Crear o actualizar un solo expediente con códigos de motivo estables
Conversación y entrega	WhatsApp Business Platform	Conservar IDs necesarios y contexto mínimo; no mantener un estado paralelo

La base de conocimiento tampoco se gobierna sola. Cada pieza necesita owner, audiencia, versión, fecha de revisión y condición de retirada. Si dos documentos vigentes se contradicen, el agente no elige por estilo: bloquea la respuesta y crea una excepción para el owner.

Guardá el mínimo contexto permitido. En muchos casos alcanza con IDs de correlación, intención, fuente consultada, resumen operativo y resultado. Copiar toda la conversación al CRM por defecto aumenta exposición y no mejora necesariamente la resolución.

3. Asigná control por acción

La autonomía pertenece a una acción, no al agente completo. El marco de copiloto o piloto automático ayuda a separar cuatro niveles:

Nivel	Qué puede hacer en postventa	Límite verificable
Leer	Consultar cuenta, producto, caso y documentos aprobados	Campos, audiencias y productos permitidos; acceso registrado
Recomendar	Clasificar intención, proponer una respuesta o un destino	Mostrar fuente, razón y datos faltantes; no modificar el caso
Preparar	Redactar el mensaje y armar la actualización exacta	Una persona revisa el mensaje y el payload; un cambio invalida la aprobación
Ejecutar	Enviar una respuesta o escribir un estado preaprobado	Identidad resuelta, política vigente, operación idempotente y reglas de parada

Una conversación puede mezclar niveles. El agente puede leer una guía, preparar una respuesta y registrar que entregó instrucciones; una persona decide una cancelación o un ajuste. No habilites acciones irreversibles solo porque la redacción tenga alta confianza. Cambiar titularidad, saldo, cobertura, contrato o estado final exige el control definido por el sistema responsable y, durante el piloto, revisión humana.

Empezá con un especialista. La comparación entre un agente generalista y agentes especializados explica por qué separar postventa, ventas, cobranzas y operaciones reduce cruces de contexto y permisos.

4. Dale tools estrechas y observables

El agente necesita pocas operaciones con entradas, salidas y errores explícitos:

1. Búsqueda en documentos aprobados. Filtra por producto, audiencia, región, idioma, versión y vigencia; devuelve fragmento, fuente y fecha de revisión. Un resultado vacío o contradictorio es un fallo utilizable, no permiso para improvisar.
2. Consulta de sistemas por audiencia. Recupera solo campos autorizados de cuenta, producto, activación o caso. La tool aplica control de acceso; el prompt no sustituye ese control.
3. Biblioteca de plantillas. Expone respuestas y solicitudes de aclaración aprobadas, con variables permitidas y tono por idioma. Mantiene separado el texto fijo de los datos consultados.
4. Handoff humano con contexto. Crea un caso en la cola correcta con identidad resuelta o pendiente, motivo, prioridad, evidencia, acciones ya intentadas, borrador y decisión necesaria. Devuelve un ID para escribirlo en el sistema de registro.

El adaptador de WhatsApp recibe y entrega mensajes, pero no contiene la política de soporte. Esa separación permite cambiar proveedor o canal sin reescribir reglas de identidad, conocimiento y escalado.

Tratá los errores de tools como estados del flujo. Definí timeout, reintentos acotados, idempotencia y circuit breaker. Una consulta vencida o una escritura sin confirmación no es una resolución.

5. Construí el flujo feliz como estados auditables

Probá primero una intención de bajo riesgo, por ejemplo una duda de activación de una persona ya identificada:

1. Recibir el evento y deduplicarlo por ID de mensaje.
2. Clasificar si pertenece al alcance de postventa sin decidir todavía la respuesta.
3. Resolver identidad, cuenta, producto y audiencia con una regla aprobada.
4. Leer casos abiertos, estado vigente y restricciones aplicables.
5. Recuperar contenido aprobado para esa intención, producto, audiencia e idioma.
6. Preparar la respuesta y la actualización propuesta del expediente.
7. Aplicar controles deterministas: vigencia, campos permitidos, estado compatible y ausencia de excepciones.
8. Ejecutar solo la acción autorizada o solicitar aprobación sobre el payload exacto.
9. Escribir resultado, fuente, mensaje y próximo estado en el sistema de registro; leer de vuelta la confirmación.
10. Detener cualquier secuencia previa cuando haya respuesta, handoff, opt-out, cierre o pausa manual.

Para un journey de bienvenida o activación, agregá hitos explícitos: invitación enviada, identidad verificada, activación iniciada, paso completado, bloqueo detectado y handoff. No midas progreso por cantidad de mensajes. Si el proceso solo debe reaccionar, no envíes recordatorios «útiles» sin una política de contacto.

6. Diseñá las excepciones antes de ampliar autonomía

Las excepciones son resultados operativos con owner y plazo, no conversaciones que el modelo «perdió».

Identidad ambigua

Un teléfono puede pertenecer a una empresa, familia o dispositivo compartido. Si aparecen varias cuentas o la verificación aprobada no coincide, el agente responde solo información pública o no sensible y pide el dato mínimo permitido. No muestra saldo, movimientos, producto contratado ni historial. El handoff conserva candidatos posibles sin fusionarlos.

Dato no encontrado o fuentes contradictorias

Si el back office no devuelve estado, la FAQ está vencida o dos documentos difieren, el agente explica que necesita validarlo y abre un caso. Registra las consultas realizadas, no convierte «sin resultado» en «no existe» y no atribuye la causa a un sistema sin evidencia.

Caso complejo o con consecuencias

Reclamos sensibles, fraude, cancelación, compensación, disputa de cobertura, cambio contractual o una persona molesta requieren criterio y autoridad. El agente reconoce la solicitud, evita prometer un resultado y entrega contexto, urgencia y decisión necesaria al equipo adecuado.

Saturación o caída de IA, canal o sistemas

Definí un modo degradado desde el día uno. Puede acusar recibo con una plantilla determinista, crear el caso y comunicar una expectativa aprobada; no debe repetir mensajes, cerrar casos ni afirmar que consultó datos inaccesibles. La cola necesita límites de capacidad, alertas y una ruta manual. Al recuperar el servicio, conciliá IDs y estados antes de reanudar.

Usá códigos estables para cada excepción. El revisor debe poder corregir intención, fuente, borrador y resolución, y esa corrección debe volver al expediente para evaluar reglas y contenido.

7. Incorporá el handoff humano desde el día uno

El handoff no es un botón genérico al final del chat. Definí:

• criterios de escalado: identidad no resuelta, fuente ausente, intención fuera de alcance, consecuencia alta, solicitud explícita de una persona, sentimiento crítico, fallo de tool o límite de tiempo;
• cola: equipo, prioridad, horario, capacidad, responsable, antigüedad y regla de reasignación;
• paquete de contexto: qué pidió la persona, qué identidad se resolvió, fuentes y sistemas consultados, datos faltantes, acciones intentadas, borrador y decisión necesaria;
• respuesta al usuario: confirmación clara de que el caso pasó a una persona, sin prometer un plazo que la operación no pueda cumplir; y
• writeback: ID del caso, motivo, owner, estado, decisión, respuesta enviada y resultado final en el sistema de registro.

La persona debe ver el contexto antes de responder y poder tomar la conversación sin competir con el agente. Una marca de human_owned bloquea nuevas respuestas automáticas hasta una devolución explícita. Cuando cierra o devuelve el caso, su decisión actualiza el SoR y, si corresponde, crea una tarea para corregir la base de conocimiento.

8. Ejecutá un piloto de dos semanas

Elegí un alcance que el equipo pueda revisar completo: un producto, una población, unas pocas intenciones y un horario. Tomá una línea base con la misma definición de conversación elegible y resolución que usará el piloto.

Semana 1: sombra y cobertura

• El agente clasifica, consulta y prepara; una persona aprueba cada respuesta y escritura.
• Revisá a diario identidad, fuentes usadas, consultas fallidas, motivos de escalado y borradores corregidos.
• Probá duplicados, mensajes fuera de orden, documento vencido, dato ausente, timeout, handoff y toma humana.
• Convertí correcciones repetidas en reglas o contenido con owner; no las escondas en un prompt más largo.

Semana 2: ejecución acotada

• Automatizá solo una respuesta repetible que haya mostrado fuentes claras y bajo riesgo en la primera semana.
• Mantené aprobación para identidad dudosa, consecuencias contractuales, reclamos complejos y cualquier escritura irreversible.
• Revisá cola, falsas resoluciones y fallos de control todos los días.
• Ensayá parada, modo degradado, recuperación y conciliación sin duplicar mensajes ni casos.

Usá métricas con numerador, denominador y criterio de revisión:

Métrica	Definición para el piloto
Resueltos sin humano	Conversaciones elegibles cerradas con respuesta verificada y sin intervención / conversaciones elegibles atendidas
Tiempo a primera respuesta	Mediana y percentil alto desde el mensaje elegible hasta una respuesta válida o un handoff confirmado
Escalados	Casos entregados a una persona / conversaciones elegibles, separados por motivo y antigüedad
Falsas resoluciones	Casos marcados como resueltos que reabren, se corrigen o fallan en revisión / casos marcados como resueltos
Corrección humana	Intenciones, respuestas o writebacks modificados / propuestas revisadas
Fallos de control	Exposición indebida, duplicados, mensajes después del handoff o escrituras sin confirmación

Segmentá por intención, producto y causa. Un handoff correcto no es fracaso; una conversación contenida con una respuesta equivocada tampoco es éxito. Dos semanas sirven para validar cobertura, operación y límites, no para prometer ROI. El coste real de un agente de IA debe incluir modelo, tools, canal, infraestructura, supervisión, mantenimiento y error con datos del piloto.

9. Reconocé cuándo no construirlo

No construyas el agente todavía cuando:

• no existe CRM, back office o sistema equivalente que conserve cuenta, producto, caso y resolución;
• nadie es owner de las FAQ, políticas, versiones y fechas de revisión;
• no hay canal humano, cola operativa ni responsable de las excepciones;
• la identidad no puede verificarse con una regla segura para los datos que se quieren mostrar;
• el equipo no puede definir qué significa resuelto ni corregir una falsa resolución;
• la demanda es tan baja o variable que una bandeja bien gestionada resulta más simple;
• el proceso depende de decisiones contractuales o de cobertura que todavía no están escritas; o
• no existe forma de pausar el agente, revocar accesos y recuperar la operación manualmente.

Si falta alguno de esos contratos, empezá por ordenar el registro, asignar ownership del conocimiento y diseñar el handoff. Si el trabajo real es captar y calificar oportunidades, usá el playbook del agente comercial; no amplíes postventa hasta convertirla en un generalista con permisos mezclados.

Kiia puede mapear un journey de postventa, separar canal y fuente de verdad, y montar un piloto con permisos y métricas observables. Conocé nuestro enfoque de integración de sistemas y llevá diez casos recientes, incluidos los que terminaron en handoff: ahí aparecen el alcance y las excepciones reales.