Pular para o conteúdo
Todos os artigos

Anatomia da receita

Fin: cobrar por resultado começa definindo o que conta

A evolução de resoluções para outcomes mostra como uma mudança de produto altera a unidade faturável.

Infi4 min de leitura

Um agente de suporte reúne os dados, executa um procedimento e encaminha o caso para uma pessoa fazer a confirmação final.

Ele falhou porque houve participação humana? Ou concluiu exatamente o trabalho que lhe foi atribuído?

Essa pergunta ajuda a entender uma mudança documentada pelo time do Fin: ampliar a unidade de cobrança de resoluções para resultados, chamados de outcomes.

Este é um estudo de fontes públicas consultadas em 31 de agosto de 2026. Não é um caso de cliente da Infi nem uma descrição da arquitetura interna do Fin.

Quando a métrica fica menor que o produto

Em março de 2026, a equipe explicou que a métrica original reconhecia o valor quando o agente resolvia uma conversa sozinho. Com a ampliação das funções, passaram a existir procedimentos que terminavam deliberadamente numa transferência para uma pessoa.

O trabalho podia ter sido concluído como configurado, mesmo sem resolução integral pela IA. A empresa apresentou outcomes como uma forma de representar esse escopo maior. Relato da evolução da métrica.

Nossa leitura: uma métrica pode ser clara no lançamento e perder aderência quando o produto assume outra responsabilidade.

Manter o nome antigo não preserva necessariamente a simplicidade. Pode obrigar a operação a explicar exceções que já fazem parte do uso normal.

O detalhe que precisa virar regra

Na documentação consultada, uma resolução e um procedimento executado com sucesso para terminar em handoff são categorias distintas de outcome. Uma transferência configurada não deve ser confundida com qualquer escalonamento ou falha.

O fluxo de atendimento descrito também limita a cobrança de outcomes a uma por conversa, mesmo que existam várias perguntas ou etapas. Definições operacionais do Fin.

Esses detalhes mostram por que contar mensagens não seria equivalente a contar a unidade comercial.

Para quem constrói um produto próprio, há três decisões separadas: qual trabalho vale, o que comprova sua conclusão e qual identidade impede que o mesmo resultado seja cobrado novamente.

Em vendas, a fronteira é outra

Ao explicar Fin for Sales, a equipe documentou a escolha por lead qualificado e o descarte de cobrar uma participação na venda fechada.

Os motivos apresentados incluem atribuição e medição: entre a qualificação e o fechamento, entram decisões e acontecimentos fora do controle do agente; acompanhar toda essa trajetória também exige mais integração. Decisão de pricing para vendas.

Isso não prova que lead qualificado seja a unidade ideal para qualquer produto. Mostra uma empresa delimitando a parte do resultado pela qual pretende responder.

A pergunta transferível é: em que ponto seu software conclui sua parte do trabalho?

Modelo e métrica merecem decisões diferentes

Num relato sobre seu processo de pricing, o time do Fin separa o modelo comercial da métrica usada para medir valor. Também descreve pesquisa com compradores antes de definir a oferta. Processo de pricing e packaging.

Para aplicar essa distinção, uma equipe pode começar com “cobrar por resultado” e ainda ter bastante trabalho pela frente.

Resultado pode significar arquivo entregue, tarefa concluída, problema resolvido ou uma oportunidade que atende a critérios acordados. São contratos diferentes, mesmo quando todos cabem no mesmo slogan.

Também é necessário decidir o tratamento de correções e contestações. Se a conclusão de uma operação for revista, a explicação financeira precisa conseguir acompanhar essa revisão.

A lição para uma nova linha de receita

O caso não sugere copiar a tabela do Fin. Sugere documentar a unidade antes de transformar uma atividade em cobrança.

Para seu produto, escreva um exemplo de resultado cobrável, um de tentativa sem resultado e um de repetição do mesmo trabalho. Peça a pessoas de produto, engenharia e suporte que classifiquem os três.

Se houver desacordo, falta uma decisão comercial. Criar mais eventos no backend não vai resolvê-la.

Billing consegue transformar fatos elegíveis em uma fatura. A definição de elegível começa no produto.

É ali que “pagar por resultado” deixa de ser uma frase e passa a ser um contrato que alguém consegue conferir.