--- id: saas/comissao-ativacao-pagamento industria: SaaS e tecnologia uso: comum esforco: médio grao: Venda ou conta x marco; pessoa x semana ou mês --- # Comissão ligada a ativação e pagamento O variável de SDR, closer, AM e CS calculado sobre o que o cliente fez depois da venda (ativou, pagou, usou), com o dono certo de cada período e uma linha auditável por item. ## Resumo executivo **Para quem:** Empresas de SaaS que pagam variável de vendas e CS pelo resultado do cliente depois da venda. **O que resolve** - A apuração sai em horas, com uma linha por venda que o time consegue conferir. - O crédito vai para quem tinha o papel na época, não para o dono de hoje. - A meta premia cliente que ativa e paga, não só contrato assinado. **Por que importa:** Comissão é o número em que o time mais confia, ou menos. Uma regra ligada a ativação e pagamento alinha vendas com retenção, mas só funciona se cada linha puder ser auditada: uma disputa por mês custa mais que a automação inteira. **Perguntas de negócio que responde** - Quanto cada ISA atingiu da meta de ativação em W+5 neste mês? - Quais vendas de setembro ainda não pagaram o primeiro boleto? - Quem era o AM desta conta em agosto, e quanto MRR ele carregava? - Quanto da receita do cliente veio depois do fechamento? - Por que o meu variável deste mês ficou menor? **O que você precisa** - CRM com histórico de dono e billing ou contas a receber conectados na Nekt - Os marcos que pagam variável, com fonte e prazo de cada um - Uma tabela de metas e parâmetros com vigência **O que você recebe** - Uma base de apuração com uma linha por venda e marco - Totais por pessoa com atingimento de meta - Envio para a ferramenta de comissão ou para a planilha de pagamento - Um agente de IA que explica o variável linha a linha ## Detalhado ### O problema Em SaaS, o variável depende de eventos que estão fora do CRM: o cliente ativou, pagou o primeiro boleto, usou o produto. Calcular à mão leva dias e gera disputa: o dono do deal mudou depois da venda, um boleto cancelado contou como pago, o nome do vendedor aparece de três jeitos e ninguém sabe qual versão da regra valia naquele mês. ### Regras de negócio 1. **Cada marco tem fonte e data oficial.** Declare os marcos que pagam e a fonte de cada um: venda (data de ganho do deal), ativação (marco do produto ou data de implantação), primeiro pagamento (contas a receber ou billing), uso (consumo nos primeiros 30 dias depois da ativação). A data do marco é a do evento na fonte, nunca a data em que alguém mudou a etapa no CRM. (Evite: Pagar ativação pela etapa 'implantado' marcada no CRM.) 2. **Primeiro pagamento é a primeira parcela válida paga.** Descarte as parcelas canceladas, ordene as restantes do cliente pelo vencimento e fique com a primeira. Ela conta quando tem data de pagamento. Segundo e terceiro boletos seguem a mesma regra, para metas de AM. Cobrança recusada e depois paga é um pagamento só. (Evite: Pegar a parcela de menor vencimento, inclusive cancelada.) 3. **Ativação no prazo conta da semana da venda.** Exemplo real: ativação em W+5. A semana da venda vai de domingo a sábado e o prazo termina no sábado da quinta semana seguinte. Taxa por pessoa e semana de venda = vendas ativadas no prazo / vendas da semana, com meta (por exemplo, 60%) e super meta (80%). Venda ativada fora do prazo aparece como fora do prazo, não some. (Evite: Contar ativações do mês sobre vendas do mês.) 4. **O crédito vai para quem tinha o papel na data.** O SDR ou ISA da venda é o dono do deal na data de ganho. O AM de uma conta num mês passado é o dono vigente no dia de corte (por exemplo, dia 5); o mês corrente usa o dono atual. Leia do histórico de dono, nunca do dono de hoje. Conta só entra na carteira do AM se estava ativa na data de referência. (Evite: Apurar o passado com o dono atual do deal.) 5. **Pessoa é um id, não um nome.** Use o id do usuário do CRM e uma tabela de pessoas com grafias e apelidos mapeados, time, papel, data de entrada e de saída. Nunca cruze por nome digitado num campo livre ou numa planilha. (Evite: Normalizar nomes com um CASE espalhado pelas queries.) 6. **Receita pós-venda em janelas fixas.** Quando o variável depende da receita que o cliente gera na plataforma (volume transacionado, receita da plataforma), meça em ciclos de 30 dias a partir do fechamento (ciclo 1, 2 e 3) e compare com os 30 dias anteriores ao fechamento. Resultado real = ciclo 1 menos os 30 dias anteriores, para não pagar por receita que já existia. (Evite: Pagar sobre toda a receita do cliente no mês da venda.) 7. **Meta e regra têm vigência.** Metas por pessoa e período e parâmetros (percentuais, faixas, prazos) ficam numa tabela com início e fim de vigência, não no código. A apuração de um mês usa a versão vigente naquele mês. Meta proporcional ao dia (meta do mês x dias corridos / dias do mês) serve para acompanhar, nunca para pagar. (Evite: Trocar o percentual no código e reapurar meses passados.) 8. **Teste, interno e ajuste manual à parte.** Deals de teste, contas internas e duplicadas saem por uma lista com motivo, não por ids escritos no código. Ajustes manuais de MRR ou de crédito entram numa tabela com autor, data e motivo, somados à apuração e visíveis no extrato da pessoa. (Evite: Ids de teste e ajustes escritos dentro do SQL.) 9. **Uma linha auditável por item.** A base de apuração tem uma linha por venda (ou conta) e marco, com pessoa, datas, status (no prazo, fora do prazo, pendente, cancelado) e a chave única (por exemplo, semana mais id do deal) que a ferramenta de comissão usa para atualizar sem duplicar. O total da pessoa é a soma dessas linhas, e ela consegue conferir uma a uma. (Evite: Mandar só o total por pessoa para a ferramenta de comissão.) 10. **Mês apurado é congelado.** Depois do pagamento, o mês é gravado e não se recalcula. Pagamento ou ativação que chega depois entra como ajuste no mês em que foi descoberto, com o mês de origem registrado. Cancelamento depois do pagamento segue a regra de estorno declarada, sem reescrever o passado. (Evite: Recalcular o mês pago quando chega um boleto atrasado.) ### Marcos que costumam pagar variável Papel, marco e a fonte que prova o marco. - **SDR / ISA** → Venda ganha (`data de ganho do deal`) - **ISA** → Ativação no prazo (`marco até o sábado de W+5`) - **ISA / AM** → Primeiro boleto pago (`1ª parcela não cancelada com data de pagamento`) - **AM** → Segundo e terceiro boletos pagos - **Implantação** → Consumo nos 30 dias após a ativação - **Closer de plataforma** → Receita nos ciclos de 30, 60 e 90 dias (`ciclo 1 - 30 dias antes`) - **CS** → Indicadores de valor da conta acima da meta - **AM** → MRR da carteira no dia de corte ### Definições | Métrica | Definição | |---|---| | Venda | deal ganho, fora da lista de teste, com data de ganho no período, creditado ao dono na data de ganho | | Semana da venda | domingo a sábado que contém a data de ganho | | Ativação no prazo (W+5) | marco de ativação com data até o sábado da quinta semana depois da semana da venda | | Taxa de ativação no prazo | vendas da semana ativadas no prazo / vendas da semana, por pessoa | | Primeiro pagamento | primeira parcela do cliente por vencimento, excluídas as canceladas, com data de pagamento | | Dono do mês | dono vigente no dia de corte do mês (meses fechados) ou o atual (mês corrente) | | Resultado real | receita do cliente nos 30 dias depois do fechamento menos a receita nos 30 dias anteriores | | Atingimento | realizado / meta vigente da pessoa no período | ### Armadilhas - **O dono de hoje recebeu pelo passado.** Contas transferidas tinham a carteira de meses anteriores recalculada com o dono atual, e o AM antigo perdia crédito. Como evitar: Dono vigente no dia de corte, lido do histórico. - **Vendedor com três nomes.** O mesmo vendedor aparecia com apelido, nome completo e grafia errada, corrigidos por um CASE copiado em várias queries. Como evitar: Tabela de pessoas com id e apelidos. - **Boleto cancelado como primeiro.** A primeira parcela por vencimento podia ser uma cancelada e substituída, e a venda ficava como não paga. Como evitar: Exclua canceladas antes de ordenar. - **Ativação em dobro.** A mesma conta tinha mais de um registro de implantação e gerava duas ativações. Como evitar: Deduplique pela primeira data de implantação da conta. - **Deal de teste na comissão.** Os deals de teste estavam como ids fixos no SQL; um teste novo entrou na apuração. Como evitar: Lista de exclusão com motivo, revisada a cada apuração. - **Linha sem chave na ferramenta.** Linhas sem chave única chegaram à ferramenta de comissão e foram gravadas em dobro. Como evitar: Chave semana mais deal obrigatória; linha sem chave não sai. ### Teste de aceitação - [ ] Para cada pessoa e mês, o total apurado é a soma das linhas da base, e cada linha tem fonte e data do marco. - [ ] Trocar o dono atual de um deal não muda a apuração de nenhum mês fechado. - [ ] Nenhuma parcela cancelada conta como primeiro pagamento. - [ ] A taxa de ativação no prazo de uma semana, refeita à mão para 3 pessoas, bate com a base. - [ ] Toda linha enviada à ferramenta de comissão tem chave única, sem chave repetida. ### Context document ```text Comissão ligada a ativação e pagamento - O variável é apurado pela base de apuração: uma linha por venda ou conta e marco, com pessoa, data do marco e status. Totais são a soma dessas linhas. - Venda é creditada ao dono do deal na data de ganho. AM de mês fechado = dono vigente no dia . Nunca use o dono atual para o passado. - Ativação no prazo: marco até o sábado da quinta semana depois da semana da venda (domingo a sábado). Meta %, super meta %. - Primeiro pagamento = primeira parcela não cancelada, por vencimento, com data de pagamento. - Metas e parâmetros vêm da tabela de regras vigente no período apurado. - Mês pago é congelado. Atrasos entram como ajuste no mês em que foram descobertos. - Ao explicar um variável, mostre as linhas que compõem o total e o status de cada uma. Exceções por cliente: - : o marco de ativação do produto é . - : o time de implantação recebe sobre consumo nos 30 dias após a ativação. ``` ### Variações - **Indicadores de CS:** A conta conta para o CSM quando três indicadores de valor (por exemplo, funcionalidades usadas, falhas identificadas e economia registrada) estão acima da meta no mês. - **Receita de plataforma:** Para plataformas transacionais, o closer recebe sobre a receita da plataforma nos ciclos de 30 dias depois do fechamento. - **Metas da empresa:** Metas mensais de MRR, NPS, churn e inadimplência na mesma tabela com vigência, ligadas a OKRs.