Cómo operamos el posventa de una herramienta de escritorio instalada en el cliente

Una herramienta de escritorio instalada en la computadora del cliente no se actualiza sola, y cuando alguien del otro lado encuentra un problema, la forma más común de avisar es un mensaje perdido en una conversación de WhatsApp. El panel administrativo que sostiene la operación de nuestras herramientas de escritorio en producción ya tenía telemetría de uso y reporte de errores (contamos los detalles en Cómo monitoreamos una herramienta que corre en varios totems físicos al mismo tiempo). Lo que todavía no habíamos mostrado era la otra mitad del ciclo: cómo una versión nueva sale de nuestra computadora y llega a la del cliente, y cómo una respuesta del cliente vuelve hasta nosotros sin perderse en el camino.

Publicar una versión, en la práctica

El founder sube el instalador directo en la página del cliente, dentro del panel. Antes que nada, el navegador valida el archivo: el nombre tiene que terminar en .exe o .dmg, el tamaño tiene que estar entre 1 KB y 200 MB, y los bytes del propio archivo tienen que coincidir con la firma real del formato (encabezado MZ al inicio, para .exe; firma koly del trailer UDIF, siempre en los últimos 512 bytes, para .dmg). Recién después de eso el upload sigue hacia Vercel Blob, firmado, y el registro entra en la base de datos: número de versión en semver, tamaño, URL del archivo, y el campo de versión actual del cliente se actualiza en el mismo request. En el instante en que la versión se publica, el formulario de mensaje se abre solo, con asunto y cuerpo ya prellenados con el link de descarga de esa versión específica. Publicar y notificar se volvieron el mismo gesto, en vez de dos tareas separadas que dependen de acordarse de la segunda.

Mensajes no es solo el founder mandando email

El historial de mensajes de cada cliente es una vía de doble sentido. Cuando el cliente responde el email (desde el cliente de correo que use normalmente, sin necesidad de acceder a nada), Postmark recibe esa respuesta y llama a nuestro webhook, verificado por firma HMAC. El sistema empareja la respuesta con el cliente correcto por la dirección del remitente o por el encabezado In-Reply-To, graba el mensaje como recibido en el historial de ese cliente y nos avisa por email. Si tardamos en responder, el cliente recibe un aviso automático confirmando que el mensaje llegó, limitado a uno por cliente cada 6 horas, y que nunca se dispara si la respuesta viene de nuestro propio dominio de envío (para no entrar en un loop de autorrespuesta).

Por qué existe esto

Ninguna de las dos partes resuelve un problema exótico. Resuelven el problema común de quien entrega software a medida en vez de SaaS: sin un sistema, el rastro de qué cliente está en qué versión, y qué ya se respondió a quién, vive en la cabeza de quien lo construyó, o en una búsqueda manual en una conversación vieja. Acá, cada versión y cada mensaje queda ligado al cliente correcto, sin depender de que alguien se acuerde.

El gap que pasó desapercibido: email sin la marca

Todo mensaje enviado desde el panel usaba solo texto plano en el cuerpo del email, sin HTML. Funcionaba, pero desentonaba con el resto del sitio: el email de bienvenida, el de confirmación de pago, el aviso automático de respuesta recibida, todos usan la misma tarjeta verde musgo sobre fondo off-white que es la identidad visual de la marca. Corregimos eso: el cuerpo que el founder escribe libremente, sin formato, ahora se divide en párrafos y se renderiza dentro de la misma plantilla compartida, con una versión en texto plano como respaldo para clientes de correo que no renderizan HTML.

Y el segundo: solo corría en Windows

La validación de archivo aceptaba solo .exe. Un cliente con Mac simplemente no tenía forma de recibir una actualización por el panel. Agregamos .dmg junto a .exe, con validación propia: no bastaba con aceptar cualquier archivo que terminara en .dmg, porque la extensión de archivo es solo un nombre, no prueba nada sobre el contenido real. .dmg tiene una firma real (el trailer UDIF, identificado por los bytes koly al final del archivo), así que la validación lee exactamente ese trailer antes de aceptar el upload, del mismo modo que ya lo hacía con el encabezado MZ del .exe.

Publicar una versión y responder un mensaje de cliente no son tareas glamorosas, pero son el tipo de cosa que, sin un sistema, filtra confianza de a poco: un cliente que nunca está seguro de si la versión nueva es la correcta, o que manda una duda y no sabe si alguien la vio. Si tu operación también entrega herramientas a medida a clientes y todavía depende de mandar un archivo por WhatsApp y esperar que alguien vea el mensaje, contanos tu contexto.