1 · Configurar
Catálogos (etapas, motivos, categorias), equipes e estratégias de roteamento, permissões por módulo e ação, dados da empresa, horários e aparência (11 presets).
Sem códigoA maioria dos CRMs guarda o mesmo cliente várias vezes (lead, contato, conta). O Aynflow registra uma vez e modela processos e interações sobre essa identidade. Modelo técnico: Entidade ? Processo ? Interação.
Tudo o que acontece com um cliente se encaixa em uma dessas três categorias. Por isso o histórico nunca se fragmenta.
Quem é. Criada uma vez e sem “status comercial”: não é lead nem cliente, é a pessoa ou empresa. ID, telefones e e-mail ajudam a encontrá-la e evitar duplicatas.
O que está acontecendo com ela. Um lead é um processo; quando qualificado, abre-se uma oportunidade; quando ganha, nasce uma venda. Cada processo tem responsável, equipe, etapa e motivo.
O que foi dito ou feito. Mensagens de webchat e bot, chamadas, notas, repasses entre agentes e até leituras de dados sensíveis ficam na mesma linha do tempo.
Como o lead não é uma cópia do cliente, mas um passo sobre ela, quando Rosa escreve de novo seis meses depois o sistema não cria “Rosa 2”: abre um novo processo sobre a mesma Rosa, com histórico completo visível para o agente e o bot.
Seguindo Rosa Quispe da ferragem, do primeiro clique ao pagamento. Cada etapa mapeia para um módulo real.
Rosa preenche o formulário da sua landing. O Marketing Analytics registra a visita e transforma o envio em lead do CRM (idempotente: reenviar não duplica).
Ela abre o webchat. O fluxo “Orçamento” publicado coleta dimensões e tipo de produto e, ao detectar intenção de compra, repassa para um humano na fila de vendas.
O motor verifica presença e horário da equipe e atribui por menor carga. Marcos recebe notificação com o cadastro completo e o chat.
Marcos orça com produtos do catálogo, exporta o PDF e avança a oportunidade. Registra a chamada de confirmação como interação.
Oportunidade ganha ? venda. No PDV, o pagamento ocorre dentro da sessão de caixa aberta; o estoque do armazém diminui e o comprovante é emitido.
Rosa escreve sobre uma troca. O agente de plantão vê a venda #0481, o orçamento e o chat anterior sem perguntar de novo.
O supervisor vê tempos de primeira resposta, atribuições no mesmo dia e aderência ao horário; compara equipes por período e exporta.
Uma função por cliente notifica o ERP externo e registra no cadastro. Tudo roda isolado e auditado.
Equipes são por domínio: vendas (CRM), salão (restaurante), caixa (PDV). Um usuário pode pertencer a várias. Cada equipe define como sua fila é roteada e quem supervisiona.
Não é ter mais recursos, é fazer todos apontarem para o mesmo cadastro.
| CRM tradicional | Aynflow |
|---|---|
| Lead ? Contato ? Cliente: a mesma pessoa três vezes | Uma entidade; lead e oportunidade são processos sobre ela |
| O chat vive em outra ferramenta e é copiado manualmente | Inbox, bots e CRM na mesma identidade e thread |
| O bot é um produto à parte que “cria tickets” | O bot repassa à fila da equipe com contexto completo |
| Atribuição manual ou rodízio em planilha | Round-robin / menor carga por presença e horário |
| Vendas, caixa e estoque em outro sistema | Oportunidade ganha ? venda no PDV, caixa, estoque e comprovante |
| Personalizar = alterar código do produto | Configuração, layouts por instância e funções isoladas |
| Um deploy diferente por cliente para o implementador | Multi-instância com portal de parceiro, sandbox e promoção |
Do mais simples ao mais poderoso. A maioria dos negócios vive no primeiro; implementadores usam os três.
Catálogos (etapas, motivos, categorias), equipes e estratégias de roteamento, permissões por módulo e ação, dados da empresa, horários e aparência (11 presets).
Sem códigoFormulários e seções por instância: mesmos módulos, apresentação adaptada ao cliente. Editado no Ops ou pelo portal de parceiro e promovido a partir do sandbox.
Sem código, por instânciaJavaScript por cliente em runtime isolado, com SDK em lista permitida (bp.entities, bp.processes, bp.http, bp.emit…), acionado por evento ou webhook. Teste em sandbox e promova com gates.
Código isolado e auditadoPara integradores, BFFs e ferramentas de IA: consumidores com credenciais, limites por consumidor e IP e exposição controlada de recursos pelo Ops. A mesma API que a UI usa, versionada para terceiros.
O core emite eventos de sistema com idempotência e correlação. Automações reagem a eles e webhooks de entrada acionam funções, com segredo obrigatório em produção.
| Instância | Plano | Preset | Parceiro |
|---|---|---|---|
| ferreteria-andes | Pro | saas-dashboard-light | Agência Norte |
| hotel-mirador | Pro | flatly | Agência Norte |
| resto-qori | Basic | darkly | — |
| sandbox-qori | Sandbox | darkly | — |
Cada cliente roda em sua própria instância com banco, usuários e configuração próprios. O Ops gerencia planos, capacidades, cotas, aparência e ciclo de vida. Um token de uma instância não funciona em outra.
Importamos uma amostra dos seus clientes, ativamos os módulos que se aplicam e percorremos o fluxo completo juntos: da mensagem ao pagamento.