Como operamos o pós-venda de uma ferramenta desktop instalada no cliente

Ferramenta desktop instalada no computador do cliente não se atualiza sozinha, e quando alguém do outro lado encontra um problema, a forma mais comum de avisar é uma mensagem perdida numa conversa de WhatsApp. O painel administrativo que sustenta a operação das nossas ferramentas desktop em produção já tinha telemetria de uso e reporte de erro (contamos os detalhes desse sistema no post Como monitoramos uma ferramenta que roda em vários totens físicos ao mesmo tempo). O que ainda não tínhamos mostrado era a outra metade do ciclo: como uma versão nova sai do nosso computador e chega no do cliente, e como uma resposta do cliente chega de volta pra gente sem se perder no caminho.

Publicar uma versão, na prática

O founder sobe o instalador direto na página do cliente, dentro do painel. Antes de qualquer coisa, o navegador valida o arquivo: o nome precisa terminar em .exe ou .dmg, o tamanho tem que ficar entre 1 KB e 200 MB, e os bytes do próprio arquivo precisam bater com a assinatura real do formato (cabeçalho MZ no início, pra .exe; assinatura koly do trailer UDIF, sempre nos últimos 512 bytes, pra .dmg). Só depois disso o upload segue pro Vercel Blob, assinado, e o registro entra no banco: número de versão em semver, tamanho, URL do arquivo, e o campo de versão atual do cliente é atualizado no mesmo request. No instante em que a versão é publicada, o formulário de mensagem já abre sozinho, com assunto e corpo pré-preenchidos com o link de download daquela versão específica. Publicar e notificar viraram o mesmo gesto, em vez de duas tarefas separadas que dependem de lembrar da segunda.

Mensagens não é só founder mandando email

O histórico de mensagens de cada cliente é uma via de mão dupla. Quando o cliente responde o email (pelo cliente de email de sempre, sem precisar acessar nada), o Postmark recebe essa resposta e chama nosso webhook, verificado por assinatura HMAC. O sistema casa a resposta com o cliente certo pelo endereço do remetente ou pelo cabeçalho In-Reply-To, grava a mensagem como recebida no histórico daquele cliente e nos avisa por email. Se demorarmos pra responder, o cliente recebe um aviso automático confirmando que a mensagem chegou, limitado a um por cliente a cada 6 horas, e que nunca dispara se a resposta vier do nosso próprio domínio de envio (pra não entrar num loop de auto-resposta).

Por que isso existe

Nenhuma das duas partes resolve um problema exótico. Resolve o problema comum de quem entrega ferramenta sob medida em vez de SaaS: sem um sistema, o rastro de qual cliente está em qual versão, e o que já foi respondido pra quem, vive na cabeça de quem construiu, ou numa busca manual numa conversa antiga. Aqui, cada versão e cada mensagem fica ligada ao cliente certo, sem depender de ninguém lembrar.

O gap que passou despercebido: email sem a marca

Toda mensagem enviada pelo painel usava só texto puro no corpo do email, sem HTML. Funcionava, mas destoava do resto do site: o email de boas-vindas, o de confirmação de pagamento, o de aviso automático de resposta recebida, todos usam o mesmo cartão verde-musgo sobre fundo off-white que é a identidade visual da marca. Corrigimos isso: o corpo que o founder escreve livre, sem formatação, agora é dividido em parágrafos e renderizado dentro do mesmo template compartilhado, com uma versão em texto puro como fallback pra clientes de email que não renderizam HTML.

E o segundo: só rodava em Windows

A validação de arquivo aceitava só .exe. Cliente com Mac simplesmente não tinha como receber uma atualização pelo painel. Adicionamos .dmg ao lado do .exe, com validação própria: não bastava aceitar qualquer arquivo terminado em .dmg, porque extensão de arquivo é só um nome, não prova nada sobre o conteúdo real. .dmg tem uma assinatura de verdade (o trailer UDIF, identificado pelos bytes koly no fim do arquivo), então a validação lê exatamente esse trailer antes de aceitar o upload, do mesmo jeito que já fazia com o cabeçalho MZ do .exe.

Publicar uma versão e responder uma mensagem de cliente não são tarefas glamourosas, mas são o tipo de coisa que, sem sistema, vaza confiança aos poucos: um cliente que nunca tem certeza se a versão nova é a certa, ou que manda uma dúvida e não sabe se alguém viu. Se sua operação também entrega ferramenta sob medida pro cliente e ainda depende de mandar arquivo por WhatsApp e torcer pra alguém ver a mensagem, conta pra gente o contexto.