Monta un agente de ventas en WhatsApp con la API oficial de Meta, un servidor propio y un panel donde tú apruebas lo que el agente dice. Incluye los errores que nos aparecieron de verdad.
Ir al paso 116 pasos en 5 fases. Informativa, no es asesoría legal.
Todo parte de un portafolio comercial y una app. Aquí no se programa nada.
Al final tendrás un agente que conversa por WhatsApp con tus clientes usando la API oficial de Meta (WhatsApp Cloud API), con un portafolio y una app propios, un servidor propio y un panel donde ves y gobiernas todo lo que el agente hace.
Es para quien tiene un negocio, aunque todavía no tenga empresa constituida, y quiere montar un agente de ventas o atención sin depender de un intermediario. Los menús de Meta cambian seguido: guíate por el sentido de cada paso, no por la posición exacta de los botones.
Necesitas cuatro cosas:
Para empezar no necesitas una empresa constituida, la verificación del negocio ni la revisión de la app, siempre que uses tu propio número y tu propio portafolio. Sin verificación el límite de envío es más bajo (alrededor de 250 contactos únicos por día al momento de escribir esto; confírmalo en tu panel).
El portafolio comercial de Meta (antes Business Manager) es el contenedor que posee la app, la cuenta de WhatsApp y los permisos. Crea uno por cada operación, para que un bloqueo en una no afecte a la otra.
En Configuración → Información del negocio, pulsa Editar. Meta exige un nombre legal para poder guardar.
el autocompletado del navegador puso el estado civil («Soltero(a)») en el campo Estado/provincia/región. Revisa cada campo antes de guardar; en Colombia va el departamento.
La app queda como «Sin publicar». El panel ofrece «Conviértete en proveedor de tecnología»: ignóralo. Solo hace falta para atender datos de otros negocios y exige verificación del negocio.
En el panel de la app entra a WhatsApp → Configuración de la API. Ahí aparecen los pasos: probar con un número de prueba, configurar el webhook, registrar tu número, agregar información de pago y enviar un mensaje.
Requisitos del número: una SIM que nunca haya tenido WhatsApp, que no esté registrada en la app de WhatsApp y que reciba SMS o llamadas.
SIM prepago de Tigo (Colombia), lo que nos pasó:
*520# muestra el número y *123# el saldo.Registro en Meta: WhatsApp → Configuración de la API → Agregar número de teléfono. Nombre para mostrar igual a la marca, zona horaria, categoría y número con +57. Verificación por SMS una sola vez; si no llega, llamada de voz una vez. No pidas códigos repetidos.
Resultado: en WhatsApp Manager → Números de teléfono, el número aparece con estado Conectado.
no instales WhatsApp ni WhatsApp Business en el celular con esa SIM, porque sacarías el número de la API.
Meta necesita una dirección pública con HTTPS para entregarte cada mensaje.
El webhook de WhatsApp necesita una dirección pública con HTTPS. Para eso se monta un servidor pequeño, separado de cualquier otro sistema.
6.1 Proteger la cuenta. Antes de crear nada, activa el 2FA en tu proveedor de servidores con una app autenticadora. Guarda la clave de recuperación en un gestor de contraseñas. Nunca muestres el QR ni la cadena manual en capturas o chats: esa semilla genera tus códigos.
6.2 Proyecto aislado. Crea un proyecto exclusivo para el agente, así sus recursos no se mezclan con los de otros proyectos.
6.3 Llave SSH propia. En tu computador: ssh-keygen -t ed25519 -C "radar-agente". Dale un nombre propio al archivo para no pisar otras llaves. En el proveedor solo se pega la clave pública (.pub); la privada no sale de tu computador.
6.4 Crear el servidor. Tipo económico de 2 vCPU y 4 GB (unos 7 USD al mes), Ubuntu LTS, la llave SSH marcada, sin volumen ni backups al inicio. Anota la IP pública.
6.5 Subdominio. En tu proveedor de DNS crea un registro A hacia la IP del servidor. Si usas Cloudflare, deja el proxy apagado (DNS only, nube gris): con el proxy encendido el servidor no puede obtener su certificado HTTPS de la forma habitual y Meta puede fallar al verificar el webhook.
6.6 Firewall. Sin firewall todo queda abierto. Crea uno con entrada TCP 22, 80 y 443 y asígnalo al servidor. El 80 es obligatorio aunque solo uses HTTPS: lo necesita el proxy para obtener el certificado. Lección aprendida: un servidor nuevo sin nada escuchando en el 443 parece «bloqueado» y puede costar una hora de diagnóstico.
6.7 Primera conexión. ssh -i ~/.ssh/TU_LLAVE root@IP_DEL_SERVIDOR. La primera vez pregunta si confías en el servidor: respondes yes, porque lo acabas de crear tú.
6.8 Actualizar e instalar. apt update && apt upgrade -y y luego apt install -y docker.io docker-compose-v2 ufw. La terminal muestra decenas de líneas y una barra de progreso; es normal y tarda unos minutos. Los avisos como rehash: warning son inofensivos. No cierres la terminal hasta que vuelva el prompt.
6.9 Usuario propio y firewall interno. Crea un usuario sin privilegios (no se trabaja como root), copia la llave SSH, agrégalo al grupo docker y activa ufw permitiendo 22, 80 y 443 antes de encenderlo. Antes de cerrar la sesión de root, comprueba en una segunda ventana que el nuevo usuario entra por SSH; solo entonces desactiva el acceso directo de root.
7.1 Servidor en marcha. Con el código en el servidor, crea allí mismo un archivo .env (nunca en el chat ni en un repositorio) con cuatro valores: un token de verificación que inventas con openssl rand -hex 24, el App Secret (App → Configuración → Básica), el token permanente de un usuario del sistema y el identificador del número de teléfono (no el teléfono ni el de la cuenta). El envío se deja apagado al inicio: el agente recibe y guarda, pero no responde. Para verificar sin exponer secretos: awk -F= '/^[A-Z]/ {print $1, length($2)}' .env muestra solo nombres y largos. Luego docker compose up -d --build.
7.2 Probar antes de ir a Meta. Con curl se imita lo que hace Meta: una petición a https://TU_DOMINIO/webhook con hub.mode=subscribe, tu token y hub.challenge=12345 debe responder 12345.
7.3 Configurar webhooks en Meta. App → Casos de uso → Personalizar → Configuración de producción → Configurar webhooks. URL: https://TU_DOMINIO/webhook. Token: el mismo del .env. Deja apagado el certificado de cliente. Cuidado con espacios al inicio o al final de la URL y del token.
7.4 Campos. Comprueba que el campo messages esté en «Suscritos».
7.5 El interruptor que se olvida. En «Registra tu número de teléfono», la tarjeta de la cuenta tiene el interruptor Suscribir webhooks. Si está apagado, Meta no envía a tu app los mensajes de ese número aunque el webhook esté verificado. Enciéndelo y espera el aviso «Se suscribió correctamente a webhooks».
7.6 Probar de punta a punta. En el campo messages pulsa Probar → Incoming Message → Enviar al servidor. Los datos son de ejemplo. Comprueba que apareció una conversación y un mensaje sin enviar en la base del agente, y luego borra esas filas.
Mientras la app esté sin publicar, Meta solo entrega webhooks de prueba. Para recibir mensajes reales hay que publicarla (modo Live).
Antes de recibir mensajes reales, la política pública tiene que cubrir al agente.
8.1 Qué pide Meta. En Configuración → Básica: URL de la política de privacidad, URL de las condiciones del servicio, URL de eliminación de datos (o instrucciones), un ícono de 1024 × 1024 y una categoría. En este flujo la categoría fue «Negocios y páginas». Todas las URLs deben cargar sin pedir inicio de sesión.
8.2 Antes de publicar. La política pública tiene que cubrir al agente (ver el paso 9). Publicar sin eso expone a recibir mensajes reales con una política que no los menciona.
8.3 Publicar. En el panel de la app, sección Publicar, revisa la lista de requisitos y pulsa Publicar. Meta confirma con «Tu app se publicó correctamente».
8.4 Prueba real. Desde un WhatsApp personal escribe «hola» al número del agente. El evento debe llegar al servidor. Con el envío apagado el agente guarda la respuesta pero no la manda.
Esta guía describe una implementación real y no es asesoría legal. Valida los textos y las decisiones de este paso con un abogado de tu país.
9.1 Quién es quién. La ley colombiana de protección de datos (Ley 1581 de 2012) distingue al responsable (decide para qué se usan los datos) del encargado (los trata por cuenta del responsable). Define cuál es cada uno antes de escribir el texto.
9.2 Qué debe decir la política. Un apartado propio para el agente: quién es el responsable, qué datos pide (número, nombre de perfil y respuestas), para qué, cómo se autoriza (responder SÍ), cómo se revoca (responder NO), cómo ejercer los derechos y qué proveedores intervienen, incluidos los que están fuera del país. Si cambias de proveedor, actualiza la lista antes de usarlo con datos reales.
9.3 Cómo se publica sin romper nada. Los cambios al sitio se hacen en una rama, se abre un Pull Request y solo el dueño hace el merge. El hosting despliega solo al aprobar. Un cambio de una sola sección es fácil de revisar.
9.4 Qué revisar con el abogado. Datos de la empresa responsable (NIT y domicilio), plazo de conservación, inscripción en el Registro Nacional de Bases de Datos, validez de la autorización por chat y, si hay contacto saliente, la Ley 2300 de 2023.
10.1 Interruptor de envío. El agente solo responde si en su archivo de entorno está activado el envío. Se activa en el servidor, editando el archivo con un editor de texto, y se recrea el contenedor para que lo lea. Verifica sin mostrar secretos que la variable quedó en 1.
10.2 Decidir a quién responder. Se puede limitar a una lista de números o abrirlo a cualquiera que escriba. Con respuestas abiertas cualquiera puede iniciar una conversación, así que la política y la opción de salir (NO) deben estar listas.
10.3 Lo que mostró la prueba real. (a) Si la persona pide ayuda a mitad de la entrevista, el agente debe repetir la pregunta pendiente, no solo el mensaje de ayuda. (b) Si la pregunta tiene opciones numeradas y la persona responde «1, 2», se guarda el texto de cada opción, no los números. Probar con una conversación real encuentra defectos que un simulador no ve.
Ves cada conversación y nada cambia sin tu aprobación.
El agente guarda todo en una base local pequeña. Para ver la operación, editar el guion y aprobar cambios se monta un panel aparte.
11.1 Base de datos. Un proyecto nuevo de Supabase, exclusivo del agente y separado de cualquier otro sistema. Tablas: conversaciones, mensajes, eventos, prospectos con etapas, versiones del cerebro (guion, reglas y mensajes por etapa), notas de la guía, consentimientos, solicitudes de derechos y auditoría del panel.
11.2 Seguridad por filas. Todas las tablas con seguridad por filas activada y una sola política: solo entra quien está en la lista de administradores. Las funciones que consultan esa lista no deben ser ejecutables por usuarios anónimos; revisa los avisos de seguridad del proyecto después de crear el esquema.
11.3 Inicio de sesión con Google. Crea un proyecto propio en Google Cloud para el agente, no reutilices el de otra operación. Cliente OAuth tipo aplicación web, con el origen del panel y la URL de callback que muestra Supabase. En Supabase activa el proveedor Google con el ID y el secreto del cliente. Solo el correo que esté en la tabla de administradores ve datos.
11.4 El panel. Aplicación web (Next.js) en su propio repositorio, desplegada en Vercel con despliegue automático al hacer merge. Variables de entorno solo con la URL del proyecto y la clave pública (publishable). La clave secreta (service role) nunca va en el panel.
11.5 Error real: redirección a localhost. Después de iniciar sesión con Google, el navegador fue a localhost:3000. Causa: la URL del sitio en Supabase seguía en su valor por defecto. Solución: en Supabase → Authentication → URL Configuration, poner la URL pública del panel como Site URL y en las Redirect URLs.
11.6 Cuidado con «Add Supabase» de Vercel. Vercel ofrece ese integrador al importar el proyecto. No lo uses: crearía otra base y mezclaría credenciales.
12.1 Espejo. El agente copia cada conversación a Supabase en segundo plano. Si Supabase falla, el agente responde igual: la base local sigue siendo la fuente primaria. Si la persona responde NO, se borran en Supabase sus mensajes y su prospecto.
12.2 Variables. En el archivo de entorno del servidor se agregan la URL del proyecto y la clave secreta. Esa clave da acceso total y vive solo ahí. Se pega directamente en el editor del servidor, nunca en un chat.
12.3 Despliegue en el servidor, paso a paso.
scp.docker compose up -d --build.12.4 Error real: PGRST102 «All object keys must match». El espejo guardaba la conversación pero no los mensajes. Causa: el lote de mensajes mezclaba filas con y sin el campo del identificador de WhatsApp. Solución: enviar ese campo en todas las filas (vacío en las del agente).
12.5 Error real: comandos ejecutados dentro del servidor. Si el prompt ya muestra el usuario del servidor, estás dentro; los comandos ssh y scp se ejecutan desde tu computador, no desde allí.
13.1 Versiones. Guion, reglas y mensajes se guardan en la base como versiones: borrador, aprobada o archivada. Un cambio nace como borrador y solo el administrador lo aprueba; la aprobación queda auditada.
13.2 El agente lee lo aprobado. El agente consulta la versión aprobada del guion y la guarda en memoria durante un minuto. Si la base no responde o el contenido no es válido, usa el guion que lleva en el código, para no quedarse sin responder. Cada conversación guarda con qué versión del guion se atendió, lo que permite comprobar el cambio.
13.3 Sectores. Las versiones llevan un campo de sector. El mismo motor puede atender distintos negocios con un paquete de guion y reglas por sector. Valida con uno solo antes de generalizar.
13.4 Código en un repositorio. Sube el código a un repositorio privado por Pull Request, con el mismo contenido que corre en el servidor. El archivo de entorno nunca entra al repositorio.
Cuando el agente escribe primero o pasan más de 24 horas, entran las plantillas.
14.1 La ventana de 24 horas. Meta solo deja escribir texto libre dentro de las 24 horas siguientes al último mensaje de la persona. Cada mensaje que ella envía reabre la ventana. Fuera de ese plazo, o si el agente escribe primero, hay que usar una plantilla aprobada por Meta.
14.2 Cuándo no las necesitas. En un flujo donde la persona escribe primero y el agente responde enseguida, la ventana siempre está abierta. Es el caso de la entrevista entrante.
14.3 Cuándo sí. Recordar una reunión, retomar una entrevista que quedó a medias y cualquier contacto saliente.
14.4 Tipos. Las de utilidad (confirmaciones y recordatorios sobre algo que la persona ya pidió) son las más fáciles de aprobar. Las de marketing (promociones o contacto en frío) exigen autorización previa de la persona y se cobran por mensaje; confirma las tarifas vigentes en tu panel de Meta.
14.5 Cómo se crean. En WhatsApp Manager → Plantillas de mensajes: nombre, idioma, categoría y texto con variables. Meta las revisa y puede rechazarlas, así que escribe textos claros y sin promesas exageradas.
14.6 Orden recomendado. Primero las de utilidad. La de marketing va al final, cuando el texto esté revisado por un abogado, la empresa esté constituida y el negocio verificado. Sin verificación el límite es de unos 250 contactos únicos por día.
15.1 Punto de partida. Hoy, al terminar la entrevista, el agente ofrece reunión virtual, presencial (en la ciudad del asesor) o solo chat, propone tres horarios y guarda la elegida. Un asesor la confirma a mano en horario hábil.
15.2 Etapa 1: enlace de agenda. El mensaje de respuesta a LLAMADA incluye un enlace público de agenda (por ejemplo, Programación de citas de Google Calendar). Es un cambio de texto en el guion: nace como borrador y solo cuenta cuando el administrador lo aprueba. No requiere código ni plantillas.
15.3 Etapa 2: agenda automática. El agente consulta horarios libres en Google Calendar, propone opciones, crea el evento y manda confirmación y recordatorio con una plantilla de utilidad. Antes de usarla con datos reales, Google debe figurar como proveedor en la política de privacidad.
Esta sección es un diseño y se actualizará cuando se implemente.
16.1 Qué promete el agente. Al cerrar la entrevista, la persona recibe sus primeros 5 prospectos de alto valor: decisores que encajan con el ICP que acaba de describir. Hoy un asesor los prepara a mano con Sales Navigator. El objetivo es que el agente lo haga solo.
16.2 Qué es “alto valor”. No es un cargo importante. Es un decisor que coincide con el ICP y muestra señales recientes de compra, contratación, expansión o necesidad. Cada prospecto se puntúa por ajuste al ICP, señales, necesidad y capacidad de pago, con reglas que el administrador puede ver y cambiar.
16.3 Dos capas de herramientas. Para encontrar perfiles: Sales Navigator o una base de datos B2B (Apollo, Cognism, ZoomInfo, entre otras). Para enriquecer y calificar: datos de contacto y señales. Una cosa es encontrar el cargo y otra saber si está listo para comprar.
16.4 Lo que descubrimos con una prueba real. En Apollo, una búsqueda de decisores en Colombia devolvió miles de perfiles, con enlace a LinkedIn visible en la interfaz. Eso confirma que hay cobertura en el mercado, pero se verificó solo en la interfaz web, no con la API ni con todos los sectores.
16.5 El límite que casi nadie mira: la licencia. Las licencias estándar de estos proveedores son de uso interno. Apollo y RocketReach prohíben, en sus términos, ceder o revender los datos a terceros y automatizar acciones sobre LinkedIn. Entregar prospectos a un cliente puede ser redistribución y requiere una licencia escrita del proveedor. Revisa los términos vigentes antes de contratar; aquí no es asesoría legal.
16.6 Datos personales. Un prospecto es una persona que no te dio su dato. Antes de entregar o contactar necesitas una base legal, una política de privacidad que mencione estos datos y terceros, y un canal para que la persona pida su eliminación. En Colombia aplica la Ley 1581; consulta con un abogado.
16.7 Plan por fases. Fase 1: el agente entrega 5 empresas objetivo a partir de datos abiertos, más un enlace de búsqueda de LinkedIn ya filtrado para que el asesor o el cliente abran los perfiles. Fase 2: un proveedor con licencia de redistribución entrega los perfiles. Se diseña sin atarse a un proveedor, para poder cambiarlo.
16.8 Lo que no hacemos. No automatizamos invitaciones ni mensajes en LinkedIn, no extraemos perfiles con herramientas no autorizadas y no contactamos a nadie en frío sin la autorización del dueño.
Esta sección es un diseño y se actualizará cuando se implemente. Precios y condiciones de los proveedores cambian: confírmalos con ellos.
Escríbenos y te ayudamos a pasar de la guía a un agente funcionando.
hola@ventas10x.co