Due Diligence de Precificação para Software de IA: Por Assento, Uso, Resultado

A due diligence de modelo de precificação é a disciplina de testar se o modelo de monetização de uma empresa-alvo — por assento, por uso ou consumo, por resultado ou por valor, ou um híbrido destes — se ajusta de fato à economia subjacente do produto e ao contexto de compra em que vende. Não é uma análise da página de preços. Ela pergunta qual unidade a empresa fatura, quem aciona essa unidade, se a empresa consegue prevê-la e se o modelo sobreviverá ao contato com as compras corporativas, a automação orientada por IA e a própria estrutura de custos da empresa-alvo. Errar nisso leva a avaliar incorretamente a qualidade do crescimento, a retenção e a margem na valuation.

A razão de isto se ter tornado uma questão viva de due diligence é que a IA quebra a premissa sobre a qual a precificação tradicional de SaaS foi construída. O SaaS clássico assumia custo marginal zero: uma vez construído o software, o próximo cliente custava aproximadamente o mesmo de servir que o anterior, pelo que as assinaturas fixas por assento funcionavam. Os produtos de IA têm um custo de inferência variável e significativo, em que cada consulta, ação de agente ou artefato gerado aciona um gasto de computação que o fornecedor paga. Quando o modelo de precificação não acompanha esse custo variável, a margem encolhe com a adoção em vez de se expandir.[1]

As equipas de due diligence devem calibrar-se face à realidade do mercado e não face ao hype. A AlixPartners analisou 65 grandes empresas de SaaS e concorrentes nativos de IA e descobriu que apenas 4 adotaram plenamente preços baseados em resultados, enquanto 72% seguem uma abordagem híbrida que incorpora consumo através de créditos de IA ou medição de utilização, e mais de metade das restantes empresas ainda dependem principalmente de modelos por utilizador.[2] A migração é real, mas mais lenta e desigual do que os comentários sugerem, razão pela qual o modelo correto é uma questão de economia do produto, não de ideologia.

Por utilizador (per seat): uma taxa fixa por utilizador com acesso à IA, familiar para os compradores, mas frágil quando o custo variável de inferência aumenta com a utilização.

Por token (per token): medição da entrada e saída do modelo, o modelo canónico da camada de infraestrutura, transparente para os engenheiros, mas difícil de orçamentar para os compradores de negócios.

Por atividade (per activity): uma cobrança por ação discreta, como uma conversa, uma chamada de API ou uma execução de fluxo de trabalho.

Por resultado gerado (per output): uma cobrança por artefacto gerado, como uma imagem, um documento ou um relatório redigido.

Por resultado de negócio (per outcome): uma cobrança apenas quando a IA entrega um resultado de negócio definido, como um ticket resolvido.

Híbrido: uma base de subscrição combinada com excedentes de consumo, créditos pré-pagos ou componentes baseados em resultados, o padrão que a maioria dos negócios de IA em produção segue.

Cada um destes modelos tem um perfil de due diligence distinto. Para um tratamento mais aprofundado de como a compressão de utilizadores, o COGS de inferência e as estruturas híbridas se refletem na análise de transações, consulte o nosso artigo complementar sobre due diligence de preços de IA. As secções abaixo oferecem aos compradores um enquadramento correspondente, testes modelo a modelo, uma lista de verificação de evidências e os sinais de alerta que ligam as conclusões sobre preços à avaliação.

Antes de julgar se o modelo de preços de uma empresa-alvo é bom ou mau, os compradores devem aplicar um diagnóstico que separe adequação de moda. Um modelo que parece agressivo num contexto pode ser exatamente o correto noutro. Seis perguntas estruturam esse julgamento:

O que está a ser monetizado: o acesso ao software, uma atividade contável, um resultado gerado ou um resultado de negócio entregue?

Quem desencadeia o consumo: um utilizador humano, um fluxo de trabalho automatizado ou o próprio agente de IA? Um modelo faturado por utilizador comporta-se de forma muito diferente quando são os agentes que fazem o trabalho.

Quão previsível é a utilização: o consumo é estável e previsível, ou oscila com a sazonalidade, o comportamento dos clientes e a complexidade das consultas?

O valor ou o resultado pode ser medido e atribuído: o sucesso é discreto e verificável, ou difuso entre muitos fatores contribuintes?

Os preços estão alinhados com os processos de aquisição das empresas: um CIO consegue orçamentá-lo, fazê-lo passar pelas compras e defendê-lo internamente?

Quanto poder de precificação a empresa realmente tem: o modelo de preços é defensável porque o produto está integrado nos fluxos de trabalho e é difícil de substituir, ou está exposto a reprecificação competitiva?

Dois enquadramentos publicados ajudam a responder a estas perguntas. O enquadramento COMPASS da Zuora ordena os seis modelos comuns de preços de IA — por utilizador, por token, por atividade, por resultado gerado, por resultado de negócio e híbrido — pela unidade de valor que a IA entrega e pela clareza com que esse valor pode ser medido, e observa que a maioria dos negócios de IA em produção acaba por seguir modelos híbridos que combinam uma base de subscrição com excedentes de consumo ou créditos pré-pagos.[1] O enquadramento não diz a uma empresa quanto cobrar, mas mostra quando uma alegação de resultado é credível e quando é um verniz de marketing: onde o sucesso não pode ser medido de forma aceitável para o cliente, um medidor de resultados é uma posição de negociação, não um modelo de preços.

A AlixPartners acrescenta três condições estruturais de exposição que indicam aos compradores quanta pressão um modelo de preços está a sofrer: uma elevada concentração de utilizadores em fluxos de trabalho automatizáveis, como o serviço ao cliente ou o ticketing de TI, a venda para funções onde o ROI da IA é facilmente mensurável, e a dependência de utilizadores com camadas secundárias limitadas de preços. As empresas na interseção das três condições enfrentam a necessidade mais urgente de agir.[2] O poder de precificação em si deve ser testado separadamente: onde um produto está profundamente integrado e a mudança é dispendiosa, o fornecedor tem mais margem para defender o valor por utilizador, uma dinâmica que examinamos na nossa análise dos custos de mudança de fluxos de trabalho.

Cada modelo de preços falha à sua maneira, pelo que cada um exige as suas próprias perguntas de due diligence. A tabela abaixo resume os testes essenciais; os parágrafos seguintes aprofundam as duas áreas onde os negócios mais frequentemente correm mal.

Modelos por utilizador: a compressão é o churn silencioso

Para alvos com modelo por utilizador, o teste central é o risco de compressão de utilizadores: quando agentes de IA conseguem lidar com a carga de trabalho de utilizadores que, de outra forma, teriam licenças, o argumento de valor por utilizador enfraquece a cada ciclo de implementação. A due diligence deve quantificar quanta receita está em fluxos de trabalho repetitivos e baseados em regras e, separadamente, examinar o shelfware, ou seja, a diferença entre licenças atribuídas e utilizadores ativos, porque este inflaciona a adoção reportada e subestima o risco de renovação. A profundidade dos descontos e a realização de preço completam o quadro: uma empresa que cresce em utilizadores cortando preços não está a demonstrar poder de fixação de preços.

Modelos por resultado: a definição é o produto

Para alvos com modelo por resultado, a definição de preços é efetivamente parte do produto. Não existe um padrão industrial acordado para pontuar resultados, pelo que os preços por resolução publicados não são comparáveis entre fornecedores.[3] Os compradores devem estabelecer como o sucesso é verificado, como o silêncio do cliente é tratado, o que acontece quando a IA transfere a tarefa para um humano a meio e quem suporta o custo quando as taxas de resolução decepcionam. A AlixPartners constatou que as quatro empresas do seu grupo com preços por resultado confirmados operam todas em fluxos de trabalho de atendimento ao cliente, onde os resultados são discretos e verificáveis — um referencial útil para mostrar quão estreito é atualmente o espaço viável.[2]

As conclusões sobre preços são tão sólidas quanto os documentos que as sustentam. A sala de dados deve ser analisada à procura do seguinte, e as lacunas nesta lista são, em si mesmas, uma conclusão:

Mapeamento das evidências de preços, de contratos e dados de utilização até às conclusões da due diligence. · Gerado por IA

Contratos de clientes e formulários de encomenda com tabelas de preços, incluindo condições de renovação e quaisquer compromissos de utilização ou de resultados.

Listas de preços e registos de aprovação de descontos, para testar o preço efetivo face ao preço de tabela.

Dados de utilização e consumo por cliente, incluindo mecanismos de consumo de créditos e de regularização (true-up) para modelos pré-pagos ou baseados em franquias.

Memorandos de reconhecimento de receita que cubram como a utilização, os créditos e as taxas por resultados são tratados ao abrigo da ASC 606.

Evidência de churn, downgrades e expansão em torno de alterações anteriores de preços ou de pacotes, ao nível de coortes quando disponível.

As condições contratuais determinam o tratamento contabilístico, que por sua vez molda a qualidade da receita reportada. As orientações DART da Deloitte destacam o julgamento-chave para contratos de IA agêntica: se a promessa do fornecedor é uma obrigação de disponibilidade contínua (stand-ready) de acesso ao agente, normalmente reconhecida ao longo do tempo, ou uma obrigação de entregar uma quantidade específica de resultados bem-sucedidos, normalmente reconhecida à medida que esses resultados ocorrem. Os critérios de sucesso e os direitos de transferência de créditos importam aqui, e os créditos pré-pagos por resultados podem ser não reembolsáveis numa base de "usa ou perde" ou reembolsáveis, o que altera o comportamento da receita diferida e da consideração variável.[4]

A evidência de utilização também precisa de estar ligada ao medidor efetivamente em vigor, porque os próprios medidores estão em mudança. O GitHub Copilot, por exemplo, mede interações por tokens de entrada, saída e em cache a tarifas que diferem por modelo, converte-as em créditos de IA em que um crédito equivale a um cêntimo de dólar, inclui uma franquia por plano e fatura a utilização acima dessa franquia por token, enquanto as conclusões de código ficam fora do medidor de créditos.[5] Um conjunto de dados de utilização baseado num medidor antigo pode ser inútil para prever o atual. As ferramentas de análise de documentos financeiros ajudam as equipas de transação a extrair estas condições de contratos densos e a cruzá-las com os ficheiros de utilização.

Os padrões seguintes devem desencadear testes mais aprofundados antes de chegarem ao comité de investimento.

O padrão por trás de várias destas bandeiras vermelhas é a alocação de risco. Das 65 empresas analisadas pela AlixPartners, 53 colocam o risco de desempenho no cliente, 8 partilham-no, e apenas 4 o suportam como fornecedor, o que significa que, para 82% das empresas, o cliente leva a punição se o software não cumprir.[2] E no pricing por resultados em particular, a parte que escolhe o substituto do sucesso é a parte que envia a fatura, razão pela qual as definições de resultados merecem o mesmo escrutínio que o próprio preço.[3]

Para os profissionais de investimento em PE e VC, as conclusões sobre pricing devem alimentar diretamente a avaliação da qualidade da receita. No âmbito da consideração variável, a Deloitte nota que, quando um contrato se qualifica como uma série de serviços distintos, as taxas baseadas em resultados podem ser reconhecidas à medida que os resultados bem-sucedidos ocorrem, em vez de ao longo do tempo, o que altera o momento do reconhecimento da receita e torna o crescimento reportado mais sensível aos volumes de resoluções.[4] Prever um negócio cuja receita depende de resultados que o cliente tem de alcançar é um exercício diferente de prever licenças, e a análise da qualidade do ARR deve refleti-lo.

A margem bruta é a segunda exposição. Quando o pricing não acompanha o custo variável, a adoção expande a despesa de inferência mais depressa do que a receita — a armadilha de margem que a Zuora descreve.[1] A due diligence deve modelar o custo de servir por unidade de faturação, e não apenas a margem bruta agregada, e testá-lo em cenários de stress face ao crescimento da utilização. Isto liga-se diretamente ao trabalho de due diligence do modelo financeiro, onde os pressupostos de unit economics escondem frequentemente o risco do modelo de pricing.

Em terceiro lugar, a mecânica do NRR e o risco de múltiplos concentram-se onde um modelo está em plena migração. A AlixPartners adverte que migrar para precificação baseada em resultados demasiado cedo arrisca canibalizar receita por lugar, enquanto migrar tarde demais arrisca ceder posição de mercado.[2] Um alvo apanhado entre os dois modelos pode apresentar NRR comprimido na base antiga e retenção não comprovada no novo — o que é uma questão de múltiplo, não uma nota de rodapé.

Reprecificação: corrigir o preço realizado em direção à tabela de preços onde os descontos erodiram a realização.

Reempacotamento: reestruturar franquias, excedentes e direitos de módulos para corresponder à forma como os clientes realmente consomem.

Sequenciamento da migração: mover coortes de clientes para os novos modelos numa ordem que proteja a receita por lugar enquanto a retenção do novo modelo é comprovada.

Essas alavancas são onde o valor pós-fechamento é criado ou destruído, e as equipas que assessoram mandatos de advisory M&A advisory devem tratar a questão do sequenciamento como um item do plano de criação de valor, e não como um detalhe comercial secundário.

A estrutura acima só tem valor se chegar às frentes de trabalho da equipa de transação de forma estruturada e baseada em evidências. A plataforma apoia esse fluxo de trabalho de ponta a ponta:

Use a Data Room Ingestion para analisar contratos de clientes, formulários de encomenda e tabelas de preços minutos após a abertura da sala, para que as condições de precificação entrem na análise desde o primeiro dia.

Use o AI-Analysis Engine para extrair condições de precificação, definições de medidores e critérios de sucesso de contratos densos, e para cruzar dados de utilização com a receita reportada.

Use o Risk Radar para identificar riscos de precificação, pontuá-los por materialidade e relevância para a transação, e classificá-los juntamente com o restante registo de riscos.

Use o Collaboration Hub para alinhar as frentes de due diligence comercial, financeira e tecnológica num único conjunto de questões e evidências de precificação.

Use o Report Builder para redigir conclusões baseadas em evidências com rastreabilidade completa às fontes, para que cada afirmação de precificação no relatório remeta para um documento da sala.

Um limite deve ser enunciado com clareza: a Plausity ajuda as equipas de transação a estruturar evidências e a organizar questões de due diligence, mas não determina automaticamente o modelo de precificação correto. Esse juízo permanece com a equipa, e é melhor tomado da forma como os especialistas da TechTarget aconselham os compradores: percorrendo casos reais pela precificação antes de assinar, em vez de discutir taxas de destaque.[3] As equipas de transação que quiserem ver como isto se encaixa numa configuração mais ampla de deal team evidence-backed deal team baseada em evidências, ou como a IA apoia a automação do fluxo de due diligence na triagem da sala de dados e no registo de riscos, encontrarão as questões de precificação acima encaixando-se diretamente nesses fluxos de trabalho.

Na prática, conduza a frente de precificação em quatro passos. Primeiro, classifique a unidade de faturação e o empacotamento do alvo a partir dos formulários de encomenda, e não da página de preços, e note onde lugares, medidores e taxas por resultado se sobrepõem. Segundo, aplique as seis questões de diagnóstico acima para testar a adequação à economia do produto e à realidade de aquisição. Terceiro, vincule cada afirmação a um documento: contratos, tabelas de preços, extratos de utilização e memorandos de reconhecimento de receita, sinalizando lacunas como conclusões por si mesmas. Quarto, traduza as conclusões para o caso de avaliação, mostrando o que significam para a qualidade do crescimento, a margem bruta, a previsibilidade da receita e o plano pós-fechamento de reprecificação, reempacotamento e sequenciamento da migração. As equipas de due diligence comercial podem levar essa estrutura diretamente para o dossiê do comité de investimento.

1. [1] zuora.com — https://www.zuora.com/guides/ai-pricing-models
2. [2] alixpartners.com — https://www.alixpartners.com/insights/102nf2s/outcome-based-software-pricing-hype-or-reality/
3. [3] techtarget.com — https://www.techtarget.com/enterprise-software/feature/Outcome-based-AI-pricing-hits-a-measurement-problem
4. [4] dart.deloitte.com — https://dart.deloitte.com/USDART/home/publications/deloitte/industry/technology/accounting-outcome-based-pricing-agentic-ai
5. [5] docs.github.com — https://docs.github.com/copilot/reference/copilot-billing/models-and-pricing