Para el soporte de Developers Map construí un bot de Telegram, una Mini App y una interfaz de operador. Una tarea era conservar el estado del ticket cuando se repetía una petición o Telegram aceptaba una respuesta sin que el programa recibiera confirmación.
Una petición puede repetirse. Un operador puede pulsar otra vez. Telegram puede aceptar un mensaje y cortarse la conexión antes de que el programa sepa que funcionó. Mientras tanto, el usuario abre un segundo ticket en el mismo chat. No hace falta mala intención: una conexión normal puede organizar una pequeña crisis por sí sola.
Del menú al proceso de trabajo
Para Developers Map construí un bot de Telegram, una Mini App y una interfaz de soporte para operadores. Es una herramienta aparte junto al servicio principal; no me convierte en autor de Developers Map ni da al bot permiso para modificar cuentas de usuarios de la plataforma principal.
Esta pantalla muestra la interfaz original de soporte con tickets preparados. Permite ver el espacio de trabajo junto al bot, no solo su menú.
Vista general del soporte
Interfaz archivada · datos de demostración
Hay una base de respuestas aprobada en ruso e inglés, varios tickets dentro de un chat y adjuntos en un R2 privado. Las respuestas AI están desactivadas en esta implementación. El usuario recibe soporte predecible, no una invención libre del modelo sobre cómo funciona un producto ajeno.
Dentro de un ticket se ve una conversación de demostración. Se pueden probar las acciones locales disponibles para el operador; los usuarios reales de Telegram no recibirán nada de esta demo.
Conversación del ticket
Interfaz archivada · datos de demostración
Primero el evento, después la acción
Los eventos entrantes se guardan en D1. Una cola y un procesador periódico los llevan al coordinador del chat en Durable Objects. Después el motor actualiza el ticket y escribe la acción saliente en la outbox, una tabla de envíos preparados.
Esto permite vincular el cambio de un ticket con la intención de enviar un mensaje en una sola operación de base de datos. De lo contrario puede aparecer un mundo intermedio extraño: la persona ya recibió el mensaje, pero el sistema cree que no pasó nada. O al revés.
Los comandos de la Mini App tienen un identificador estable y comprobación de versión. Las peticiones repetidas se reconocen y una acción sobre un estado antiguo no debe sobrescribir silenciosamente trabajo más reciente del operador.
El estado más interesante: «resultado desconocido»
Si el envío externo pudo haberse realizado, repetirlo automáticamente puede crear un duplicado. Por eso un resultado incierto no se trata como un error corriente que deba reintentarse enseguida. Aquí el reintento es una decisión aparte del operador, consciente del riesgo.
No es una promesa de entrega matemáticamente perfecta. Es una forma de dejar de esconder la incertidumbre detrás de un indicador verde.
Hay una instancia funcional desplegada para el piloto; la aceptación completa por los usuarios sigue siendo una etapa aparte. WhatsApp y el correo no se convierten en canales conectados solo porque una vez aparecieron en un plan.
Hay una instancia funcional desplegada para el piloto. La demo permite pasar de la lista de tickets a la conversación del operador; la aceptación completa aún no ha terminado. WhatsApp y el correo no están conectados y las respuestas AI están desactivadas en esta implementación.
Historias relacionadas: El concepto de producto de Developers Map.
@nevsky_alexander
En Instagram, Dubái más allá de la postal: familia, ciudad, descubrimientos y la vida entre proyectos. En Threads, ideas en voz alta sobre diseño e IA. En YouTube, vídeos que necesitan más espacio que una historia. Sígueme donde te sientas más a gusto y seguimos en contacto