Encerrar um produto não é desligar um botão. O último pedido, login ou transação pode acontecer em uma data, enquanto suporte, pagamentos, disputas, dados, integrações e responsabilidades continuam por dias, meses ou anos. A saída da Uber da Nigéria nesta semana deixa essa diferença muito visível: as corridas terminaram em 2 de setembro, mas a empresa informou que seu centro de ajuda permaneceria disponível até 23 de setembro para questões pendentes de conta.

A decisão encerrou uma presença de 12 anos no país. A Uber disse ter tomado a medida após uma revisão do negócio, sem detalhar os motivos. A Reuters contextualizou um mercado com concorrência intensa, alta de custos de combustível, inflação e volatilidade cambial. No dia seguinte, o Washington Post relatou que motoristas e passageiros foram surpreendidos pelo anúncio e reproduziu a posição da companhia de que sua prioridade imediata era apoiar motoristas, usuários e equipes locais durante a transição.

Isso cria uma pergunta útil para qualquer empresa que descontinua um software, uma funcionalidade, uma integração ou até um processo interno: quando exatamente a operação termina?

O serviço pode parar antes da operação

Para quem usa um produto, o momento mais visível é o corte: não dá mais para pedir uma corrida, abrir um novo chamado naquele sistema ou emitir um documento por uma integração antiga. Para a empresa, porém, esse é apenas um dos marcos.

Ainda podem existir cobranças em processamento, créditos, estornos, chamados abertos, contratos com parceiros, acessos administrativos, relatórios que precisam ser preservados, solicitações de dados, disputas e obrigações regulatórias. A própria política de privacidade da Uber continua descrevendo direitos de usuários na Nigéria e práticas de retenção de dados que podem se estender além da vida ativa de uma conta quando há exigências legais, fiscais, de seguro ou defesa de reivindicações.

Essa cauda operacional costuma receber menos atenção porque não gera mais receita nova. Só que ela concentra risco. É justamente quando o volume cai e o time começa a desmontar que um caso esquecido, uma integração que continua chamando um endpoint ou um cliente sem caminho para exportar dados pode virar incidente.

Em SaaS B2B, a situação é ainda mais clara. Um botão de “desativar cliente” raramente encerra o relacionamento. Existem documentos, permissões, dados históricos, integrações com ERP, usuários dependentes, obrigações contratuais e alguém que precisa responder se algo der errado depois do corte.

Um bom encerramento precisa de duas datas, não uma

A forma mais simples de pensar no problema é separar a data em que o produto deixa de aceitar trabalho novo da data em que a empresa considera encerradas as responsabilidades operacionais daquela transição.

Essas datas podem coincidir em operações simples. Em ambientes mais complexos, quase nunca coincidem.

A Microsoft oferece um contraste interessante com o Project Online. O produto será aposentado em 30 de setembro de 2026. A empresa manteve projetos, integrações e acesso dos usuários funcionando até a data de aposentadoria, publicou alternativas de migração e orientou clientes a fazer backup e concluir a transição antes do corte. A decisão foi anunciada com antecedência, e a comunicação oficial foi atualizada em agosto conforme a data se aproximou.

Não significa que todo desligamento precise de um ano de aviso. Uma saída de mercado e a aposentadoria de um produto enterprise têm riscos, contratos e velocidades diferentes. O ponto é outro: o prazo de transição deveria nascer das dependências que precisam ser resolvidas, não apenas da conveniência de escolher uma data para o fim.

Antes de desligar, descubra o que ainda depende do que

Projetos de implantação costumam gastar bastante energia mapeando dependências para colocar algo no ar. No encerramento, vale fazer o caminho inverso.

Quais sistemas ainda consomem dados da solução? Quem recebe arquivos, webhooks ou relatórios dela? Há automações que continuarão tentando executar uma ação depois que o serviço for desligado? Existem usuários que acessam o produto apenas uma vez por mês e podem descobrir a mudança tarde demais? Que processos de faturamento, auditoria ou suporte consultam o histórico?

Esse tipo de pergunta também aparece quando uma empresa tenta reduzir seu portfólio de ferramentas. No artigo sobre portfólio de software sem desperdício, a discussão central era que retirar uma solução com segurança exige conhecer uso, integrações e sobreposições antes de cancelar a licença. A lógica vale para qualquer sunset: desligar o ativo antes de retirar as dependências só transforma economia em retrabalho.

Em integrações com ERP, por exemplo, uma API pode parecer pouco usada porque recebe poucas chamadas. Mas talvez aquela chamada mensal feche uma obrigação fiscal ou contábil crítica. Volume baixo não significa impacto baixo. Por isso, os mesmos riscos que precisam aparecer cedo em uma integração ERP durante a implantação precisam ser revisitados quando ela vai embora.

O encerramento precisa de dono e capacidade

Existe também um problema organizacional pouco intuitivo. Quando uma empresa decide sair de um mercado ou aposentar um produto, a tendência natural é deslocar rapidamente pessoas para o próximo foco. Só que a operação antiga ainda pode precisar de capacidade.

Alguém deve ser dono dos chamados remanescentes. Alguém precisa reconciliar pagamentos. Alguém decide exceções. Alguém confirma que integrações foram desligadas. Alguém responde pela exportação ou retenção de dados. Se esses donos desaparecem antes das pendências, o trabalho não some: ele reaparece como escalonamento improvisado.

Por isso, o sucesso de um encerramento não deveria ser medido apenas por “serviço desligado na data”. Um fechamento saudável também consegue responder quantas pendências restam, quais têm prazo, quem é responsável, quais acessos continuam ativos e qual condição permite desmontar de fato a estrutura de transição.

Isso é o inverso de um go-live. Na entrada em produção, a pergunta é se a organização está pronta para assumir demanda. Na saída, a pergunta é se ela já resolveu o suficiente para retirar capacidade sem deixar responsabilidade órfã.

Comunicação não é aviso; é instrução operacional

Outro risco é tratar comunicação como um e-mail de despedida.

Uma mensagem de encerramento precisa permitir ação. O usuário deve entender o que deixa de funcionar, quando, o que ainda funcionará, como resolver pendências, onde obter seus dados quando aplicável e qual canal continuará disponível. Parceiros e clientes empresariais podem precisar de instruções diferentes de usuários finais.

O relato do Washington Post sobre a surpresa de motoristas e passageiros na Nigéria mostra por que a antecedência percebida faz parte da experiência, mesmo quando a decisão empresarial é legítima. Não é possível concluir, de fora, qual janela seria adequada para a Uber ou quais restrições internas existiam. Mas é possível extrair uma lição geral: a última experiência do cliente com um produto também compõe a percepção que fica da empresa.

Isso aparece do outro lado no onboarding. Quando marcos, próximos passos e responsabilidades ficam visíveis, a ansiedade cai. No encerramento ocorre o mesmo fenômeno: incerteza operacional vira ansiedade. Clareza sobre o que acontecerá depois é parte da entrega — uma lógica próxima da que discutimos sobre experiência do cliente durante a implantação.

Automação ajuda muito na cauda — se não esconder exceções

Encerramentos também são bons candidatos a automação. É possível identificar contas sem ação, disparar comunicações segmentadas, acompanhar confirmação de migração, verificar integrações ainda ativas, consolidar chamados e sinalizar exceções.

A IA pode resumir históricos longos, classificar motivos de contato e ajudar a equipe a priorizar casos que exigem interpretação. Mas a automação não deveria transformar “sem resposta” em “resolvido”, nem fechar disputas simplesmente porque o volume de casos caiu.

O objetivo é reduzir o custo da cauda sem fingir que ela não existe.

Uma boa operação de sunset torna visível o que ainda está aberto. Isso vale para retirada de um módulo, troca de ERP, substituição de fornecedor, desligamento de uma automação, encerramento de uma unidade de negócio ou descontinuação de um mercado inteiro.

O que deve existir antes do anúncio

Antes de comunicar uma descontinuação, algumas respostas precisam estar prontas.

O que exatamente para na data de corte? Quais funcionalidades ficam disponíveis depois? Há trabalho em andamento que precisa ser concluído ou migrado? Como ficam pagamentos, créditos e disputas? Quais dados precisam ser exportados, retidos ou excluídos? Quais integrações e credenciais serão revogadas? Quem atende exceções? Qual é o prazo final dessa equipe de transição? Como saberemos que a operação terminou de verdade?

Essas perguntas não formam um método proprietário. Elas apenas impedem um erro recorrente: confundir decisão estratégica com execução concluída.

A empresa pode decidir muito rapidamente que não quer mais sustentar um produto. Executar essa decisão com qualidade exige mapear tudo que o produto sustentava.

Nem todo encerramento precisa ser lento

Há um contraponto importante. Mais antecedência nem sempre é melhor.

Em incidentes de segurança, exigências regulatórias, risco financeiro ou serviços inviáveis, desligar rapidamente pode ser a decisão correta. Manter uma solução antiga disponível por tempo demais também cria custo, risco e complexidade. O próprio objetivo de um sunset é remover algo que não deveria continuar consumindo atenção indefinidamente.

A disciplina está em distinguir velocidade de abandono.

Um corte rápido pode vir acompanhado de uma cauda organizada: canal de suporte, responsáveis, reconciliação, preservação do necessário e comunicação clara. Da mesma forma, uma migração de 12 meses pode ser ruim se ninguém souber quais clientes ainda não estão prontos no último dia.

A pergunta não é “quanto tempo devemos avisar?”. É “quais condições precisam estar satisfeitas para cada parte poder terminar?”

A última etapa também constrói confiança

Empresas gostam de investir no começo da jornada: aquisição, onboarding, ativação, lançamento e expansão. O fim costuma parecer um problema administrativo.

Só que desligamentos testam algo mais profundo. Eles mostram se a organização conhece suas dependências, se consegue distinguir transação de responsabilidade, se seus dados são governados, se os clientes têm caminhos claros e se existe um dono até a última pendência.

A saída da Uber da Nigéria tornou essa diferença concreta em poucos dias: o serviço acabou em uma data; o suporte continuou depois dela. Para empresas de software e operações B2B, essa é a parte mais útil do caso.

Um produto não está realmente encerrado quando o botão some. Ele está encerrado quando o trabalho que ficou para trás tem destino, dono e critério de fechamento.

Fontes consultadas