PresenteIA B2B: transformar a rede de lojas da CRMBonus em canal de vendas.

As features e o recorte vinham do PM. Eu partia da documentação e das regras de negócio (saldo pré-pago, comissão das lojas, estoque real, prazos de entrega) e traduzia essa complexidade em fluxos que fizessem sentido para quem ia operar: o RH que compra, o financeiro que aprova, a operação que rastreia.

Cada proposta de fluxo eu levava ao PM e à engenharia, checando se respeitava a regra de negócio e o que dava para construir. Meu valor não estava em decidir o que o produto seria, e sim em garantir que a decisão do produto virasse algo utilizável.

Uma empresa quer presentear mil funcionários no Natal. Hoje isso é uma operação artesanal: planilha, cotação com fornecedor, endereço errado, caixa que não chega, e o RH virando central de rastreio.

A CRMBonus estava numa posição única para resolver isso. Não por ter tecnologia, mas por ter a rede de lojas. Se essas lojas virassem catálogo, a empresa cliente compraria ali, e a CRMBonus ficaria com comissão sobre a venda.

Isso define o modelo inteiro: a empresa deposita saldo, escolhe produtos do catálogo, e a plataforma leva o presente até a casa de cada pessoa. Dinheiro real, produto real, entrega real.

A empresa cliente sabe quem quer presentear: tem nome e telefone na base de RH. Mas presentear exige endereço, e endereço é o dado que ninguém tem atualizado.

Perguntar para mil pessoas, uma a uma, não escala: cada não-resposta vira um presente que não sai. A taxa de entrega despencaria antes mesmo da campanha começar.

Havia ainda um segundo problema, menos óbvio e mais caro: depois do envio, o cliente ficava no escuro. Mil caixas, três transportadoras, zero visibilidade.

A saída óbvia seria disparar uma mensagem para cada presenteado pedindo o endereço. Fiz a conta e levei ao PM: com mil destinatários, cada não-resposta vira um presente que não sai. A taxa de entrega passaria a depender da boa vontade de mil pessoas.

O fluxo que propus: buscar o endereço primeiro na base de clientes da própria CRMBonus, e só acionar o presenteado por WhatsApp quando não encontrar. O canal deixa de ser a regra e vira fallback. A decisão de usar a base foi do produto; meu papel foi desenhar como esse encadeamento aconteceria sem o usuário perceber a costura.

O efeito é direto na operação: a maioria dos endereços nunca precisa ser perguntada, e a taxa de entrega para de depender da boa vontade de mil pessoas responderem uma mensagem.

Vale registrar o que os dois produtos que desenhei na mesma época têm em comum. Nos dois, a tese foi transformar um ativo que a CRMBonus já tinha em receita nova: no retail media, o inventário e a audiência da base; aqui, a rede de lojas parceiras. Mesmo raciocínio de plataforma, mercados diferentes.

Configurar uma campanha significa cruzar mil destinatários, um catálogo com estoque limitado, orçamento aprovado, frete e data de disparo. É denso o suficiente para travar qualquer usuário numa tela única.

Propus quebrar em quatro etapas (dados gerais, público, presentes, conclusão), cada uma respondendo a uma única pergunta. O saldo fica visível o tempo todo, porque o usuário está comprometendo dinheiro de verdade a cada clique.

Esta não é uma plataforma com um usuário. É uma plataforma onde interesses opostos precisam coexistir na mesma tela.

Foi esse mapeamento que sustentou as escolhas: a aprovação de saldo é lenta e deliberada, enquanto a configuração de campanha é um wizard que não deixa você errar. Cada fluxo pertence a um dono diferente, e tratá-los igual seria errar com os dois.

E é por isso que existe um registro de atividades: quando muitas mãos operam o mesmo sistema, alguém precisa conseguir reconstruir o que aconteceu.

Como a plataforma compra produto de loja parceira, ela não pode prometer o que não tem lastro. O cliente deposita saldo, anexa comprovante, e o financeiro aprova ou reprova antes que o valor fique disponível.

É fricção, e foi deliberada. Sem ela, a CRMBonus assumiria risco de inadimplência sobre mercadoria de terceiros.

Era tentador cortar a logística do escopo: dispara a mensagem, entrega o pedido à transportadora, acabou. Muitos produtos de gifting param aí.

O escopo se manteve, e o argumento que sustentou isso foi de retenção, não de completude. Sem visibilidade, a empresa passa dezembro inteiro caçando rastreio em três transportadoras diferentes e não repete a campanha no ano seguinte. Levei isso como risco de negócio, não como pedido de designer.

PresenteIA e CRMAds rodam sobre a mesma base visual, e não por acaso: o design system da casa estava sendo validado justamente nesses dois produtos. Meu trabalho incluía descobrir onde ele não dava conta.

O CRMAds cobrou estados de ciclo de vida e barra de pacing. O PresenteIA cobrou outras três coisas:

Nenhum desses componentes existiria se o sistema tivesse sido desenhado no vazio. Foram os dois produtos, com problemas diferentes, que revelaram as lacunas — e cada peça voltou para a biblioteca, disponível para o próximo time.

Como no outro produto, a estratégia foi construir primeiro e testar depois. Aqui o risco era maior: o produto movimenta saldo real, aprovação financeira e entrega física. Um fluxo mal calibrado não gera só fricção, gera dinheiro parado ou presente que não chega.

Trabalhei com proto-personas e alinhamento com o PM, que são proxy, não evidência. O que eu defenderia hoje: testar antes do build justamente os pontos de maior risco (a aprovação de saldo e a confirmação de endereço), porque são os dois lugares onde o custo de errar é mais alto.

Não acompanhei os resultados. Mas o funil que instrumentei na própria interface era o instrumento de aprendizado:

Estruturei, junto ao PM, o framework de métricas e os OKRs que guiariam essa validação. O produto foi desenhado para medir a si mesmo: cada card do dashboard corresponde a uma etapa do funil que precisava ser aprendida.