Visão Geral da Arquitetura

O MoneySystem segue uma arquitetura MVC (Model-View-Controller) modular com separação clara de responsabilidades. O sistema é projetado para suportar 50.000+ usuários ativos simultaneamente.

Padrões de Projeto

• Repository Pattern — Abstração do acesso ao banco de dados
• Service Layer — Lógica de negócio encapsulada em serviços
• Middleware Pipeline — Autenticação, CORS, rate limiting, logging
• Observer Pattern — Sistema de eventos para webhooks e notificações
• Strategy Pattern — Cálculos de impostos por região/setor
• Multi-Tenancy — Isolamento de dados por empresa no mesmo banco

Diagrama de Componentes

┌─────────────────────────────────────────────────────┐
│                    CLIENTE                          │
│   Browser (PWA) │ App Mobile (WebView) │ API REST  │
└────────────────────────┬────────────────────────────┘
                         │ HTTPS
┌────────────────────────▼────────────────────────────┐
│                   LOAD BALANCER                     │
│               (Nginx / CloudFlare)                  │
└────────────────────────┬────────────────────────────┘
                         │
┌────────────────────────▼────────────────────────────┐
│                APLICAÇÃO PHP 8.2+                   │
│  ┌──────────┐ ┌──────────┐ ┌──────────────────────┐│
│  │  Router  │→│Middleware │→│    Controllers       ││
│  └──────────┘ └──────────┘ └──────────┬───────────┘│
│                                       │            │
│  ┌──────────────────┐  ┌──────────────▼──────────┐ │
│  │  Services Layer  │  │   Repository Layer      │ │
│  └──────────────────┘  └──────────────┬──────────┘ │
└────────────────────────────────────────┬────────────┘
                         │               │
          ┌──────────────▼──┐   ┌────────▼──────────┐
          │     Redis       │   │   MySQL 8.0       │
          │ (Cache/Session) │   │ (Multi-Tenant)    │
          └─────────────────┘   └───────────────────┘

Banco de Dados

O schema é desenhado para ser modular, escalável e preparado para 50.000+ usuários ativos simultâneos. Todo o banco de dados é escrito em inglês (tabelas, colunas, constraints, índices) para padronização internacional e facilitar a colaboração com desenvolvedores de qualquer país.

Cada empresa possui dados isolados via company_id em todas as tabelas, seguindo o padrão de multi-tenancy compartilhado — um único banco de dados serve todas as empresas, mas com isolamento rigoroso por chave.

Convenções de Naming

Estratégia de Escalabilidade (50k+ Usuários)

Para suportar mais de 50.000 usuários ativos sem lentidão, o banco de dados utiliza uma combinação de técnicas:

Regras de Integridade

• Índices Compostos — Todas as tabelas possuem índice em (company_id, campo_principal) para queries eficientes por empresa
• Soft Delete — Registros nunca são excluídos fisicamente. Usam deleted_at (NULL = ativo, TIMESTAMP = excluído)
• Auditoria — Tabela audit_logs registra TODAS as alterações com usuário, IP, ação, tabela, valores antes/depois e timestamp
• Foreign Keys — Constraints de FK garantem integridade referencial, com ON DELETE RESTRICT para evitar exclusões em cascata acidentais
• Enum via Lookup Tables — Em vez de ENUM no MySQL, usamos tabelas de lookup para valores fixos (status, tipos), facilitando manutenção

Exemplo: Tabela companies

Esta é a tabela principal onde ficam cadastradas todas as empresas do sistema. Cada registro representa uma empresa cliente do MoneySystem:

CREATE TABLE companies (
    id              BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    uuid            CHAR(36)        NOT NULL UNIQUE,

    -- Dados da empresa
    company_name    VARCHAR(255)    NOT NULL,              -- Razão social
    trade_name      VARCHAR(255)    DEFAULT NULL,          -- Nome fantasia
    document_number VARCHAR(20)     NOT NULL UNIQUE,       -- CNPJ ou equivalente
    state_registration VARCHAR(30)  DEFAULT NULL,          -- Inscrição estadual
    municipal_registration VARCHAR(30) DEFAULT NULL,       -- Inscrição municipal

    -- Contato
    email           VARCHAR(255)    NOT NULL,
    phone           VARCHAR(20)     DEFAULT NULL,
    website         VARCHAR(255)    DEFAULT NULL,

    -- Endereço
    address_street  VARCHAR(255)    DEFAULT NULL,
    address_number  VARCHAR(20)     DEFAULT NULL,
    address_complement VARCHAR(100) DEFAULT NULL,
    address_neighborhood VARCHAR(100) DEFAULT NULL,
    address_city    VARCHAR(100)    DEFAULT NULL,
    address_state   CHAR(2)         DEFAULT NULL,
    address_zip_code VARCHAR(10)    DEFAULT NULL,
    address_country VARCHAR(3)      DEFAULT 'BRA',

    -- Configurações do sistema
    sector          VARCHAR(50)     NOT NULL,              -- grafica|automotivo|mecanica|outro
    currency        CHAR(3)         NOT NULL DEFAULT 'BRL',-- BRL | ARS | USD
    language        VARCHAR(5)      NOT NULL DEFAULT 'pt-BR',
    timezone        VARCHAR(50)     NOT NULL DEFAULT 'America/Sao_Paulo',

    -- Plano e faturamento
    plan_id         BIGINT UNSIGNED DEFAULT NULL,
    storage_used_mb BIGINT UNSIGNED DEFAULT 0,
    is_active       TINYINT(1)      NOT NULL DEFAULT 1,
    is_suspended    TINYINT(1)      NOT NULL DEFAULT 0,
    suspended_at    TIMESTAMP       NULL DEFAULT NULL,
    days_overdue    INT UNSIGNED    DEFAULT 0,

    -- NF-e (apenas BRL)
    has_nfe         TINYINT(1)      NOT NULL DEFAULT 0,
    nfe_environment TINYINT(1)      DEFAULT 1,            -- 1=Produção, 2=Homologação
    nfe_series      INT UNSIGNED    DEFAULT 1,
    nfe_last_number INT UNSIGNED    DEFAULT 0,
    digital_certificate_path VARCHAR(255) DEFAULT NULL,
    digital_certificate_password VARCHAR(255) DEFAULT NULL,

    -- White Label
    is_white_label  TINYINT(1)      NOT NULL DEFAULT 0,
    custom_logo_path VARCHAR(255)   DEFAULT NULL,
    custom_primary_color VARCHAR(7) DEFAULT NULL,

    -- Controle
    created_at      TIMESTAMP       NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at      TIMESTAMP       NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    deleted_at      TIMESTAMP       NULL DEFAULT NULL,

    -- Índices
    INDEX idx_companies_sector (sector),
    INDEX idx_companies_plan (plan_id),
    INDEX idx_companies_active (is_active, is_suspended),
    INDEX idx_companies_deleted (deleted_at),

    -- Foreign Keys
    CONSTRAINT fk_companies_plan
        FOREIGN KEY (plan_id) REFERENCES plans(id) ON DELETE RESTRICT
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Área administrativa da plataforma (/admin)

A equipe MoneySystem acessa https://moneysystem.com.br/admin. A primeira tela é login (usuário e senha), sem misturar com o fluxo das empresas clientes.

• CEOs — perfil com visão global (clientes, suporte, operações, o que for definido no produto).
• Funcionários — mesmo painel /admin, mas só enxerga e altera o que as permissões do perfil permitirem.

Onde fica no banco (otimizado e seguro) — não usar as tabelas de usuários das empresas (company_id). Manter conjunto separado só para quem opera a plataforma:

• Tabela dedicada — ex.: platform_admin_users (poucos registros, consulta por login só no momento da autenticação).
• Senha — apenas hash forte (Argon2id ou bcrypt), nunca texto puro; custo de hash configurável.
• Papel — coluna role ou FK para platform_roles; permissões granulares de atendente em tabela de junção (platform_admin_permissions) ou JSON validado na aplicação, conforme complexidade.
• Índices — UNIQUE em username (ou e-mail de login) para lookup O(1) no sign-in.
• Sessão — cookie HTTP-only / servidor (Redis), TTL curto; rate limit e auditoria em ações sensíveis (qual admin acessou qual tenant).

CREATE TABLE platform_admin_users (
    id              BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    uuid            CHAR(36)        NOT NULL UNIQUE,
    username        VARCHAR(64)     NOT NULL UNIQUE,
    email           VARCHAR(255)    NOT NULL UNIQUE,
    password_hash   VARCHAR(255)    NOT NULL,
    role            VARCHAR(32)     NOT NULL,           -- ex.: owner | support
    is_active       TINYINT(1)      NOT NULL DEFAULT 1,
    last_login_at   TIMESTAMP       NULL DEFAULT NULL,
    created_at      TIMESTAMP       NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at      TIMESTAMP       NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

    INDEX idx_platform_admin_users_active (is_active, role)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Esse desenho mantém o painel interno isolado dos dados multi-tenant, com superfície de ataque menor e modelo de permissões claro.

Campos do Registro

Ao criar uma conta no MoneySystem, o usuário da empresa deverá preencher:

• Nome da empresa — Razão social
• CNPJ — Validação em tempo real
• Nome do responsável — Administrador principal
• E-mail — Será usado para cobranças e notificações
• Telefone/WhatsApp — Para comunicação de inadimplência
• Senha — Mínimo 8 caracteres, letra maiúscula, número e caractere especial

Seleção de Moeda

Uma caixa de seleção exibe as opções de moeda. O Real Brasileiro (R$) vem pré-selecionado:

Seleção de Idioma

O idioma padrão é Português (PT-BR). A tradução para Espanhol e Inglês é feita via arquivos de idioma (i18n) — JSONs estáticos carregados uma vez e armazenados no cache do navegador. Nas configurações do sistema, o usuário pode alterar o idioma a qualquer momento.

• 🇧🇷 Português — Padrão (nativo)
• 🇪🇸 Espanhol — Arquivo es.json
• 🇺🇸 Inglês — Arquivo en.json

Seleção de Setor

O campo de setor vem sem nada selecionado. O usuário deve obrigatoriamente selecionar um setor para conseguir criar a conta. Após criação, não há como alterar.

Comportamento

O mesmo endereço moneysystem.com.br exibe conteúdo diferente dependendo do estado de autenticação:

Implementação Técnica

// index.php — Roteamento dinâmico
if (Auth::check()) {
    // Usuário logado → Dashboard
    return (new DashboardController)->index();
} else {
    // Visitante → Site Institucional
    return view('landing.index');
}

Referência Visual

Dashboard do MoneySystem — clique aqui para Live Preview

Componentes do Dashboard (Conforme Permissões)

Dados Offline (PWA)

Funcionalidades

• Criação de Pedido — Selecionar cliente, adicionar produtos/serviços, definir quantidades, preços, descontos
• Nome Fantasia — Campo opcional que substitui o nome do produto na impressão do pedido
• Complemento — Campo de texto livre para informações adicionais (visível em setores como Gráfica)
• Faturamento — Converter pedido em faturado, gerando parcelas financeiras
• Parcelas — Divisão do valor em parcelas com datas de vencimento
• Comissões — Atribuição automática de comissão ao funcionário responsável
• Impressão — Layout otimizado para impressão (58mm e 80mm para etiquetas)
• Status — Pendente, Em Andamento, Faturado, Cancelado

Fluxo do Pedido

Dados do Cliente

• Dados Pessoais — Nome, CPF/CNPJ, RG, data de nascimento
• Contato — E-mail, telefone, WhatsApp, redes sociais
• Endereço — CEP com autopreenchimento, cidade, estado, bairro
• Dados Fiscais — Inscrição estadual, municipal, regime tributário
• Histórico — Todos os pedidos, valores totais, última compra
• Observações — Campo livre para anotações internas

Funcionalidades

• Busca por nome, CPF/CNPJ, e-mail ou telefone
• Filtros por estado, cidade, valor total gasto
• Importação de clientes via CSV/Excel
• Exportação da base de clientes
• Aniversariantes do mês no calendário do Dashboard

Campos do Produto

• Básico — Nome, descrição, código interno, código de barras
• Preço — Preço de custo, preço de venda, margem de lucro
• Estoque — Quantidade atual, estoque mínimo, unidade de medida
• Tributação — NCM, CFOP, CST, origem, alíquotas (ICMS, PIS, COFINS)
• Categoria — Agrupamento por categoria para organização

Importação

Produtos podem ser importados via XML de NF-e ou via CSV/Excel. Na importação XML, dados tributários (origem, NCM, CFOP) são extraídos automaticamente.

Funcionalidades

• Cadastro de serviços com nome, descrição e preço
• Vinculação de serviços a pedidos junto com produtos
• Código de serviço para NFS-e (quando aplicável)
• Histórico de serviços prestados por cliente
• Relatórios de serviços mais prestados

Módulos Financeiros

Cálculos do DRE

• Lucro Bruto = Pedidos de Venda Faturados − Despesas Pagas
• Lucro Líquido = Receitas Financeiras − Despesas Pagas

Características

• Interface simplificada para vendas rápidas
• Leitor de código de barras integrado
• Busca rápida de produtos por nome ou código
• Múltiplas formas de pagamento (dinheiro, cartão, PIX)
• Impressão de cupom em impressoras térmicas (58mm / 80mm)
• Emissão de NFC-e diretamente pelo PDV (contas BRL)

Tipos de Nota Fiscal

Características

• Sem intermediário — Comunicação direta com SEFAZ
• Importação de XML — Importar NF-e de fornecedores
• DANFE — Geração automática do documento auxiliar
• Cancelamento — Cancelar NF-e dentro do prazo legal
• Carta de Correção — CC-e para ajustes na nota
• Inutilização — Inutilizar faixas de numeração

Fluxo

Tipos de Relatório

• Vendas — Pedidos por período, por funcionário, por cliente
• Clientes — Cadastros, aniversariantes, ranking por faturamento
• Produtos — Mais vendidos, estoque baixo, margem de lucro
• Financeiro — DRE, fluxo de caixa, contas a pagar/receber
• Comissões — Valores devidos por funcionário por período
• NF-e — Notas emitidas, canceladas, valores totais

Limites por Plano

Permissões Disponíveis

• Criar/editar/excluir pedidos
• Visualizar/editar clientes
• Gerenciar produtos e estoque
• Acessar módulo financeiro
• Emitir notas fiscais
• Gerar relatórios
• Acessar PDV
• Gerenciar configurações do sistema
• Gerenciar outros usuários

Tela de Funcionários

• Lista de funcionários com foto, nome, cargo e status
• Comissões acumuladas — Total de comissões geradas por pedidos
• Valores a receber — Quanto cada funcionário tem direito no período
• Relatório individual — Pedidos criados, valores faturados, comissões
• Histórico mensal — Comparativo de desempenho mês a mês

Comissões

Ao criar um pedido, o funcionário responsável pode ser atribuído. A comissão pode ser:

• Percentual fixo — Ex: 5% sobre o valor do pedido
• Valor fixo — Ex: R$50 por pedido
• Por produto — Percentual diferente por categoria/produto

Comparativo Completo

O que é o DRF?

O DRF (Demonstrativo de Resultados Familiar) é inspirado no DRE empresarial, mas voltado para o controle financeiro pessoal do funcionário. Ao assinar o plano DRF, o usuário acessa exclusivamente a tela de finanças pessoais — sem acesso aos módulos empresariais.

Como Funciona

• Plano independente — O DRF é um plano separado dos planos empresariais (Essencial, Profissional, etc.)
• Acesso exclusivo — Ao entrar com o plano DRF, o usuário vê apenas a tela de finanças pessoais
• Sem módulos empresariais — Não tem acesso a Pedidos, Clientes, Produtos, NF-e, etc.
• Conta individual — Cada pessoa cria sua própria conta DRF

Funcionalidades

Como Funciona

E-mails de Cobrança

O MoneySystem envia e-mails automáticos em momentos-chave:

• Fatura gerada — E-mail com PDF da fatura e link de pagamento
• 3 dias antes do vencimento — Lembrete de pagamento
• Dia do vencimento — Aviso de vencimento
• 1 dia após vencimento — Primeiro aviso de atraso
• 3 dias de atraso — Segundo aviso (urgente)
• 5 dias de atraso — Último aviso antes da suspensão

Cronograma de Avisos

Autenticação

A API utiliza Bearer Token (JWT) para autenticação. Tokens são gerados via endpoint de login e possuem expiração configurável.

POST /api/v1/auth/login
Content-Type: application/json

{
  "email": "admin@empresa.com",
  "password": "sua_senha_segura"
}

// Resposta
{
  "token": "eyJhbGciOiJIUzI1NiIs...",
  "expires_in": 3600,
  "type": "Bearer"
}

Endpoints Principais

Rate Limiting

Como Funciona

Funcionalidades Bancárias

• Boleto Registrado — Geração de boletos com registro automático no banco
• PIX Automático — Geração de QR Code PIX para pagamentos instantâneos
• Conciliação — Baixa automática de pagamentos quando confirmados pelo banco
• Extrato — Consulta de extrato bancário direto no sistema
• Open Banking — Acesso seguro via APIs bancárias padronizadas

Eventos Disponíveis

• pedido.criado — Quando um novo pedido é criado
• pedido.faturado — Quando um pedido é faturado
• pedido.cancelado — Quando um pedido é cancelado
• cliente.criado — Quando um novo cliente é cadastrado
• pagamento.confirmado — Quando um pagamento é confirmado
• nfe.emitida — Quando uma NF-e é emitida com sucesso
• nfe.cancelada — Quando uma NF-e é cancelada

Formato do Payload

{
  "event": "pedido.faturado",
  "timestamp": "2026-02-13T23:00:00-03:00",
  "data": {
    "id": 1847,
    "cliente": "João Silva",
    "valor": 2450.00,
    "moeda": "BRL"
  }
}

Idiomas

O MoneySystem utiliza arquivos de idioma estáticos (JSON) para tradução. Cada idioma possui um arquivo contendo todas as labels, botões e textos do sistema. O arquivo é carregado uma única vez e fica salvo no cache do navegador (localStorage + Service Worker), garantindo velocidade instantânea nas próximas visitas — inclusive offline.

Como Funciona

// lang/en.json — Exemplo de arquivo de idioma
{
  "menu": {
    "orders": "Orders",
    "customers": "Customers",
    "products": "Products",
    "financial": "Financial",
    "reports": "Reports"
  },
  "buttons": {
    "save": "Save",
    "cancel": "Cancel",
    "delete": "Delete",
    "new_order": "New Order"
  },
  "status": {
    "pending": "Pending",
    "in_progress": "In Progress",
    "completed": "Completed"
  }
}

Moedas

Autenticação

• Senhas — Hashing com bcrypt (cost 12), política de senhas fortes
• 2FA — Autenticação de dois fatores via SMS (Número do Usuário)
• JWT — Tokens com expiração curta, refresh tokens seguros
• Rate Limiting de Login — Bloqueio após 5 tentativas, desbloqueio progressivo
• Sessões — Armazenadas em Redis, invalidação ao trocar senha

Proteção de Dados

• HTTPS obrigatório — TLS 1.3 em todas as comunicações
• Criptografia em repouso — AES-256 para dados sensíveis
• LGPD — Conformidade com Lei Geral de Proteção de Dados
• Backups — Automáticos, criptografados, armazenados em múltiplas regiões
• Isolamento de dados — Multi-tenancy com isolamento rigoroso por empresa_id

Prevenção de Ataques

Auditoria

Todas as ações são registradas em logs de auditoria imutáveis:

• Quem fez (usuário + IP + User-Agent)
• O que fez (ação, tabela, registro)
• Quando fez (timestamp UTC)
• Valores antes e depois da alteração

PWA (Progressive Web App)

• Instalável — Aparece como app na tela inicial do dispositivo
• Offline — Dashboard exibe dados em cache mesmo sem internet, com banner "Você está offline"
• Push Notifications — Notificações de pedidos, pagamentos e eventos
• Service Workers — Cache inteligente de assets e dados da Home
• Manifest.json — Configuração de ícone, cores, orientação, nome do app

App Nativo (WebView)

Apps publicados na App Store e Google Play usando WebView que carrega o site do MoneySystem:

• Wrapper nativo simples com WebView
• Push notifications nativas via Firebase
• Splash screen com logo MoneySystem (ou marca White Label)
• Ícone customizável para plano White Label

Responsividade

Toda a interface é projetada mobile-first:

• Menu lateral vira drawer com toggle
• Tabelas com scroll horizontal
• Cards empilham verticalmente
• Botões com tamanho mínimo de toque (44px)
• Formulários otimizados para teclado mobile

Requisitos de Escala

Estratégia de Cache

• Redis — Cache de sessões, queries frequentes, rate limiting
• CDN (CloudFlare) — Assets estáticos, imagens, CSS/JS
• Opcache — Cache de bytecode PHP
• Query Cache — Resultados de relatórios em cache com TTL

Banco de Dados

• Read Replicas — Réplicas de leitura para distribuir carga
• Particionamento — Tabelas de logs e transações por data
• Índices Compostos — (empresa_id, campo) em todas as tabelas
• Connection Pooling — Gerenciamento eficiente de conexões
• Slow Query Log — Identificação automática de queries lentas

Monitoramento

• Métricas de aplicação (response time, error rate, throughput)
• Métricas de infraestrutura (CPU, RAM, disco, rede)
• Alertas automáticos via Slack/Email para anomalias
• Dashboard de health check em tempo real

Estratégia

E-mails Transacionais

• Boas-vindas — Ao criar a conta, com guia de início
• Fatura mensal — PDF com detalhes e link de pagamento
• Lembretes — Antes/depois do vencimento
• Suspensão — Aviso de perda de acesso (D+7)
• Reativação — Confirmação de pagamento e reativação
• Exclusão — Avisos progressivos até D+365
• Segurança — Login em novo dispositivo, troca de senha

WhatsApp (mensagens transacionais)

Canal automatizado para ciclo de cobrança e vida da assinatura — distinto do WhatsApp de suporte humano descrito na seção Atendimento:

• Aviso de atraso (D+3, D+5)
• Suspensão (D+7)
• Lembretes mensais
• Avisos de exclusão (D+90, D+180, D+330, D+350)

Notificações In-App

• Avisos de manutenção programada
• Novidades do sistema e atualizações
• Alertas de segurança (login suspeito)
• Lembretes de eventos do calendário

Chat de Suporte no Sistema (IA + humano)

Primeira linha de atendimento dentro do produto. Aberto por qualquer usuário logado pelo ícone de suporte na barra superior (ao lado de Configurações) ou pelo item Ajuda no menu Outros. Disponível 24/7, com resposta imediata da IA e encaminhamento humano em horário comercial.

Recursos do painel

• Persistência da conversa — histórico salvo em localStorage por sessão, limitado a 40 mensagens; sobrevive a recarregar a página.
• Indicador de digitando e bloqueio do botão enviar enquanto aguarda resposta.
• Aborto automático de requisições pendentes ao iniciar nova conversa (AbortController).
• Links auto-detectados nas respostas da IA, abertos em nova aba com rel="noopener noreferrer".
• Estado de erro visível (bolha vermelha) se a API cair, com sugestão de abrir o WhatsApp.
• Disclaimer fixo: “Respostas geradas por IA podem conter erros. Em caso de dúvida, fale com um atendente.”
• Acessibilidade — aria-live="polite" na lista de mensagens, focus-visible nos botões, fechamento por Esc.
• Offline (PWA) — banner fino na parte superior sinaliza quando o navegador perde conexão; nessas condições, o chip do WhatsApp continua funcional.

Contrato com o backend

Quando o backend de IA estiver disponível, basta preencher SUPPORT_CONFIG.apiEndpoint no dashboard. Payload esperado:

POST /api/support/chat
{
  "sessionId": "uuid-v4",
  "messages": [
    { "role": "user",      "content": "Como emito uma NF-e?" },
    { "role": "assistant", "content": "..." }
  ],
  "question": "texto atual do usuário"
}

// resposta
{ "answer": "texto final da IA", "sources": ["url-do-artigo-1"] }

Horário de atendimento humano

Canais para o cliente

Planejamento do fluxo (funcionário)

A equipe opera a partir de uma visão unificada: tudo que entra pelo WhatsApp ou por ticket vira um atendimento registrado, para métricas, qualidade e continuidade.

Tickets — comportamento esperado no sistema

• Abertura — Menu Ajuda / Suporte ou ícone dedicado; campos mínimos: categoria, título, descrição; anexos opcionais (prints, XML, logs autorizados).
• Notificações — E-mail (e opcionalmente push) a cada resposta da equipe, para quem não está no fuso de SP.
• SLA interno — Primeira resposta em horário comercial conforme fila; urgências (ex.: indisponibilidade do sistema) com fila prioritária.
• Auditoria — Histórico por conta e por usuário que abriu o chamado, visível para administradores da assinatura quando aplicável.

WhatsApp — boas práticas operacionais

• Usar modelos aprovados para mensagens repetitivas (horário, link da documentação, como abrir ticket).
• Não tratar dados sensíveis sem necessidade; direcionar para área logada quando possível.
• Antes das 18h, avisar se a conversa ficará pendente até o próximo dia útil.
• Separar tecnicamente, quando possível, o número de suporte das automações de cobrança descritas em E-mails e Notificações.

Pré-Lançamento

• Banner informativo no topo do Dashboard
• E-mail para todos os usuários com cronograma
• Página de status do sistema atualizada em tempo real

Pós-Lançamento (Primeiros 7 dias)

Estratégia GTM

• Onboarding guiado — Tutorial interativo para novos recursos
• Base de conhecimento — Artigos de ajuda atualizados
• Suporte reforçado — Equipe ampliada nos primeiros 30 dias
• Feedback — Formulário de feedback na Home durante 15 dias
• Rollback — Plano de contingência caso problemas críticos surjam