Decide qué cuenta como fallo
No todos los problemas son iguales. Una automatización puede detenerse con un aviso claro, dar un resultado dudoso o, peor, parecer correcta y estar equivocada. Distinguir esos casos por escrito ahorra discusiones cuando ocurran.
En pantallas pequeñas, desplaza la tabla horizontalmente o usa las flechas del teclado para ver todas las columnas.
| Tipo | Ejemplo ilustrativo | Primera respuesta propuesta |
|---|---|---|
| Entrada incorrecta | Falta una columna o hay una referencia desconocida | No procesar esa fila y dejarla en incidencias |
| Conexión caída | La aplicación conectada no responde | Parar sin aplicar nada y avisar al responsable |
| Resultado dudoso | Un precio cambia de forma muy distinta a lo habitual | Marcarlo para revisión antes de aplicarlo |
| Cambio ya aplicado | Se descubre un error después de publicar | Usar el procedimiento de recuperación acordado |
Los umbrales («muy distinta a lo habitual») los fija tu negocio, no la herramienta. Si no puedes definirlos todavía, anótalo como pendiente.
Que se detenga antes de aplicar
La medida más útil es de diseño: que el primer ciclo sólo prepare una propuesta de cambios y una persona la apruebe. Así un fallo se queda en un listado, no en tu tienda o en tu web.
Comprueba también qué pasa si la misma entrada llega dos veces. Una automatización que aplica dos veces el mismo cambio puede ser más peligrosa que una que se bloquea. Es uno de los casos que conviene incluir en la prueba, junto a una entrada válida y otra incompleta, como se plantea en la guía de actualizar stock en WooCommerce con CSV.
Un registro de incidencias mínimo
No hace falta un sistema complejo. Hace falta que cada incidencia deje las mismas huellas para poder entenderla semanas después.
En pantallas pequeñas, desplaza la tabla horizontalmente o usa las flechas del teclado para ver todas las columnas.
| Campo | Qué anotar | Por qué |
|---|---|---|
| Fecha y entrada | Cuándo ocurrió y con qué archivo o mensaje | Poder reproducirlo |
| Qué se esperaba y qué pasó | Resultado previsto frente al real | Distinguir error de criterio |
| Estado | Detenida, pendiente, resuelta | Saber qué sigue abierto |
| Responsable | Quién la atiende | Evitar que nadie la vea |
| Decisión | Qué se corrigió: la entrada, la regla o el proceso | Evitar que se repita |
Recuperar el estado anterior
Que se pueda deshacer un cambio depende de la plataforma y de los permisos disponibles. En algunas basta con una copia previa; en otras habrá que revertir elemento a elemento; y a veces no se podrá deshacer. No lo des por supuesto: pregunta y prueba en un entorno de ensayo o con un cambio pequeño antes de confiar en ello.
Deja escrito qué se guarda antes de cada ejecución, dónde, cuánto tiempo y quién puede usarlo.
Quién avisa a quién
Una incidencia detectada pero no comunicada es una incidencia sin resolver. Acuerda un canal, una persona responsable y una segunda persona para cuando la primera no esté. Si hay clientes afectados, decide quién habla con ellos y qué se dice.
Revisa después, no sólo durante
Tras cada incidencia relevante, haz una revisión breve con tres preguntas: qué falló, por qué no lo detectamos antes y qué cambiamos. La respuesta puede ser una regla nueva, una prueba adicional o decidir que ese caso lo gestione siempre una persona. Una automatización que mejora así se vuelve más fiable; una que sólo se parchea acumula riesgos.
Si estás valorando cuánto cuesta mantener esta supervisión, la checklist para pedir presupuesto de automatización web ayuda a separar construcción y mantenimiento.
¿Una automatización con IA falla más que una sin IA?
No hay una respuesta general. Una parte con interpretación puede equivocarse de forma menos previsible, por eso conviene que proponga y una persona apruebe, y que el sistema pueda abstenerse ante un caso ambiguo.
¿Quién atiende los fallos tras la entrega?
Debe acordarse por escrito: qué soporte entra en el alcance, en qué plazo y por qué canal. Si no consta, pregúntalo antes de contratar.