1 · Configurar
Catálogos (etapas, motivos, categorías), equipos y estrategias de reparto, permisos por módulo y acción, datos de la empresa, horarios y apariencia (11 presets).
Sin códigoLa mayoría de los CRM guardan al mismo cliente varias veces (lead, contacto, cuenta). Aynflow lo registra una vez y modela procesos e interacciones sobre esa identidad. Modelo técnico: Entidad → Proceso → Interacción.
Todo lo que ocurre con un cliente cabe en una de estas tres categorías. Por eso el historial nunca se fragmenta.
Quién es. Se crea una sola vez y no tiene "estado comercial": no es lead ni cliente, es la persona o empresa. Documento, teléfonos y correos sirven para encontrarla y evitar duplicados.
Qué está pasando con ella. Un lead es un proceso; cuando se califica, se abre una oportunidad; cuando se gana, nace una venta. Cada proceso tiene dueño, equipo, etapa y motivo.
Qué se habló o se hizo. Mensajes de webchat y del bot, llamadas, notas, pases entre agentes y hasta las lecturas de datos sensibles quedan en la misma línea de tiempo.
Como el lead no es una copia del cliente sino un paso sobre él, cuando Rosa vuelve a escribir seis meses después el sistema no crea "Rosa 2": abre un nuevo proceso sobre la misma Rosa, con todo su historial a la vista del agente y del bot.
Siguiendo a Rosa Quispe, de la ferretería, desde el primer clic hasta el cobro. Cada paso corresponde a un módulo real.
Rosa llena el formulario de tu landing. Marketing Analytics registra la visita y convierte el envío en un lead del CRM (idempotente: si reenvía, no duplica).
Abre el webchat. El flujo "Cotizar" publicado recoge metros y tipo de producto y, al detectar intención de compra, hace pase a humano a la cola de ventas.
El motor revisa presencia y horario del equipo y asigna por menor carga. Marcos recibe una notificación con la ficha y el chat completos.
Marcos cotiza con productos del catálogo, exporta el PDF y avanza la oportunidad. Registra la llamada de confirmación como interacción.
Oportunidad ganada → venta. En el POS se cobra dentro de la sesión de caja abierta; el stock del almacén baja y se emite el comprobante.
Rosa escribe por un cambio. El agente de turno ve la venta #0481, la cotización y el chat anterior sin pedirle nada.
El supervisor ve tiempos de primera respuesta, asignaciones del día y adherencia horaria; compara equipos por periodo y exporta.
Una función por cliente avisa al ERP externo y deja constancia en la ficha. Todo corre aislado y auditado.
Los equipos son por dominio: ventas (CRM), salón (restaurante), caja (POS). Un usuario puede estar en varios. Cada equipo define cómo se reparte su cola y quién la supervisa.
No se trata de tener más funciones, sino de que las que hay apunten al mismo registro.
| CRM tradicional | Aynflow |
|---|---|
| Lead → Contacto → Cliente: el mismo humano tres veces | Una entidad; lead y oportunidad son procesos sobre ella |
| El chat vive en otra herramienta y se copia a mano | Inbox, bots y CRM sobre la misma identidad y el mismo hilo |
| El bot es un producto aparte que "crea tickets" | El bot entrega a la cola del equipo con contexto completo |
| Asignación manual o por turnos en una hoja | Round-robin / menor carga según presencia y horario |
| Ventas, caja e inventario en otro sistema | Oportunidad ganada → venta en POS, caja, stock y comprobante |
| Personalizar = tocar el código del producto | Configuración, layouts por instancia y funciones aisladas |
| Un despliegue distinto por cliente para el implementador | Multi-instancia con portal partner, sandbox y promoción |
De lo más simple a lo más potente. La mayoría de los negocios vive en el primero; los implementadores usan los tres.
Catálogos (etapas, motivos, categorías), equipos y estrategias de reparto, permisos por módulo y acción, datos de la empresa, horarios y apariencia (11 presets).
Sin códigoFormularios y secciones por instancia: mismos módulos, presentación adaptada al cliente. Se edita en Ops o desde el portal partner y se promueve desde sandbox.
Sin código, por instanciaJavaScript por cliente en un runtime aislado, con SDK de lista blanca (bp.entities, bp.processes, bp.http, bp.emit…), disparado por evento o webhook. Prueba en sandbox y promoción con compuerta.
Código aislado y auditadoPara integradores, BFFs y herramientas de IA: consumidores con credenciales, límites por consumidor e IP, y exposición de recursos controlada desde Ops. La misma API que usa la interfaz, versionada para terceros.
El núcleo emite eventos del sistema con idempotencia y correlación. Las automatizaciones reaccionan a ellos y los webhooks entrantes disparan funciones, con secreto obligatorio en producción.
| Instancia | Plan | Preset | Partner |
|---|---|---|---|
| ferreteria-andes | Pro | saas-dashboard-light | Agencia Norte |
| hotel-mirador | Pro | flatly | Agencia Norte |
| resto-qori | Basic | darkly | — |
| sandbox-qori | Sandbox | darkly | — |
Cada cliente tiene su instancia con su propia base de datos, usuarios y configuración. Desde Ops se gestionan planes, capacidades, cupos, apariencia y ciclo de vida. Un token de una instancia no sirve en otra.
Importamos un extracto de tus clientes, activamos los módulos que apliquen y recorremos juntos el flujo completo: del mensaje al cobro.