FluuaEnglish

Um case de produto e tecnologia

Um cockpit para times de Customer Success que já não cabiam na planilha.

Carteira de clientes, sinais de risco, pesquisas, contratos e playbooks em um mesmo ambiente. A Fluua foi desenvolvida para organizar o trabalho diário dos times de Customer Success.

A operação da Fluua foi encerrada. Este case apresenta a visão, as decisões e a tecnologia que deram forma ao produto.

Carteira de clientes no cockpit da Fluua.
Carteira de clientes no cockpit da Fluua.

O problema

Quando a carteira cresce, o contexto se perde

Planilhas permitem começar com poucos recursos. Com o crescimento da carteira, manter contatos, contratos, pesquisas e tarefas atualizados passa a exigir trabalho manual frequente.

Informações distribuídas entre arquivos e ferramentas dificultam o acompanhamento. Um contrato pode se aproximar da renovação enquanto a queda de uso ou uma pesquisa negativa permanece em outro lugar.

A proposta da Fluua era reunir esses dados com as ações do time: consultar o histórico, entender a situação de uma conta e registrar o próximo passo no mesmo fluxo.

carteira.xlsx
ClienteNPS
Acme Logística8
Vortex Tech7
Nordeste S.4
……
Fluua
agora

Acme Logística

Carteira ativa · em adoção

Health

78

NPS

8

MRR

4k

Próximo passo · sex
Representação do fluxo de importação e organização da carteira.

A tese

A tabela no centro, tudo o mais em volta

A tabela de clientes foi escolhida como ponto de partida. Filtros, indicadores e ações partiam da mesma carteira; o detalhe da conta abria em um painel lateral, preservando a posição de trabalho.

Tabela como interface principal

A carteira inteira em uma superfície densa, com colunas configuráveis, agrupamento, filtros salvos e views compartilháveis por URL.

Contexto sem trocar de rota

O cliente 360 abria em um drawer sobre a tabela. O CSM aprofundava e voltava sem perder a fila em que estava trabalhando.

Sinal antes do sintoma

Health score próprio, indicadores de produto, suporte e survey combinados para que o risco aparecesse antes de virar pedido de cancelamento.

Execução no mesmo lugar

Tarefas, interações, pesquisas e playbooks podiam ser acionados no contexto da conta.

Da visão à execução

Um produto construído de ponta a ponta.

À frente da Fluua, Daniel Kafruni conduziu negócio, produto e tecnologia: da definição do problema e da experiência de uso à arquitetura, ao desenvolvimento e à operação comercial. As escolhas apresentadas neste case fazem parte dessa construção.

Fundador · Daniel Kafruni

  1. Estratégia de negócio
  2. Visão de produto
  3. Arquitetura e engenharia
  4. Execução e operação

O que estava pronto

Escopo entregue

As funcionalidades desenvolvidas para acompanhar a carteira, organizar o trabalho e executar ações por cliente. Os visuais ilustram os fluxos com dados de exemplo.

Carteira

A carteira inteira, priorizada por risco

A tabela era o centro da operação. Cada cliente entrava com health score, estágio, receita, próximo vencimento e último contato, agrupados pela dimensão que o CSM escolhesse.

  • Cinco lentes sobre a mesma carteira: portfólio, scorecard, tarefas, receita e sinais
  • Colunas configuráveis, agrupamento, ordenação e densidade por preferência do usuário
  • Views salvas e compartilháveis por URL — recarregar preservava o contexto inteiro

Carteira total

32contas

Carteira segmentadapor health
  • Risco4

    Acme · Nordeste · +2

  • Atenção9

    Vortex · Loja Verde · +7

  • Saudável19

    Norte SaaS · Nova Co · +17

4 pedem ação hojeordenado por risco

Cliente 360

Contexto profundo sem sair da fila

O drawer abria sobre a tabela com o cliente inteiro em cinco abas. O CSM investigava, agia e voltava para a fila sem perder o lugar em que estava.

  • Visão geral, atividade, entrega, receita e conta em uma única superfície
  • Ações diretas: criar tarefa, registrar interação, lançar survey, acionar playbook
  • Estado preservado na URL — o link do cliente abria exatamente o mesmo contexto

Uso · 30 dias

22%

Vortex Tech

Padrão

vortex.com · HealthTech · Pequeno

Ao vivo

Saúde

6,2

Atenção

NPS

7

passivo

CSAT

4,1

de 5

Renovação

28d

a vencer

Tickets

2

abertos

Atividade

5d

atrás

Visão geralAtividadeEntregaReceitaConta
Resumo do caso

Risco de renovação: uso caiu 22% e renova em 28 dias. Priorize um contato esta semana.

Criar tarefaLançar surveyAcionar playbookRegistrar interação

Health score

Saúde do cliente com composição visível

O health score reunia dimensões da conta com pesos e histórico. O time podia consultar a composição do indicador e acompanhar sua evolução.

  • Dimensões e pesos configuráveis para os indicadores da conta
  • Histórico por cliente, com série diária para leitura de tendência
  • Distribuição da carteira por faixa de saúde, comparável entre segmentos

Health Score

Acme Logística

78/100
Saudável · subindo
Uso do produto28
NPS18
Contrato15
Contato10
Suporte7

Sinais

Uso, suporte e pesquisas como sinais da conta

Sinais de uso, suporte e survey chegavam na mesma fila operacional. Queda de adoção, usuário-chave sumido ou feature nova adotada viravam eventos com contexto e dono.

  • Sinais de produto, métricas de suporte e resultados de survey consolidados
  • Metas por sinal com verificação diária e evento gerado no rompimento
  • Rompimento de meta podia disparar o playbook associado automaticamente

Sinais hoje

27eventos

Sinais do produto
ao vivo

  • Uso da feature core caiu 38%

    Acme · há 2min

  • Usuário-chave sem login há 9 dias

    Nordeste S. · há 1h

  • Novo usuário ativado

    Vortex Tech · há 3h

  • Feature de relatórios adotada

    Norte SaaS · há 5h

Vira tarefa no playbooksem time técnico

Risco

Risco visível enquanto ainda dava para agir

O cockpit reunia fatores de risco da conta, como queda de adoção, pesquisa negativa e proximidade da renovação, para apoiar a priorização do contato.

  • Fatores de risco combinados: NPS, adoção, contrato e recência de contato
  • Fila de clientes em risco no topo da operação diária
  • Receita e vencimentos disponíveis para apoiar a priorização
Risco hoje

3 clientes

Sinais antecipados
há 1h

Nordeste Saúde

Cliente desde 2024 · MRR R$ 4.800

  • NPS = 4 (detrator)
  • Uso ↓ 60% em 14 dias
  • Contrato vence em 45d
  • Sem contato há 3 semanas
Playbook de retenção ativo45d até renovar

Playbooks

A resposta padronizada, executada e registrada

Playbooks transformavam a boa prática do time em passos executáveis: tarefas, surveys, notificações e interações, com registro por cliente e acompanhamento de execução.

  • Acionamento por gatilho de sinal ou manualmente pelo CSM
  • Passos com responsável, prazo e estado de execução por cliente
  • Histórico de execuções auditável dentro do drawer do cliente

Disparados hoje

12playbooks

Gatilho

NPS ≤ 6 + uso ↓ 30% em 7 dias

Criar tarefa

atribuir pra CSM

1

Enviar NPS

follow-up de 7d

2

Notificar time

Teams + email

3
Roda no automáticoRegistrado na visão 360

Receita

Contratos e renovações acompanhados na carteira

Contratos, aditivos e datas de renovação alimentavam uma linha do tempo de receita, com ARR e MRR calculados e o risco financeiro da carteira visível.

  • Contratos com aditivos, cálculo de ARR e MRR e histórico de mudanças
  • Pipeline de renovação por janela de vencimento
  • Leitura de expansão e risco financeiro no nível da carteira

MRR em renovação

R$ 38k/90d

Próximas renovações9 em 30d
  • 8dias
    Acme LogísticaR$ 4.2k
    uso caiu · risco
  • 21dias
    Vortex TechR$ 6.0k
    QBR agendado
  • 34dias
    Norte SaaSR$ 2.8k
    expansão sinalizada
1 renovação em riscoplaybook aos 30d

Onboarding

Do kickoff ao valor, com estágio visível

A implantação era acompanhada por estágios de jornada, marcos de projeto e tarefas. Responsáveis e vencimentos ajudavam o time a identificar pendências.

  • Estágios de jornada com marcos, responsável e vencimento
  • Tarefas e contadores por visão da carteira
  • Acompanhamento de tarefas e marcos em atraso

Time-to-Value

24dde 30 alvo

Em Onboardingdia 18 de 30

Vortex Tech

ICP enterprise · ativada em 3 de 5 etapas

  • Kickoff
  • Setup
  • Adoção
  • Value
  • Ativado
Próximo passo programadoMaria · sex

Voz do cliente

NPS e CSAT na mesma superfície da operação

NPS e CSAT eram enviados no contexto da conta ou de uma campanha. Convites, respostas e lembretes tinham acompanhamento próprio, conectado às comunicações do produto.

  • Lançamento de NPS e CSAT por cliente ou por segmento
  • Distribuição de promotores, neutros e detratores com corte por segmento
  • Respostas de pesquisa disponíveis para gatilhos de playbooks

CSAT médio

4.6/5

NPS da carteira

30 respostas · trimestre

47NPS
  • Promotores1860%
  • Neutros827%
  • Detratores413%

“Não consegui o relatório que precisava.”

Nordeste S. · detrator · vira pauta

Resposta vira tarefa

O dia a dia

A semana do CSM cabia em uma tela

O cockpit reunia tarefas, vencimentos e sinais da carteira para orientar a rotina do CSM. Ações e atalhos mantinham o trabalho próximo ao contexto da conta.

  • Fila do dia composta por risco, vencimento e tarefa em atraso
  • Command palette para navegar e agir sem tirar a mão do teclado
  • Suporte a português e inglês, com temas claro e escuro

Carteira

32contas

Minha semana · CSM2 de 4 feitas
  • SEG

    Acme Logística

    Call de renovação

  • TER

    Vortex Tech

    Revisar adoção

  • QUA

    Nordeste S.

    Risco · NPS caiu

  • QUI

    Norte SaaS

    QBR trimestral

Priorizado por riscoMaria · CSM

Inteligência na operação

Um agente com contexto para ajudar a decidir.

O Flow conectava a intenção do usuário aos dados da conta. Consultava ferramentas do produto, reunia evidências e devolvia uma análise com referências e próximos passos, dentro do contexto de trabalho do CSM.

Arquitetura do Flow · da intenção à recomendação

  1. Intenção

    Uma pergunta sobre o cliente ou a operação.

  2. Contexto

    Ferramentas consultavam dados e registros da conta.

  3. Síntese

    A análise conectava sinais e referências às fontes.

  4. Decisão

    Recomendações eram avaliadas e acompanhadas pelo usuário.

Ferramentas com contrato

Catálogo de ferramentas, validação de parâmetros e limites de execução conectavam o modelo às operações disponíveis no produto.

Memória contextual

Análises eram associadas à empresa, ao cliente e à data, com identificação do contexto e acompanhamento das recomendações.

Evidências e rastreabilidade

Execuções registravam chamadas de ferramentas, referências, latência e consumo de tokens. A síntese mantinha vínculo com os registros consultados.

A fundação

Como estava construído

Arquitetura multi-tenant, com contexto de empresa na camada de acesso aos dados.

Backend NestJS com Drizzle sobre PostgreSQL, camada de cache com TTL por domínio e deduplicação de requisições em voo

Autenticação JWT com refresh token e acesso a dados mediado por contexto de tenant

Frontend React com estado de servidor em cache tiered e um único request de bootstrap para montar o cockpit

Warehouse analítico separado, com tabela de snapshot diário particionada para série histórica e sparklines

Design system com tokens de CSS e verificações automáticas de consistência visual

Scripts de verificação de tipos, lint, testes e regras de interface no repositório

Reconhecimento

Fluua no Web Summit Lisbon 2025

Em novembro de 2025, Daniel Kafruni apresentou a Fluua no Web Summit, em Lisboa. Uma oportunidade de discutir o produto e sua proposta com o mercado.

Registro da participação

A conversa continua

Se identificou com o que construímos?

Se a visão da Fluua faz sentido para você, vamos conversar. Sobre o produto, a tecnologia ou as possibilidades de dar continuidade ao projeto.

Contato direto

Vamos conversardaniel.kafruni@icloud.com

Conhecer mais

A visão, as escolhas e o que foi desenvolvido.

Explorar possibilidades

A tecnologia e sua aplicação em novos contextos.

Dar continuidade

Uma conversa sobre assumir e evoluir o projeto.

A operação foi encerrada. O projeto permanece aberto a conversas sobre continuidade.