Resumen Ejecutivo
Objetivo
Evaluar la viabilidad técnica y comercial de construir una plataforma proprietaria de contact center omnicanal, analizando referencias open source existentes, definiendo arquitectura recomendada, y estimando esfuerzo de desarrollo.
El producto objetivo es una plataforma multi-tenant SaaS dirigida al mercado latinoamericano (con foco inicial en Perú), que integre canales de mensajería, telefonía SIP, automatización de campañas, y herramientas de supervisión de agentes.
Proyectos de Referencia Estudiados
Se analizaron seis proyectos de referencia con diferentes enfoques, licencias y arquitecturas:
| Proyecto | Lenguaje | Licencia | Enfoque Principal |
|---|---|---|---|
| OMniLeads | Python/Django | LGPL v3 | Contact center completo |
| Chatwoot | Ruby/Rails | MIT (core) | Gestión de conversaciones |
| Zammad | Ruby/Rails | AGPL v3 | Helpdesk/ticketing |
| VICIdial | Perl/PHP | AGPLv2 | Dialer y campañas |
| Omnidialer | Python/Flask | No especificada | Dialer ARI |
| Asterisk | C | GPLv2 + excepción | Plataforma telefónica |
Hallazgos Clave
1. Nunca reimplementar SIP/RTP
Asterisk es la única plataforma telefónica viable como sustrato. El soporte completo de códecs, signaling, NAT traversal, y transcoding es un problema resuelto. Cualquier intento de reimplementar desde cero resultaría en años de desarrollo y superficie de errores inmanejable.
Decisión: Delegar toda telefónica a Asterisk vía ARI (Asterisk REST Interface). La aplicación se comunica con Asterisk mediante API REST y WebSocket, sin acceder directamente a canales ni havehash.
2. El patrón de adaptadores de Chatwoot es altamente reutilizable
Chatwoot utiliza un patrón polimórfico de canales donde cada tipo de canal (WhatsApp, Facebook, Email, etc.) implementa una interfaz común. Este patrón, bajo licencia MIT, puede servir como referencia directa para la arquitectura de canales.
Concepto clave: Inbox (polimórfico) → Channel → Conversation → Message
3. OMniLeads tiene el modelo de dominio más completo, pero LGPL limita reutilización
El modelo de dominio de OMniLeads cubre: campañas (4 estados), contactos, colas, IVR, y integración telefónica. Sin embargo, la licencia LGPL v3 impide inclusiones directas en un producto proprietario sin obligar al LGPL de todo el stack.
Decisión: Estudiar el modelo de dominio como referencia conceptual, reimplementar en Go con arquitectura limpia.
4. La licencia AGPL de Zammad impide cualquier reutilización de código
Zammad tiene funcionalidades superiores en RBAC (53 políticas), SLA/escalación, y Knowledge Base. Sin embargo, la licencia AGPL-3.0 prohíbe cualquier reutilización de código en un producto proprietario, incluyendo modificaciones internas.
Decisión: Estudiar únicamente los patrones de diseño, nunca el código fuente.
5. Los algoritmos de pacing de VICIdial son referencia de referencia
VICIdial implementa 6 modos de discador con algoritmos de pacing adaptativo probados en producción durante más de 15 años. Aunque el código es Perl/PHP legado, la lógica del algoritmo es transferible.
Decisión: Estudiar los algoritmos de pacing como referencia para nuestro implementar en Go.
6. Omnidialer muestra la integración moderna vía ARI
Omnidialer demuestra que es posible construir un discador moderno utilizando ARI en lugar de AMI, con flujos más limpios y mejor control de llamadas.
Decisión: Adoptar ARI como interfaz de integración telefónica.
Arquitectura Recomendada
| Aspecto | Decisión |
|---|---|
| Lenguaje | Go 1.22+ |
| Patrón | Modular monolito, Clean/Hexagonal |
| Eventos | Event-first (eventos como ciudadanos de primera clase) |
| Telefónica | Asterisk vía ARI (delegación) |
| Base de datos | PostgreSQL 16+ |
| Cola de mensajes | NATS o Redis Streams |
| Frontend | React/Next.js o Vue/Nuxt (pendiente de decisión) |
| Multi-tenancy | Shared database, schema-per-tenant o row-level security |
| Despliegue | Docker/Kubernetes, cloud-agnostic |
Principios Arquitectónicos
- Hexagonal: Puertos y adaptadores, dominio aislado de infraestructura
- Event-first: Las mutaciones de estado generan eventos; el dominio no conoce el efecto colateral
- Modular monolito: Módulos con límites claros, preparados para extracción futura
- Delegación telefónica: Asterisk como servicio externo, nunca como biblioteca embebida
- Canales como adaptadores: Cada canal es un adaptador que implementa una interfaz común
Estimación de Esfuerzo
Con Desarrollo Tradicional
| Fase | Duración | Equipo |
|---|---|---|
| Investigación y diseño | 2-3 meses | 2-3 senior |
| Core (mensajería, canales) | 4-6 meses | 3-4 devs |
| Telefónica (Asterisk/ARI) | 3-4 meses | 2 devs |
| Dialer y campañas | 3-4 meses | 2-3 devs |
| Supervisión y reporting | 2-3 meses | 2 devs |
| IA y automatización | 2-3 meses | 2 devs |
| Agentes residentes y MCP | 2-3 meses | 2 devs |
| Testing, hardening, deployment | 2-3 meses | 2-3 devs |
| Total | 20-30 meses | 3-5 devs |
Con Codificación Asistida por IA (Agentic Coding)
| Fase | Duración | Equipo |
|---|---|---|
| Investigación y diseño | 1-2 meses | 2 senior |
| Core (mensajería, canales) | 2-4 meses | 2-3 devs |
| Telefónica (Asterisk/ARI) | 2-3 meses | 1-2 devs |
| Dialer y campañas | 2-3 meses | 2 devs |
| Supervisión y reporting | 1-2 meses | 1-2 devs |
| IA y automatización | 1-2 meses | 1-2 devs |
| Agentes residentes y MCP | 1-2 meses | 1-2 devs |
| Testing, hardening, deployment | 1-2 meses | 1-2 devs |
| Total | 11-20 meses | 2-3 devs |
Nota: La estimación agentic asume uso intensivo de IA para generación de código, tests, y documentación, con supervisión humana constante. El ahorro realista es del 30-40%, no del 50-70% como sugieren algunos benchmarks optimistas.
Riesgos Principales
Riesgo 1: Dependencia de WhatsApp/Meta (Alto)
- Cambios unilaterales en políticas de API pueden romper funcionalidad core
- El proceso de verificación de cuenta de business es volátil
- Los costos de conversación pueden cambiar sin previo aviso
- Mitigación: Capa de abstracción sobre proveedores, soporte multi-proveedor WhatsApp (360dialog, Twilio, directo)
Riesgo 2: Complejidad de Multi-tenancy (Alto)
- Aislamiento de datos entre tenants
- Performance under noisy neighbor
- Backup/restore por tenant
- Mitigación: Empezar con shared database + row-level security, migrar a schema-per-tenant si es necesario
Riesgo 3: Licencias de Dependencias (Medio)
- LGPL: Restringe linking dinámico/estático en productos proprietarios
- AGPL: Cualquier uso obliga a open-sourcing completo
- GPLv2: Excepción de protocolo permite apps ARI proprietarias, pero no modificar Asterisk
- Mitigación: Auditoría de licencias antes de cada dependencia, whitelist de licencias permitidas
Riesgo 4: Complejidad Telefónica (Medio)
- NAT traversal, codecs, DTMF, SRTP
- Múltiples proveedores SIP con comportamientos diferentes
- Grabación y compliance
- Mitigación: Delegar 100% a Asterisk, no tocar protocolos SIP/RTP directamente
Riesgo 5: Adopción en Mercado Competitivo (Medio)
- Competencia con Zendesk, Freshdesk, Twilio Flex
- Costos de adquisición de clientes en Latam
- Mitigación: Enfoque en verticalidad (contact center + WhatsApp para Latam), pricing competitivo