Cómo gestiona Telematic un saldo bajo de tokens: sin spam de notificaciones, con una pausa gradual de la autopublicación y una reanudación automática después de recargar el saldo.
La automatización de contenidos se basa en la confianza: configuras las fuentes, el calendario y el piloto automático, y esperas que los vídeos y las publicaciones aparezcan por sí solos, sin tener que comprobar cada día «si todo sigue funcionando». Esa confianza se rompe en una única situación: cuando los tokens se agotan en mitad de un flujo de trabajo activo y el piloto automático se queda de pronto en silencio sin dar explicaciones, mientras la persona se entera después de los hechos, al ver un hueco en el calendario de publicaciones.
En un sistema así, los tokens no son una métrica abstracta del panel de control, sino un recurso real que se consume para generar guiones, locuciones, imágenes y editar vídeos. El saldo puede agotarse en cualquier momento: a veces de forma predecible, hacia el final de un mes de uso intensivo, y otras de manera inesperada, si uno de los proyectos empieza de pronto a generar mucho más contenido de lo habitual. La cuestión es qué ocurre cuando quedan pocos tokens, no cuando ya se han agotado por completo.
En Telematic diseñamos una lógica que trata el saldo bajo no como una situación de emergencia que exige entrar en pánico de inmediato, sino como un estado predecible con el que el sistema sabe trabajar con tranquilidad.
Lo primero con lo que se encuentra el usuario cuando el saldo disminuye es una notificación. Pero aquí es fácil caer en un extremo: enviar un recordatorio con cada consumo de tokens. Al cabo de un día, el usuario simplemente dejará de leerlos, igual que deja de leer cualquier alerta demasiado frecuente. Por eso, los recordatorios de saldo bajo en Telematic están limitados en frecuencia: el sistema no los envía con cada generación, sino que controla su frecuencia para que el mensaje siga siendo relevante y no se convierta en ruido de fondo.
La idea es que, cuando el usuario abra realmente una notificación de saldo bajo, la perciba como algo que requiere atención y no como otra línea más que se puede descartar sin mirar. Paradójicamente, los recordatorios frecuentes y repetitivos reducen, en lugar de aumentar, la probabilidad de que la persona reaccione a tiempo.
Si el saldo desciende hasta un nivel crítico, el sistema tiene que elegir entre dos escenarios negativos: seguir intentando generar contenido y encontrarse con errores por falta de fondos en mitad del proceso —con el riesgo de dejar un vídeo incompleto o «dañado»—, o detener de antemano y de forma ordenada los procesos automáticos hasta que el saldo permita completarlos correctamente.
Telematic elige el segundo camino: cuando es necesario, la autopublicación se pausa suavemente hasta que se recarga el saldo. No se trata de una parada de emergencia con pérdida de progreso, sino de una pausa controlada: los materiales que ya están listos siguen listos, y los procesos programados que aún no han comenzado simplemente esperan su turno, en lugar de iniciarse y quedarse sin tokens a mitad de la generación del vídeo o de la locución.
Aquí se encuentra, probablemente, el detalle más importante de todo el sistema: después de recargar el saldo no es necesario «reiniciar» nada manualmente. El piloto automático no vuelve a su estado inicial ni espera a que el usuario entre en la configuración y vuelva a activar todos los interruptores que estaban pausados. El sistema detecta por sí mismo que el saldo se ha restablecido y reanuda automáticamente los procesos que habían quedado suspendidos.
Esto difiere fundamentalmente del comportamiento habitual de muchos servicios automatizados, donde la falta de fondos provoca una parada total que después exige una reconfiguración manual: volver a activar el calendario, comprobar qué proyectos estaban activos y asegurarse de que no se ha perdido nada. En Telematic, una pausa por falta de saldo es un estado temporal de espera, no un restablecimiento de la configuración.
Durante una prueba interna nos ocurrió que el saldo de uno de los proyectos de prueba se agotó el viernes por la tarde, el peor momento posible, porque nadie tenía previsto reaccionar antes del lunes. La primera reacción fue, como era de esperar, de preocupación: ¿qué pasaría con las publicaciones programadas para el fin de semana?, ¿tendríamos que revisar manualmente el lunes qué parte del flujo se había detenido a mitad y qué parte había llegado a completarse?
Resultó que no había motivos para preocuparse. El sistema envió una advertencia con antelación —cuando el saldo descendió por debajo de un nivel determinado— y, cuando los tokens se agotaron realmente, la autopublicación se pausó correctamente, sin dejar ni un solo material «dañado». El lunes, después de recargar el saldo, todo se reanudó por sí solo: el calendario funcionó como si nunca hubiera habido una pausa, sin una sola acción manual por nuestra parte. Lo único que realmente necesitó la intervención de una persona fue recargar el saldo a tiempo, no reparar las consecuencias.
La conclusión práctica para el propietario del proyecto es no ignorar los primeros recordatorios de frecuencia limitada, considerándolos una precaución excesiva: si el sistema limita deliberadamente su frecuencia, significa que cada uno de ellos ya ha pasado un filtro de relevancia y merece atención. Conviene interpretar el primer mensaje de este tipo como una señal para planificar con antelación la recarga del saldo y no como un motivo para entrar en pánico de inmediato: el sistema ya se ha ocupado de que, si llega a producirse una pausa, transcurra sin pérdidas.
También conviene evaluar de antemano el consumo habitual de tokens durante los periodos de actividad intensa, por ejemplo, al lanzar un proyecto nuevo con varias fuentes o al pasar a un piloto automático más intensivo con procesamiento masivo. Esto permite recargar el saldo de forma proactiva, en lugar de reaccionar a las notificaciones en el último momento. Pero incluso si se pierde la oportunidad y el saldo llega a cero, lo peor que ocurrirá será una pausa temporal y totalmente controlada, no la pérdida de trabajo ni la necesidad de volver a configurarlo todo desde cero.
Plataforma no disponible durante la publicación: qué hace el sistema
Biblioteca multimedia: cómo evitar generar contenido dos veces
