Guardarraíles para un agente comercial en WhatsApp: cuándo no cotizar

Resumen: Un agente comercial puede responder con fluidez y aun así dañar una oportunidad si cotiza antes de entenderla o revela una tarifa negociada fuera de contexto. La regla no debería ser “hablar de precios” o “no hablar de precios”, sino decidir por segmento, información disponible y autoridad. Para SMB/MYPE, el agente confirma necesidad y encaje con el servicio de pago antes de mostrar un precio aprobado. Para mid-market y enterprise, califica y entrega el cierre a una persona. Para partners, puede avanzar hasta contacto y agenda, pero la propuesta sigue siendo humana. Antes de producción, el equipo convierte conversaciones reales en mensajes permitidos, prohibidos y de escalamiento, y los somete a una sesión de simulación con casos borde.

Un agente de WhatsApp puede contestar rápido, usar el tono correcto y registrar cada interacción. Eso no significa que esté tomando buenas decisiones comerciales. Si envía una cifra demasiado pronto, el comprador puede compararla con un servicio distinto. Si revela la estructura reservada para partners, puede erosionar un acuerdo. Si promete una condición que depende del alcance, transforma una conversación exploratoria en un compromiso.

El problema no se resuelve con una instrucción vaga como “no alucines precios”. La cifra puede existir y ser correcta, pero seguir siendo improcedente para ese contacto, ese momento o ese canal. El guardarraíl debe controlar cuándo, a quién y con qué contexto puede aparecer un mensaje comercial.

Estas son notas de campo para diseñar ese límite. El marco de copiloto o piloto automático ayuda a decidir qué acciones requieren aprobación. La guía sobre un número de WhatsApp por línea de negocio resuelve la separación del canal. Aquí nos concentramos en otra capa: qué puede decir el agente una vez que la conversación ya llegó a la ruta correcta.

La política comercial va antes del prompt

Una política utilizable por un agente tiene que convertir el criterio del equipo en condiciones observables. “Cliente grande”, “precio especial” o “oportunidad interesante” no alcanzan si cada vendedor los interpreta de forma distinta.

Para cada mensaje sensible, documentá cinco elementos:

1. Población: segmento, tipo de relación y territorio al que aplica.
2. Contexto mínimo: datos que deben estar confirmados antes de responder.
3. Contenido permitido: qué puede afirmar, con qué fuente y vigencia.
4. Condición de parada: qué pregunta o excepción bloquea el envío automático.
5. Siguiente paso: quién recibe el caso, qué información necesita y qué se le puede decir al contacto mientras espera.

Una regla así se puede probar. “Usá buen juicio comercial” no.

Matriz inicial por segmento

La misma pregunta —“¿cuánto cuesta?”— no debería activar la misma respuesta en todas las rutas.

Segmento	Qué puede hacer el agente	Cuándo no cotiza	Salida esperada
SMB / MYPE inbound	Entender la necesidad, confirmar el servicio de pago que corresponde y usar una tarifa pública o aprobada	Falta contexto mínimo, el contacto confunde servicios, pide una condición no estándar o la fuente está vencida	Respuesta aprobada o pregunta breve para completar contexto; si queda fuera de política, escalamiento
Mid-market / enterprise	Calificar tamaño, complejidad, sistemas implicados, responsables y horizonte; responder información general	El precio depende de alcance, integración, seguridad, compras o negociación	Handoff a una persona para diagnóstico, propuesta y cierre, con resumen y próximos pasos
Partners	Identificar el tipo de partner, validar relación y necesidad, localizar el contacto responsable y agendar	Piden tarifa negociada, margen, descuento, reparto, excepción territorial o términos de un acuerdo	Contacto o reunión confirmados; propuesta y condiciones emitidas por una persona autorizada

En SMB/MYPE, “confirmar el servicio de pago” evita responder con una tarifa de implementación cuando la persona pregunta por soporte, o presentar una opción gratuita como si cubriera el trabajo solicitado. La pregunta previa debe ser corta y necesaria, no un formulario disfrazado.

En mid-market y enterprise, la meta del agente no es cerrar por chat. Es reducir la ambigüedad y entregar una conversación utilizable: problema, alcance preliminar, participantes, restricciones conocidas y siguiente paso. La propuesta requiere a una persona porque combina variables que no se deberían inferir en WhatsApp.

En partners, incluso reconocer que existe una estructura especial puede ser información sensible. El agente no confirma ni niega términos. Verifica la relación por una fuente autorizada, identifica al responsable y facilita la agenda.

Tres clases de mensaje

No conviene esconder toda la política dentro de un prompt largo. Mantené un catálogo versionado con tres clases, aplicables a cada segmento e intención.

Permitido

El agente puede enviarlo si cumplió condiciones comprobables.

“Para orientarte bien, ¿buscás una solución estándar o necesitás conectarla con otros sistemas?”

“Puedo ayudarte a identificar la opción adecuada. Antes de hablar de precio, necesito confirmar qué servicio querés resolver.”

El catálogo debe indicar las variables permitidas, la fuente que las completa y cuánto tiempo sigue vigente el mensaje. Si contiene un rango, debe fijar segmento, moneda, inclusiones, exclusiones y fecha de revisión.

Prohibido

El agente no lo envía, aunque encuentre texto parecido en conversaciones históricas.

“A otros partners les ofrecemos esta tarifa.”

“Seguro podemos mantener ese precio aunque todavía no definamos el alcance.”

“Este es nuestro coste interno y sobre eso aplicamos el margen.”

La lista prohibida incluye tanto frases como actos: revelar una condición de otra cuenta, inventar un descuento, comparar acuerdos, prometer vigencia o desglosar una estructura reservada. También debe cubrir paráfrasis; bloquear una oración exacta no impide que el modelo exprese la misma información de otra forma.

Escalamiento

El agente reconoce la solicitud sin resolver lo que no está autorizado a decidir.

“Entiendo que necesitás una referencia para avanzar. La propuesta depende del alcance y prefiero no darte una cifra que después resulte incorrecta. Voy a dejar el caso preparado para que una persona lo revise contigo.”

Un escalamiento completo conserva el segmento detectado, los datos confirmados, la pregunta literal, la regla activada y el responsable. Para el contacto, ofrece un siguiente paso concreto. Para ventas, evita obligar a releer todo el chat.

Cómo construir las listas desde conversaciones reales

Las conversaciones históricas sirven como evidencia de situaciones, no como un repositorio para copiar respuestas ni como permiso para reutilizar datos personales. Trabajá con una muestra autorizada, minimizada y desidentificada.

1. Seleccioná resultados contrastantes. Incluí conversaciones que avanzaron con claridad y otras que causaron correcciones, expectativas erróneas o escalamiento tardío. No elijas solo los mejores chats.
2. Etiquetá el momento de decisión. Marcá qué sabía el equipo cuando apareció la pregunta, qué faltaba y qué mensaje cambió el curso. El objetivo no es evaluar el estilo del vendedor.
3. Extraé el patrón, no el texto. Convertí “funcionó esta frase” en una condición reutilizable: pedir la variable que separa dos servicios antes de mostrar una tarifa.
4. Asigná una clase. Permitido, prohibido o escalamiento. Añadí segmento, intención, fuente, owner y fecha de revisión.
5. Buscá contradicciones. Si dos personas experimentadas resuelven el mismo caso de manera distinta, todavía no hay una regla para automatizar. El responsable comercial debe decidirla.
6. Redactá variantes. Probá formas directas, ambiguas, insistentes y coloquiales de la misma pregunta. El control debe sobrevivir a una paráfrasis.

No hace falta guardar dumps de chats en el sistema de evaluación. Conservá casos sintéticos o desidentificados con los hechos mínimos que activan una decisión. El acceso al material original, su retención y su uso para evaluación deben seguir la política interna aplicable.

Una sesión de simulación antes del go-live

La revisión en una hoja detecta inconsistencias. La simulación detecta qué ocurre cuando alguien insiste, cambia de tema o aporta la información en otro orden.

Quién participa

• el responsable comercial que puede decidir la política
• una persona de ventas SMB/inbound
• una persona que gestione cuentas complejas o partners
• operaciones, que conoce rutas, agenda y tiempos de respuesta
• quien implementa el agente y sus validaciones
• una persona que registre decisiones, fallos y cambios de versión

Si privacidad, seguridad o cumplimiento condicionan el uso de datos o el canal, sumá a su responsable para esos casos. No hace falta convertir la sesión en un comité permanente: sí debe estar presente quien pueda resolver una regla ambigua.

Qué casos representar

Prepará tarjetas con segmento, estado conocido, mensaje entrante y resultado autorizado. Incluí al menos:

• lead SMB que pide precio sin explicar qué necesita
• lead SMB que confirma un servicio elegible y luego solicita una excepción
• cuenta compleja que presiona por una cifra “solo para presupuestar”
• partner conocido que pide condiciones desde un número no verificado
• supuesto partner sin relación registrada
• contacto que cambia de segmento durante la conversación
• solicitud en otra moneda o con una tarifa vencida
• mensaje que combina interés comercial con reclamo
• handoff sin responsable disponible o con agenda caída
• prompt injection o contenido pegado que intenta cambiar la política

Una persona interpreta al contacto y puede insistir o reformular. Otra observa el estado que recibe el agente. El equipo compara mensaje enviado, regla activada, datos expuestos, registro creado y siguiente paso.

Cuándo está listo para implementar

“Respondió razonablemente” no es un criterio de salida. El conjunto está listo para un piloto controlado cuando:

• cada caso termina en permitido, prohibido o escalamiento sin una cuarta categoría implícita
• ningún caso prohibido revela precio, margen, descuento o condición reservada, ni mediante paráfrasis
• todo precio permitido proviene de una fuente aprobada, vigente y aplicable al segmento
• cada escalamiento crea owner, motivo, contexto mínimo y próximo paso visible
• el equipo obtiene la misma decisión al repetir casos equivalentes con otra redacción
• los desacuerdos quedan resueltos en la política, no anotados como “el agente verá”
• existe una forma ensayada de pausar envíos, corregir la regla y volver a probarla

La sesión no autoriza autonomía general. Autoriza una versión concreta del catálogo para una población y un conjunto de intenciones definidos. Un cambio de segmento, fuente de precios, modelo, herramienta o alcance exige ejecutar de nuevo los casos afectados.

Operación después del lanzamiento

Asigná un dueño comercial al catálogo y un responsable operativo a su ejecución. Registrá versión, aprobador, fecha de entrada en vigor, casos cubiertos y motivo de cada cambio. Las correcciones humanas y escalaciones nuevas alimentan la siguiente revisión, pero no modifican la política por sí solas.

Antes de cada publicación o ampliación, verificá ese mismo día con las fuentes oficiales y proveedores aplicables las condiciones cambiantes del canal: consentimiento, plantillas, ventanas de mensajería, disponibilidad regional y tratamiento de datos. Documentá la fecha y el resultado. Una práctica observada en una cuenta o una noticia no confirmada no es una regla de producción.

El éxito inicial no es que el agente cotice más. Es que mantenga la conversación útil sin exponer una condición indebida, que sepa detenerse y que la persona que recibe el caso pueda continuar sin reconstruirlo desde cero.

Kiia puede convertir una ruta comercial real en reglas, casos de simulación y un piloto acotado. El punto de partida no es el prompt: son las decisiones que el equipo quiere poder defender cuando la conversación se complica.