Análisis de Canales de Comunicación

WhatsApp Business Platform

Estado actual (2026)

Desde octubre de 2025, la API On-Premise de WhatsApp Business fue retirada definitivamente. La Cloud API es ahora la única vía oficial de integración. Esto simplifica la infraestructura (no hay que mantener servidores locales) pero introduce dependencia directa de la infraestructura de Meta.

Modelo de precios por conversaciones

El sistema de facturación se basa en conversaciones, no en mensajes individuales. Cada conversación tiene una ventana de 24 horas y se clasifica en categorías:

• Marketing: promociones, ofertas, mensajes de marca. Mayor costo.
• Utility: actualizaciones de pedidos, confirmaciones, notificaciones de cuenta. Costo intermedio.
• Autenticación: códigos OTP, verificación en dos pasos. Menor costo.
• Servicio: respuesta a consultas del usuario dentro de la ventana de servicio. Solo se inicia cuando el usuario envía un mensaje.

Una conversación de servicio se inicia automáticamente cuando el usuario contacta al negocio. Las conversaciones de marketing, utility y autenticación son outbound y requieren templates.

Restricciones operativas

• Ventana de 24 horas: después de que el cliente envía un mensaje, solo se puede responder libremente durante 24 horas. Fuera de esta ventana, solo se permiten templates pre-aprobados.
• Templates: mensajes pre-aprobados por Meta para comunicación outbound. Requieren aprobación previa. Se cobran por conversación de template.
• Rate limits: sistema de tiers (Tier 1 a Tier 4) que limita la cantidad de conversaciones simultáneas. Se escala automáticamente con uso consistente.
• Per-phone number: cada número de teléfono está aislado. Un WABA (WhatsApp Business Account) puede tener múltiples números, pero cada número tiene sus propios limits y estado.

Desafíos multi-tenant

Para una plataforma SaaS que sirve múltiples clientes:

• Aislamiento de sesiones: cada tenant debe tener sus credenciales de Cloud API, su WABA, y potencialmente sus propios números de teléfono.
• Webhook routing: un único endpoint público debe enrutar los webhooks al tenant correcto basándose en el phone_number_id o waba_id.
• Credenciales por tenant: cada cliente necesita su propio token de acceso y su propia configuración de Cloud API. No se puede compartir un token entre tenants.
• Per-WABA isolation: la configuración de templates, catálogos y mensajes está a nivel de WABA. Cada tenant necesita su propio WABA o al menos su propio espacio de configuración.

BSP vs Cloud API directa

• BSP (Business Solution Provider): intermediarios como Twilio, 360dialog, Gupshup. Manejan la infraestructura de Cloud API, ofrecen dashboards simplificados. Pros: menos complejidad operativa. Contras: costo adicional, menos control, dependencia de un tercero.
• Cloud API directa: integración directa con la API de Meta. Pros: control total, sin intermediarios. Contras: mayor complejidad operativa, soporte propio.

Recomendación: Cloud API directa para control total y minimizar costos operativos en escala. BSP puede ser útil para MVP o validación rápida.

Restricciones clave para SaaS

• Cada número de teléfono solo puede estar vinculado a un WABA.
• Un WABA puede tener hasta 25 números de teléfono (con requests a soporte se pueden obtener más).
• Los webhooks deben ser endpoints HTTPS públicos con verificación de hub challenge.
• La búsqueda de clientes (Contacts API) requiere opt-in explícito del usuario.

Email

Integración IMAP/SMTP

El email es un canal establecido y bien comprendido. La integración se realiza mediante:

• IMAP (Inbound): conexión a buzones de correo para recibir y sincronizar mensajes.
• SMTP (Outbound): envío de correos a través de servidores configurados.

Procesamiento de inbound

• Forward email parsing: configurar reglas de reenvío que envían emails a una dirección centralizada. Más simple pero menos control.
• Action Mailbox pattern: patrón de Rails que asigna direcciones de email únicas por conversación y procesa automáticamente el contenido.
• Parser personalizado: parsing de headers, MIME, adjuntos y cita de email original para mantener contexto.

Threading y gestión de conversaciones

• Citas de email (quoted replies) para mantener historial.
• Tracking de Message-ID, In-Reply-To, References para agrupar hilos.
• Merge de conversaciones cuando un cliente responde a un thread antiguo.

Deliverability

Para email transaccional y de campañas:

• SPF (Sender Policy Framework): registro DNS que autoriza servidores de envío.
• DKIM (DomainKeys Identified Mail): firma criptográfica que verifica que el email no fue alterado.
• DMARC: política que indica a los receptores cómo manejar emails que fallan SPF/DKIM.

La omisión de cualquiera de estos resultados en spam folders o rechazo directo.

Multi-tenant

• Cada tenant necesita direcciones de email propias o subdominios configurados.
• Los registros DNS deben apuntar al dominio del tenant (o al nuestro con configuración de white-label).
• Configuración de SMTP credentials por tenant si se permite usar servidores propios.

Web Chat

Widget embedding

Un widget JavaScript que se integra en el sitio web del cliente:

• JavaScript SDK: snippet que se carga en el sitio del cliente, maneja la conexión WebSocket y la UI del chat.
• Tema personalizable: colores, logotipo, posición, comportamiento de apertura.
• Pre-chat form: formulario antes de iniciar la conversación para capturar información del visitante (nombre, email, departamento, etc.).
• Visitor tracking: tracking de páginas visitadas, tiempo en sitio, y contexto de navegación.

Infraestructura

• WebSocket: conexión en tiempo real entre el widget y el servidor de mensajería.
• Reconexión automática: manejo de caídas de conexión y reconexión transparente.
• Historial persistente: conversaciones guardadas que persisten entre sesiones del visitante.

Multi-tenant

• Configuración de widget por tenant (colores, logotipo, comportamiento).
• Dominios permitidos para embedding (CORS).
• Tenant-specific WebSocket endpoints o rutas.

Instagram Direct Messages

Integración con Facebook Graph API

Instagram Direct Messages se gestiona a través de la API de Graph de Facebook. Es un canal de alto crecimiento en Latinoamérica, especialmente entre audiencias jóvenes y marcas de estilo de vida.

• Cuenta de negocio requerida: la cuenta de Instagram debe ser un Business o Creator account vinculado a una Facebook Page.
• Webhook events: recepción de mensajes directos via webhook, similar a Facebook Messenger.
• Mismas restricciones de ventana de 24 horas: aplica la misma lógica de conversación de 24 horas que Messenger.
• Template messages: para mensajes fuera de la ventana de servicio, se requiere usar templates de Messenger (mismos que Facebook).

Por qué priorizar Instagram sobre Telegram

• Alcance comercial: Instagram tiene mayor penetración como canal de atención al cliente en LATAM que Telegram.
• Demografía joven: base de usuarios activa en el segmento 18-35, clave para muchas verticales.
• Integración nativa: comparte la infraestructura de Graph API con Facebook Messenger, reduciendo costos de desarrollo.
• Compras sociales: funcionalidades de shopping integradas que habilitan conversaciones de compra.

Limitaciones

• No soporta todos los tipos de mensajes de Messenger (por ejemplo, botones globales limitados).
• Las respuestas automáticas de Instagram (fuera de horario) interactúan con el sistema de 24h.
• La API de Instagram es más restrictiva que la de Messenger en cuanto a tipos de contenido.
• Requiere una Facebook Page vinculada, lo que añade una capa de configuración.

Multi-tenant

• Cada tenant necesita su propia cuenta de Instagram Business vinculada a una Facebook Page.
• Page Access Token por tenant (compartido con Facebook Messenger).
• Webhook routing basado en page_id de Instagram.

TikTok Messaging

TikTok Business API

TikTok ha expandido sus funcionalidades de mensajería para negocios. Aunque es un canal más nuevo que WhatsApp o Instagram, su crecimiento en LATAM lo convierte en un canal estratégico.

Estado actual (2026)

• TikTok Business Chat: funcionalidad de mensajería para cuentas de negocio, disponible en mercados seleccionados.
• Webhook-based: recepción de mensajes vía webhook, similar a otros canales.
• Restricted access: la API completa de TikTok para mensajería aún está en expansión; algunas funcionalidades pueden no estar disponibles en todos los mercados.

Capacidades

• Mensajes de texto y media: soporte básico para diferentes tipos de contenido.
• Comentarios de videos: los negocios pueden responder a comentarios en videos, creando un canal de atención al cliente.
• Formularios de lead: captura de leads desde anuncios de TikTok.
• Integración con TikTok Ads: respuestas automáticas a interacciones generadas por campañas publicitarias.

Por qué priorizar TikTok

• Crecimiento explosivo: TikTok es la plataforma de más rápido crecimiento en LATAM, especialmente en Perú.
• Audiencia joven: acceso directo al segmento Gen Z y Millennials.
• Comercio social: TikTok Shop está expandiéndose rápidamente en la región.
• Diferenciación: pocos proveedores de contact center ofrecen TikTok nativo, ventaja competitiva.

Limitaciones

• La API de mensajería de TikTok es más nueva y menos madura que WhatsApp o Instagram.
• Disponibilidad variable por mercado (algunas funcionalidades pueden no estar disponibles en Perú aún).
• Menor base de usuarios business comparado con WhatsApp o Instagram.
• Dependencia de la evolución de las políticas de TikTok para negocios.

Multi-tenant

• Cada tenant necesita su propia cuenta de TikTok Business.
• Webhook routing basado en el identificador de cuenta de TikTok.
• Configuración de token de acceso por tenant.

Facebook Messenger

Facebook Graph API

Integración completa con la plataforma de mensajería de Facebook:

• Webhook-based: recepción de eventos via webhook configurado en la Facebook App.
• Persistent menu: menú persistente que permite navegación rápida.
• Structured messages: tarjetas, botones, listas, checkouts integrados.
• 24h messaging window: similar a WhatsApp, hay una ventana de 24 horas para respuestas libres. Fuera de esta ventana, solo se permiten tags específicos (confirmation, account_update, etc.).

Consolas de desarrollador

• Facebook App Dashboard para configuración.
• Webhook verification challenge.
• Subscription para campos específicos (messages, messaging_postbacks, etc.).
• Access tokens de página para envío.

Multi-tenant

• Cada tenant necesita su propia Facebook Page vinculada a la aplicación.
• Page Access Token por tenant.
• Webhook routing basado en page_id.

SMS

Proveedores

• Twilio: el más popular, API REST completa, soporte global, precio competitivo.
• MessageBird (Bird): fuerte en Europa y mercados emergentes, API moderna.
• Vonage (Nexmo): buena cobertura en América Latina, API consolidada.

Características

• API simple y bien establecida (HTTP REST).
• Baja complejidad de integración comparada con canales OTT.
• Soporte para DLR (Delivery Reports) para confirmar entrega.
• Callbacks para recepción de mensajes (inbound).
• Numéricos de corta distancia o alfanuméricos para branding.

Multi-tenant

• Cada tenant puede tener su propio número de teléfono (long code o short code).
• O compartimos números con routing basado en prefijos o tags.
• Configuración de webhook por tenant.

Limitaciones

• Sin soporte nativo para multimedia (MMS es limitado y costoso).
• Límite de 160 caracteres por SMS estándar (concatenación para mensajes largos).
• Costo por mensaje (mayor que Telegram, menor que WhatsApp en algunos casos).

SIP/PSTN (Telefonía)

Asterisk como sustrato

La integración telefónica se basa en Asterisk como plataforma de comunicación unificada. Asterisk maneja toda la complejidad del stack de telecomunicaciones:

• SIP/RTP: protocolos de señalización y media. Stack con más de 20 años de desarrollo, basado en pjproject.
• Transcodificación de codecs: negociación y conversión en tiempo real. Crítico para rendimiento.
• NAT traversal: ICE, STUN, TURN para comunicación detrás de NAT. Complejidad enorme de implementar correctamente.
• DTLS-SRTP: encriptación de media. Seguridad crítica.

Nunca reimplementar estas capacidades. Asterisk las resuelve de forma probada y escalable.

Gestión de números DID

• Asignación de números directos inbound a extensiones o contextos.
• Gestión de proveedores de troncales SIP.
• Routing de llamadas entrantes basado en DID.

WebRTC

• Soporte nativo de SIP over WSS (WebSocket Secure).
• ICE, STUN, TURN para traversión de NAT desde navegadores.
• DTLS-SRTP para media encriptada.
• Codec Opus preferido para calidad en navegador.
• Agentes basados en navegador sin necesidad de softphone.

Consideraciones multi-tenant con Asterisk

• Contexts: separación de dialplan por tenant.
• ARI applications: aplicación ARI por tenant o routing basado en tenant ID.
• Configuración vía base de datos: Sorcery realtime para configuración dinámica sin reiniciar.
• Monitoreo de recursos: tracking de canales activos, llamadas concurrentes, y uso por tenant.

Modelo de Capacidad de Canal (Patrón Adapter)

Diseño propuesto

Cada canal se integra mediante un adapter que implementa una interfaz común. El core del sistema nunca asume que todos los canales tienen las mismas capacidades.

// ChannelAdapter define la interfaz que todo adapter de canal debe implementar
type ChannelAdapter interface {
    // SendMessage envía un mensaje a través del canal
    SendMessage(ctx context.Context, msg OutboundMessage) (MessageID, error)
    
    // ReceiveMessage procesa un mensaje entrante del canal
    ReceiveMessage(msg InboundMessage) error
    
    // GetStatus verifica el estado de un mensaje enviado
    GetStatus(ctx context.Context, msgID string) (MessageStatus, error)
    
    // GetMedia descarga o accede a un medio del canal
    GetMedia(ctx context.Context, mediaID string) (io.Reader, MediaType, error)
    
    // GetTemplates obtiene templates disponibles para un tenant
    GetTemplates(ctx context.Context, tenantID string) ([]Template, error)
    
    // ChannelID retorna el identificador único del canal
    ChannelID() string
    
    // Capabilities retorna las capacidades soportadas por este canal
    Capabilities() ChannelCapabilities
}

Matriz de capacidades

Implementación del adapter

Cada adapter se registra en un ChannelRegistry que permite:

• Descubrimiento de canales disponibles.
• Routing de mensajes al adapter correcto.
• Fallback cuando un canal no está disponible.
• Métricas por canal (mensajes enviados, entregados, fallidos).

type ChannelRegistry struct {
    adapters map[string]ChannelAdapter
}

func (r *ChannelRegistry) Get(channelID string) (ChannelAdapter, error) {
    adapter, ok := r.adapters[channelID]
    if !ok {
        return nil, ErrChannelNotFound
    }
    return adapter, nil
}

func (r *ChannelRegistry) Capabilities() map[string]ChannelCapabilities {
    caps := make(map[string]ChannelCapabilities)
    for id, adapter := range r.adapters {
        caps[id] = adapter.Capabilities()
    }
    return caps
}

Principios del modelo

1. El core no asume capacidades: la lógica de negocio consulta las capacidades del canal antes de intentar usar una funcionalidad.
2. Graceful degradation: si un canal no soporta una funcionalidad (ej: typing indicators en email), la interfaz de usuario muestra una alternativa o omite la funcionalidad.
3. Extensibilidad: agregar un nuevo canal solo requiere implementar la interfaz ChannelAdapter. No se necesita modificar el core.
4. Testing: cada adapter puede ser testeado de forma aislada con mocks de la interfaz.