Resumen Ejecutivo

Este documento consolida las conclusiones de la investigación técnica y de mercado para construir una plataforma SaaS de contact center omnicanal para Latinoamérica. Cada respuesta se deriva del análisis comparativo de OMniLeads, Chatwoot, Zammad, VICIdial, Omnidialer y de la experiencia práctica en teleconmutación con Asterisk.

1. ¿Qué producto estamos realmente intentando construir?

Un plataforma SaaS omnicanal y contact center para Latinoamérica (empezando por Perú) que unifica WhatsApp, Telegram, email, web chat, redes sociales y telefonía en un solo inbox, con herramientas de campañas, routing, supervisión e IA.

No es un simple wrapper de WhatsApp. Es una herramienta de productividad para equipos de soporte y ventas que necesitan gestionar todas las conversaciones de clientes desde una única interfaz, con inteligencia artificial integrada para automatizar respuestas y mejorar la eficiencia.

2. ¿Qué funcionalidades de OMniLeads son relevantes?

Las funcionalidades de OMniLeads que aportan valor y debemos estudiar son:

• Gestión de campañas: Tipos Manual, Dialer, Incoming y Preview con configuración flexible por cola
• Modelo de colas (Queue): Estrategias de routing como Least Recent, Fewest Calls, Random y Round Robin con pesos configurables
• IVR con grafo de destinos: Modelo DestinoEntrante → OpcionDestino que permite construir flujos telefónicos complejos sinhardcodear
• Gestión de contactos: Campos flexibles guardados en JSON que permiten atributos personalizados por tenant
• Integración con dialer predictivo: Algoritmo de pacing que ajusta velocidad de llamadas según disponibilidad de agentes
• Grabación de llamadas: Sistema de MixMonitor con almacenamiento y búsqueda
• Supervisión en tiempo real: Monitoreo de agentes y colas con métricas de performance

3. ¿Cuáles son irrelevantes para nuestro mercado inicial?

Las siguientes funcionalidades no aplican para nuestro contexto SaaS moderno:

• Integración con Vtiger CRM: Nuestros clientes no usan Vtiger; preferirán integraciones con CRMs populares (HubSpot, Salesforce, Pipedrive)
• Kamailio SIP proxy: Innecesario en un SaaS multi-tenant donde Asterisk maneja la telefinternamente
• Template de dialplan generation: Demasiado específico de configuración manual de Asterisk; en nuestro caso Asterisk será un proceso controlado via ARI
• Módulo de backoffice: No aplica para un producto SaaS donde el admin panel se construye desde cero

4. ¿Qué ya resuelve Chatwoot?

Chatwoot establece el estándar para un inbox omnicanal:

• Patrón de adapter de canales: 12 canales via Inbox polimórfico (WhatsApp, Facebook, Twitter, Telegram, LINE, SMS, Web Chat, Email, API, etc.)
• Sistema de eventos: Dispatchers síncronos y asíncronos que desacoplan el procesamiento de canales
• Ciclo de vida de conversaciones: open → resolved → pending → snoozed con reglas de auto-resolución
• Auto-asignación round-robin: Distribución equitativa de conversaciones entre agentes disponibles
• Gestión de contactos: Atributos personalizados con búsqueda y merge automático
• Widget de web chat: Personalizable con API para embedding en sitios web
• API REST completa: Endpoints para todas las operaciones, ideal para integraciones

Nota importante: Chatwoot usa licencia MIT, lo que permite reutilizar patrones de diseño, aunque recomendamos construir nuestra propia implementación para control total.

5. ¿Qué aporta Zammad?

Zammad aporta madurez en gestión de soporte:

• Modelo de tickets: Estados, prioridades y SLA con seguimiento de tiempo de respuesta
• Sistema de escalación: Escalamiento automático basado en horarios laborales y tiempo de espera
• Knowledge Base: Categorías, artículos con versionado y permisos por grupo
• RBAC sofisticado: 53 políticas de permisos que cubren todos los escenarios de control de acceso
• Gestión de组织: Organizaciones con miembros y roles

ADVERTENCIA: Zammad usa licencia AGPL, lo que impide reutilizar cualquier código fuente. Solo podemos estudiar sus patrones de diseño y modelo de dominio.

6. ¿Qué aporta VICIdial?

VICIdial es el estándar de la industria para call centers:

• Algoritmo de pacing predictivo: Battle-tested con 3 modos adaptativos (conservador, normal, agresivo)
• Sistema de hopper: Gestión eficiente de leads con buffer circular y priorización
• Gestión DNC: Lista de no-contactar integrada con reglas por campaña
• Manejo de callbacks: Sistema completo de programación de devoluciones de llamada
• Reportes extensos: 50+ scripts SQL para métricas de performance, ventas y calidad

ADVERTENCIA: VICIdial usa licencia AGPLv2, lo que impide reutilizar cualquier código fuente. Solo podemos estudiar su algoritmo de pacing como referencia para nuestra implementación.

7. ¿Qué aporta Omnidialer?

Omnidialer aporta innovación técnica:

• Integración moderna con ARI: No usa AMI (obsoleto), sino la interfaz REST de Asterisk
• Arquitectura con Gearman: Sistema de colas de trabajo para escalabilidad horizontal
• Sistema de reglas de incidencia: Retry inteligente con backoff exponencial
• Distribución justa por prioridad: Algoritmo que equilibra carga entre campañas con diferentes pesos

8. ¿Qué debe delegarse permanentemente a Asterisk?

Asterisk es un whiskey Viejo, no un framework. Debe manejar todo lo relacionado con medios:

Filosofía: Asterisk como black box controlada via ARI, no como framework para construir lógica de negocio.

9. ¿Qué componentes open source podemos reutilizar directamente?

La respuesta corta es casi ninguno por restricciones de licencia:

Conclusión: Construiremos nuestra propia implementación inspirada en patrones probados, sin código de referencia con licencias restrictivas.

10. ¿Qué componentes conviene solamente estudiar?

Estos componentes son valiosos como referencia de diseño, pero no debemos copiar código:

• Modelo de dominio de OMniLeads: Cómo estructuran campañas, colas, contactos y reglas
• RBAC de Zammad: Sistema de permisos granular que cubre casos edge
• Sistema de tickets de Zammad: Estados, prioridades, SLA y escalamiento
• Knowledge Base de Zammad: Categorías, artículos y búsqueda
• Sistema de reporting de VICIdial: Métricas clave para call centers
• Manejo de IVR de OMniLeads: Grafo de destinos para flujos telefónicos

11. ¿Dónde tiene sentido construir tecnología propietaria?

Estos componentes son nuestra ventaja competitiva y deben construirse internamente:

1. Motor de routing/asignación de conversaciones: Lógica central de distribución entre canales y agentes
2. Algoritmo de pacing predictivo: Predictive dialer adaptativo para campañas salientes
3. Abstracción de canales (adapter pattern): Capa unificada que normaliza WhatsApp, Telegram, email, etc.
4. Multi-tenancy y aislamiento de datos: Arquitectura de seguridad desde el diseño
5. Procesamiento de eventos en tiempo real: Sistema de pub/sub para actualizaciones instantáneas
6. Consola de agentes unificada: Interfaz web que integra todos los canales
7. Abstracción de IA: Puertos y adaptadores para LLMs que permita cambiar proveedores
8. Reglas de automatización: Motor de reglas para auto-respuestas y flujos
9. Agentes residentes autónomos: 4 agentes de IA que monitorean y optimizan el sistema
10. Servidor MCP: Interfaz para integración externa con herramientas de IA y chatbot interno

12. ¿Dónde está nuestra posible diferenciación?

Nuestras ventajas competitivas potenciales:

• Experiencia de agente unificada: Todos los canales en un solo inbox con contexto completo
• IA práctica (no decorativa): Resumen de conversaciones, suggested replies, routing inteligente
• Agentes residentes autónomos: 4 agentes de IA que optimizan KPIs, detectan amenazas, gestionan políticas y monitorean salud - NINGÚN competidor open source ofrece esto
• MCP Server: Integración con herramientas de IA externas y chatbot interno en lenguaje natural
• Mercado LATAM: WhatsApp nativo, multi-idioma, compliance local, soporte en español
• Pricing transparente: Sin costos ocultos, modelo predecible para clientes LATAM
• Facilidad de onboarding: Setup en minutos, no semanas; experiencia tipo “plug and play”

13. ¿Qué arquitectura Go proponemos?

┌─────────────────────────────────────────────────────────┐
│                     Load Balancer                        │
└─────────────┬───────────────┬───────────────┬──────────┘
              │               │               │
    ┌─────────▼───────┐ ┌────▼────────────┐ ┌▼──────────────┐
    │   Core API       │ │  Messaging      │ │  WebSocket    │
    │   (Go)           │ │  Gateway (Go)   │ │  Server (Go)  │
    │   REST + gRPC    │ │  Async + Queue  │ │  Real-time    │
    └─────────┬───────┘ └────┬────────────┘ └┬──────────────┘
              │               │               │
    ┌─────────▼───────────────▼───────────────▼──────────┐
    │              PostgreSQL + Redis                      │
    └──────────────────────┬──────────────────────────────┘
                           │
              ┌────────────▼────────────┐
              │      Asterisk (ARI)      │
              │   SIP/RTP/WebRTC Stack   │
              └─────────────────────────┘

• Modular monolith primero: Clean Architecture / Hexagonal
• Event-first logic: Eventos como ciudadanos de primera clase
• PostgreSQL: Persistencia principal con row-level security
• Redis: Cache, pub/sub, rate limiting
• WebSocket: Comunicación real-time con clientes
• gRPC: Fronteras entre procesos cuando sea necesario
• Asterisk: Proceso separado controlado via ARI

14. ¿Necesitamos Python y exactamente dónde?

Probablemente NO para el MVP.

Python sería útil solo si existe ventaja concreta:

Recomendación: Empezar 100% Go. Revisar si Python es necesario cuando lleguemos a pipelines de datos o ML avanzado.

15. ¿Qué bounded contexts existen?

┌─────────────────────────────────────────────────────────┐
│                    Bounded Contexts                      │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  1. Core                                                  │
│     └─ Identity, Tenants, Users, RBAC                     │
│                                                          │
│  2. Messaging Gateway                                     │
│     └─ Channel Adapters, Normalization, Events            │
│                                                          │
│  3. Conversations                                         │
│     └─ Inbox, Assignment, Lifecycle, Context              │
│                                                          │
│  4. Contacts & CRM                                        │
│     └─ Contacts, Companies, Attributes, Segments          │
│                                                          │
│  5. Campaigns                                             │
│     └─ Outbound, Pacing, Scheduling, DNC                  │
│                                                          │
│  6. Telephony                                             │
│     └─ Asterisk Integration, ARI, IVR, Recording          │
│                                                          │
│  7. Dialer                                                │
│     └─ Predictive/Progressive/Preview, Hopper             │
│                                                          │
│  8. Reporting                                             │
│     └─ Metrics, Dashboards, Exports, Analytics            │
│                                                          │
│  9. Workers                                               │
│     └─ Background Jobs, Webhooks, Email Processing        │
│                                                          │
│  10. AI                                                   │
│      └─ LLM Integration, Classification, Suggestions      │
│                                                          │
└─────────────────────────────────────────────────────────┘

16. ¿Qué debería ser un módulo?

Estos bounded contexts deben ser módulos dentro del mismo binario:

Implementación: Límites via Go packages con interfaces explícitas. El módulo expone una API interna clara.

17. ¿Qué debería convertirse en proceso/servicio independiente?

Estos componentes necesitan escalabilidad y aislamiento separados:

18. ¿Realmente necesitamos microservicios?

NO para empezar. Un modular monolith cubre MVP y V1.

Criterios para separar:

• Razón técnica convincente (escalabilidad, aislamiento)
• Razón operacional (equipo separado, despliegue independiente)
• Carga diferenciada (un componente con 10x más tráfico)

Arquitectura recomendada: Máximo 4-5 procesos grandes, no 20-50 microservicios.

MVP:          1 binario (modular monolith)
V1:           2-3 procesos (gateway, telephony, main)
V2:           4-5 procesos (agregar dialer, workers)

19. ¿Cuál es el MVP?

Alcance mínimo viable (3-4 meses):

No incluido en MVP: Predictive dialer, AI, knowledge base, advanced reporting, video calls.

20. ¿Cuál es el camino hacia un contact center completo?

MVP (3-4 meses)
│
├─ WhatsApp + Web Chat + Email + SMS
├─ Inbox unificado básico
├─ Contactos con atributos
├─ Routing round-robin
├─ Telefonía básica (IVR simple)
├─ Auth multi-tenant
└─ API REST
    │
    ▼
V1 (4-6 meses adicionales)
│
├─ Telegram + Facebook Messenger + Instagram
├─ Campañas salientes (manual/preview)
├─ Routing avanzado (skills-based)
├─ Reporting básico
├─ Integraciones CRM
└─ Knowledge Base básica
    │
    ▼
V2 (4-6 meses adicionales)
│
├─ Predictive dialer
├─ AI (resumen, suggested replies)
├─ SLA y escalamiento
├─ Reporting avanzado
├─ Quality assurance
└─ Advanced automation
    │
    ▼
Enterprise (futuro)
│
├─ On-premise option
├─ Advanced analytics
├─ Custom integrations
├─ Multi-region
└─ SOC2/HIPAA compliance

21. ¿Cuál sería el esfuerzo tradicional?

Estimación con equipo de desarrollo convencional:

22. ¿Cuál sería el esfuerzo con agentic coding al 20%?

Con herramientas de coding asistido por IA operando al 20% de eficiencia:

23. ¿Cuál sería el esfuerzo con agentic coding al 10%?

Con herramientas de coding asistido por IA operando al 10% de eficiencia (máxima automatización):

Nota: Estas estimaciones asumen que la IA puede generar código confiable para componentes estandarizados (CRUD, API, UI), pero no para lógica de negocio compleja (predictive dialer, routing inteligente).

24. ¿Qué partes no se aceleran proporcionalmente con IA?

Estos componentes requieren intervención humana significativa:

25. ¿Cuáles son los principales riesgos técnicos y comerciales?

26. ¿Qué desconocemos todavía?

Preguntas abiertas que requieren investigación:

• Demanda real: ¿Cuántos contact centers en Perú/LATAM necesitan esta solución?
• Volúmenes: ¿Cuántos mensajes por tenant esperamos? (100/día vs 100K/día)
• Compliance: ¿Qué requisitos específicos por país? (Ley de Protección de Datos en Perú)
• Costos WhatsApp: ¿Cuánto costará realmente por conversación?
• Equipo: ¿Qué capacidad de desarrollo tenemos disponible?
• Integraciones: ¿Qué sistemas pedirán integrar los primeros clientes?

27. ¿Qué experimentos/prototipos deberíamos realizar antes de comprometernos?

Prototipos obligatorios antes del MVP:

Inversión total en prototipos: ~6-8 semanas de un solo desarrollador.

Criterio de decisión: Si los prototipos fallan en aspectos críticos (latencia, costos, complejidad), reconsiderar alcance del MVP.

Tabla Resumen

Conclusión Final

La construcción de una plataforma omnicanal de contact center para Latinoamérica es un proyecto ambicioso pero factible. Las clave está en:

1. Empezar con un MVP acotado (3-4 meses) que demuestre valor real
2. Aprender de proyectos existentes sin depender de su código (licencias restrictivas)
3. Construir tecnología propietaria donde exista ventaja competitiva
4. Usar agentic coding para acelerar componentes estandarizados
5. Validar con prototipos antes de comprometer recursos completos

El mercado LATAM tiene necesidades específicas (WhatsApp nativo, multi-idioma, compliance local) que representan una oportunidad real para una solución diseñada desde cero para esta región.