Considere um serviço que transforma dados em relatórios.
Uma equipe o usa diariamente. Um consultor precisa de um relatório específico. Uma plataforma quer integrar a API. Outra empresa prefere comprar um pacote e controlar o consumo.
O motor do produto pode ser o mesmo. O compromisso que cada comprador quer assumir é diferente.
Este é um exercício de desenho de oferta, não o relato de clientes da Infi. Ele ajuda a separar modelo de receita de método de pagamento.
Assinatura: vender uma relação por período
A equipe que trabalha com o serviço todos os dias pode valorizar acesso recorrente, com condições previsíveis.
A assinatura define um período e os direitos que o acompanham. Pode incluir uma franquia ou outros limites, desde que a oferta explique o que acontece depois deles.
A operação precisa saber quando começa e termina o acesso, qual versão foi contratada e como uma mudança afeta os ciclos seguintes.
Não basta cobrar o mesmo valor novamente. A renovação precisa continuar representando a promessa feita ao cliente.
Uso: vender uma unidade mensurável
Uma plataforma integrada à API pode preferir pagar pelas operações elegíveis que realiza.
Nesse modelo, definir a unidade é parte do produto: consulta, registro processado, tempo de execução ou relatório concluído.
O sistema precisa medir a unidade correta, reconhecer reenvios e atribuir o consumo ao cliente e ao período certos.
O risco de implementação é começar pelo contador mais fácil. Contar requisições internas pode ser conveniente e ainda assim medir algo diferente do que foi vendido.
Créditos: vender capacidade antecipadamente
Um pacote permite adquirir uma quantidade de uso e consumi-la ao longo do tempo, conforme as condições comerciais.
Isso traz outras perguntas: qual unidade o crédito representa? Há validade? Como bônus e ajustes aparecem? O que acontece com trabalhos em andamento?
O saldo precisa de histórico. Se houver reservas, também é necessário distinguir disponível e comprometido.
Receber um pagamento por um pacote e registrar o consumo posterior são acontecimentos diferentes. Misturá-los apaga a explicação de como a compra foi utilizada.
Compra avulsa: vender uma entrega delimitada
O consultor que precisa de um único relatório pode querer uma compra sem relacionamento recorrente.
A operação precisa identificar a entrega, confirmar o pagamento e permitir recuperar o resultado quando houver interrupção.
Nesse modelo, a pergunta central é o que encerra a obrigação. Iniciar um job, concluir o processamento e disponibilizar um arquivo não são necessariamente o mesmo marco.
Compare as promessas antes de comparar os botões
| Modelo | O que a oferta organiza | Evidência que a cobrança precisa preservar |
|---|---|---|
| Assinatura | Acesso e condições por período | Versão contratada e ciclo |
| Uso | Quantidade de unidades cobráveis | Eventos elegíveis e regra de preço |
| Créditos | Capacidade adquirida e consumida | Concessões, débitos e ajustes |
| Avulso | Uma entrega específica | Compra, confirmação e entregável |
Cartão, Pix ou um fluxo compatível de cripto entram em outra dimensão: como o pagamento é executado.
O mesmo cuidado vale para agentes. Vender para software não define sozinho se a oferta é avulsa ou medida por consumo.
O custo continua do lado do produto
Escolher uma unidade comercial não elimina a necessidade de acompanhar o custo para produzi-la.
Se o preço cobre um relatório concluído, as tentativas necessárias para concluí-lo continuam consumindo recursos. Se o produto vende acesso por período, alguns clientes podem usar mais que outros.
Vale comparar uma oferta com uso baixo, uso intenso e falhas de execução. O objetivo é entender o compromisso antes de multiplicar opções na página de preços.
Na Infi, Billing reúne catálogo, medição, créditos e cobrança, com configuração explícita dos modelos suportados. O billing documentado é em BRL. Rail e aceitação de cripto estão em early access; os quatro exemplos acima não prometem disponibilidade de todos esses caminhos pelo Rail. Configuração de produtos e cobrança.
Uma boa primeira oferta cabe numa frase que o cliente entende e o sistema consegue verificar.
As outras podem vir quando houver uma razão de compra diferente, não apenas mais espaço na tabela de planos.