Si quieres operar dos WhatsApps (uno para ventas y otro para posventa/soporte) dentro del Kommo CRM sin duplicar leads, sin perder historial y sin pelear por el “dueño del contacto”, la solución es simple: un contacto único + múltiples pipelines (embudos) + reglas de entrada + gobernanza de propiedad. El error es intentar “separar” creando dos CRMs, dos bases o dos contactos. Esto mata el ROI, mata el rastreo y genera guerra interna.
Soy Luiz Otávio Gonçalves (ingeniero mecánico que se convirtió en ingeniero digital) y, en la práctica, este diseño es uno de los que más desbloquea escala de atención al cliente con WhatsApp en Brasil — especialmente cuando la empresa crece y se da cuenta de que “vender” y “retener/atender” son operaciones diferentes, con SLA y métricas distintas.
El problema real: 2 WhatsApps sin arquitectura se convierten en 4 dolores
Cuando usas un WhatsApp para vender y otro para atender, sin método, aparecen cuatro problemas previsibles:
- Contacto duplicado: el mismo cliente entra en ventas y luego contacta posventa; alguien crea otro contacto y pierdes el historial.
- Conversación fragmentada: el equipo no sabe qué se prometió, qué se negoció y qué ya se resolvió.
- Disputa de dueño: el vendedor “retiene” el contacto, posventa no puede actuar (o viceversa).
- Reporte basura: no sabes el CAC real, tasa de recompra, tiempo de respuesta ni cuello de botella del embudo.
El antídoto es arquitectura operacional: un CRM, una base, dos embudos, dos líneas de comunicación y reglas de enrutamiento. Y sí: se puede hacer en Kommo de forma limpia.
Para quién es esto (y para quién no es)
Sirve para empresas que:
- Vendan por WhatsApp y tengan Volumen suficiente para justificar posventa separada (ej.: clínicas con recurrencia, inmobiliarias, cursos, industria con posventa técnica, asistencia, contratos).
- Necesiten SLA (tiempo de primera respuesta, tiempo de resolución) y seguimiento de promesas comerciales.
- Quieran retener y aumentar LTV sin inflar el equipo (automatización + proceso).
No sirve (todavía) para quienes:
- Tienes bajo volumen y solo un operador: separar WhatsApps solo añadirá fricción y costo.
- No tiene disciplina mínima de CRM (registro, etapas, actividades). Si el equipo “odia el CRM”, primero arregla lo básico.
- Quiere “automatización mágica” para compensar un producto malo o mal servicio. El CRM no salva operaciones rotas.
La regla de oro: 1 contacto, 1 historial, N jornadas
El cliente es uno. Lo que cambia son las jornadas (venta, onboarding, soporte, renovación, recomendación). En Kommo, esto significa:
- Un contacto único (con teléfono normalizado y campos estandarizados).
- Dos pipelines (ej.: “Ventas” y “Posventa/Retención”).
- Dos números de WhatsApp conectados a Kommo (vía API oficial de WhatsApp/Cloud API con BSP — esto evita bloqueos y permite escalar).
- Una política de propiedad: quién es dueño del contacto y quién es dueño del trato en cada embudo.
Si quieres profundizar en lo que cambia al escalar WhatsApp (costo y operación), también recomiendo leer: Kommo + WhatsApp API: el costo real (en R$) y lo que frena el ROI cuando escalas la atención.
Arquitectura recomendada (el diseño que implemento)
Te daré un modelo práctico que funciona en el 80% de los escenarios. Ajusta luego por nicho.
1) Dos embudos (pipelines) con objetivos y métricas diferentes
Pipeline 1: Ventas (objetivo: cerrar y recibir)
- Lead nuevo
- Calificado
- Propuesta enviada
- Negociación
- Ganado / Perdido
Pipeline 2: Posventa / Retención (objetivo: activar, resolver, retener, expandir)
- Bienvenida / Onboarding
- En curso (solicitud)
- Pendiente cliente
- Resuelto
- Recompra / Upsell
Ventas mide tasa de conversión y ciclo. Posventa mide SLA y retención. Mezclar todo en un solo embudo es la forma más rápida de destruir la visibilidad.
2) Una política de “dueño” (sin peleas y sin bloquear la atención)
Lo separo así:
- Dueño del contacto: generalmente lo tiene un rol de “Cuenta” (ej.: gerente de cuentas) o puede quedarse con el vendedor original. Lo importante es que sea regla, no discusión.
- Dueño del trato: cambia según el pipeline. En el embudo de ventas, es el vendedor/SDR. En el embudo de posventa, es el equipo de CS/soporte.
Esto evita el clásico: “no toques a ese cliente que es mío”. El cliente no es de nadie. El cliente es de la empresa.
3) Dos WhatsApps conectados: lo que es hecho y lo que es ilusión
Hecho: se pueden operar 2 números dentro de Kommo y organizar por fila/equipo.
Ilusión: pensar que dos números, solos, resuelven el proceso. Sin reglas, se vuelve ruido duplicado.
Dato real: Kommo tiene un plan pago por usuario y suele cobrarse en US$ por usuario/mes (con variación por plan y cobro mensual/anual). Para consultar los valores actualizados y qué licencia tiene sentido para tu escenario, detallé aquí: ¿Cuánto cuesta Kommo CRM? Precios y planes en 2026. Y si tu problema es elegir licencia sin caer en trampas, aquí: Licencias de Kommo CRM: ¿Cuál es la mejor para su empresa?.
Ahora, la parte sensible: API de WhatsApp (oficial) tiene costos propios (conversación/mensaje según regla vigente de Meta y tu BSP). No inventaré números aquí porque cambia por categoría y país y se actualiza. Lo que hago es: lo pongo en la hoja de cálculo de ROI el costo por conversación + costo por usuario + costo de automatización y dejo esto explícito en el proyecto.
4) Enrutamiento: cómo evitar duplicación cuando el cliente cambia de WhatsApp
Lo que impide la duplicación no es la “buena voluntad”. Es regla de sistema + estándar de registro.
Lista de verificación práctica que implemento:
- Normalizar teléfono (DDI + DDD + número) y bloquear creación sin estándar.
- Regla de búsqueda por teléfono: al entrar un mensaje nuevo, Kommo debe identificar contacto existente antes de crear otro.
- Creación de trato por canal/pipeline: si el mensaje vino del WhatsApp de posventa, crea/activa trato en el pipeline de posventa (no en ventas).
- Si ya existe trato abierto en el mismo pipeline, no crea otro; solo reabre, mueve etapa o crea actividad.
Esto exige configurar automatizaciones con cuidado para no generar “spam de trato”. Si quieres automatización y seguimiento sin irritar al lead, mira también: Follow-up de ventas automático: qué es, por qué casi todo el mundo hace errado y cómo montar.
5) Automatización mínima que da ROI (sin sobreingeniería)
Cuando hablo de ROI, no hablo de “verse bonito”. Hablo de reducir tiempo y aumentar ingresos con control.
En el embudo de Ventas, automatizaciones que casi siempre valen la pena:
- SLA de primera respuesta: si entra un lead y nadie responde en X minutos, alerta + redistribución.
- Seguimiento por etapa: propuesta enviada sin respuesta en 24h/48h? crea tarea y sugiere mensaje.
- Higiene del embudo: lead detenido X días vuelve a una etapa o cae en una fila de reactivación.
En el embudo de postventa, automatizaciones que casi siempre valen la pena:
- Bienvenida + onboarding (con listas de verificación y recopilación de datos).
- Recordatorio de pendiente del cliente (sin depender de que el operador recuerde).
- NPS/CSAT y envío de solicitud de recomendación cuando se resuelve.
- Recompra: disparadores por fecha (D+30, D+60, D+90) según tipo de compra/contrato.
La recompra y retención son donde aparece el flujo de caja. Detallo esta estrategia aquí: Kommo CRM para retención y recompra: cómo convertir el postventa en ingresos (sin aumentar el equipo).
6) Tabla de decisión: 1 embudo vs 2 embudos (criterios objetivos)
| Criterio | Solo 1 embudo | 2 embudos (ventas + postventa) |
|---|---|---|
| Volumen de atención al cliente | Bajo, equipo pequeño | Medio/alto, necesita fila y SLA |
| Recompra/recurrencia | Casi inexistente | Importante para LTV y margen |
| Complejidad del soporte | Simple, pocas dudas | Técnico, plazos, pendientes, tickets |
| Riesgo de promesas comerciales | Bajo | Alto (contratos, entrega, SLA) |
| Métricas exigidas | Conversión y ciclo ya bastan | Necesita SLA + resolución + churn + upsell |
7) El “truco”: cuándo postventa debe ver el embudo de ventas (y cuándo no)
Transparencia total parece bien, pero a veces es ruido. Mi regla práctica:
- Postventa debe ver lo que se vendió, plazos, condiciones y mensajes clave (para no prometer diferente).
- Postventa no necesita operar el embudo de ventas. Cada equipo en su embudo, con sus metas.
- Ventas debe ver estado de onboarding y satisfacción, porque esto se convierte en prueba social y upsell.
Esto es gobernanza: quién puede ver, quién puede editar, quién puede mover etapas. Sin esto, el CRM se vuelve “tierra de nadie”.
8) Cómo medir el ROI de este diseño (sin suposiciones)
Si usas 2 WhatsApps y 2 embudos, empiezas a medir lo que antes era invisible:
- Tiempo de 1ª respuesta por canal (ventas vs postventa).
- Tasa de resolución y tiempo promedio de resolución.
- Ingresos por recompra/upsell originada por postventa (sin depender del vendedor).
- Reducción de retrabajo (menos “mándame de nuevo”, menos “¿qué se acordó?”).
El ROI de automatización y CRM debe ser una cuenta cerrada: tiempo ahorrado + ingresos incrementales – costos. Si quieres el método para medir esto bien, sin autoengaño, aquí: Cómo medir el ROI de las automatizaciones empresariales.
Errores que veo bloqueando 2 WhatsApps en Kommo (y cómo corregirlos)
- Error 1: crear “Contacto Ventas” y “Contacto Postventa”. Corrección: el contacto es único; usa etiquetas/campos y deals separados.
- Error 2: pipeline de postventa con etapas de ventas. Corrección: las etapas deben reflejar la operación real (SLA, pendientes, resolución).
- Error 3: automatización que crea un deal cada vez que llega un mensaje. Corrección: valida si ya existe un deal abierto; si existe, solo actualiza/reactiva.
- Error 4: sin política de propiedad. Corrección: define dueño del contacto y dueño del deal por pipeline.
- Error 5: querer “IA” antes del proceso. Corrección: primero estandariza etapas, SLA y campos; luego aplicas IA donde aporta valor.
Conclusión: dos WhatsApps no es “más herramienta”, es más proceso
Cuando implementas dos WhatsApps en Kommo de la manera correcta, construyes una cadena: ventas cierra, postventa activa y retiene, y el historial queda completo. Esto reduce fricción interna, aumenta la satisfacción y abre espacio para recompra con método. Sin arquitectura, solo duplicas el ruido.
Si quieres que diseñe e implemente esto en tu operación (desde el embudo hasta los enrutamientos, automatizaciones y métricas), el siguiente paso es directo: solicitar un proyecto.
Preguntas frecuentes
1) ¿Se pueden usar dos números de WhatsApp en Kommo al mismo tiempo?
Sí, se puede. El punto crítico no es “conectar”, es enrutar cada conversación al pipeline correcto e impedir duplicación de contacto/deal.
2) ¿Cómo evitar contacto duplicado cuando el cliente llama al WhatsApp de ventas y luego al WhatsApp de soporte?
Estandariza teléfono (DDI+DDD+número), fuerza este patrón en el registro y configura reglas para el sistema buscar contacto existente antes de crear uno nuevo. El diseño correcto es un contacto, múltiples deals por jornada.
3) ¿Es mejor tener un solo embudo con etapas de postventa después de “Ganado”?
Casi nunca. Mezclar ventas y postventa en un solo embudo destruye la lectura de conversión y no crea métricas de SLA. Lo más eficiente es dos pipelines con metas e informes separados.
4) ¿Quién debe ser el dueño del contacto: ventas o postventa?
Depende de tu modelo, pero debe ser regla. Yo suelo separar: Contacto con un responsable de “cuenta” (o vendedor) y negocio con el responsable del pipeline (ventas en el pipeline de ventas; CS/soporte en el pipeline de postventa).
5) ¿Funciona esto para clínica, inmobiliaria e industria B2B?
Funciona, siempre que haya volumen y necesidad real de postventa/retención. En operaciones pequeñas, separar WhatsApps puede ser excesivo y reducir la productividad en lugar de aumentarla.