Cómo se arma el caso de negocio
Un caso de negocio para WhatsApp multiagente conectado a CRM se sostiene en cuatro partes: situación actual con cifras, alcance propuesto, beneficios esperados y riesgos aceptados. Si falta una, la conversación se convierte en una discusión de opiniones.
El punto de partida es dos ejecutivos pueden responder al mismo lead o dejarlo sin responsable, descrito con datos de la propia empresa y no con estimaciones genéricas del sector. Las cifras propias, aunque imperfectas, resisten mejor las preguntas.
Línea base y supuestos
La línea base se construye con lo que hoy se puede medir: volumen de casos, tiempo de primera respuesta, correcciones, oportunidades perdidas. No necesita ser exacta, necesita ser comparable después.
Los supuestos se escriben aparte y con nombre: de dónde sale cada número, qué se asume constante y qué podría cambiarlo. Un supuesto explícito se discute; uno escondido se descubre tarde.
Para comprender mejor esta decisión, puedes profundizar en bot, chatbot o agente de IA para WhatsApp.
Beneficios que se pueden medir
Los beneficios defendibles en este tipo de proyecto son tiempo de asignación, duplicados y cargas por ejecutivo. Se expresan como variación frente a la línea base, con un plazo y un responsable de medirlos.
Los beneficios que no se pueden medir conviene declararlos como tales. Prometer mejoras que nadie va a verificar es la forma más rápida de perder credibilidad en la siguiente revisión.
Costos que suelen omitirse
Además de licencias e implementación, el presupuesto debería incluir el tiempo del equipo interno, la mantención de contenido, la capacitación y la revisión periódica. Son costos reales y casi nunca aparecen en la cotización inicial.
En este caso la integración con bandeja multiagente, asignación, SLA y sincronización CRM es la partida que más varía: depende de cuántos sistemas haya que conectar y de la calidad del acceso disponible.
Cómo presentarlo para que se apruebe
Presenta primero el problema y su costo, después el alcance acotado y recién entonces la solución. Un comité decide sobre el problema que reconoce, no sobre la arquitectura que se le muestra.
Ayuda proponer una primera etapa verificable: una conversación completa desde el primer mensaje hasta la actualización del CRM. Un alcance pequeño con criterio de éxito claro se aprueba más rápido que un proyecto amplio con beneficios difusos.
Este paso se relaciona directamente con nuestra guía sobre WhatsApp Cloud API directa vs BSP en Chile.
Riesgos que el comité querrá ver
Declara el riesgo principal (definir propiedad de la conversación y recuperación ante fallos) junto con su mitigación. Un riesgo reconocido y acotado genera más confianza que una lista de certezas sin respaldo.
Incluye también el riesgo de adopción: qué pasa si el equipo no lo usa. Es el más frecuente y el que menos aparece en los documentos de proyecto.
Revisión del caso a los seis meses
A los seis meses corresponde comparar lo prometido con lo medido: indicadores, costo real, horas internas consumidas y excepciones atendidas. La comparación se hace contra los supuestos escritos, no contra el recuerdo de la reunión.
De ahí salen tres decisiones posibles: continuar, corregir el alcance o detener. Las tres son resultados legítimos y conviene decirlo así desde el principio, porque reduce la presión por defender una inversión que ya no se justifica.
Si quieres llevar este criterio a la práctica, consulta cómo automatizar WhatsApp Business en Chile.
Cómo se trabaja este caso con Sysora
Sysora comienza con una sesión de descubrimiento junto a quienes ejecutan el proceso. Documentamos preguntas frecuentes, fuentes autorizadas, datos mínimos, responsables, excepciones y resultados esperados. Después construimos un flujo acotado, lo probamos con escenarios reales anonimizados y dejamos visible la transferencia a una persona cuando falta información o se alcanza un límite.
La entrega incluye reglas operativas, accesos administrados por la empresa, registro de eventos y métricas comparables con la línea base. Durante el lanzamiento revisamos errores y decisiones corregidas con el equipo, incluyendo los casos que la automatización no pudo resolver. La solución se amplía cuando demuestra valor sin aumentar reclamos ni trabajo posterior, de modo que la empresa pueda entenderla, supervisarla y mejorarla sin depender de una demostración técnica.
También dejamos un criterio de decisión para el siguiente ciclo: qué señal justificaría ampliar el alcance, qué indicador obligaría a corregirlo y qué situaciones deben seguir atendidas por una persona. Así, la capacidad se integra al trabajo cotidiano como algo gobernado y no como un experimento separado de ventas, servicio o administración.