Respuesta corta: Si buscas un CRM de WhatsApp con agente de IA que puedas alojar en tu propio servidor, Vocero CRM es un candidato real, pero muy joven: el repositorio se creó en julio de 2026 y no publica releases. Según su documentación, ofrece bandeja en tiempo real, pipeline de ventas, un agente de IA configurable con el conocimiento de tu negocio y un Laboratorio que autoevalúa al agente con clientes simulados, todo bajo licencia MIT. Nuestra lectura: es apto para pruebas controladas y para agencias que despliegan una instancia por cliente; no es todavía una apuesta segura para un negocio que necesite garantías de continuidad o funciones como agendamiento y RAG.

Qué es Vocero CRM y para quién es

Vocero CRM es un CRM de WhatsApp open source y self-hosted, escrito principalmente en TypeScript. El repositorio lo describe como un CRM gratuito para negocios que venden por WhatsApp: bandeja en tiempo real, pipeline de ventas, un agente de IA con el conocimiento del negocio y un Laboratorio donde clientes simulados evalúan al agente antes de que hable con clientes reales. El modelo propuesto es «una instancia = un negocio»: cada cliente corre su propia copia en su servidor, con sus datos.

El README distingue dos públicos:

• Agencias de IA y automatización que implementan CRM más agente para sus clientes, desplegando una instancia por cliente en su VPS y entregándola con el reporte del Laboratorio como evidencia de calidad.
• Negocios que quieren atender WhatsApp con IA sin entregar sus datos a un SaaS, manteniendo todo en su propia infraestructura.

Esto define un primer filtro de adopción: Vocero no es un SaaS multi-tenant con alta gestionada; es software que alguien tiene que instalar, operar y actualizar.

Hechos clave del repositorio

Datos observados directamente en el repositorio el 21 de agosto de 2026:

Dos lecturas de estos números. La actividad reciente y el alto número de forks para un proyecto de un mes sugieren que hay equipos modificándolo, probablemente agencias. En contra, la ausencia de releases complica fijar versiones estables y evaluar madurez, y la única issue abierta es relevante para Latinoamérica (la analizamos en limitaciones).

Qué incluye: bandeja, pipeline, agente y Laboratorio

Según la documentación del proyecto, las piezas centrales son:

• Bandeja de WhatsApp en tiempo real: tres columnas (conversaciones, hilo, contacto), mensajes entrantes en menos de dos segundos sin recargar, estados enviado/entregado/leído, ventana de 24 horas visible y bloqueada, plantillas aprobadas cuando la ventana se cierra, respuestas del agente marcadas como IA y traspaso a humano con un clic.
• Contactos y pipeline kanban: cada persona que escribe queda registrada y entra al pipeline editable (Nuevo → En conversación → Interesado → Cliente → Perdido), con búsqueda, notas y archivo. El agente puede mover leads de etapa cuando detecta intención de compra.
• Agente de IA con conocimiento propio: configuración de nombre, tono, instrucciones y reglas de escalado; conocimiento en pares pregunta/respuesta y bloques libres; responde solo con lo que sabe, agrupa ráfagas de mensajes y escala a humano cuando el cliente lo pide o cuando algo falla. El proveedor LLM se conecta por un adaptador compatible con OpenRouter.
• Laboratorio de auto-evaluación: seis clientes simulados (el comprador decidido, el que pregunta precios, el cliente enojado, el que pregunta lo que no se sabe, el que exige un humano y el que escribe mal) conversan contra el agente real en un sandbox interno que, según el README, jamás envía mensajes reales. Un juez LLM independiente puntúa cada conversación de 0 a 100, lista hallazgos con evidencia (alucinaciones, huecos de conocimiento, tono), sugiere cambios aplicables con un clic al knowledge base y guarda historial con delta para comparar corridas.

El Laboratorio es la propuesta más diferenciada del proyecto: convierte «esperar que el bot funcione» en una métrica reproducible antes de exponerlo a clientes reales. También es la función más dependiente del proveedor LLM, porque el juez es otro modelo.

Seguridad y control de datos

El argumento central de Vocero frente a un SaaS es el control: cada instancia corre en el servidor del negocio y los datos no salen de ahí. La documentación menciona medidas concretas:

• Token de WhatsApp cifrado en reposo con AES-256-GCM.
• Webhook autenticado en dos capas, con URL secreta y verificación de firma opcional vía META_APP_SECRET.
• Cierre del registro público tras la primera organización: el primer usuario crea la organización y el registro abierto se desactiva.
• Respeto declarado de las políticas de Meta: opt-in, ventana de 24 horas, plantillas aprobadas y ausencia de envíos masivos no verificados.
• Cero dependencias de runtime más allá de Meta y del proveedor LLM opcional.

Con matices. Estas son afirmaciones de la documentación, no el resultado de una auditoría independiente que hayamos visto. Además, el mismo README advierte que no hay flujo de «olvidé mi contraseña»: el proyecto no envía correos por diseño, y la salida documentada es reescribir el hash en la base de datos con un script que imprime el UPDATE para ejecutarlo a mano. Para una empresa, la recuperación de acceso depende de la disciplina operativa de quien administra la base.

¿Tu sistema tiene un problema parecido? Contactarme

Ver el servicio relacionado

Integraciones: WhatsApp Cloud API, LLM y tu propio agente

Vocero consume un token de la WhatsApp Cloud API de Meta; no implementa el Embedded Signup. En modo directo necesitas una app en Meta, un usuario del sistema con permisos whatsapp_business_messaging y whatsapp_business_management, y un dominio con HTTPS para el webhook. En modo agencia (Tech Provider), tu plataforma hace el Embedded Signup y guarda los tokens; la instancia del cliente solo recibe su token, y el webhook se conecta con el override de callback por WABA. La documentación insiste en que el orden importa: primero desplegar la instancia, después guardar la conexión y por último configurar el override, porque el enrutamiento usa el Phone Number ID guardado.

Hay un detalle de integración que las agencias deben conocer: los eventos de estado de plantillas (message_template_status_update) no siguen el override de callback; van a la app dueña. Vocero compensa sincronizando plantillas por la API de Graph con un botón en la configuración. Es una limitación de Meta documentada, no un defecto del repositorio, pero afecta al flujo de trabajo en modo agencia.

Para equipos que ya tienen su propio bot, el proyecto ofrece una API de servicio /api/bot/* para traer tu propio agente: contexto de la conversación, envío de respuestas, perfil y knowledge base, ficha del lead, handoff a humano, typing, descarga de adjuntos y reset de pruebas. Los errores 409 vienen tipados (ai_paused, window_closed, sandbox_violation) para que el bot sepa si debe callarse, mandar plantilla o rendirse. El README referencia nea-agent como agente de referencia bajo MIT.

El punto más práctico: el token de WhatsApp nunca sale del CRM. Si integras tu propio agente, la conversación se conduce desde tu microservicio, pero la mensajería y el historial quedan en la instancia.

Instalación, mantenimiento y actualizaciones

La instalación documentada toma dos rutas: docker compose clásico o Coolify con asistente de IA (el README ofrece un archivo INSTALL-IA.md para guiar a un asistente con el MCP de Coolify). En ambos casos se necesita un dominio apuntando al VPS, HTTPS vía Caddy, una base PostgreSQL y el token de WhatsApp. El healthcheck /api/health devuelve {“ok”:true} junto con versión y commit congelados en el build, lo que permite confirmar un despliegue con un curl sin abrir la app.

Para mantenimiento y actualización, el proyecto define una política SemVer explícita: mayor (2.0.0) cuando hay que hacer algo a mano (cambiar variables, migrar datos, reconectar), menor y parche cuando actualizar es redesplegar. Las migraciones corren al arranque. El FAQ documenta los fallos típicos: webhook que no verifica, mensajes que no llegan porque la conexión no quedó guardada en el wizard, token expirado, error 131030 por lista de permitidos, ENCRYPTION_KEY inválida (32 bytes en base64) y base de datos no lista.

Dos observaciones honestas. No hemos instalado ni probado el proyecto: estos pasos provienen del README, no de nuestra verificación. Y sin releases publicadas, el anclaje de versiones y el historial de cambios dependen de la rama main y de los tags que el mantenedor decida crear; un despliegue en producción debería definir su propia estrategia de respaldo y rollback. Para un proyecto de este tamaño, es un punto que un equipo de mantenimiento debe resolver antes, no después.

Limitaciones y riesgos actuales

• Proyecto joven y sin releases. Creado en julio de 2026, con poco historial: la continuidad del mantenimiento aún está por demostrarse. Si el proyecto se abandonara, la licencia MIT permite tomar el código, pero la operación recaería en ti.
• Normalización de números solo para México (issue #35). La issue abierta reporta que los envíos a números argentinos fallan con el error 131030 porque normalizeRecipient solo contempla México (521 + 10 dígitos), mientras Meta reporta destinatarios argentinos como 549 + 10 dígitos. El reporte incluye un fix local y propone cubrir 521 y 549. Hasta que se aplique, cualquier despliegue argentino debe verificar este punto.
• Sin RAG todavía. El knowledge base se inyecta completo, con aviso de tamaño; el RAG para bases grandes está en el roadmap. Para catálogos extensos, el costo y la calidad pueden degradarse.
• Multimedia limitada en la bandeja. Hoy se muestra un indicador de tipo de adjunto; la multimedia completa está en el roadmap.
• Sin motor de agendamiento. Es una decisión consciente del proyecto (fuera de alcance a propósito). Si tu bot agenda, el contrato /api/bot/availability y /api/bot/bookings está documentado en el issue #8 para implementarlo aparte.
• Recuperación de contraseña manual. No hay correos ni flujo de recuperación; la salida documentada reescribe el hash en la base.
• Sin envíos masivos. No incluye broadcast para respetar las políticas de Meta; si tu operación depende de campañas, no es el objetivo del proyecto.

Criterios de decisión y veredicto

Adopta o prueba primero si:

• Eres una agencia que despliega una instancia por cliente y puedes entregar el Laboratorio como evidencia de calidad.
• Necesitas control de datos y prefieres self-hosted sobre un SaaS, con equipo técnico propio o contratado.
• Tu operación es México-centrada o puedes verificar la normalización de números de tu país antes de producir.
• Aceptas operar sobre main sin releases, con respaldos y rollback definidos por ti.

Espera o descarta si:

• Necesitas agendamiento, broadcast verificado, RAG o multimedia completa desde el día uno.
• No tienes capacidad de instalar y mantener Docker, PostgreSQL y la integración con Meta.
• Tu mercado principal es Argentina u otro país con normalización distinta, hasta que el fix del issue #35 llegue a main.
• Buscas un proveedor con SLA, soporte corporativo o garantías de continuidad: este es un proyecto open source joven, no un servicio gestionado.

Veredicto. Vocero CRM es de los proyectos de WhatsApp con IA mejor documentados en su etapa: el Laboratorio resuelve un problema real (saber si el agente está listo) y la API para traer tu propio agente reduce el vendor lock-in. Pero la madurez no acompaña a la documentación: sin releases y con semanas de vida, tratarlo como dependencia crítica de un negocio es prematuro. La posición razonable es evaluarlo en un entorno de prueba, con datos de demostración, y decidir solo después de ver cómo se comporta el mantenimiento durante unos meses.

Un último punto práctico: en este tipo de adopción el riesgo no está solo en el software, sino en la operación. Si el despliegue se atasca, la integración con Meta o tu proveedor de IA se complica, o no quieres quedarte a cargo de las actualizaciones y de un proyecto que podría quedar sin mantenimiento, contar con un equipo que ya asuma instalaciones, integraciones y mantenimiento de este tipo reduce el riesgo real del proyecto.

¿Tu sistema tiene un problema parecido? Si una incidencia, un ataque, una actualización o un sistema sin mantenedor afecta al negocio, puedo ayudarte a diagnosticarlo y corregirlo. Contactarme

Ver el servicio relacionado

Fuentes

• kevinrivm/vocero-crm — repositorio oficial (README y metadatos)
• Issue #35 — El envío a números argentinos falla con 131030
• Issue #8 — Contrato del motor de agendamiento (/api/bot/availability y /api/bot/bookings)
• nea-agent — agente de referencia (MIT)