1 · Configure
Catalogs (stages, reasons, categories), teams and routing strategies, permissions by module and action, company data, schedules, and appearance (11 presets).
No codeMost CRMs store the same customer several times (lead, contact, account). Aynflow registers them once and models processes and interactions on that identity. Technical model: Entity ? Process ? Interaction.
Everything that happens with a customer fits one of these three categories. That is why history never fragments.
Who they are. Created once and without a “commercial status”: not a lead or customer, but the person or company. ID, phones, and email help find them and avoid duplicates.
What is happening with them. A lead is a process; when qualified, an opportunity opens; when won, a sale is born. Each process has an owner, team, stage, and reason.
What was said or done. Webchat and bot messages, calls, notes, handoffs between agents, and even reads of sensitive data sit on the same timeline.
Because the lead is not a copy of the customer but a step on them, when Rosa writes again six months later the system does not create “Rosa 2”: it opens a new process on the same Rosa, with full history visible to the agent and the bot.
Following Rosa Quispe from the hardware store, from first click to payment. Each step maps to a real module.
Rosa fills out your landing form. Marketing Analytics records the visit and turns the submission into a CRM lead (idempotent: resubmitting does not duplicate).
She opens webchat. The published “Quote” flow collects dimensions and product type and, when purchase intent is detected, hands off to a human on the sales queue.
The engine checks team presence and schedule and assigns by least load. Marcos gets a notification with the full record and chat.
Marcos quotes with catalog products, exports the PDF, and advances the opportunity. He logs the confirmation call as an interaction.
Opportunity won ? sale. At the POS, payment happens inside the open register session; warehouse stock decreases and the receipt is issued.
Rosa writes about an exchange. The agent on duty sees sale #0481, the quote, and the previous chat without asking her again.
The supervisor sees first-response times, same-day assignments, and schedule adherence; compares teams by period and exports.
A per-customer function notifies the external ERP and logs it on the record. Everything runs isolated and audited.
Teams are by domain: sales (CRM), dining room (restaurant), register (POS). A user can belong to several. Each team defines how its queue is routed and who supervises it.
It is not about having more features, but having them point at the same record.
| Traditional CRM | Aynflow |
|---|---|
| Lead ? Contact ? Customer: the same person three times | One entity; lead and opportunity are processes on it |
| Chat lives in another tool and is copied manually | Inbox, bots, and CRM on the same identity and thread |
| The bot is a separate product that “creates tickets” | The bot hands off to the team queue with full context |
| Manual assignment or turns on a spreadsheet | Round-robin / least load by presence and schedule |
| Sales, register, and inventory in another system | Won opportunity ? POS sale, register, stock, and receipt |
| Customize = change product code | Configuration, per-instance layouts, and isolated functions |
| A different deployment per customer for the implementer | Multi-instance with partner portal, sandbox, and promotion |
From simplest to most powerful. Most businesses live in the first; implementers use all three.
Catalogs (stages, reasons, categories), teams and routing strategies, permissions by module and action, company data, schedules, and appearance (11 presets).
No codeForms and sections per instance: same modules, presentation tailored to the customer. Edited in Ops or from the partner portal and promoted from sandbox.
No code, per instancePer-customer JavaScript in an isolated runtime, with an allowlisted SDK (bp.entities, bp.processes, bp.http, bp.emit…), triggered by event or webhook. Test in sandbox and promote with gates.
Isolated, audited codeFor integrators, BFFs, and AI tools: consumers with credentials, per-consumer and IP limits, and controlled resource exposure from Ops. The same API the UI uses, versioned for third parties.
The core emits system events with idempotency and correlation. Automations react to them and inbound webhooks trigger functions, with mandatory secret in production.
| Instance | Plan | Preset | Partner |
|---|---|---|---|
| ferreteria-andes | Pro | saas-dashboard-light | North Agency |
| hotel-mirador | Pro | flatly | North Agency |
| resto-qori | Basic | darkly | — |
| sandbox-qori | Sandbox | darkly | — |
Each customer runs in its own instance with its own database, users, and configuration. Ops manages plans, capabilities, quotas, appearance, and lifecycle. A token from one instance does not work on another.
We import a sample of your customers, enable the modules that apply, and walk through the full flow together: from message to payment.