Este Guia tem como objetivo registrar, de forma formal, completa e estruturada,
todas as funcionalidades associadas ao Flowt, plataforma multi-tenant
desenvolvida pela Omni8. O documento serve como artefato de referência
para áreas de negócio, tecnologia, parceiros e governança.
Aqui são descritos conceitos, módulos, fluxos, entidades principais, integrações
e boas práticas de uso, permitindo que novas equipes compreendam o escopo do
produto sem depender de conhecimento tácito.
1.2 O que é o Flowt
O Flowt é uma plataforma de comércio digital, engajamento e inteligência,
projetada para operar em um modelo multi-tenant. Ela permite que
múltiplas empresas (tenants) utilizem a mesma infraestrutura tecnológica enquanto
mantêm seus dados lógica e estruturalmente isolados.
Com o Flowt, uma empresa consegue:
Expor e gerenciar catálogo de produtos e serviços;
Criar e operar combos e ofertas customizadas;
Disponibilizar cardápio digital, páginas públicas e landing pages;
Acompanhar a jornada de navegação, engajamento e conversão;
Medir desempenho através de KPIs, dashboards, NPS e score;
Gerar e nutrir leads e indicações integradas a um funil comercial;
Integrar-se com outros módulos da Omni8, como o Nexus, CRM e governança.
1.3 Posicionamento no ecossistema Omni8
O Flowt integra-se ao ecossistema Omni8 como o motor de ofertas, engajamento e captura
de dados transacionais/comportamentais. Ele alimenta e é alimentado por outros módulos,
tais como:
Nexus – Gestão de governança, compliance, riscos e controles;
CRM e Funil de vendas – Gestão de relacionamento, pipeline comercial e pós-venda;
Analytics & IA – Modelos de recomendação, previsão, score e análise preditiva.
Capítulo 1 – Introdução ao Flowt.
Capítulo 2 – Visão Geral e Arquitetura da Plataforma
2.1 Objetivos centrais da plataforma
O Flowt foi concebido com os seguintes objetivos principais:
Digitalizar a jornada comercial de empresas, da exposição da oferta até a efetivação do pedido.
Centralizar dados de comportamento (cliques, visualizações, origens, carrinho, conversão).
Gerar inteligência por meio de NPS, score, dashboards e indicadores de uso.
Reduzir custo operacional via multi-tenancy, automações e reaproveitamento de componentes.
Permitir extensibilidade, tornando simples a adição de novos módulos e integrações.
2.2 Camadas lógicas da solução
A arquitetura do Flowt pode ser compreendida em camadas lógicas:
Camada de Apresentação (Front-end)
Responsável por páginas públicas (catálogo, cardápio, landing pages) e interfaces administrativas
(cadastro, dashboards, configurações).
Camada de Negócio (Back-end)
Implementada em PHP tipado, concentra regras de negócio de cadastros, ofertas, score, NPS,
tracking e fluxo de pedidos.
Camada de Persistência
Banco de dados relacional (MariaDB/MySQL) com tabelas orientadas a tenant.
Camada de Telemetria, Logs e Auditoria
Componentes de tracking silencioso, logs de erros e registros de ações relevantes
(mudanças de parâmetros, cadastros críticos, etc.).
Capítulo 2 – Visão Geral e Arquitetura da Plataforma.
Capítulo 3 – Multi-tenancy e Identidade do Tenant
3.1 Conceito de tenant
No Flowt, cada empresa atendida é um tenant, identificado por um código único
(como cod_tenant ou tenant_id). Este identificador permeia todas as camadas
da solução e é fundamental para o isolamento lógico dos dados.
Cada tenant possui:
Catálogo próprio de produtos/serviços;
Combos e ofertas específicas;
Cardápios e páginas públicas configuráveis;
Dashboards e indicadores exclusivos;
Parâmetros de score, NPS e campanhas de leads próprios.
3.2 Resolução do tenant
O Flowt utiliza múltiplas estratégias para resolver e fixar o tenant em cada sessão de usuário:
Parâmetros de URL – ex.: ?tenant=XYZ ou ?cod_tenant=XYZ,
com suporte a codificação/decodificação quando necessário.
Sessão – após a primeira identificação, o tenant é armazenado na sessão para navegação contínua.
Fallbacks e validações – se não for possível encontrar um tenant válido, a aplicação redireciona
para página de “tenant inexistente” ou exibe mensagens adequadas.
3.3 Isolamento lógico dos dados
O isolamento é garantido incluindo o identificador do tenant em todas as tabelas de negócio críticas.
As consultas e operações de escrita são sempre filtradas pelo tenant, impedindo acesso acidental ou indevido
aos dados de outras empresas.
Capítulo 3 – Multi-tenancy e Identidade do Tenant.
Capítulo 4 – Gestão de Cadastros Básicos
4.1 Cadastro de tenants (empresas)
As principais funcionalidades relacionadas ao cadastro de tenants incluem:
Inclusão de novos tenants, com dados cadastrais (razão social, CNPJ/CPF, endereço, contatos);
Configurações de identidade visual – logotipo, cores, textos padrão de cabeçalho e rodapé;
Parâmetros de funcionamento – horários de atendimento, regiões atendidas, políticas de entrega;
Ativação e desativação de tenants, com impacto direto nas áreas públicas e administrativas;
Histórico de alterações relevantes (quem alterou, quando e o que foi modificado).
4.2 Cadastro de pessoas (clientes e contatos)
4.2.1 Pessoa Física
Campos: nome, CPF, e-mail, telefone, data de nascimento, entre outros;
Associação da pessoa a um ou mais tenants;
Histórico de interações, pedidos, NPS e score por tenant.
Limites de uso por cliente, por tenant, por período;
Códigos promocionais (cupons), quando utilizados.
6.3 Associação às páginas de venda
As ofertas são refletidas nas páginas públicas por meio de destaques visuais
(selos, cores) e seções específicas como “Ofertas do dia” ou “Mais vantajosas para você”.
Capítulo 6 – Gestão de Combos e Ofertas.
Capítulo 7 – Cardápio Digital e Páginas Públicas
7.1 Conceito de cardápio digital
O cardápio digital é uma interface pública amigável, frequentemente acionada via QR Code,
que reúne os principais produtos, serviços e combos de um tenant em um layout simples e responsivo.
7.2 Características funcionais
URL dedicada por tenant, com parâmetros de tracking de origem;
Organização por categorias e seções (destaques, mais vendidos, combos especiais);
Integração com o módulo de tracking para registro de visualizações e cliques;
Compatibilidade com dispositivos móveis e desktop.
7.3 Outras páginas públicas
Página de catálogo completo – visão abrangente de todos os itens do tenant;
Landing pages de campanha – orientadas a conversão específica (lead, oferta, evento);
Páginas de boas-vindas – contextualização sobre o tenant, storytelling, proposta de valor.
Capítulo 7 – Cardápio Digital e Páginas Públicas.
Capítulo 8 – Compartilhamento, Links e QR Codes
8.1 Geração de QR Codes
O Flowt gera QR Codes dinâmicos contendo informações essenciais para tracking e roteamento:
Identificador do tenant;
Identificador da página/entidade (cardápio, catálogo, produto, combo, oferta);
Parâmetros de origem, como via=qr, qr_src=cardapio, UTM etc.
8.2 Links de compartilhamento
Além dos QR Codes, o Flowt disponibiliza links prontos para compartilhamento:
WhatsApp, Telegram, e-mail;
Botões “copiar link” para uso em redes sociais;
Links que preservam parâmetros de tracking, permitindo atribuição correta de canais.
Capítulo 8 – Compartilhamento, Links e QR Codes.
Capítulo 9 – Carrinho de Compras e Jornada do Cliente
9.1 Ações de engajamento nos cards
“Quero conhecer” – leva o usuário a detalhes, capta interesse e pode acionar captura de lead;
“Adicionar ao carrinho” – inclui o item na jornada de compra, registrando evento de tracking.
9.2 Estrutura e lógica do carrinho
O carrinho é mantido principalmente em sessão, com:
Lista de itens (produtos, serviços, combos), suas quantidades e preços;
Cálculo de valores, descontos e totais;
Validação de disponibilidade e status dos itens;
Garantia de consistência de tenant (quando aplicável).
9.3 Etapas da jornada
Navegação e descoberta em catálogo/cardápio;
Detalhamento de itens (opcional);
Inclusão no carrinho;
Revisão do carrinho, com possíveis upsells e cross-sells;
Coleta ou confirmação de dados do cliente;
Geração de pedido ou intenção de compra;
Acionamento de fluxos pós-venda (comunicação, NPS, etc.).
Capítulo 9 – Carrinho de Compras e Jornada do Cliente.
Capítulo 10 – Pedidos, Eventos e Pós-venda
10.1 Registro de pedidos
Os pedidos (ou intenções de pedido) são registrados em estruturas próprias
(tabela de pedidos, itens e eventos), garantindo rastreabilidade completa.
10.2 Eventos de pedido
Criação do pedido;
Atualizações de status (em análise, aprovado, rejeitado, cancelado);
Eventos de pagamento (aprovado, recusado, estornado);
Contatos pós-venda, quando aplicável.
10.3 Pós-venda
Envio de confirmações e resumos de pedido;
Convites para NPS e avaliações qualitativas;
Possível integração com fluxos de CRM para acompanhamento de relacionamento.
Capítulo 10 – Pedidos, Eventos e Pós-venda.
Capítulo 11 – Módulo de Tracking e Telemetria
11.1 Estrutura de tracking
O módulo de tracking registra silenciosamente eventos de navegação e interação
em tabelas como:
tb_omni8_tracker_produto_servico
tb_omni8_tracker_combo
tb_omni8_tracker_cardapio
Cada evento inclui, por exemplo:
Tenant;
Identificador do item;
Tipo de evento (impressão, clique, adicionar ao carrinho, etc.);
Data/hora (com fuso);
Origem (web, qr, campanha X);
Dispositivo/navegador (user-agent) e IP (quando aplicável);
Outros parâmetros de contexto.
11.2 Tipos de eventos
Visualizações de itens (impressões);
Cliques em “Quero conhecer”;
Cliques em “Adicionar ao carrinho”;
Acessos a cardápio e páginas específicas via QR ou links de campanha.
11.3 Fins do tracking
Construção de dashboards de engajamento e conversão;
Identificação de Top 10 itens mais engajados (visualizações e cliques);
Análises por canal, período, categoria e tenant.
Capítulo 11 – Módulo de Tracking e Telemetria.
Capítulo 12 – KPIs e Dashboards Operacionais
12.1 KPIs de engajamento e conversão
Visualizações por item;
Taxa de clique em “Quero conhecer”;
Taxa de adição ao carrinho;
Conversão de carrinho em pedido;
Desempenho por canal, campanha, período.
12.2 Dashboards
Os dashboards do Flowt são construídos em cards com gráficos como:
Top 10 itens mais engajados – ranking por visualizações/clicks;
Visualizações x Carrinho (Top 10) – comparação entre interesse e intenção de compra;
Gráficos de barras, linhas e pizza com filtros de data, canal e categoria.
Capítulo 12 – KPIs e Dashboards Operacionais.
Capítulo 13 – Módulo de NPS (Net Promoter Score)
13.1 Estrutura do NPS
O NPS é mantido em tabela específica, como tb_omni8_nps, associada a clientes,
tenants e, quando aplicável, a pedidos ou produtos específicos.
13.2 Coleta
Envio de convite após conclusão de pedidos;
Campanhas periódicas de NPS;
Links em e-mails, cardápios ou áreas autenticadas.
13.3 Cálculo e uso
Classificação em detratores (0–6), neutros (7–8) e promotores (9–10);
Cálculo de NPS = %Promotores − %Detratores;
Dashboards de distribuição de notas e evolução temporal;
Utilização do NPS como insumo para o módulo de score.
Capítulo 13 – Módulo de NPS (Net Promoter Score).
Capítulo 14 – Score de Clientes e de Tenants
14.1 Conceito
O módulo de score consolida múltiplos indicadores (frequência, recência, valor, NPS, etc.)
em uma pontuação por cliente e por tenant.
14.2 Estrutura de dados
tb_omni8_score_param – parâmetros, pesos e fórmulas de score;
tb_omni8_score_cliente – score calculado por cliente;
tb_omni8_score_tenant – score consolidado por tenant;
Procedures como sp_o8_calc_score_cliente e sp_o8_calc_score_tenant.
14.3 Dimensões componentes do score
Frequência de interação e compra;
Recência da última interação;
Valor monetário (ticket médio, receita total);
Aprovação de pedidos;
NPS e outros indicadores de satisfação.
Capítulo 14 – Score de Clientes e de Tenants.
Capítulo 15 – Módulo de Indicação e Geração de Leads
15.1 Estrutura de leads e indicações
Leads e indicações são registrados em tabelas como tb_omni8_indicacao_lead, contemplando:
Dados do lead (nome, e-mail, telefone, CPF/CNPJ);
Origem (indicador, campanha, canal);
Código exclusivo de indicação;
Tenant associado;
Status (novo, em contato, convertido, etc.).
15.2 Fluxo de indicação
Geração de link ou QR Code de indicação;
Compartilhamento pelo indicador ou parceiro;
Acesso de novos interessados por esses links;
Registro automático do lead com informações de origem;
Evolução do lead no funil comercial, possivelmente integrada com CRM.
15.3 Pré-cadastro automático
Em cenários B2B/B2C, o Flowt pode identificar se o lead é pessoa física ou jurídica e pré-cadastrar:
Pessoas físicas em tb_omni8_pessoa_fisica;
Pessoas jurídicas em tb_omni8_tenant (potenciais clientes da plataforma).
Capítulo 15 – Módulo de Indicação e Geração de Leads.
Capítulo 16 – Comunicação com Clientes
16.1 Gatilhos de comunicação
Após criação ou atualização de pedidos;
Após registro de lead ou conclusão de etapas do funil;
Em ações de NPS, campanhas e eventos específicos.
16.2 Canais
E-mail (via bibliotecas como PHPMailer);
Links diretos para WhatsApp, Telegram e outros mensageiros;
Mensagens contextuais dentro das páginas (sucesso, erro, orientações).
16.3 Parametrização
Templates por tenant, com textos customizáveis;
Suporte a variáveis dinâmicas (nome do cliente, pedido, datas);
Configuração de idioma, tom e frequência.
Capítulo 16 – Comunicação com Clientes.
Capítulo 17 – Administração, Perfis de Acesso e Segurança
17.1 Perfis de acesso
Administrador global (Omni8) – acesso a múltiplos tenants, parâmetros globais;
Administrador do tenant – gestão de catálogo, ofertas, dashboards, leads;
Operador/comercial – foco em operação diária e atendimento;
Visualizador/analista – acesso a relatórios e indicadores.
17.2 Segurança
Sessões autenticadas, com validação de credenciais;
Proteções contra CSRF em formulários sensíveis;
Sanitização e validação de entradas;
Respeito a LGPD/GDPR em dados pessoais.
17.3 Auditoria
Registro de ações críticas (incluindo quem, quando e o que foi alterado);
Histórico de modificações em parâmetros de score, NPS, ofertas e cadastros sensíveis.
Capítulo 17 – Administração, Perfis de Acesso e Segurança.
Capítulo 18 – Integrações Externas e Ecossistema
18.1 Integração com pagamentos
Gateways de pagamento (cartão, PIX, boleto);
Registro de eventos de pagamento atrelados a pedidos;
Sincronização de status de pagamento com o fluxo de pedidos.
18.2 Integração com CRM, ERP e outros sistemas
Exportação de dados (CSV, JSON) de pedidos, leads, NPS, score;
Integração via APIs quando disponíveis;
Uso de conectores e pipelines para BI.
18.3 Integração com ferramentas de BI
Power BI, Metabase, entre outras;
Views dedicadas no banco para exposição de dados consolidados;
Rotinas de atualização periódica de dados.
Capítulo 18 – Integrações Externas e Ecossistema.
Capítulo 19 – Monitoramento, Logs e Observabilidade
19.1 Logs de erros e execução
Arquivos de log PHP para registro de erros e exceções;
Log de eventos críticos de negócio, quando configurado;
Organização dos logs por data e tipo.
19.2 Monitoramento de uso
Volumes de tenants ativos;
Quantidade de eventos de tracking por período;
Carga de acessos e picos de uso.
19.3 Alertas e ações preventivas
Alertas por aumento anormal de erros;
Monitoramento de performance;
Planejamento de escala de recursos (infraestruturais, banco, aplicação).
Capítulo 19 – Monitoramento, Logs e Observabilidade.
Capítulo 20 – Extensibilidade, Evolução e Roadmap
20.1 Extensibilidade da plataforma
O Flowt foi arquitetado para permitir a inclusão de novos módulos, tabelas e fluxos sem
ruptura das funcionalidades existentes. A multi-tenancy e a estrutura modular facilitam:
Criação de novos tipos de ofertas, campanhas e lógicas de precificação;
Ampliação do módulo de IA para recomendações e segmentações automáticas;
Construção de funcionalidades específicas por nicho (educação, consultoria, varejo, etc.).
20.2 Possíveis extensões futuras
Módulo de assinaturas recorrentes e planos;
Marketplace multi-seller (vários vendedores em um ou múltiplos tenants);
Automação de marketing baseada em score, NPS e comportamento;
Integração profunda com o Nexus para governança de ofertas, contratos, políticas.
20.3 Governança do produto
Definição de responsáveis pelo roadmap do Flowt;
Estratégia de versionamento (major, minor, patch);
Processos de homologação, testes e publicação de novas releases;
Atualização contínua deste Guia com novos módulos e decisões arquiteturais.
Capítulo 20 – Extensibilidade, Evolução e Roadmap.
Capítulo 21 – Considerações Finais
Este Guia consolida, em formato de capítulos, as principais dimensões funcionais
e conceituais do Flowt. Ele deve ser utilizado como documento de referência para:
Onboarding de novas pessoas nas equipes técnicas e de negócio;
Planejamento de evoluções de produto e integrações;
Governança de decisões e alinhamento com stakeholders internos e externos.
À medida que novos módulos forem implementados ou refinados, recomenda-se a revisão
e expansão deste documento, preservando o histórico das versões para rastreabilidade
de decisões ao longo do tempo.
Capítulo 21 – Considerações Finais.
Guia do Flowt
Privacidade, uso de dados e consentimento
Esta solução digital utiliza cookies e tecnologias semelhantes para melhorar sua experiência,
apoiar análises de uso e cumprir obrigações legais.
Ao continuar navegando e utilizando as funcionalidades disponibilizadas,
você declara estar ciente e concorda, de forma livre, informada e inequívoca,
com o tratamento de seus dados pessoais nos termos descritos nos
Termos de Uso e na
Política de Privacidade da OMNI8.
Caso não concorde, você poderá revogar o seu consentimento a qualquer tempo,
por meio do link específico disponível nesta solução, sem prejuízo da legitimidade
do tratamento realizado até a data da revogação.
Para revogar posteriormente o seu consentimento, utilize o link
disponível nesta e em outras páginas.
