Intermedio
8–11 horas
8 módulos completos
Cómo estudiar este curso
Requisitos previos
Necesitas conocer conceptos básicos de WhatsApp Business Platform y procesos de CRM. No hace falta programar, aunque el curso explica estructuras de datos para que negocio y tecnología hablen el mismo idioma.
Módulo 1. Modelo de datos: contacto, conversación y mensaje
1.1 Contacto
El contacto representa a una persona. Puede tener teléfono, nombre, email, organización, país, preferencias y consentimientos. El número WhatsApp es importante, pero la identidad no debe depender exclusivamente de él si tu negocio también usa email, documento, customer ID u otras claves.
1.2 Conversación
Una conversación agrupa una interacción operativa: canal, número empresarial, contacto, estado, cola, agente, timestamps y motivo. Puede reabrirse o crear una nueva sesión según tus reglas internas. Separarla del contacto permite medir cuántas interacciones requiere una persona.
1.3 Mensaje
El mensaje almacena dirección, wamid, tipo, contenido normalizado, plantilla, estado y fecha. Los estados deben llegar como eventos y conservar historial. No coloques toda la lógica del CRM dentro del JSON crudo de Meta; guarda el payload para auditoría, pero extrae campos útiles.
| Entidad | Clave | Relaciones |
|---|---|---|
| Contact | contact_id | muchas conversaciones, oportunidades, consentimientos |
| Conversation | conversation_id | un contacto, un canal/número, mensajes, agente |
| Message | message_id + wamid | una conversación, estados |
| Opportunity | opportunity_id | contacto/empresa, etapa, valor |
| Consent | consent_id | contacto, propósito, fuente, fecha |
Práctica del módulo
Comprueba lo aprendido
¿Por qué no usar el número como primary key universal?
Puede cambiar, existir en varios contextos o no ser suficiente para unir identidad omnicanal. Usa un ID interno.
¿Por qué conservar payload crudo además de campos normalizados?
Ayuda a auditoría y depuración futura sin obligar a consultar a Meta, mientras los campos normalizados facilitan consultas del negocio.
Módulo 2. Identidad, consentimiento y deduplicación
2.1 Normalización E.164
Normaliza números antes de comparar. Guarda valor canónico y, si necesitas, el texto original separado. No confíes en espacios, guiones o prefijos introducidos por formularios. La deduplicación debe considerar contexto de país y otros identificadores.
2.2 Resolución de identidad
Cuando llega un mensaje, intenta resolver wa_id/teléfono a un contacto. Si no existe, crea uno provisional con fuente “WhatsApp inbound”. Si luego el usuario proporciona email o customer ID, aplica reglas de fusión auditables; no fusionar solo por nombres similares.
2.3 Consentimiento como entidad
Un contacto puede aceptar actualizaciones transaccionales y no promociones. Modelar consentimiento por propósito permite campañas más precisas. Registra baja como un evento y propágala a herramientas conectadas.
Práctica del módulo
Comprueba lo aprendido
¿Por qué no fusionar por nombre?
Los nombres no son únicos y pueden cambiar; una fusión incorrecta mezcla conversaciones y datos de personas distintas.
¿Un campo marketing_opt_in=true basta?
Es un inicio, pero para trazabilidad conviene guardar fuente, fecha, texto/propósito y estado de baja.
Módulo 3. Bandeja, asignación, colas y SLA
3.1 Propietario de conversación
La conversación debe tener un responsable actual y un historial de asignaciones. Esto permite saber quién debía responder en un momento concreto. Si existe autoasignación, registra la regla que produjo la decisión.
3.2 Colas
Las colas representan capacidad y especialidad: ventas, soporte, región, producto. Mantén prioridad, orden, fecha de entrada y SLA. Una conversación “sin asignar” no debería ser invisible; debe pertenecer a una cola monitoreada.
3.3 SLA basado en eventos
Calcula tiempos desde eventos: ingreso, primera respuesta humana, espera de cliente, reanudación y resolución. Pausar el SLA cuando esperas al usuario puede ser válido, pero documenta la regla para que las métricas sean comparables.
Práctica del módulo
Comprueba lo aprendido
¿Por qué guardar historial de asignación?
Porque el responsable actual no explica quién atendió antes ni dónde ocurrieron demoras.
¿Una conversación puede estar sin agente y seguir controlada?
Sí, si está en una cola visible con prioridad/SLA y reglas de asignación.
Módulo 4. Pipeline comercial y etapas
4.1 Contacto vs. oportunidad
Una persona puede comprar varias veces o tener oportunidades simultáneas. La oportunidad representa una intención comercial concreta con etapa, valor, producto, fecha y owner. No crees una nueva oportunidad por cada mensaje entrante; define eventos que justifican su creación.
4.2 Etapas con criterio de entrada/salida
“Interesado”, “calificado” y “propuesta” solo sirven si todos los vendedores entienden qué evidencia mueve al lead. Define criterio observable: datos mínimos, cita agendada, propuesta enviada, pago recibido. Esto mejora automatización y reporting.
4.3 Próxima acción
Toda oportunidad abierta debería tener next_action y fecha. WhatsApp facilita seguimiento, pero sin próxima acción el CRM se convierte en archivo histórico. Automatiza recordatorios internos; no envíes automáticamente al cliente sin revisar ventana, plantilla y consentimiento.
Práctica del módulo
Comprueba lo aprendido
¿Por qué no crear lead por cada conversación?
Genera duplicados y distorsiona pipeline. La conversación es una interacción; la oportunidad es una intención comercial.
¿Qué hace una etapa automatizable?
Tener criterios objetivos y datos disponibles para detectar la transición.
Módulo 5. Automatizaciones y eventos
5.1 Event-driven CRM
Eventos útiles: mensaje recibido, conversación asignada, etapa cambiada, cita creada, pago confirmado, plantilla entregada, baja recibida. Cada evento puede disparar tareas, integraciones o notificaciones. No todas deben generar mensajes al cliente.
5.2 Idempotencia de automatizaciones
Si el mismo webhook o evento llega dos veces, la automatización no debe crear dos reservas o dos oportunidades. Usa event IDs, claves idempotentes y estados de ejecución. Registra quién/qué originó cada cambio.
5.3 Reglas y humanos
Las automatizaciones importantes deben ser visibles para los agentes. Si una regla cambia la etapa, deja un activity log. Si envía un mensaje, muestra el motivo y plantilla. Los humanos necesitan comprender el sistema para corregir excepciones.
Práctica del módulo
Comprueba lo aprendido
¿Qué causa un bucle común?
Un evento generado por una automatización vuelve a cumplir el mismo trigger sin una condición/idempotencia que lo detenga.
¿Por qué registrar actor/origen?
Permite distinguir cambios humanos, API, IA y reglas automáticas al auditar un caso.
Módulo 6. Integración con Meta Ads y atribución
6.1 Modelo de touchpoint
Crea un objeto o registro de touchpoint para fuente, campaña, conjunto/anuncio cuando esté disponible, landing, UTM, click identifiers y fecha. Relaciónalo con contacto y oportunidad. No sobrescribas permanentemente “source” con el último contacto; conserva historial.
6.2 Click-to-WhatsApp
Cuando una conversación proviene de un anuncio, captura el contexto que Meta entregue y asócialo al contacto/conversación. Si tu plataforma recibe referencias publicitarias en webhooks, persístelas antes de que se pierdan en capas de presentación.
6.3 Eventos de conversión
Define qué eventos del CRM representan resultados: lead calificado, cita, checkout, purchase. Envía a sistemas de medición solo datos compatibles con políticas y consentimiento aplicable. La atribución debe poder unir touchpoint→oportunidad→evento.
Práctica del módulo
marketing_touchpoints y conversion_events. Explica cómo atribuirías una compra a un anuncio sin eliminar otros touchpoints previos.Comprueba lo aprendido
¿Por qué conservar historial de fuentes?
Porque una persona puede interactuar con varios anuncios/canales; sobrescribir impide analizar recorridos y modelos de atribución.
¿Qué es una conversión CRM?
Un evento de negocio verificable en tu sistema, como una cita o venta, no simplemente un mensaje recibido.
Módulo 7. Reporting y calidad de datos
7.1 Diccionario de métricas
Define cada KPI: numerador, denominador, zona horaria, ventana y exclusiones. “Tasa de conversión” puede significar ventas/leads, ventas/conversaciones o ventas/oportunidades. Sin diccionario, dos dashboards pueden contradecirse sin que ninguno esté técnicamente roto.
7.2 Integridad
Monitorea porcentaje de contactos sin fuente, oportunidades sin owner, conversaciones sin motivo, mensajes sin wamid, consentimientos sin fecha y eventos de conversión sin valor. La calidad de datos debe tener métricas propias.
7.3 Cohortes
Analiza por fecha de entrada, campaña, país, equipo o producto. Las cohortes permiten distinguir si el desempeño cambió por calidad de leads, por vendedores o por estacionalidad.
Práctica del módulo
Comprueba lo aprendido
¿Qué debe incluir la definición de un KPI?
Fórmula, población, periodo, zona horaria, exclusiones y fuente de datos.
¿Por qué medir datos faltantes?
Porque un KPI calculado sobre datos incompletos puede parecer preciso pero llevar a decisiones erróneas.
Módulo 8. Arquitectura CRM final y gobierno
8.1 Fuente de verdad
Decide qué sistema es authoritative para contacto, oportunidad, consentimiento, pedidos y conversaciones. Dos sistemas que “mandan” sobre el mismo campo sin reglas generan sincronizaciones circulares.
8.2 Integraciones
Utiliza eventos o APIs con contratos claros. Registra external IDs y timestamps. En integraciones bidireccionales, define resolución de conflictos. No uses “último write gana” para datos sensibles sin entender las consecuencias.
8.3 Retención y privacidad
Define cuánto tiempo necesitas mensajes, media, logs y datos de marketing. Minimiza datos y controla acceso por rol. Un CRM conectado a WhatsApp puede contener información sensible de clientes; la conveniencia de tener “todo para siempre” debe equilibrarse con riesgo y obligaciones legales.
Práctica del módulo
Comprueba lo aprendido
¿Qué es una fuente de verdad?
El sistema considerado autoritativo para un dato concreto cuando existen varias copias.
¿Por qué definir resolución de conflictos?
Porque integraciones bidireccionales pueden modificar el mismo dato y producir bucles o valores inconsistentes.
Caso completo: del anuncio a la venta sin perder la historia
Una persona ve un anuncio de un plan empresarial, toca “Enviar mensaje” y entra a WhatsApp. El reto del CRM es conservar la relación entre ese touchpoint, el contacto, la conversación, la oportunidad y la compra, incluso si la venta ocurre días después y participan varios asesores.
1. Ingesta
Al recibir el webhook, el sistema resuelve la cuenta/número empresarial y normaliza el remitente. Busca contacto por identificadores seguros. Si no existe, crea uno con una fuente inicial. Luego crea o reabre una conversación y persiste el contexto publicitario que esté disponible como touchpoint separado.
2. Calificación
Un bot o agente pregunta empresa, necesidad, usuarios y plazo. Esos datos no deben quedarse solamente dentro del texto del chat; los campos útiles pasan al CRM con metadata de origen. La conversación conserva el texto completo, pero el negocio puede consultar “leads con más de 10 usuarios” sin procesar mensajes cada vez.
3. Creación de oportunidad
Cuando el lead cumple criterios, se crea una oportunidad. La oportunidad conserva source_touchpoint_id o una relación many-to-many con touchpoints. El asesor recibe ownership. Un cambio de etapa escribe una actividad; no se limita a sobrescribir stage.
4. Seguimiento fuera de ventana
Si el asesor debe retomar dos días después, el CRM no debe permitir “texto libre porque sí”. La capa de mensajería evalúa ventana y selecciona una plantilla permitida, con consentimiento y propósito. La regla de CRM conoce la intención (“recordar propuesta”), no necesita duplicar toda la política de WhatsApp.
5. Conversión
Cuando se confirma compra, se registra un evento con order_id, valor, moneda, fecha y oportunidad. Ese evento puede alimentar BI y, cuando corresponda, sistemas publicitarios. El CRM conserva la trazabilidad desde adquisición hasta revenue.
SQL conceptual para evitar duplicados
contacts
id PK
phone_e164
email_normalized
customer_external_id
conversations
id PK
contact_id FK
wa_account_id FK
status
assignee_id
opportunities
id PK
contact_id FK
owner_id
stage_key
value
marketing_touchpoints
id PK
contact_id FK
campaign_id
ad_id
click_id
occurred_at
conversion_events
id PK
opportunity_id FK
event_key UNIQUE
event_name
value
occurred_atEste esquema es conceptual, no una receta universal. En un SaaS multiempresa necesitas tenant_id en las entidades y constraints compuestos que impidan cruces entre clientes.
Auditoría de automatizaciones CRM
| Regla | Riesgo | Control |
|---|---|---|
| Crear oportunidad al primer mensaje | Duplicados por conversaciones repetidas | Condición por oportunidad abierta/caso de uso |
| Asignar round-robin | Agente ausente recibe leads | Presence/capacity + fallback |
| Cambiar etapa por palabra | Falso positivo | Evento/criterio estructurado |
| Enviar follow-up a X horas | Ventana/política/opt-in | Messaging policy service |
| Enviar conversión a Ads | Evento duplicado | event_id/idempotencia |
Evaluación CRM
¿Qué entidad representa la interacción actual por WhatsApp?
Conversation. Contact representa a la persona y Opportunity el proceso comercial.
¿Dónde conviene guardar la fuente de campaña?
Como touchpoint/historial relacionado, no solo en un campo que se sobrescribe cada vez.
¿Cómo evitar dos conversiones por el mismo pago?
Usa una clave de evento única/idempotente basada en el evento de negocio.
¿Por qué una etapa necesita criterios?
Para que vendedores, automatizaciones y BI interpreten el pipeline de la misma manera.
¿Qué debe ocurrir si un contacto pide baja?
Actualizar una entidad/preferencia central y bloquear campañas que dependan de ese consentimiento.
¿Por qué separar payload de WhatsApp de campos de CRM?
El payload sirve para auditoría; los campos normalizados permiten consultas, reglas y reporting estable.
Proyecto final del curso
Diseña un CRM para una empresa que capta leads desde Meta Ads, atiende por WhatsApp y vende por un equipo de 15 asesores.
- Modelo Contact/Conversation/Message/Opportunity/Consent.
- Normalización y deduplicación.
- Colas, asignación y SLA.
- Pipeline con criterios objetivos.
- Automatizaciones idempotentes.
- Touchpoints publicitarios.
- Eventos de conversión.
- Diccionario de KPI.
- Reglas de calidad de datos.
- Fuentes de verdad e integraciones.
- Retención y roles de acceso.
Competencias que debes dominar al terminar
- Modelar conversaciones sin duplicar contactos.
- Mantener consentimiento trazable.
- Diseñar colas y SLA.
- Crear pipeline con criterios claros.
- Automatizar con eventos e idempotencia.
- Relacionar Meta Ads con oportunidades.
- Crear reporting y data quality.
- Definir fuentes de verdad e integraciones.
Fuentes oficiales para continuar estudiando
- WhatsApp Business — Developer Hub
- Meta — colección oficial de WhatsApp Business Platform en Postman
- WhatsApp Business — Política de mensajes
- Meta for Developers — WhatsApp Cloud API
- Meta for Developers — precios de WhatsApp Business Platform