Case · Plataforma multi-tenant · Fidelidade
O ponto é um
ativo financeiro.
Uma rede com 390 mil clientes cadastrados operava seu programa de fidelidade num sistema que ela mesma queria aposentar. O protótipo desenha a plataforma que o substitui: multi-tenant, white-label e construída sobre um registro de pontos que não se edita — só se corrige.
01 · Contexto
O sistema em produção era o ponto de partida — não o de chegada.
Havia um programa funcionando, com números reais e regras reais. O que não havia era uma plataforma que o cliente quisesse mostrar.
O Club Petro é o sistema de pontos que o Grupo Aldo usa hoje: seis áreas, cerca de 45 telas, 390.168 clientes cadastrados na REDE ALDO distribuídos em cinco níveis. O levantamento dele foi feito a partir das telas em produção, não de suposição — e ele estabeleceu o que o produto novo precisa conseguir fazer. O cliente rejeita a forma: menu horizontal, painéis de filtro densos, tabelas de nove colunas com ícones de ação de 16 pixels e banner de marketing no painel inicial.
O critério ficou explícito desde o começo: paridade de funcionalidade é obrigatória, paridade visual não é. O legado é referência de fluxo e de dado, nunca de forma. Em paralelo, a visão de arquitetura do cliente definia um produto bem maior que o sistema atual — um core único servindo N clientes, com marca, tema, domínio e idioma como configuração por tenant, nunca como código.
02 · Desafio
Três fontes, e nenhuma delas concordava inteiramente com as outras.
O projeto começou com um mapa mental de arquitetura de informação, um deck de arquitetura de solução e o mapeamento do sistema em produção. Cada um descrevia o mesmo produto, e os três divergiam em pontos que mudavam o desenho das telas.
Entidades sem lugar na navegação
Empresas, unidades, produtos e categorias apareciam na hierarquia de dados do mapa mental, mas não na navegação. O legado as tem de fato — então existem e precisavam de endereço.
"Campanhas" aparecia três vezes
Em Campanhas, em Comunicação e em Analytics. A pergunta não era onde colocar: era se eram três entidades ou uma entidade com três visões — e a resposta muda o modelo de dado.
Terminologia em conflito
O mapa usava Membros na navegação e Consumidores na hierarquia; o legado dizia Cliente. E "cliente" é ambíguo neste produto: pode ser o consumidor final ou a empresa que contrata a plataforma.
Treze relatórios, quatro destinos
Analytics tinha quatro itens; o legado tinha treze relatórios. Seis deles não tinham destino evidente — e inventar um lugar para eles teria sido pior que registrar a pergunta.
Funções sem regra de negócio
Missões, indique e ganhe, automação e templates de comunicação não existem no legado e não estavam detalhados no deck. Construí-las de verdade exigiria levantamento próprio que ainda não havia.
Escopo não podia ser decoração
O isolamento entre tenants é o produto, segundo o próprio material do cliente. Isso significa que o seletor de escopo do cabeçalho não é um filtro de conveniência: ele reflete uma segregação que existe na origem do dado.
03 · Estratégia e mapeamento
Nenhuma divergência resolvida em silêncio.
Cruzar as três fontes produziu uma lista de lacunas e conflitos. Cada item virou uma decisão registrada — ou uma pergunta explicitamente em aberto.
O documento de lacunas e conflitos é a espinha dorsal do projeto. Toda escolha de arquitetura de informação aparece lá com a alternativa que foi descartada e o motivo. Mais importante: cada decisão registra o que muda se o cliente preferir o contrário — porque essa é a informação de que quem for implementar precisa, e não o veredito isolado.
Quando a regra não existia em lugar nenhum, a escolha foi a mais conservadora e ficou marcada como tal. A senha do protótipo, por exemplo, valida apenas obrigatoriedade: sem tamanho mínimo, sem exigência de maiúscula ou símbolo. Inventar política de senha teria criado requisito que ninguém pediu e que alguém implementaria como se fosse decisão de produto. Onde a decisão tinha consequência no código, ela foi implementada no mesmo dia — não ficou só escrita.
04 · Decisões de design
O modelo de dado decide a forma da tela.
As escolhas mais consequentes deste projeto não foram visuais. Foram as que traduziram uma premissa de arquitetura em um comportamento de interface — e as que recusaram o padrão óbvio porque ele contrariava o modelo.
- 01
Ledger imutável, então a transação não se edita
O registro de pontos é imutável e de dupla entrada. A consequência direta na tela: não existe formulário de edição de lançamento. Erro se corrige por estorno, que é um novo lançamento com contrapartida. Um botão "editar" ali seria contrariar o modelo de dado e produzir um saldo que o ledger não reconhece.
- 02
Regras não são CRUD
O motor de regras é declarativo e versionado, com simulação em caixa de areia antes de publicar. A tela de regras precisa, portanto, de prévia e de histórico de versões — e não da lista com botão de criar que um cadastro qualquer pediria. Publicar uma regra de pontuação sem simular é publicar um cálculo que ninguém viu rodar.
- 03
Uma entidade, três visões
Campanha é uma coisa só, vista de três ângulos: gestão (regra, público, período), disparo (mensagem, canal, modelo) e resultado (desempenho). Tratá-las como três entidades teria duplicado o cadastro e criado a chance de divergirem. Se o cliente quiser separado, o registro diz exatamente o que precisa mudar.
- 04
O ato e o comprovante são coisas diferentes
Resgate é o ato; voucher é o ciclo de vida do comprovante — emitido, utilizado, cancelado, expirado —, incluindo a baixa manual no balcão. O legado tratava voucher como módulo inteiro, e juntar os dois teria apagado um fluxo operacional que acontece todo dia.
- 05
Aprovações é fila, não formulário
O lançamento manual entra em Ajustes, mas as aprovações ganharam rota própria: é uma fila com alçada por faixa de pontos, com motivo e evidência obrigatórios e trilha de auditoria. Fila e formulário têm ritmos de uso opostos, e misturá-los penaliza o uso mais frequente.
- 06
Um termo, um significado
Membros na interface, member no código, registrado em glossário. "Cliente" foi aposentado por ambiguidade. É a correção mais barata de um produto com três fontes de vocabulário, e a que mais rende: cada palavra duplicada vira uma dúvida por sessão.
- 07
Duas portas de entrada, não uma
O formulário de e-mail e senha é a tela de acesso do produto. A entrada por perfil de demonstração é outra rota, porque o valor do protótipo está em mostrar a plataforma pelos olhos de cada perfil. Juntar as duas encheria o login de andaime — e o andaime sai junto com a autenticação real, de uma vez só.
- 08
Preferência pessoal não é permissão
Tema escuro, alto contraste, escala de fonte e redução de movimento ficam por usuário e sobrevivem à navegação, mas não alteram perfil de acesso. Um operador continua operador com tema escuro e fonte a 125% — parece óbvio e é exatamente o tipo de coisa que produto nenhum verifica até alguém reclamar.
05 · O ciclo do ponto
Da bomba ao resgate, em seis passos.
O produto inteiro existe para operar um ciclo. Entender esse ciclo foi o que permitiu decidir o que cada tela precisa mostrar — e o que ela não tem o direito de fazer.
- 01
Transação na origem
Uma venda acontece no ponto de venda, no aplicativo ou no portal de qualquer unidade da rede. A plataforma não cria transação: ela recebe de origens cadastradas.
- 02
Evento de negócio
A transação vira evento, desacoplada da venda. É o que permite que a mesma regra sirva a origens diferentes sem que o cálculo dependa do sistema que vendeu.
- 03
Motor de regras calcula
Pontos por perfil, produto, campanha e empresa emissora. A tela de transações mostra a regra que foi considerada e o cálculo linha a linha — porque "por que recebi 95 pontos" é a pergunta que o atendimento mais recebe.
- 04
Ledger credita em dupla entrada
Saldo do cliente de um lado, passivo da empresa emissora do outro. É daí que sai o indicador de passivo em pontos, que é o número que o financeiro da rede realmente acompanha.
- 05
Resgate na rede
Em unidade do próprio tenant ou em parceiro credenciado — farmácia, clínica, lavanderia. O parceiro entra por um portal de credenciamento leve e amplia o valor percebido do ponto sem tocar no core.
- 06
Liquidação e auditoria
Acerto entre unidades e repasse ao parceiro, com ciclos de composição rastreável, aprovação por alçada e conciliação de divergências. O ponto é um ativo financeiro: o fim do ciclo é contábil, não visual.
06 · Permissões
A matriz governa o menu, não o contrário.
Em quase todo painel administrativo, o menu é uma lista fixa e a permissão apenas desabilita botões. Aqui a relação é invertida — e isso mudou o que o protótipo é capaz de demonstrar.
Oito perfis, oito produtos diferentes
Admin master, administrador do tenant, gestor de empresa ou unidade, operador, financeiro, marketing, parceiro e consumidor. Quem entra como operador de balcão vê 9 itens de menu; o admin master vê os 40. Não é a mesma tela com menos botões: é uma plataforma diferente.
Mudar a permissão muda a interface
A matriz cruza recurso, ação, escopo e alçada. Alterá-la na tela de perfis de acesso muda o que aquele perfil enxerga — no menu e nas telas. É o tipo de comportamento que normalmente só aparece depois da integração, e aqui é demonstrável numa reunião.
Escopo em três níveis
Tenant, empresa e unidade. O escopo acompanha o usuário pela navegação e os filtros globais sobrevivem à troca de contexto — porque perder o filtro ao trocar de aba é como o legado ensinava a não confiar na tela.
Auditoria que só acrescenta
A trilha é somente de acréscimo, e usuários vinculados e comparação entre perfis ficam na mesma tela. Quem concede acesso precisa ver o que o acesso permite antes de conceder — não depois de alguém usar.
07 · Da estratégia à experiência
Quarenta itens de menu, nenhum deles planejado.
Todo item do menu abre uma tela que existe. Nenhum é promessa, rascunho ou caminho que termina em branco.
Em qualquer tela pronta é possível criar, editar e excluir registros, filtrar, buscar, ordenar e paginar — e ver como o produto se comporta carregando, vazio e com erro, porque os quatro estados são condição para uma tela ser considerada pronta. O vazio ainda distingue "nenhum registro" de "nenhum resultado para este filtro", que são situações diferentes e pedem ações diferentes. Os dados são fictícios, mas ancorados nas regras do sistema que a rede usa hoje.
Todo cadastro tem "preencher com exemplo": um clique preenche o formulário inteiro com dados válidos — no assistente de abertura de tenant, as seis etapas de uma vez. Parece conveniência e é decisão de apresentação: ninguém digita um CNPJ em reunião, e a alternativa real era a demonstração travar no formulário em vez de chegar à tela que importava.
08 · Em destaque
O que distingue esta plataforma de um CRUD grande.
Quase todo módulo aqui poderia ter virado cadastro com lista e formulário. Os que não viraram são os que carregam a inteligência do produto.
Catálogo visual como contrato
A regra é curta: o que não estiver no catálogo não deveria aparecer numa tela. Se faltar algo, ele entra no catálogo junto com a primeira tela que precisar dele — e não depois, quando já existem três variações.
Marca como configuração
A primária deriva de variáveis, não de cor fixa em componente. Trocar o preset de marca de um tenant não exige mudar nenhuma tela — e se exigir, é sinal de cor crua em algum lugar, que é justamente o que o catálogo expõe.
Níveis são configuração, não segmento
O nível carrega validade de pontos e política de aprovação, pertence a uma empresa e tem ordem de exibição. Segmento, do CRM, é outra coisa. Tratá-los como sinônimos no legado é o que fazia a validade do ponto parecer global quando ela é por nível.
Simulação antes de valer
Regras, níveis e segmentação têm simulação e reprocessamento com prévia. Em um produto onde o cálculo vira passivo financeiro, publicar sem ver o resultado é a operação mais cara que a interface pode permitir.
Liquidação com cálculo aberto
Ciclos com composição rastreável, aprovação por alçada, repasse e conciliação de divergências. O parceiro precisa conferir o número antes de aceitar — e um total sem a composição é um número que gera disputa.
Analytics por objetivo, não por tabela
Dashboards por perfil em abas, matriz de recência, frequência e valor interativa, e alertas que vêm com recomendação. Relatório que não sugere ação é relatório que ninguém abre duas vezes.
09 · Impacto e aprendizados
O valor de um protótipo que se opera.
O marco desta fase, nos termos do próprio roteiro do cliente, é "protótipo aprovado". O objetivo não era uma tela bonita: era uma decisão informada.
A hipótese central que este protótipo permite explorar é de representabilidade: um produto multi-tenant com oito perfis, três níveis de escopo e um modelo de dado imutável consegue ser compreendido por quem decide o investimento antes de o back-end existir? A resposta não vem de uma apresentação — vem de alguém entrando como operador, não encontrando o que o admin encontra, e percebendo que isso é o desenho e não um defeito.
A fronteira física entre design e desenvolvimento foi o que tornou isso sustentável. Nenhuma tela faz requisição; as bibliotecas de integração nem estão instaladas; um verificador varre o código e reprova o pull request se aparecerem. Não é burocracia: é o que faz uma tela ser integrável em horas em vez de virar retrabalho — e é o que permitiu as duas equipes trabalharem em paralelo sem se atropelar.
O que ficou em aberto está escrito como aberto. Seis relatórios do legado ainda não têm destino em Analytics, a regra de faixa de cartão não está documentada nem no sistema atual, e quatro funções novas entraram apenas como rota navegável porque construí-las de verdade exige levantamento próprio. Um protótipo que finge ter respondido tudo entrega para o desenvolvimento uma dívida que ninguém sabe que existe.
10 · Conclusão
Arquitetura antes de interface.
Em um produto onde o ponto é um ativo financeiro, as decisões mais importantes de design acontecem antes de qualquer tela existir.
Este projeto foi, acima de tudo, um exercício de traduzir premissas de arquitetura em comportamento de interface. Ledger imutável vira ausência de botão de editar. Motor de regras com caixa de areia vira simulação obrigatória antes de publicar. Isolamento entre tenants vira um seletor de escopo que não é decoração. Nada disso aparece num layout — mas tudo isso decide se a plataforma vai ser integrável ou se vai precisar ser redesenhada na primeira sprint de back-end.
O protótipo cumpre o papel que lhe cabe na fase: apresentar e validar o produto com o cliente antes de o back-end existir, com quarenta itens de menu que abrem telas de verdade e oito perfis que enxergam plataformas diferentes. O que ele não faz — e não finge fazer — é provar resultado de negócio. Isso só vem depois do primeiro ponto emitido de verdade.