Desconectar a Agenda derruba seu e-mail do Google

Conectar o Gmail para enviar e-mail em nome do vendedor parece um passo simples: o usuário autoriza, o app recebe o token, o disparo funciona. O problema aparece três semanas depois, quando alguém desconecta a Agenda porque trocou de conta. O Google revoga a autorização do app inteiro para aquela conta, e a caixa de envio que estava funcionando para de responder no próximo envio. O vendedor recebe um erro, o lead não recebe a mensagem, e o gestor descobre que o problema não era o e-mail, era o desenho da sessão.

Este artigo explica a armadilha, o desenho que a evita e por que a plataforma usa OAuth com escopo gmail.send em vez de SMTP com XOAUTH2. O tema é técnico, mas o impacto é comercial: cada revogação mal-entendida vira e-mail não enviado e cadência quebrada.

O que realmente acontece quando o Google revoga um app

O OAuth do Google funciona por concessão por usuário e por cliente. Quando o usuário autoriza o app, o Google emite um token de acesso e um refresh token vinculados àquela conta e àquele cliente OAuth. Se o usuário revoga a autorização em myaccount.google.com/permissions, ou se desconecta uma integração que usa o mesmo cliente, o Google invalida todos os tokens daquele cliente para aquela conta, não só o escopo da tela que ele estava usando.

É aqui que a maioria dos times se machuca. A plataforma tem duas conexões com o Google: Agenda, para criar reuniões e checar disponibilidade, e Gmail, para enviar e-mail em nome do usuário. Se as duas usam o mesmo cliente OAuth e o usuário desconecta a Agenda, o Google revoga o cliente inteiro. A caixa de envio cai junto, mesmo que ninguém tenha tocado nela.

O sintoma é sempre o mesmo: o vendedor jura que não mexeu no e-mail, o suporte não encontra erro no disparo, e a caixa aparece como conectada na tela mas falha no envio seguinte. A causa está na camada de autorização, não na camada de envio.

Remover caixa de envio não é o mesmo que revogar autorização

A distinção que resolve 90% dos casos é simples: existe uma diferença entre apagar o vínculo local e chamar o revoke do Google. Apagar o vínculo remove a referência daquela caixa na plataforma. O token continua válido no Google, mas a plataforma não o usa mais. Chamar o revoke é dizer ao Google para invalidar a autorização daquele cliente para aquela conta, e isso derruba tudo que depende dele, inclusive a Agenda.

No desenho correto, remover a caixa de envio não chama revoke. A plataforma só apaga o vínculo e o envio cai para a caixa da empresa no disparo seguinte. O usuário não precisa reconectar nada, e a operação continua. Já desconectar a Agenda chama revoke de verdade, porque é isso que o usuário está pedindo ao Google. Nesse caso, a caixa de envio do mesmo usuário para de funcionar e o envio cai para a caixa da empresa, com pedido de reconexão na interface.

Esse comportamento parece pequeno, mas separa uma operação que segue de uma operação que trava. Um time de 12 vendedores com duas desconexões de Agenda por semana perde, em média, cerca de 8 a 10 envios por dia até alguém perceber. Em uma cadência de 5 toques, isso é lead que esfria antes do segundo e-mail.

Por que a plataforma usa OAuth com gmail.send e não SMTP com XOAUTH2

A alternativa técnica mais comum é SMTP com XOAUTH2, que usa o escopo mail.google.com. Esse escopo é classificado pelo Google como restrito. Para publicar um app com escopo restrito, é preciso passar por auditoria de segurança anual, feita por um avaliador credenciado, com custo que começa na casa dos milhares de dólares e prazo de semanas. Para uma plataforma de vendas que quer conectar Gmail em escala, isso vira gargalo de produto e de caixa.

O escopo gmail.send é classificado como sensível, não restrito. Ele permite enviar e-mail em nome do usuário e nada além disso: não lê a caixa de entrada, não apaga mensagem, não acessa anexo recebido. A auditoria exigida é menor e o processo de verificação é mais direto. Para prospecção B2B, o que importa é enviar, não ler a caixa do vendedor. O escopo enxuto é decisão de produto e de segurança ao mesmo tempo.

Quem já sofreu com e-mail caindo em spam ou domínio queimado sabe que o problema de entrega está em outro lugar. Se o assunto é entregabilidade, vale revisar SPF, DKIM e DMARC na prospecção antes de culpar o escopo.

O que acontece quando o admin do Workspace bloqueia o app no meio do envio

Cenário comum em conta corporativa: o administrador do Google Workspace decide bloquear apps de terceiros por política de segurança, ou o app entra na lista de restritos do domínio. O bloqueio não avisa a plataforma em tempo real. O próximo envio daquele usuário falha porque o token não é mais aceito.

O adaptador de envio devolve invalid_credentials, a caixa daquele usuário vira error na interface e aquele e-mail específico falha. O que não acontece: a operação inteira não para. Os outros e-mails da cadência continuam, a fila segue para os demais leads e o restante do time não é afetado. O gestor vê a caixa em erro e sabe exatamente qual usuário precisa reconectar ou qual domínio precisa liberar o app.

O desenho é o mesmo em qualquer falha de credencial: isolar o erro na caixa, não na operação. É a diferença entre uma cadência que perde um toque e uma cadência que perde o dia inteiro. Quem está estruturando a operação comercial do zero sente essa diferença na prática, e vale ver o que entra em uma implementação de plataforma de vendas bem feita nesse nível de detalhe.

Como o vendedor percebe isso no dia a dia

A interface mostra três estados por caixa: conectada, erro e desconectada. Conectada envia normalmente. Erro indica que o Google recusou a credencial, geralmente por revogação ou bloqueio de admin, e pede reconexão. Desconectada é vínculo removido ou nunca feito, e o envio cai para a caixa da empresa.

Na prática, o vendedor raramente entende a diferença entre revogar e desconectar. Por isso o desenho tem que ser defensivo: não chamar revoke quando o usuário só quer tirar a caixa da plataforma, e avisar claramente quando uma ação na Agenda vai afetar o Gmail. Quem já montou tela única de BDR sabe que cada estado ambíguo na interface vira chamado no suporte.

Checklist para o gestor antes de conectar Gmail no time

• Confirme se a plataforma chama revoke ao remover caixa ou só apaga o vínculo.
• Pergunte se Agenda e Gmail compartilham o mesmo cliente OAuth e o que acontece ao desconectar um.
• Verifique qual escopo é usado no envio e se ele é sensível ou restrito.
• Teste o comportamento de erro: a caixa fica em error ou a operação inteira para?
• Peça ao admin do Workspace para revisar a lista de apps restritos antes do rollout.

O que muda no processo comercial com esse desenho

Com o vínculo separado da credencial, o envio cai para a caixa da empresa quando a caixa pessoal falha, e a cadência não interrompe. Isso reduz o suporte de primeiro nível, porque o vendedor vê o erro na tela e resolve sozinho com reconexão. E reduz o retrabalho do gestor, que deixa de caçar e-mail não enviado no meio da semana.

A escolha de escopo também tem efeito comercial. Um app com gmail.send passa por revisão mais simples e chega mais rápido à operação. O time ganha envio em nome do usuário sem abrir mão de segurança, e o admin do Workspace tem menos motivo para bloquear.

Quem está comparando fornecedores deve incluir esse item na avaliação. Já existe um checklist com critérios para escolher plataforma de vendas que cobre a camada de integração, e vale acrescentar esta pergunta: o que exatamente é revogado quando o usuário desconecta uma integração?

Conclusao

A armadilha não está no envio, está na sessão. Desconectar a Agenda revoga o cliente OAuth inteiro e derruba a caixa de envio do mesmo usuário. Remover a caixa de envio, por outro lado, deve só apagar o vínculo, sem chamar revoke, para o envio cair para a caixa da empresa e a operação seguir.

Entender essa diferença antes de conectar o time inteiro evita um mês de e-mails perdidos e chamados de suporte. O resto é detalhe de implementação que o fornecedor precisa responder sem rodeio.