KPIs que importam: como definir com stakeholders

Existe um padrão recorrente no desenvolvimento de dashboards B2B: o sistema é construído, entregue, e três meses depois o time de dados descobre que ninguém abre as telas. O dashboard está funcionando perfeitamente do ponto de vista técnico — as queries rodam, os gráficos renderizam, os filtros funcionam. Mas não houve adoção.

O diagnóstico quase sempre aponta para o mesmo problema: as métricas foram definidas sem os stakeholders que precisam usar o dashboard. Alguém da área técnica decidiu o que seria medido com base em "o que está disponível no banco" em vez de "o que as pessoas precisam para tomar decisões".

Métricas de Vaidade vs Métricas que Geram Ação

A distinção fundamental antes de qualquer workshop é entender a diferença entre métricas de vaidade e métricas de ação.

Métricas de vaidade fazem números crescerem e parecem bem em apresentações, mas não orientam nenhuma decisão específica. Exemplos clássicos: número total de usuários cadastrados (inclui usuários inativos, cancelados, duplicados), pageviews totais (sem contexto de qual página ou de qual comportamento), número de posts publicados.

Métricas de ação são aquelas que, quando mudam, implicam uma ação específica que alguém na empresa pode executar. A pergunta diagnóstica é simples: "Se este número cair 20% amanhã, o que você vai fazer diferente?" Se a resposta for "nada" ou "não sei", é métrica de vaidade.

Exemplos de métricas de ação em contextos B2B:

Contexto	Métrica de Vaidade	Métrica de Ação
E-commerce B2B	Total de pedidos	Taxa de conversão por categoria
SaaS	Usuários cadastrados	DAU/MAU ratio (stickiness)
Logística	Entregas realizadas	% de entregas no prazo por rota
Suporte	Tickets abertos	Tempo médio de primeira resposta
Financeiro	Receita bruta	MRR + net churn por coorte

A diferença prática: se a taxa de conversão por categoria cai, você sabe que precisa investigar aquela categoria específica — sortimento, preço, UX do processo de compra. Se o total de pedidos cai, você sabe... que algo está errado, mas não onde começar a investigar.

Workshop de KPIs: Como Facilitar a Conversa

Um workshop de KPIs bem conduzido dura entre 2 e 4 horas e resulta em uma lista priorizada de no máximo 15-20 métricas. Workshops que tentam cobrir mais do que isso geralmente terminam com listas extensas de indicadores que nunca são revisitados.

Estrutura recomendada:

1. Contexto e alinhamento (20 min): Comece com a pergunta "quais decisões você toma semanalmente que poderiam ser melhores com dados?" — não "quais métricas você quer ver". A orientação por decisão em vez de por dados muda o frame da conversa. Stakeholders tendem a pedir métricas baseadas no que já conhecem; a pergunta por decisão abre espaço para métricas que eles não saberiam pedir.

2. Mapeamento de decisões (30 min): Liste as 5-10 decisões mais importantes que cada stakeholder toma. Para cada decisão, pergunte: "o que você precisaria saber para tomar essa decisão com mais confiança?" Documente as respostas como requisitos de informação, não como métricas ainda.

3. Tradução para métricas (45 min): Para cada requisito de informação, defina: o nome da métrica, a fórmula de cálculo, a fonte dos dados, a frequência de atualização necessária, e o que seria um valor bom vs alarmante.

4. Priorização (30 min): Use uma matriz 2x2 simples: impacto na decisão (alto/baixo) vs facilidade de instrumentação (alta/baixa). Comece pelas métricas de alto impacto e alta facilidade. As de alto impacto e baixa facilidade entram no backlog com prazo definido.

5. Validação técnica (offline): Antes de confirmar o escopo, o time técnico verifica se os dados necessários existem, se as queries são viáveis e quais instrumentações adicionais são necessárias.

OKRs e Sua Relação com Dashboards Operacionais

OKRs (Objectives and Key Results) e dashboards operacionais medem coisas diferentes em escalas de tempo diferentes — e entender essa relação evita o erro de tentar usar um único dashboard para ambos.

OKRs são instrumentos de alinhamento estratégico com ciclos trimestrais ou anuais. Os Key Results são metas com data e target numérico: "aumentar NPS de 42 para 55 até dezembro". Eles respondem à pergunta "estamos indo na direção certa?".

Dashboards operacionais são instrumentos de monitoramento com atualização diária ou intradiária. Eles respondem "o que está acontecendo agora?" e "onde está o problema específico?".

A conexão entre os dois: os Key Results do OKR devem aparecer como métricas de destaque no dashboard, com visualização de progresso em relação à meta. Os indicadores operacionais do dashboard são os "leading indicators" — os sinais que antecipam se o Key Result vai ser alcançado.

OKR: aumentar NPS de 42 para 55 até dezembro
  └─ KR: NPS mensal [dashboard: progresso até meta]
       └─ Leading indicators:
            - Tempo médio de resolução de tickets [dashboard: diário]
            - Taxa de bugs críticos em produção [dashboard: em tempo real]
            - % de onboarding completado em 7 dias [dashboard: semanal]

Visualizar explicitamente essa hierarquia — meta estratégica → indicadores operacionais — dá ao dashboard um propósito que os usuários entendem. Em vez de "uma coleção de números", ele se torna "o sistema que mostra se estamos alcançando nossos objetivos".

Instrumentação: Do KPI à Query de Banco

Definir KPIs é a parte estratégica. Instrumentar para calculá-los corretamente é a parte técnica que frequentemente é negligenciada e causa inconsistências.

Cada KPI precisa de um documento de especificação técnica com:

• Definição precisa: "pedidos confirmados" inclui ou exclui pedidos cancelados posteriormente? Inclui todos os canais ou apenas o canal digital?
• Query canônica: a query SQL (ou equivalente) que produz o número correto, revisada pelo stakeholder
• Grain da tabela: a granularidade dos dados fonte (uma linha por pedido? por item de pedido?)
• Tratamento de nulos e bordas: o que acontece com pedidos sem data de entrega confirmada?

-- Especificação técnica: taxa de entrega no prazo
-- Definição: % de pedidos com status 'delivered' onde
--   delivery_date <= promised_date
--   excluindo pedidos com causa_raiz = 'cliente_ausente'
-- Grain: um registro por pedido

SELECT
  DATE_TRUNC('week', o.delivery_date) AS week,
  COUNT(*) AS total_delivered,
  COUNT(*) FILTER (
    WHERE o.delivery_date <= o.promised_date
  ) AS on_time,
  ROUND(
    COUNT(*) FILTER (WHERE o.delivery_date <= o.promised_date)::numeric
    / NULLIF(COUNT(*), 0) * 100, 2
  ) AS on_time_rate_pct
FROM orders o
WHERE
  o.status = 'delivered'
  AND o.cancellation_reason IS DISTINCT FROM 'cliente_ausente'
  AND o.delivery_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1
ORDER BY 1;

A query canônica vira o contrato entre o time de dados e os stakeholders. Quando alguém perguntar "por que o dashboard mostra 87% mas a planilha do gerente mostra 91%?", você vai para a query canônica e encontra a diferença de definição — provavelmente o critério de exclusão de "cliente ausente".

Conclusão

O dashboard que ninguém usa é construído por um time técnico que não conversou o suficiente com quem vai usar. O processo de definição de KPIs — workshop, validação técnica, especificação de queries — parece burocrático antes de começar e parece óbvio depois de concluído.

O investimento é real: um workshop de KPIs bem conduzido pode atrasar o início do desenvolvimento em uma semana. Mas ele evita dois ou três meses de retrabalho quando o sistema entregue não atende porque mediu as coisas erradas.

Na SystemForge, a definição de métricas faz parte da fase de brief — antes de qualquer decisão técnica. Os KPIs definidos nos workshops viram requisitos documentados no PRD, que guiam as queries no LLD e a arquitetura do dashboard no design. Não tratamos métricas como detalhe de implementação.