Duplicar plano sem perder preço anual e limites

Duplicar plano de assinatura SaaS parece operação de dois cliques: abre o plano modelo, clica em copiar, ajusta o nome e publica. Na prática, quando a cópia sai pela tela de criação (o endpoint POST /plans), o clone nasce incompleto. Preço semestral e anual somem, limites de automação zeram e flags de módulo ficam desligadas. O plano novo entra em produção autorizando coisas que a plataforma não sabe cobrar. Este texto mostra por que isso acontece e qual é a mecânica correta.

Por que copiar pela tela de criação produz clone inútil

A tela de criação de plano existe para montar um plano do zero. Ela coleta os campos mínimos para o plano existir: nome, preço mensal, moeda, ciclo padrão. Tudo que está fora desse formulário, como preço anual, limites de automação, pacote de minutos inclusos e flags de módulo, não é enviado no corpo da requisição. O endpoint grava apenas o que recebe.

O resultado é um plano estruturalmente válido e comercialmente quebrado. A base aceita o registro, a tela de checkout lista o plano, o vendedor fecha negócio. Trinta dias depois o cliente reclama que o preço anual combinado não aparece na fatura, ou que a automação travou no limite de plano inicial. Aí começa a caça ao campo perdido.

O problema não é bug. É que o endpoint de criação não foi desenhado para duplicar. Ele cria. Duplicar exige copiar a linha inteira, incluindo colunas que o formulário não expõe. Quem duplica pela tela está usando a ferramenta errada para o trabalho.

O que a cópia pelo DAO resolve e a tela não

A camada de acesso a dados, o DAO, lê a linha do plano original e grava uma nova com todos os campos, exceto o identificador. O que entra na cópia:

• Preço por ciclo: mensal, semestral e anual, cada um com seu valor e sua regra de desconto.
• Limites operacionais: número de usuários, automações ativas, disparos por mês, armazenamento.
• Pacote de minutos inclusos no plano e o preço do minuto excedente.
• Flags de módulo: discador, WhatsApp oficial, enriquecimento, IA de transcrição, cada uma com seu estado.
• Add-ons vinculados e regras de elegibilidade.

O ganho não é estético. É que o clone nasce com o mesmo comportamento comercial do original. Se o plano modelo vendia com 20% de desconto no anual, o clone vende igual. Se autorizava 3.000 automações por mês, o clone autoriza também.

Antes de mexer em qualquer rotina de duplicação, vale revisar como a plataforma está estruturada no geral, porque plano e módulos se conversam. O artigo sobre plataforma de vendas SaaS versus CRM ajuda a separar o que é configuração de produto do que é configuração comercial.

O caso do pacote de minutos que ninguém copiou

Cenário concreto. Uma operação com 12 BDRs vende um plano que inclui 2.000 minutos de ligação por mês e cobra R$ 0,18 por minuto excedente. O plano anual custa R$ 18.000 à vista, com 15% de desconto sobre o mensal.

O gestor quer lançar uma variante para um segmento novo. Duplica pela tela, muda o nome e o preço mensal. O clone fica com zero minutos inclusos e sem preço de excedente. O cliente novo liga 900 minutos no primeiro mês. O sistema não encontra pacote, não encontra tarifa e libera as chamadas porque o módulo de discador veio ligado por padrão.

Resultado: R$ 0,00 faturado sobre R$ 162 de consumo real, mais o retrabalho de explicar ao cliente que haverá cobrança retroativa. Em uma base de 30 clientes no plano novo, a conta passa de R$ 4.800 por mês de receita não faturada, além do desgaste comercial. Tudo por um campo que a tela não perguntou.

O pacote de minutos é o item mais sensível da cópia porque ele conecta três coisas: autorização de uso, custo real do provedor e regra de faturamento. Se o clone perde o pacote, autoriza ligação que a plataforma não sabe precificar. Times que operam minutos e carteira precisam de visão de consumo antes de escalar, tema tratado em eficiência comercial em serviços de margem apertada.

Flags de módulo: copie por nome, nunca por id

Esse é o erro silencioso mais comum em duplicação entre bases. Flags de módulo têm identificador numérico que difere de ambiente para ambiente. O módulo de discador pode ser id 3 na base de staging e id 7 na produção. Se a rotina de cópia leva o id, o clone herda o módulo errado ou nenhum.

A correção é simples e obrigatória: mapear a flag pelo nome estável do módulo (discador, whatsapp_oficial, enriquecimento, transcricao_ia) e resolver o id no ambiente de destino no momento da gravação. Vale a mesma regra para add-ons: nome antes de id.

Sem esse cuidado, a duplicação funciona no ambiente de teste e falha em produção, o pior tipo de defeito. A cópia precisa ser validada no ambiente onde o plano vai ser vendido. Se a operação é multi-empresa, o cuidado dobra, porque permissões e flags se cruzam. O texto sobre segurança de dados em plataforma de vendas cobre o que perguntar ao fornecedor sobre isolamento entre bases.

Checklist antes de colocar o clone à venda

Duplicar é o começo. Validar é o que impede o problema chegar ao cliente. Rode esta lista em cada plano clonado, de preferência com um teste de compra em ambiente controlado:

1. Preço por ciclo conferido: mensal, semestral e anual com os descontos corretos em relação ao original.
2. Limites de automação e usuários iguais aos do plano modelo.
3. Pacote de minutos inclusos presente e preço do minuto excedente definido.
4. Flags de módulo resolvidas por nome no ambiente correto, não por id.
5. Add-ons vinculados e elegíveis no novo plano.
6. Teste de faturamento simulado rodado com consumo acima do pacote, para confirmar que a cobrança funciona.
7. Registro de quem duplicou, quando e de qual plano, para auditoria posterior.

O passo 6 é o que a maioria pula. Simular consumo acima do pacote expõe em minutos o que levaria um mês para aparecer na fatura. Se você já passou por uma troca de plataforma, sabe que esse tipo de conferência é o que separa uma virada limpa de um trimestre de correção. O artigo sobre trocar de plataforma sem perder dados nem o time trata da mesma lógica aplicada à migração inteira.

Quem deve operar a duplicação

Em time pequeno, o próprio gestor comercial duplica. Em operação acima de 20 vendedores, isso vira função de sales ops ou de quem responde pela plataforma. O motivo é simples: a duplicação mexe em preço, limite e permissão ao mesmo tempo, e erro nesses três campos tem custo financeiro direto.

Vale documentar o procedimento em uma página. Qual endpoint usar, quais campos conferir, quem aprova a publicação. Um documento curto evita que a próxima pessoa repita a duplicação pela tela e recrie o problema. O tema de governança de configuração aparece em customizar pipeline na plataforma sem virar bagunça, com lógica que se aplica aqui.

Conclusao

Duplicar plano pela tela de criação funciona na aparência e falha na operação. O endpoint cria planos mínimos, não cópias fiéis. A duplicação pelo DAO copia a linha inteira e preserva o que dá dinheiro: preço por ciclo, limites, pacote de minutos e flags de módulo.

Se a sua operação já tem planos clonados em produção, vale auditar agora os que foram criados pela tela. É provável que algum esteja autorizando uso sem cobrança correspondente. Corrigir antes do fechamento do mês custa menos do que explicar a diferença ao cliente.