Um Mês de Atraso nas Aprovações: Como a Falta de Planejamento Aumentou o Custo do Projeto em 1,5 Vezes
Descubra como um simples atraso de um mês em aprovações pode inflacionar o custo de um projeto de CRM em 50%, detalhando os desafios técnicos e financeiros envolvidos no 'aquecimento' de servidores de e-mail.
MundiX News·10 de junho de 2026·6 min de leitura·👁 7 views
Olá, Habr! Meu nome é Alexey Postrigaylo, sou sócio sênior da integradora de TI "Ensign". Há mais de 20 anos atuo em integração de sistemas e gerenciamento de projetos.
Esta é a segunda parte da história sobre nosso projeto de CRM. Na primeira parte, analisamos detalhadamente por que foi necessário desenvolver uma solução customizada para a tarefa de envio de e-mails, como garantimos a conformidade com as leis de proteção de dados pessoais e, finalmente, obtivemos um produto totalmente pronto para uso. Hoje, quero falar sobre o que mais preocupa qualquer gestor do que um código limpo – o dinheiro. Mostrarei como uma oportunidade de otimização não aproveitada a tempo se transforma em números muito concretos no orçamento e onde o projeto tinha potencial de economia.
Introdução: Quando o Sistema Está Pronto, Mas a Entregabilidade Está em Dúvida
Lembro das premissas: desenvolvemos e implementamos um sistema de CRM, cuja função principal era um circuito de envio de e-mails próprio para gerenciar uma base de 70 mil endereços. A velocidade alvo era de toda a base em uma hora. O sistema estava pronto, o botão "Enviar" piscava e convidava. No entanto, justamente porque criamos uma solução sob medida, e não algo pronto de prateleira, simplesmente apertar o botão não era possível.
É possível passar semanas aprimorando textos com advogados e profissionais de marketing, garantindo o cumprimento dos requisitos da Lei Federal nº 152 e da FSTEC. Só que, sem uma infraestrutura de e-mail corretamente preparada, todos esses esforços da equipe são em vão, e as cartas permanecem invisíveis para os destinatários, indo direto para os "filtros de spam".
Gigantes do e-mail como Google, Mail.ru e Yandex, com seus algoritmos anti-spam, são rigorosos, mas justos. Eles veem o fluxo de e-mails de um servidor novo e "frio" e, por padrão, o consideram suspeito. A confiança precisa ser conquistada. Assim, em nosso projeto, surgiu uma tarefa obrigatória – o "aquecimento" dos servidores de e-mail.
Por Que um Servidor de E-mail Precisa Ser "Aquecido"
Todo o sistema funciona com base na reputação. Imagine que seu novo servidor é uma pessoa sem histórico de crédito, que vai ao banco e, de cara, pede o maior empréstimo. O que o banco fará? Exato, olhará com grande suspeita. Assim como os provedores de e-mail olham para o seu IP "frio" e para o nome de domínio remetente desconhecido. E quando esse "estranho" tenta, de uma só vez, enviar 70.000 e-mails, o alarme dispara. Primeiro, todas as suas mensagens vão para "Spam", e se você continuar assim, será simplesmente bloqueado. Isso não é má intenção dos provedores de e-mail – seus servidores bloqueiam automaticamente envios em massa de um novo IP para proteger seus usuários de lixo eletrônico real.
Para que esse "banco" comece a confiar em você, é preciso se mostrar um cliente adequado. É necessário o "aquecimento" – um procedimento obrigatório para novos domínios, que forma a reputação de remetente confiável. O processo é metódico: começamos enviando pequenos lotes de e-mails e, seguindo um esquema comprovado, aumentamos gradualmente os volumes. A equipe, nesse período, monitora as métricas chave: quantos e-mails foram enviados, quantos retornaram (bounce-rate), se os servidores dos destinatários estão reclamando de nós. Essencialmente, estamos apresentando nosso servidor ao mundo do e-mail e provando que não somos spammers, mas pessoas decentes.
Naturalmente, antes do início do aquecimento, preparamos a base técnica: configuramos os registros SPF, DKIM e DMARC. Isso é uma espécie de passaporte digital que confirma a autenticidade do remetente e nos diferencia de fraudadores de e-mail. A configuração correta desses parâmetros é o mínimo de higiene, a "base" para qualquer envio legítimo. Pular esta etapa significa dar um prego no caixão de toda a empreitada.
O Fator Tempo: Por Que uma Margem é Sempre Bem-Vinda
Idealmente, o aquecimento deve ser iniciado com alguns meses de antecedência em relação ao início do envio principal. Isso permite, com calma e sem pressa, construir a reputação necessária. Mas aqui aconteceu um clássico do gênero, familiar a qualquer gerente de projeto: as aprovações finais e as correções foram concluídas apenas um mês antes do prazo. Ficamos em uma situação em que nosso novo servidor de e-mail tinha reputação zero, e o tempo era escasso. No entanto, tínhamos um plano de ação aprovado para esse cenário.
Tivemos que pegar a calculadora. As premissas para o cálculo eram as seguintes: base de 70 mil usuários, cada um precisando receber no mínimo três e-mails para aumentar a conversão. Total – 210 mil e-mails. Tínhamos 20 dias úteis. Recomendações adicionais sobre restrições: intervalo de 3-4 dias entre e-mails repetidos para o mesmo destinatário e a regra clássica de aquecimento – aumentar o volume diário de envio em não mais que 10-15%.
A aritmética simples mostrou: para aquecer um servidor de acordo com todas as regras para nossos volumes, são necessários 38 dias úteis. E em nosso poder tínhamos apenas 20. E a cereja do bolo: não havia mais tempo para envios "de treinamento". Tivemos que aquecer imediatamente com os e-mails "de combate" – aqueles mesmos, para coletar consentimentos para o processamento de dados pessoais. Tal cenário transformava nossa equipe em desarmadores de bombas, ou seja, sem direito a erro – cada e-mail, desde o primeiro dia, deveria chegar ao destinatário.
Solução: Paralelizar o Processo
Encaixar os 38 dias de trabalho calculados em um sprint de 20 dias era impossível – qualquer equipe perceberia isso imediatamente. A solução se delineou da seguinte forma: implantamos dois servidores de e-mail em vez de um, dividimos a carga e os aquecemos em paralelo. Assim, reduzimos o risco de bloqueios, aceleramos o envio e cumprimos o prazo do cliente.
Ao mesmo tempo, para nossos engenheiros DevOps, isso significou dobrar o trabalho de configuração e lançamento da infraestrutura. Eles implantaram, configuraram e assumiram o suporte de dois servidores de e-mail idênticos, mas independentes. Dividimos toda a base de usuários ao meio e atribuímos cada parte ao seu próprio servidor. Cada um deles, assim, construiu sua reputação de forma gradual e previsível.
O processo ocorreu de forma sincronizada. Começamos com volumes mínimos, enviando e-mails de combate para coleta de consentimentos, e depois, diariamente e metodicamente, aumentamos os limites de envio, sem ultrapassar a marca de 10-15% de crescimento. Ao mesmo tempo, monitoramos continuamente os parâmetros técnicos chave: limites de envio por hora e por dia, bem como a taxa de retorno (bounce-rate), para reagir imediatamente a quaisquer sinais de bloqueio. Essencialmente, conduzimos duas campanhas de envio paralelas e extremamente cautelosas.
A abordagem funcionou como um relógio. Realizamos o envio para coleta de consentimentos para o processamento de dados pessoais, cumprimos o prazo, e o sistema, utilizando dois servidores simultaneamente, atingiu a velocidade alvo de 70.000 e-mails/hora. Como a quantidade de e-mails enviados durante o processo de aquecimento cresce geometricamente, um dos servidores logo dobrou sua velocidade de envio e o segundo servidor tornou-se simplesmente desnecessário – transferimos toda a carga para uma máquina. Assim, para o envio subsequente, programado para um evento, já tínhamos um servidor totalmente pronto e "aquecido", que poderia ser usado sem qualquer receio.
Conclusão: Calculando o Custo da Procrastinação
Esses processos me deram, como gestor, motivos para algumas reflexões.
Para sua conveniência, traduzirei essas reflexões para o plano financeiro, para que ganhem contornos mais tangíveis. Deixo claro de antemão que, para os cálculos, usarei valores médios de mercado – ou seja, em seu caso específico, eles podem diferir, mas a ordem das somas e, o mais importante, as conclusões permanecerão as mesmas.
Dado:
Custo da hora de um engenheiro DevOps: 5.000 rublos.
Custo da hora de um administrador de sistemas para suporte: 3.000 rublos.
Configuração de um servidor: 50 horas.
Suporte de um servidor: 40 horas por mês.
Aluguel de um servidor: 35.000 rublos por mês.
Custo do ambiente de servidor (SO, antivírus, etc.): 60.000 rublos.
Cenário 1: "Planejado" (2 meses para preparação)
Preparamos um servidor tranquilamente.
Aluguel do servidor: 35.000 x 2 meses = 70.000 rublos.
Ambiente de servidor: 60.000 rublos.
Configuração: 50 h x 5.000 rublos = 250.000 rublos.
Suporte: 40 h/mês x 2 meses x 3.000 rublos = 240.000 rublos.
Total: 620.000 rublos.
Cenário 2: "Emergencial" (1 mês para preparação)
Precisamos de dois servidores para cumprir os prazos.
Aluguel dos servidores: 35.000 x 2 unidades = 70.000 rublos.
Ambiente de servidor: 60.000 x 2 unidades = 120.000 rublos.
Configuração: 50 h x 2 servidores x 5.000 rublos = 500.000 rublos.
Suporte: 40 h/mês x 2 servidores x 3.000 rublos = 240.000 rublos.
Total: 930.000 rublos.
A diferença de custo é de 310.000 rublos para este exemplo, mas a soma aqui não é o indicador principal. Muito mais indicativo é outro número – o aumento de custos em quase um vez e meia. Este é o preço de um mês de procrastinação. Pensando adiante, vemos que a economia poderia ter sido ainda maior. Por exemplo, quando você está sob pressão de tempo, você pega os servidores que estão disponíveis no momento, pois não pode esperar 2-3 dias para encontrar uma oferta mais interessante. Adicione a isso as perdas não financeiras: equipe esgotada, nervos gastos, riscos excessivos – isso não aparece no orçamento.
Mais um ponto: 70 mil endereços é um volume pequeno para envios corporativos. E se sua base for 3 vezes maior (210 mil endereços), e os prazos forem os mesmos? Os custos e, consequentemente, a economia potencial aumentam exponencialmente. Em nosso exemplo, o lucro cessante seria de mais de 930.000 rublos. Assim, à primeira vista, "trocados" se transformam em somas muito impressionantes.
A conclusão é simples: a preparação da infraestrutura de e-mail deve começar o mais cedo possível, ou seja, "ontem". Esperar que a equipe de marketing prepare o texto perfeito e que os advogados verifiquem cada formulação é um luxo inadmissível, pelo qual o negócio paga. Concorde com uma versão "leve" do e-mail para aquecimento: um resumo de notícias, um anúncio, uma notificação técnica – qualquer coisa! Enquanto seus colegas trabalham na versão final do envio, seu servidor já começará a construir relacionamentos com os gigantes do e-mail e a ganhar confiança inestimável.
Portanto, da próxima vez que em uma reunião alguém disser: "Vamos pensar um pouco mais sobre o tema do e-mail", simplesmente mostre a eles esta fórmula: 1 mês de reflexão = 1 servidor adicional no orçamento. E faça uma pergunta simples: "Pessoal, vocês têm certeza de que estão dispostos a pagar por isso?"
Obrigado pela atenção. Se foi útil, inscreva-se.
P.S. A propósito, transformamos este CRM para envios seguros em um de nossos produtos prontos. Ele está disponível para empresas que se preocupam em gerenciar a segurança do armazenamento de dados pessoais ao organizar envios em seu próprio ambiente seguro.
Olá, Habr! Meu nome é Alexey Postrigaylo, sou sócio sênior da integradora de TI "Ensign". Há mais de 20 anos atuo em integração de sistemas e gerenciamento de projetos.
Esta é a segunda parte da história sobre nosso projeto de CRM. Na primeira parte, analisamos detalhadamente por que foi necessário desenvolver uma solução customizada para a tarefa de envio de e-mails, como garantimos a conformidade com as leis de proteção de dados pessoais e, finalmente, obtivemos um produto totalmente pronto para uso. Hoje, quero falar sobre o que mais preocupa qualquer gestor do que um código limpo – o dinheiro. Mostrarei como uma oportunidade de otimização não aproveitada a tempo se transforma em números muito concretos no orçamento e onde o projeto tinha potencial de economia.
Introdução: Quando o Sistema Está Pronto, Mas a Entregabilidade Está em Dúvida
Lembro das premissas: desenvolvemos e implementamos um sistema de CRM, cuja função principal era um circuito de envio de e-mails próprio para gerenciar uma base de 70 mil endereços. A velocidade alvo era de toda a base em uma hora. O sistema estava pronto, o botão "Enviar" piscava e convidava. No entanto, justamente porque criamos uma solução sob medida, e não algo pronto de prateleira, simplesmente apertar o botão não era possível.
É possível passar semanas aprimorando textos com advogados e profissionais de marketing, garantindo o cumprimento dos requisitos da Lei Federal nº 152 e da FSTEC. Só que, sem uma infraestrutura de e-mail corretamente preparada, todos esses esforços da equipe são em vão, e as cartas permanecem invisíveis para os destinatários, indo direto para os "filtros de spam".
Gigantes do e-mail como Google, Mail.ru e Yandex, com seus algoritmos anti-spam, são rigorosos, mas justos. Eles veem o fluxo de e-mails de um servidor novo e "frio" e, por padrão, o consideram suspeito. A confiança precisa ser conquistada. Assim, em nosso projeto, surgiu uma tarefa obrigatória – o "aquecimento" dos servidores de e-mail.
Por Que um Servidor de E-mail Precisa Ser "Aquecido"
Todo o sistema funciona com base na reputação. Imagine que seu novo servidor é uma pessoa sem histórico de crédito, que vai ao banco e, de cara, pede o maior empréstimo. O que o banco fará? Exato, olhará com grande suspeita. Assim como os provedores de e-mail olham para o seu IP "frio" e para o nome de domínio remetente desconhecido. E quando esse "estranho" tenta, de uma só vez, enviar 70.000 e-mails, o alarme dispara. Primeiro, todas as suas mensagens vão para "Spam", e se você continuar assim, será simplesmente bloqueado. Isso não é má intenção dos provedores de e-mail – seus servidores bloqueiam automaticamente envios em massa de um novo IP para proteger seus usuários de lixo eletrônico real.
Para que esse "banco" comece a confiar em você, é preciso se mostrar um cliente adequado. É necessário o "aquecimento" – um procedimento obrigatório para novos domínios, que forma a reputação de remetente confiável. O processo é metódico: começamos enviando pequenos lotes de e-mails e, seguindo um esquema comprovado, aumentamos gradualmente os volumes. A equipe, nesse período, monitora as métricas chave: quantos e-mails foram enviados, quantos retornaram (bounce-rate), se os servidores dos destinatários estão reclamando de nós. Essencialmente, estamos apresentando nosso servidor ao mundo do e-mail e provando que não somos spammers, mas pessoas decentes.
Naturalmente, antes do início do aquecimento, preparamos a base técnica: configuramos os registros SPF, DKIM e DMARC. Isso é uma espécie de passaporte digital que confirma a autenticidade do remetente e nos diferencia de fraudadores de e-mail. A configuração correta desses parâmetros é o mínimo de higiene, a "base" para qualquer envio legítimo. Pular esta etapa significa dar um prego no caixão de toda a empreitada.
O Fator Tempo: Por Que uma Margem é Sempre Bem-Vinda
Idealmente, o aquecimento deve ser iniciado com alguns meses de antecedência em relação ao início do envio principal. Isso permite, com calma e sem pressa, construir a reputação necessária. Mas aqui aconteceu um clássico do gênero, familiar a qualquer gerente de projeto: as aprovações finais e as correções foram concluídas apenas um mês antes do prazo. Ficamos em uma situação em que nosso novo servidor de e-mail tinha reputação zero, e o tempo era escasso. No entanto, tínhamos um plano de ação aprovado para esse cenário.
Tivemos que pegar a calculadora. As premissas para o cálculo eram as seguintes: base de 70 mil usuários, cada um precisando receber no mínimo três e-mails para aumentar a conversão. Total – 210 mil e-mails. Tínhamos 20 dias úteis. Recomendações adicionais sobre restrições: intervalo de 3-4 dias entre e-mails repetidos para o mesmo destinatário e a regra clássica de aquecimento – aumentar o volume diário de envio em não mais que 10-15%.
A aritmética simples mostrou: para aquecer um servidor de acordo com todas as regras para nossos volumes, são necessários 38 dias úteis. E em nosso poder tínhamos apenas 20. E a cereja do bolo: não havia mais tempo para envios "de treinamento". Tivemos que aquecer imediatamente com os e-mails "de combate" – aqueles mesmos, para coletar consentimentos para o processamento de dados pessoais. Tal cenário transformava nossa equipe em desarmadores de bombas, ou seja, sem direito a erro – cada e-mail, desde o primeiro dia, deveria chegar ao destinatário.
Solução: Paralelizar o Processo
Encaixar os 38 dias de trabalho calculados em um sprint de 20 dias era impossível – qualquer equipe perceberia isso imediatamente. A solução se delineou da seguinte forma: implantamos dois servidores de e-mail em vez de um, dividimos a carga e os aquecemos em paralelo. Assim, reduzimos o risco de bloqueios, aceleramos o envio e cumprimos o prazo do cliente.
Ao mesmo tempo, para nossos engenheiros DevOps, isso significou dobrar o trabalho de configuração e lançamento da infraestrutura. Eles implantaram, configuraram e assumiram o suporte de dois servidores de e-mail idênticos, mas independentes. Dividimos toda a base de usuários ao meio e atribuímos cada parte ao seu próprio servidor. Cada um deles, assim, construiu sua reputação de forma gradual e previsível.
O processo ocorreu de forma sincronizada. Começamos com volumes mínimos, enviando e-mails de combate para coleta de consentimentos, e depois, diariamente e metodicamente, aumentamos os limites de envio, sem ultrapassar a marca de 10-15% de crescimento. Ao mesmo tempo, monitoramos continuamente os parâmetros técnicos chave: limites de envio por hora e por dia, bem como a taxa de retorno (bounce-rate), para reagir imediatamente a quaisquer sinais de bloqueio. Essencialmente, conduzimos duas campanhas de envio paralelas e extremamente cautelosas.
A abordagem funcionou como um relógio. Realizamos o envio para coleta de consentimentos para o processamento de dados pessoais, cumprimos o prazo, e o sistema, utilizando dois servidores simultaneamente, atingiu a velocidade alvo de 70.000 e-mails/hora. Como a quantidade de e-mails enviados durante o processo de aquecimento cresce geometricamente, um dos servidores logo dobrou sua velocidade de envio e o segundo servidor tornou-se simplesmente desnecessário – transferimos toda a carga para uma máquina. Assim, para o envio subsequente, programado para um evento, já tínhamos um servidor totalmente pronto e "aquecido", que poderia ser usado sem qualquer receio.
Conclusão: Calculando o Custo da Procrastinação
Esses processos me deram, como gestor, motivos para algumas reflexões.
Para sua conveniência, traduzirei essas reflexões para o plano financeiro, para que ganhem contornos mais tangíveis. Deixo claro de antemão que, para os cálculos, usarei valores médios de mercado – ou seja, em seu caso específico, eles podem diferir, mas a ordem das somas e, o mais importante, as conclusões permanecerão as mesmas.
Dado:
Custo da hora de um engenheiro DevOps: 5.000 rublos.
Custo da hora de um administrador de sistemas para suporte: 3.000 rublos.
Configuração de um servidor: 50 horas.
Suporte de um servidor: 40 horas por mês.
Aluguel de um servidor: 35.000 rublos por mês.
Custo do ambiente de servidor (SO, antivírus, etc.): 60.000 rublos.
Cenário 1: "Planejado" (2 meses para preparação)
Preparamos um servidor tranquilamente.
Aluguel do servidor: 35.000 x 2 meses = 70.000 rublos.
Ambiente de servidor: 60.000 rublos.
Configuração: 50 h x 5.000 rublos = 250.000 rublos.
Suporte: 40 h/mês x 2 meses x 3.000 rublos = 240.000 rublos.
Total: 620.000 rublos.
Cenário 2: "Emergencial" (1 mês para preparação)
Precisamos de dois servidores para cumprir os prazos.
Aluguel dos servidores: 35.000 x 2 unidades = 70.000 rublos.
Ambiente de servidor: 60.000 x 2 unidades = 120.000 rublos.
Configuração: 50 h x 2 servidores x 5.000 rublos = 500.000 rublos.
Suporte: 40 h/mês x 2 servidores x 3.000 rublos = 240.000 rublos.
Total: 930.000 rublos.
A diferença de custo é de 310.000 rublos para este exemplo, mas a soma aqui não é o indicador principal. Muito mais indicativo é outro número – o aumento de custos em quase um vez e meia. Este é o preço de um mês de procrastinação. Pensando adiante, vemos que a economia poderia ter sido ainda maior. Por exemplo, quando você está sob pressão de tempo, você pega os servidores que estão disponíveis no momento, pois não pode esperar 2-3 dias para encontrar uma oferta mais interessante. Adicione a isso as perdas não financeiras: equipe esgotada, nervos gastos, riscos excessivos – isso não aparece no orçamento.
Mais um ponto: 70 mil endereços é um volume pequeno para envios corporativos. E se sua base for 3 vezes maior (210 mil endereços), e os prazos forem os mesmos? Os custos e, consequentemente, a economia potencial aumentam exponencialmente. Em nosso exemplo, o lucro cessante seria de mais de 930.000 rublos. Assim, à primeira vista, "trocados" se transformam em somas muito impressionantes.
A conclusão é simples: a preparação da infraestrutura de e-mail deve começar o mais cedo possível, ou seja, "ontem". Esperar que a equipe de marketing prepare o texto perfeito e que os advogados verifiquem cada formulação é um luxo inadmissível, pelo qual o negócio paga. Concorde com uma versão "leve" do e-mail para aquecimento: um resumo de notícias, um anúncio, uma notificação técnica – qualquer coisa! Enquanto seus colegas trabalham na versão final do envio, seu servidor já começará a construir relacionamentos com os gigantes do e-mail e a ganhar confiança inestimável.
Portanto, da próxima vez que em uma reunião alguém disser: "Vamos pensar um pouco mais sobre o tema do e-mail", simplesmente mostre a eles esta fórmula: 1 mês de reflexão = 1 servidor adicional no orçamento. E faça uma pergunta simples: "Pessoal, vocês têm certeza de que estão dispostos a pagar por isso?"
Obrigado pela atenção. Se foi útil, inscreva-se.
P.S. A propósito, transformamos este CRM para envios seguros em um de nossos produtos prontos. Ele está disponível para empresas que se preocupam em gerenciar a segurança do armazenamento de dados pessoais ao organizar envios em seu próprio ambiente seguro.
