Construir vs Reutilizar vs Integrar

Definiciones de estrategia

Telefonía

Asterisk: INTEGRATE

Mantener Asterisk como proceso separado, controlar vía ARI.

Justificación:

• Asterisk resuelve problemas de telecomunicaciones que tomarían años reimplementar.
• La protocol exception de GPLv2 permite integración propietaria.
• El proceso separado proporciona aislamiento de fallas.
• Escalamiento horizontal vía Kamailio es probado.

Riesgo: dependencia de una única plataforma. Mitigación: la interfaz ARI es estable y bien mantenida.

SIP/RTP/WebRTC: DELEGATE a Asterisk

Nunca reimplementar estos protocolos.

Justificación:

• Complejidad abrumadora de implementación correcta.
• Problemas de seguridad si se implementa incorrectamente.
• Asterisk tiene 20+ años de pruebas y correcciones.

Transcodificación de codecs: DELEGATE a Asterisk

Justificación:

• Dependiente de plataforma (SIMD, hardware acceleration).
• Performance-critical.
• Asterisk maneja negotiation y transcodificación automáticamente.

Grabación: DELEGATE a Asterisk, metadata en nuestra DB

Justificación:

• Asterisk maneja la grabación de media (MixMonitor, bridge recording).
• Nosotros almacenamos metadatos: tenant_id, agent_id, conversation_id, duration, tags.
• Pipeline post-proceso (transcripción, almacenamiento) es nuestro.

IVR: BUILD sobre ARI

Justificación:

• El IVR es lógica de negocio: menús dinámicos, personalización por tenant, integración con CRM.
• Asterisk provee media (reproducción de audio, DTMF).
• Nosotros controlamos el flujo, las decisiones, y la experiencia.

ACD/Queues: Híbrido

• BUILD: lógica de routing inteligente (skills-based, round-robin personalizado, por datos del CRM).
• DELEGATE: media handling a colas de Asterisk (ring, hold, music-on-hold, queue members).

Justificación:

• Las estrategias nativas de Asterisk son limitadas para routing complejo.
• El manejo de media (ring, hold) es mejor delegar a Asterisk.

Predictive Dialer: BUILD

Justificación:

• El algoritmo de pacing es propietario y diferenciador.
• Controlamos: velocidad de discado, detección de contestación, throttling.
• Asterisk provee: media, canales, grabación.

Canales de Mensajería

WhatsApp Business: EXTERNAL SERVICE

Consumir la Cloud API de Meta directamente.

Justificación:

• No hay alternativa open source (la API es proprietaria).
• BSPs agregan costo y complejidad sin beneficio significativo en escala.
• Cloud API es la dirección oficial de Meta.

Riesgo: dependencia de Meta, cambios de pricing. Mitigación: adapter que abstrae la interfaz, facilitando migración a BSP si es necesario.

Telegram: EXTERNAL SERVICE

Consumir la Bot API de Telegram.

Justificación:

• API gratuita, bien documentada, estable.
• No hay alternativa open source que la mejore.

Email: BUILD

Implementar adapters IMAP/SMTP y lógica de conversación.

Justificación:

• IMAP/SMTP son protocolos estándar, bien comprendidos.
• La lógica de threading y conversation management es core domain.
• Necesitamos control total sobre parsing, routing, y processing.

Componentes:

• Adapter IMAP para inbound.
• Adapter SMTP para outbound.
• Parser de email (headers, MIME, adjuntos).
• Conversation threading (Message-ID, In-Reply-To).
• Deliverability (SPF, DKIM, DMARC configuration).

Web Chat: BUILD

Widget JavaScript y WebSocket server.

Justificación:

• Experiencia del usuario es diferenciadora.
• Necesitamos control total sobre tracking, pre-chat forms, y personalización.
• WebSocket server es core de la plataforma de mensajería.

Componentes:

• JavaScript SDK (widget embedding).
• WebSocket server (realtime).
• Theme engine (personalización visual).
• Visitor tracking (analytics).
• Pre-chat forms (lead capture).

Instagram/Facebook Messenger: EXTERNAL SERVICE

Consumir la Graph API de Facebook.

Justificación:

• API proprietaria, no hay alternativa open source.
• Mismas restricciones que WhatsApp (ventana 24h, templates).

SMS: EXTERNAL SERVICE (Twilio/Vonage)

Consumir APIs de proveedores SMS.

Justificación:

• Integración con carriers es compleja y regulada.
• Proveedores manejan compliance, throughput, y deliverability.
• API simple, bajo costo de integración.

Multi-tenant: cada tenant puede tener su propio número o compartimos con routing.

Channel Adapter Pattern: BUILD

Nuestro patrón de adapters para canales.

Justificación:

• Abstracción que permite agregar canales sin modificar el core.
• Interface común para testing y mocking.
• Capability matrix para conocimiento de capacidades por canal.

Contact & CRM

Gestión de contactos: BUILD

Core domain del sistema.

Justificación:

• El CRM es diferenciador para la plataforma.
• Necesitamos control total sobre esquema, atributos, y comportamiento.
• Integración estrecha con conversaciones y campañas.

Atributos personalizados: BUILD

Schema flexible con JSONB en PostgreSQL.

Justificación:

• Cada tenant tiene necesidades diferentes de atributos.
• JSONB en PostgreSQL es la solución ideal: flexible, queryable, performant.
• Validación de schema a nivel de aplicación.

Gestión de empresas: BUILD

Simple, core domain.

Justificación:

• Relación empresa-contacto es fundamental para B2B.
• Integración con conversation history por empresa.

Lead Scoring: DEFER a V2

Justificación:

• Requiere datos históricos significativos para ser útil.
• ML model necesita entrenamiento con datos reales.
• Funcionalidad de valor agregado, no core para MVP.

Conversation Management

Inbox: BUILD

Core domain del sistema.

Justificación:

• La experiencia del inbox es el corazón del product.
• Necesitamos control total sobre UI, routing, y comportamiento.
• Integración con todos los canales y contexto del CRM.

Asignación/Routing: BUILD

Round-robin, skills-based, y algoritmos personalizados.

Justificación:

• El routing inteligente es diferenciador competitivo.
• Necesitamos flexibilidad para diferentes modelos de negocio.
• Integración con datos de agentes y contactos.

Auto-asignación: BUILD

Nuestros algoritmos de auto-asignación.

Justificación:

• Cada empresa tiene reglas diferentes.
• Integración con lógica de negocio (horarios, skills,负载).

SLA: BUILD (inspirado en Zammad)

Modelo de escalación basado en Zammad.

Justificación:

• SLA es core domain para soporte.
• El modelo de Zammad es sólido pero necesitamos adaptarlo a nuestro contexto.
• Importante: inspiración en patrones, no copia de código (Zammad es AGPL).

Macros/Respuestas predefinidas: BUILD (inspirado en Chatwoot)

Sistema de macros y canned responses.

Justificación:

• Funcionalidad estándar en contact centers.
• El patrón de Chatwoot es bueno, lo adaptamos.
• Importante: Chatwoot core es MIT, seguro para referencia.

Campañas

Gestión de campañas: BUILD

Core domain del sistema.

Justificación:

• La plataforma de campañas es diferenciadora.
• Necesitamos control total sobre lifecycle, scheduling, y pacing.
• Integración con telefónica y mensajería.

Algoritmo de pacing: BUILD (inspirado en VICIdial)

Algoritmo adaptivo de pacing para discado predictivo.

Justificación:

• El pacing es el core del predictive dialer.
• El algoritmo adaptivo de VICIdial es referencia pero necesitamos customización.
• CRITICO: VICIdial es AGPLv2. NO podemos usar código. Solo inspiración en el patrón/algoritmo a nivel conceptual.
• Implementación propia del algoritmo basado en la misma lógica matemática.

Gestión de leads: BUILD (patrón hopper de VICIdial)

Sistema de hopper para gestión de leads en campañas.

Justificación:

• El hopper system es un patrón comprobado para campañas outbound.
• El concepto es simple: cola de leads priorizada para discado.
• CRITICO: no usar código de VICIdial (AGPL). Implementación propia del patrón.

DNC Management: BUILD

Gestión de listas de no llamar.

Justificación:

• Requisito legal (TCPA, leyes locales).
• Necesitamos control total sobre verificación y compliance.
• Integración con campañas y telefónica.

Automatización

Rules Engine: BUILD (inspirado en Chatwoot)

Motor de reglas condition/action.

Justificación:

• Cada tenant tiene reglas diferentes de automatización.
• El patrón de Chatwoot (condition → action) es sólido.
• Lo implementamos sobre nuestro event system.
• Chatwoot core es MIT, seguro para referencia.

Triggers: BUILD (inspirado en Zammad)

Sistema de triggers basado en eventos.

Justificación:

• Los triggers de Zammad son potentes (event-driven, condicionales).
• Lo adaptamos a nuestro modelo de eventos.
• Importante: Zammad es AGPL. Solo inspiración en el patrón, no código.

Webhooks: BUILD

Delivery de webhooks outbound.

Justificación:

• Funcionalidad estándar para integraciones.
• Necesitamos retry logic, delivery tracking, y configuración por tenant.
• Implementación straightforward sobre nuestro event system.

AI y Agentes Autónomos

Integración LLM: BUILD abstracción, EXTERNAL SERVICE para proveedores

Capa de abstracción sobre proveedores de AI.

Justificación:

• La interfaz de AI es parte de nuestra plataforma.
• Los proveedores cambian (OpenAI, Anthropic, Google).
• Necesitamos switching entre proveedores sin modificar la lógica de negocio.

type AIClient interface {
    Classify(ctx context.Context, text string, categories []string) (Classification, error)
    Summarize(ctx context.Context, text string, maxLength int) (string, error)
    Sentiment(ctx context.Context, text string) (Sentiment, error)
    SuggestReply(ctx context.Context, conversation []Message) (string, error)
    DetectIntent(ctx context.Context, text string) (Intent, error)
    Translate(ctx context.Context, text string, targetLang string) (string, error)
}

Agentes Residentes Autónomos: BUILD

Agentes de IA que monitorean el event bus y toman acciones autónomas.

Justificación:

• Diferenciador clave del producto.
• Ningún competidor open source ofrece esto.
• Lógica de negocio propietaria de alto valor.
• Requiere integración profunda con el dominio.

Decisiones por agente:

• KPI Guardian: BUILD (core diferenciador)
• Security Sentinel: BUILD (core diferenciador)
• Policy Engine: BUILD (core diferenciador)
• Health Monitor: BUILD (puede reutilizar métricas existentes)

MCP Server (Model Context Protocol): BUILD

Servidor para integración externa con herramientas de IA y chatbot interno.

Justificación:

• Interfaz externa de la plataforma.
• Permite integración con Claude Desktop, Cursor, y otras herramientas MCP.
• Chatbot interno diferenciador.
• Requiere seguridad aislada por tenant.

Sentiment Analysis: EXTERNAL SERVICE (OpenAI/Anthropic API)

Justificación:

• Modelos de AI son mejores que cualquier implementación casera.
• Costo bajo por request.
• Calidad constantemente mejorada por los proveedores.

Summarization: EXTERNAL SERVICE

Justificación:

• LLMs son excelentes para summarización.
• La calidad supera cualquier implementación rule-based.

Suggested Replies: EXTERNAL SERVICE

Justificación:

• LLMs generan respuestas contextuales de alta calidad.
• Requiere fine-tuning que los proveedores manejan.

Classification: EXTERNAL SERVICE

Justificación:

• Modelos de clasificación entrenados son más precisos.
• Fine-tuning disponible en la mayoría de proveedores.

Intent Detection: EXTERNAL SERVICE

Justificación:

• Detección de intención requiere modelos de NLP.
• Los proveedores ofrecen modelos pre-entrenados y fine-tuning.

BYOK (Bring Your Own Key): DEFER a V2

Justificación:

• Requiere infraestructura de key management.
• Funcionalidad enterprise, no core para MVP.
• Complejidad de billing y rate limiting por customer.

Reporting

Dashboard en tiempo real: BUILD

WebSocket + queries optimizadas.

Justificación:

• Métricas en tiempo real son core para supervisores.
• Necesitamos control total sobre qué métricas展示 y cómo se计算。
• Integración con nuestro event system para actualizaciones live.

Reportes históricos: BUILD

Agregaciones en PostgreSQL.

Justificación:

• PostgreSQL tiene capacidades de agregación suficientes.
• Queries optimizadas con índices y materialized views.
• Exportación a CSV/PDF.

Exportación: BUILD

CSV y PDF generation.

Justificación:

• Funcionalidad estándar, baja complejidad.
• CSV: stdlib de Go. PDF: librerías como gofpdf o wkhtmltopdf.

Autenticación

OAuth2/SAML: BUILD (usar librerías maduras)

Justificación:

• Implementaciones open source probadas (go-oauth2, saml2).
• No reinventar criptografía.
• Configuración por tenant (proveedores de IdP diferentes).

2FA/TOTP: BUILD (usar librerías maduras)

Justificación:

• Librerías como pquerna/otp son estándar.
• Implementación straightforward.

LDAP: INTEGRATE (via librería)

Justificación:

• Integración con directorios enterprise.
• Librerías como go-ldap manejan la complejidad del protocolo.

Concerns de Licensing

Licencias seguras para uso

Licencias problemáticas

Reglas estrictas

1. Nunca copiar código de AGPL en nuestro producto propietario.
2. Inspiración conceptual está permitida: entender el patrón, reimplementar en Go.
3. Chatwoot MIT core es seguro para referencia y adaptación de patrones.
4. Asterisk GPLv2 es seguro para integración vía ARI/AMI (protocol exception).
5. Todo componente nuevo requiere revisión de licencia antes de integración.
6. Documentar todas las decisiones de licensing para revisión legal futura.

Ítems que requieren revisión legal

1. OMniLeads (LGPL v3): ¿estamos vinculando contra componentes LGPL? Si es así, debemos disclose modificaciones.
2. Asterisk (GPLv2 + protocol exception): confirmar que nuestro uso de ARI cae dentro de la protocol exception.
3. Patrones de VICIdial: confirmar que la reimplementación del algoritmo de pacing no constituye derivative work.
4. Webhooks a servicios de terceros: revisar términos de servicio de cada proveedor.
5. Uso de modelos de AI: revisar términos de uso de OpenAI/Anthropic para fine-tuning y datos de clientes.