Processo Operacional de Upsell e Ativação

O "como" da Estratégia de Expansão de Receita. Da intenção à venda: as duas rotas de originação, a matriz de autoridade do pedido, os instrumentos de formalização, o fluxo de liberação e a reconciliação entre o que está ativo e o que está sendo cobrado.

Nota de leitura. Onde a decisão ainda não foi tomada, o texto marca com <<A DEFINIR>>. O marcador é proposital: uma lacuna visível é cobrável; uma lacuna preenchida por suposição é obedecida em silêncio.

Sumário executivo

A Estratégia de Expansão estabelece que toda camada tem janela, preço e dono. Este documento estabelece que toda camada tem também um solicitante autorizado, um instrumento de formalização, um executor da ativação e uma linha de cobrança.

O documento responde três perguntas operacionais que hoje ficam no ar:

1. Oferta ativa — como, quando e por quem um novo serviço é oferecido a um cliente da base.
2. Pedido do cliente — quem tem autoridade para pedir, como o pedido se formaliza, o que exige assinatura e em quanto tempo o serviço é liberado.
3. Cobrança — quem libera o faturamento, como a fatura nasce, e como se garante que o que está ativo é exatamente o que está sendo cobrado.

O risco estrutural que este documento existe para eliminar. Hoje, "ativar a feature" e "faturar a feature" são dois atos independentes, executados por áreas diferentes, sem ponto de amarração. Isso permite dois erros silenciosos e opostos:

• Ativo e não faturado — o cliente usa, a DigAI não cobra. Receita vazando. É o antipadrão "libera que depois a gente vê", só que na etapa seguinte.
• Faturado e não ativo — o cliente paga, não recebe. Churn fabricado, e o pior tipo: o cliente descobre antes de nós.

A correção é uma regra única: a ativação e a liberação de cobrança são o mesmo evento, disparado pelo mesmo registro. Nenhuma das duas acontece sozinha.

1. Estados de uma feature

Toda feature, em qualquer conta, está em exatamente um destes estados. O estado é a fonte de verdade — não a memória do CSM, não a conversa no WhatsApp.

NÃO CONTRATADO
      │  (originação: oferta ativa ou pedido do cliente)
      ▼
OPORTUNIDADE ABERTA
      │  (aceite do trial + termo com data de virada)
      ▼
EM TRIAL  ───────────────►  TRIAL EXPIRADO (não converteu)
      │  (data de virada)          │  (desativação obrigatória)
      ▼                            ▼
CONTRATO FECHADO               NÃO CONTRATADO
      │  (inadimplência / pedido de cancelamento)
      ▼
SUSPENSO  ou  CANCELADO

Regras de estado:

• Uma feature nunca transita para EM TRIAL sem termo de trial contendo data de virada e preço de saída — a regra é herdada da Estratégia de Expansão e aqui vira condição técnica, não recomendação.
• Uma feature em TRIAL EXPIRADO que não converteu deve ser desativada. Trial que expira e continua ativo é a forma mais comum de receita vazar. A desativação é automática por default; manter ativo exige exceção documentada.
• A transição para CONTRATO FECHADO dispara simultaneamente a ativação e a liberação de cobrança. Não existe uma sem a outra (ver seção 6).
• Todo estado e toda transição vivem no Zoho. O Zoho é o sistema de registro comercial da conta. O Sheets é controle operacional, não fonte de verdade contratual.

2. Rota A — Oferta ativa (a DigAI oferece)

Responde: como oferecer um novo serviço, quem é responsável pela oferta, quando deve ser oferecido.

2.1 Quem é responsável pela oferta

Regra de autoridade: o CSM oferece o catálogo a preço de tabela sem pedir permissão. Qualquer desvio de preço, prazo de trial ou escopo sobe para o Head de CS. Desconto é exceção documentada com contrapartida — nunca reflexo.

2.2 Quando oferecer — elegibilidade

A conta precisa ter todos os sinais verdes. Conta em zona de risco recebe plano de recuperação, não oferta.

• Health Score > 70 (verde)
• Mais de 60 dias de uso
• Pelo menos 5 vagas ativas/mês
• Champion identificado na conta
• Status de jornada: Adotado (5 de 7 critérios)

Interação com a regra R12. Uma conta pode estar Adotada e ter Health Score abaixo de 70. Nesse caso ela não é elegível a upsell, mesmo tendo cruzado o marco de jornada. O marco não sobrepõe o monitor de saúde — aqui, essa regra tem consequência de receita.

2.3 Quando oferecer — o momento

A oferta nunca nasce fria. Ela nasce dentro de um momento em que o valor acabou de ser demonstrado. Os gatilhos legítimos:

Anti-fadiga. Máximo de <<A DEFINIR>> ofertas ativas por conta por trimestre. Oferta demais transforma o CSM em vendedor e corrói a confiança que torna a expansão barata. O contador vive no Zoho.

2.4 O fluxo

Sinal captado (uso, dor, ritual, relatório)
        │
        ▼
CSM valida elegibilidade (5 sinais verdes)
        │
        ▼
CSM constrói a tese  ── ancorada em Capacidade Estrutural Ganha
        │                 (FTEs liberados, não economia hipotética)
        ▼
Oportunidade aberta no Zoho  ── estado muda aqui, não antes
        │
        ▼
Conversa de oferta (documentar o dia da oferta no momento de valor)
        │
   ┌────┴──────┐
 Aceite     Recusa ── registrar motivo no Zoho, reprogramar janela
   │
   ▼
Termo de trial (data de virada + preço de saída) → seção 4
   │
   ▼
EM TRIAL → seção 5

Registro: CSM registra a oportunidade, o motivo de recusa e a data de virada no Zoho.

3. Rota B — Pedido do cliente (o cliente pede)

Responde: quem pode pedir, como o pedido é feito e formalizado, se precisa de assinatura, quanto tempo leva.

3.1 Quem pode pedir — matriz de autoridade

Esta é a distinção mais importante do documento, e a que hoje não existe: um pedido não é um pedido até vir de quem tem autoridade orçamentária. Um recrutador entusiasmado no grupo de WhatsApp está emitindo um sinal, não fazendo um pedido. Tratar sinal como pedido gera ativação sem respaldo e cobrança que o sponsor não reconhece — a origem clássica de disputa de fatura.

Regra dura: nenhuma ativação de feature paga começa sem manifestação do sponsor ou do signatário. Um pedido vindo do champion sobe para o sponsor antes de virar proposta. Se o champion é o sponsor, registrar essa identidade na conta para não travar o fluxo à toa.

Por que essa regra existe. Sem ela, a DigAI ativa a pedido de quem não paga e cobra de quem não pediu. O atrito aparece no pior momento possível, e contamina a renovação.

3.2 Como o pedido é feito

O pedido pode chegar por qualquer canal — WhatsApp, e-mail, reunião, suporte. Não se exige do cliente que ele use um formulário. O que se exige é que o pedido, chegando por onde chegar, seja convertido em registro pelo CSM.

Manifestação do cliente (qualquer canal)
        │
        ▼
CSM classifica: é sinal ou é pedido? (matriz 3.1)
        │
   ┌────┴───────────┐
 Sinal            Pedido (sponsor+)
   │                    │
   ▼                    ▼
Registra e         Abre Oportunidade no Zoho
leva ao sponsor         │
                        ▼
                   Valida elegibilidade (2.2)
                        │
                        ▼
                   Proposta formal → seção 4

3.3 Elegibilidade em pedido inbound

Um cliente pedir não dispensa a checagem de elegibilidade, mas muda o tratamento da recusa. Se a conta pede uma feature e está em zona de risco (Health < 70), a resposta não é "não". É:

"Faz todo sentido — e antes de ativar, quero garantir que vocês extraiam valor disso. Vamos primeiro destravar [o ponto do plano de atenção]; assim que a conta estabilizar, ativamos."

Vender para uma conta doente antecipa o churn e ainda dá a ele um motivo contratual. Registrar a recusa e a condição de reativação da oportunidade no Zoho.

4. Formalização — o que exige assinatura

Responde: como o pedido se formaliza, se precisamos de assinaturas.

O princípio: o instrumento acompanha a consequência financeira. Mudança que altera o valor recorrente do contrato exige aditivo assinado. Liberação temporária sem custo exige termo com data de virada. Nada exige menos que um registro.

Assinatura pela DigAI: CEO ou CRO. Ferramenta: Google eSignature.

O Termo de Trial é obrigatório e não é burocracia. Ele é o instrumento que materializa a data de virada. Um trial sem termo é exatamente o antipadrão nº 1 da Estratégia de Expansão — "libera pro cliente que ele gosta e depois a gente vê" — apenas com aparência de processo. O termo contém, no mínimo:

1. Feature liberada, escopo exato do que se espera com ela e prazo do trial
2. Data de início e data de virada (não "30 dias", mas a data-calendário)
3. Preço de saída — o valor que passa a compor a mensalidade
4. O que acontece se não houver conversão (desativação automática)
5. Aceite formal do sponsor, por e-mail, com resposta explícita

Aceite por e-mail vale. Não se exige assinatura eletrônica para trial sem custo. Exige-se um "de acordo" respondido pelo sponsor no corpo do e-mail, arquivado na conta. O que não vale como aceite: reação a mensagem, "ok" em grupo de WhatsApp, concordância verbal em call não registrada.

Lacuna remanescente. O cancelamento de feature não tem instrumento definido nesta tabela. Sem ele, o caminho de saída fica indefinido — e um cancelamento informal produz exatamente o defeito "faturado e não ativo" da seção 6.4. <<A DEFINIR>>

5. Ativação

Responde: quanto tempo leva para liberar.

Regra fundadora: a ativação e a liberação de cobrança são um único evento, disparado pela transição de estado no Zoho. Ver seção 6.

5.1 Fluxo de ativação

Aditivo assinado (ou Termo de Trial aceito)
        │
        ▼
Head de CS muda o estado no Zoho → CONTRATO FECHADO
        │
   ┌────┴──────────────────┐
   ▼                        ▼
Ativação              Liberação de cobrança
(Produto/Plataforma)   (Contas a Receber)
   └────┬──────────────────┘
        ▼
Confirmação de ativação ao cliente (CSM)
        │
        ▼
Treinamento específico da feature (CSM)  ── expansão sem treino vira churn

A ativação não termina no toggle. A Estratégia de Expansão diz que "expansão fechada sem ativação vira churn". Isto é meia-verdade operacional: expansão ativada e não treinada também vira churn, e é mais insidiosa, porque o número de ativação fica verde. Uma feature ativa com zero uso após 30 dias deve acender sinal no Health Score — é um cancelamento em gestação.

5.2 SLA de liberação

<<A DEFINIR>> — o compromisso de tempo entre o pedido registrado e o cliente usando ainda não foi fixado. Enquanto não existir, a promessa de "quanto tempo leva para liberar" não pode ser feita ao cliente.

6. Cobrança e reconciliação

Responde: como monitorar a cobrança, como a fatura é emitida, quem libera.

Esta seção existe porque a RACI da Estratégia de Expansão trata "Ativar feature" e "Aditivo/contrato" como duas linhas independentes, sem nada amarrando uma à outra. Estruturalmente, isso permite ativar sem faturar e faturar sem ativar.

6.1 A regra de amarração

A transição de estado no Zoho para CONTRATO FECHADO é o único evento que autoriza tanto a ativação quanto a inclusão na planilha de Contas a Receber. Nenhuma das duas pode ser executada a partir de outra origem — nem de um pedido no WhatsApp, nem de um favor, nem de um e-mail solto.

Consequência prática: o Financeiro não emite fatura que não tenha registro de estado no Zoho, em Contas a Receber e no B.P. O Produto não ativa feature que não tenha registro de estado no Zoho. Se alguém pedir "ativa só pra ele testar", a resposta é abrir o trial com termo — que é gratuito, rápido, e preserva a data de virada.

6.2 Quem faz o quê

Ninguém "libera a cobrança" como ato discricionário. A cobrança é consequência automática de um estado. A pergunta "quem libera a cobrança?" tem, portanto, uma resposta desconfortável e correta: o aditivo assinado libera. O Head de CS lança; o Financeiro emite; nenhum dos dois decide.

Risco de concentração — a registrar. Nesta configuração, o Head de CS conduz a negociação de exceção (2.1), muda o estado no Zoho e lança a linha em Contas a Receber. São três atos da mesma cadeia na mesma pessoa. O controle que sobra é a reconciliação mensal — que só funciona como controle se não for executada pela mesma pessoa. Ver seção 10.

6.3 Ciclo de faturamento e data de virada

Pontos que precisam de decisão antes deste processo rodar plenamente:

• Sistema e ciclo de faturamento: <<A DEFINIR>> (Financeiro).
• Pró-rata: uma feature que vira paga no meio do ciclo é cobrada proporcionalmente naquele mês, ou entra cheia no ciclo seguinte? <<A DEFINIR>> (Financeiro).
• Recomendação: fixar a data de virada no primeiro dia do ciclo de faturamento do cliente. Uma janela de trial de "30 dias" vira, na prática, "até o primeiro dia do ciclo seguinte ao 30º dia". Isso elimina o cálculo proporcional e a discussão de centavos no meio de uma conversa de valor.
• Política de inadimplência (feature vs núcleo): quantos dias até suspender a feature; se a suspensão atinge o núcleo ou só a feature. <<A DEFINIR>> (Financeiro).

6.4 Monitoramento — o relatório de reconciliação

Responde: como monitorar a cobrança.

Mensal, produzido pelo Chapéu 4 (Strategy & Performance), apresentado no Ritual Executivo Mensal de CS. Cruza três fontes:

Quatro quadrantes, e dois deles são defeitos:

E um terceiro defeito, que não aparece na matriz e é o mais comum:

• 🟠 Trial expirado ainda ativo — a janela venceu, não houve conversão, e ninguém desativou. Tecnicamente é "ativo, não faturado", mas a causa é diferente: não é erro de cobrança, é falta de disciplina na data de virada.

Métrica-mãe do processo: Taxa de Reconciliação = features corretamente faturadas ÷ features ativas. Meta: 100%. Qualquer valor abaixo disso é dinheiro ou confiança saindo pela porta. Diferente das demais métricas da área, esta não admite tendência de melhoria — ela admite apenas conformidade.

Toda divergência encontrada gera um item com dono e prazo, tratado no ritual seguinte. Divergência recorrente na mesma conta é sinal de processo quebrado, não de erro humano.

7. RACI operacional

Esta RACI cobre o processo de upsell e cobrança. Para a RACI da jornada de implantação e operação (boas-vindas, kickoff, integração, bug), ver a seção 09 · Operação & RACI do Hub. As duas não se sobrepõem: esta detalha o que aquela resume na linha "Upsell".

Exatamente um A por linha. R executa · A responde pelo resultado · C consultado · I informado.

Notas de leitura:

• O A de emitir aditivo é do Financeiro — quem responde pela integridade do instrumento contratual. O CS é consultado, não dono.
• O A de ativação da feature é do Produto, mas condicionado ao estado no Zoho. O Produto não tem autoridade para ativar sem o registro; tem responsabilidade por executar quando ele existe.
• O A de desativar trial expirado é do CSM, não do Produto. Deixar trial vencido ativo é falha de disciplina comercial, não de engenharia.
• O A de reconciliação está em aberto (<<A DEFINIR>>, ver seção 10). Ele não pode recair sobre quem executa o lançamento em Contas a Receber (o Head de CS) — quem audita não pode ser quem executa.

8. Métricas do processo

Distintas das métricas de resultado da Estratégia de Expansão (NRR, MRR expandido, attach rate). Estas medem a saúde do processo, não do negócio.

9. Antipadrões deste processo

Complementam os dez da Estratégia de Expansão. Todos já aconteceram em alguma empresa; nenhum precisa acontecer aqui.

1. Ativar a pedido de quem não paga. Recrutador pede, CSM ativa, sponsor descobre na fatura.
2. Tratar "ok" em grupo de WhatsApp como aceite. Aceite é resposta explícita de sponsor, arquivada.
3. Ativar sem registrar estado no Zoho. Ativação órfã é receita que ninguém sabe cobrar.
4. Faturar sem confirmar ativação. O cliente descobre antes de nós, e nunca esquece.
5. Deixar trial vencido rodando. É a forma mais silenciosa de ensinar o cliente que o valor é de graça.
6. Entregar acesso e chamar de ativação. Sem treino, a feature tem uso zero e vira linha de corte na renovação.
7. Vender para conta doente porque ela pediu. Antecipa o churn e ainda dá a ele um motivo contratual.
8. Discutir cobrança proporcional no meio da conversa de valor. Alinhar a data de virada ao ciclo de faturamento elimina a discussão inteira.
9. Deixar a reconciliação com quem executa a cobrança. Auditor e executor não podem ser a mesma pessoa.
10. Confundir sinal com pedido. É a origem de quase todos os outros nove.

10. Lacunas abertas

Nada aqui é decisão fechada. Estes pontos travam a execução plena do processo e precisam de decisão nomeada. Esta é a fonte canônica das lacunas do processo.

Fecho

A Estratégia de Expansão de Receita afirma que toda camada passa a ter janela, preço e dono. Este processo acrescenta que toda camada passa a ter também um solicitante com autoridade, um instrumento que a formaliza, um executor que a ativa e uma fatura que a reconcilia.

A pergunta "quem libera a cobrança?" parecia precisar de um nome. Precisava de um estado. A cobrança não é liberada por ninguém: ela é a consequência automática de um aditivo assinado, registrado no Zoho, que dispara ao mesmo tempo o acesso do cliente e a linha da cobrança. Onde esses dois atos se separam, a receita vaza ou a confiança quebra — e o CS, que é accountable pelo número, responde pelos dois.

Apêndice A — Modelo de Termo de Trial

Assunto: Liberação de [Feature] para [Cliente] — período de avaliação

Olá, [Sponsor],

Conforme conversamos, vamos liberar a feature em regime de avaliação, para que vocês possam medir o resultado antes de qualquer decisão.

Escopo liberado: [descrição exata] Início: [data] Data de virada: [data-calendário] Valor a partir da data de virada: [preço de saída]

A partir da data de virada, essa camada passa a compor a mensalidade no valor acima. Caso vocês decidam não seguir, a camada é desativada automaticamente naquela data, sem custo e sem burocracia.

Ao longo do período, vamos acompanhar juntos [métrica de prova] para que a decisão seja tomada com número, não com impressão.

Para seguirmos, preciso apenas do seu "de acordo" respondendo a este e-mail.

[Nome do CSM]

Apêndice B — Modelo de registro de pedido inbound

Campos obrigatórios ao registrar no Zoho:

1. Conta e feature solicitada
2. Quem manifestou (nome, cargo) e classificação de autoridade (sinal / pedido técnico / pedido comercial)
3. Canal de origem e data da manifestação
4. Dor declarada, nas palavras do cliente
5. Elegibilidade verificada (Health Score, tempo de uso, vagas ativas, champion) — sim/não por item
6. Sponsor confirmado (nome, e-mail)
7. Próxima ação e data