Dados viram respostas. Respostas viram decisões.

A Meridian CX é uma plataforma B2B que ajuda empresas a comparar sua experiência do cliente (CX) com a de concorrentes do mesmo setor. Ela cruza um painel de pesquisa proprietário com os dados de pesquisa e jornada de cada cliente — então o cliente não vê só se o NPS dele subiu, vê como esse movimento se compara ao de concorrentes específicos, em pontos específicos da jornada.

Métricas internas respondem "estamos melhorando?", mas não "estamos fechando a distância, ou ficando para trás mesmo melhorando?". Sem benchmarking externo, uma empresa pode comemorar um NPS em alta enquanto um concorrente sobe mais rápido no mesmo ponto da jornada. A Meridian fecha esse ponto cego com dashboards, relatórios e um time de Customer Success que ajuda os clientes a interpretar os dados.

E é exatamente essa última parte — um time de CS precisando traduzir dado em significado — que é o maior custo operacional da plataforma, e o ponto de partida deste case.

Discovery

Quatro personas, quatro perguntas diferentes

O discovery — árvore de oportunidades e soluções a partir de entrevistas estruturadas, analytics de produto e dados de Customer Success — revelou quatro personas próximas do uso direto da plataforma, formando uma escada de causalidade em que cada nível organizacional persegue um tipo diferente de "por quê".

A dor em comum é a mesma, só muda de forma: o cliente recebe o dado, mas transformá-lo em insight acionável exige esforço manual — quase sempre do time de CS. O Head não consegue correlacionar uma mudança de métrica com um evento de negócio; o Gerente não consegue cruzar métricas com o que o time realmente fez; o Analista não enxerga sua própria contribuição nem consegue recortar os dados de formas novas.

Priorização

Cinco soluções candidatas, uma dependência escondida

O discovery gerou cinco soluções candidatas: registro de eventos de negócio (para o Head entender causalidade), ações vs. métricas para gestão de time (deliberadamente reduzido em escopo — sem virar um Asana ou Jira disfarçado), métricas customizadas self-service para analistas, insights de discurso de venda para o time comercial, e um módulo de insights com IA.

A quinta solução é diferente das outras quatro: ela não está presa a uma persona ou dor específica — é uma capacidade sobre a qual as outras soluções passam a fazer mais sentido. Registro de eventos e métricas customizadas não são independentes do módulo de IA, são casos de uso que ficam muito mais valiosos quando existe uma camada que os interpreta.

A solução 4 foi cortada deste roadmap por atender uma persona secundária, tirar foco do loop central de CX, e porque os dados de concorrência necessários não estariam disponíveis na granularidade exigida.

Recomendação estratégica

A IA não é o produto. É a interface.

Dashboards customizados e métricas self-service foram considerados como soluções isoladas, mas os dois ainda exigem que o cliente já saiba o que procurar. A camada de IA resolve um problema diferente: reduzir a distância cognitiva entre "o que aconteceu?" e "por que isso pode ter acontecido, o que eu deveria investigar a seguir?".

O MVP combina um log leve de eventos de negócio com uma camada de IA que lê os dados de pesquisa já existentes da Meridian e gera insights em linguagem natural com próximos passos sugeridos. Dashboards customizados e widgets de cálculo cruzado ficam para depois — deliberadamente fora do MVP, porque são esforço de engenharia pesado em UI que não testa se o cliente confia na interpretação da IA, que é a hipótese que o MVP existe para validar.

O grupo piloto é selecionado por sinal explícito de demanda — clientes que já levantaram essa necessidade com o time de CS — combinado com diversidade vertical, para testar generalização desde o primeiro dia. Três riscos guiam a validação: se o cliente vai confiar na interpretação da IA sem exigir confirmação humana (desejabilidade), se a IA consegue gerar interpretações precisas sem alucinar correlações (viabilidade técnica), e se o cliente paga um upsell por essa capacidade ou espera que venha embutida (viabilidade de negócio).

Execução

Métricas com gate, não calendário fixo

Acima das métricas de produto tem uma que funciona como norte: Time to Insight, o tempo que o cliente leva entre olhar um dado e agir sobre ele com confiança. Repeat usage, insight rate (o positivo ou negativo que o cliente dá a cada insight) e action rate sustentam esse número.

A action rate exige duas peças pequenas de instrumentação: cada insight gerado pela IA recebe um ID único ligado ao dado ou evento de origem, e o produto expõe uma ação explícita que o usuário pode tomar sobre ele — por exemplo, "marcar como investigado" ou "criar evento de negócio a partir disso". O momento em que o insight aparece e o momento em que a ação (se houver) acontece são registrados com timestamp, e a taxa é acompanhada como tendência ao longo do piloto, não como uma foto única.

A decisão de build vs. partner é tratada em duas fases. No MVP, a arquitetura usa uma API de LLM de terceiros combinando busca estruturada — para métricas, onde alucinação é menos aceitável — com RAG especificamente para dados qualitativos (verbatims e texto aberto), sem custo inicial de infraestrutura. Na fase de escala, a decisão migra para um modelo open-source ajustado em infraestrutura provisionada, reduzindo custo por requisição em alto volume e mantendo o dado dentro de um perímetro controlado — relevante para verticais sensíveis como banking e saúde.

O roadmap segue quatro fases com gate de decisão explícito em cada uma: validar (semanas 1–8, a IA gera insights em que o cliente confia?), piloto (semanas 9–12, 5–10 clientes em 2–3 verticais acham os insights úteis?), provar valor (meses 4–5, existe sinal de disposição a pagar?) e escalar (mês 6+, só depois do gate anterior aprovado).

Confiança e risco

"A IA sugere, o humano decide"

Todo insight mostra sua origem — qual dado, qual período, qual pergunta de pesquisa. O feedback de positivo/negativo alimenta um loop de melhoria contínua, e no início, uma amostra de insights passa por revisão humana antes de qualquer saída se tornar totalmente autônoma.

Resultado esperado

Metas de hipótese, não resultados anunciados

Esta proposta ainda não foi ao ar — os números abaixo são metas orientadas por hipótese que o piloto foi desenhado para testar contra os gates definidos, não resultados já alcançados. Eles existem para deixar concreto o que "bom o suficiente para escalar" significa, nas mesmas métricas definidas antes.

Se as metas não forem batidas, as próprias métricas apontam onde: insight rate alta com action rate baixa isola um problema de confiança a resolver antes de escrever mais código; insight rate baixa isola um problema de qualidade a resolver antes de levar o conceito a mais clientes. Essa leitura dupla é mais útil do que um veredito único de go/no-go — e é por isso que o roadmap é construído em torno de métricas com gate, não de uma data fixa de lançamento.