El proceso de publicación que reemplazó seis horas semanales
Una rutina semanal de publicación parece corta hasta que la analizas. Elegir un tema, investigarlo, escribir un borrador, buscar una imagen, verificar los datos, darle formato, programar la publicación y luego repetir el mismo proceso para las redes sociales. Digamos que son seis horas. Al año, eso equivale a un mes laboral completo dedicado a producir el mismo contenido una y otra vez.
Casi todo es automatizable. Lo que no lo es, y lo que suele generar errores, es el juicio final.
Lo que realmente hace el flujo
La versión que utilizamos en producción tiene seis etapas, y cada una de ellas puede fallar de forma independiente, lo cual es importante más adelante.
- Elige un tema. Partiendo de una base de datos gestionada, en lugar de la imaginación de la modelo. Una base de datos permite controlar la línea editorial y evita que el mismo sujeto aparezca dos veces en un mes.
- Reúna fuentes. URL reales, obtenidos y leídos. No se recuerdan.
- Borrador. Con las fuentes en su contexto y la instrucción de que ninguna afirmación puede aparecer sin una que la respalde.
- Controlar. Una segunda revisión que coteja el borrador con las fuentes y lo rechaza si algún dato no está respaldado.
- Ilustrar. Una fotografía con licencia de tu propia biblioteca que coincida con el tema, o una imagen generada cuando no exista una opción con licencia.
- Preguntar. Un correo electrónico con el borrador, la imagen y un enlace para publicarlo.
La piscina es toda la estrategia editorial.
La primera versión de este flujo permitía que el modelo eligiera sobre qué escribir. El resultado fueron textos competentes pero olvidables que se inclinaban hacia lo que al modelo le resultaba fácil. En tres semanas, el blog tenía cuatro artículos sobre prácticamente el mismo tema.
El cambio a un repositorio de temas mantenido a mano lo solucionó en una tarde. Cada entrada contiene un tema, un tipo y un conjunto de datos verificados. El generador recorre el repositorio en lugar de asociar libremente, así que la cobertura es algo que decides tú, no algo que descubres después.
También pone de manifiesto las deficiencias. Al analizar una muestra con objetividad, cuatro de las quince entradas correspondían al mismo animal, y una categoría obvia no tenía ninguna entrada. Esto no es un problema de la función de la solicitud, y ninguna optimización de la misma lo habría revelado.
La verificación de hechos debe poder decir no
Un filtro de calidad que siempre pasa es la decoración. El filtro en este flujo puede rechazar, y lo hace.
Esto provocó el fallo que costó una semana de producción publicada antes de que nadie se diera cuenta. La puerta rechazó un borrador, el flujo lo descartó y el planificador registró la ejecución como completada. Sin reintentos, sin alertas, sin elementos en cola. El sistema funcionaba exactamente como estaba previsto, sin producir nada y reportando éxito.
El fallo peligroso de la automatización no es el que se bloquea, sino el que finaliza sin hacer nada.
La solución fue sencilla: en caso de rechazo, se reintentaba con la justificación de la puerta de control, se limitaban los intentos y, si se alcanzaba el límite, se aumentaba en lugar de ignorarlo. Esa es la diferencia fundamental entre una canalización que se detiene silenciosamente y una que avisa.
La aprobación es la característica, no la fricción.
El instinto al escribir un proceso es cerrar el ciclo por completo. Resiste la tentación, al menos al principio.
Un correo electrónico de aprobación con un solo clic cuesta unos cuarenta segundos por pieza y elimina todo el riesgo de que algo incorrecto, que no se ajuste a la imagen de marca o que genere problemas legales se publique a las tres de la mañana. Cuarenta segundos a la semana no es el coste que querías eliminar. Eran seis horas.
Una vez que el proceso ha generado cincuenta piezas aprobadas y ya no hay nada que modificar, cerrar el ciclo es tan sencillo como cambiar una sola línea. Si empiezas con el ciclo cerrado, nunca tendrás la confianza necesaria para abrirlo.
Lo que reemplazó, en horas
En la configuración que mejor conocemos, aproximadamente seis horas semanales dedicadas a escribir y programar se convirtieron en unos diez minutos de lectura de correos electrónicos de aprobación. La implementación tardó poco menos de tres semanas, incluyendo la ejecución supervisada por el agente, y el costo continuo es de unos pocos dólares al mes en llamadas de modelos.
La advertencia importante es que el primer mes no es gratis. Es necesario ajustar las indicaciones a tu voz, completar la base de datos y el sistema rechazará contenido que no debería hasta que lo calibres. Si planificas tu presupuesto para ese mes, el sistema seguirá funcionando correctamente.
Si construyes una cosa a partir de esto
Implementa el mecanismo de reintento ante rechazo antes de desarrollar cualquier solución ingeniosa. Cualquier otra parte de este proceso se degrada visiblemente cuando falla. Esta en particular se degrada hasta el silencio, y el silencio es costoso.
