Antes de automatizar una tarea que aún no tiene reglas, define la decisión que el equipo debe tomar y automatiza únicamente la parte que siempre se resuelve de la misma manera.
En el control de pedidos después del pago, una acción repetitiva no es necesariamente una acción lista para automatizar. Si cada persona interpreta el caso de forma distinta, la automatización solo trasladaría esa diferencia al sistema.
¿Qué debe quedar decidido antes de convertir una tarea en una regla?
Describe la tarea desde el pedido que la activa hasta el resultado que debe quedar registrado o comunicado. No hace falta redactar un manual extenso, pero sí dejar claro qué situación inicia la decisión, qué información se revisa y qué resultado corresponde.
- El punto de inicio: qué ocurre en el pedido para que el equipo intervenga después de la confirmación.
- La condición principal: qué debe ser cierto para elegir una acción y no otra.
- El resultado esperado: qué estado, aviso o acción deja el pedido listo para la siguiente etapa.
- Las excepciones conocidas: qué casos no deben seguir la regla general porque requieren revisión humana.
- La persona responsable: quién decide cuando falta información o el pedido no encaja en los casos previstos.
Esta preparación convierte una costumbre informal en una decisión que se puede revisar. También evita que una misma situación reciba respuestas distintas según quién esté gestionando los pedidos ese día.
La diferencia entre una decisión repetida y una decisión determinista
Una tarea puede repetirse muchas veces y, aun así, necesitar criterio. Por ejemplo, revisar un pedido tras el pago parece repetitivo, pero deja de ser automático si el equipo debe valorar información incompleta, elegir entre varias respuestas razonables o interpretar una circunstancia no prevista.
Una parte es determinista cuando la misma información lleva siempre al mismo resultado. Esa parte puede expresarse como una regla concreta: cuando se cumple cierta condición, el pedido pasa a un estado definido o se genera una acción ya acordada.
En cambio, si la respuesta depende de que alguien diga “normalmente lo resolvemos según el caso”, todavía no hay una regla suficiente. Conviene conservar esa decisión en manos del equipo hasta que puedan describir qué casos cambian la respuesta y cómo deben tratarse.
Un caso ambiguo: cuando parece que ya se puede automatizar
Puede ocurrir que el equipo coincida en la mayoría de los pedidos, pero no en algunos casos especiales. Eso no obliga a descartar toda automatización. La separación útil consiste en automatizar el recorrido común y detener el pedido cuando aparezca una excepción definida.
Por ejemplo, si el resultado habitual tras la confirmación está claro, ese paso puede seguir una regla. Pero si ciertos pedidos requieren una valoración adicional y aún no existe un criterio compartido para resolverlos, esos pedidos deben quedar fuera de la automatización. La regla no debe adivinar una decisión que el equipo todavía no ha definido.
Cómo dejar una regla preparada sin automatizar de más
Redacta la decisión en una frase que cualquiera del equipo pueda aplicar sin interpretaciones adicionales. Debe poder responder qué ocurre, bajo qué condición y cuál es el resultado. Si para entenderla hacen falta explicaciones verbales, probablemente aún mezcla casos distintos.
Después, prueba la regla con pedidos ya conocidos o situaciones habituales del flujo pospago. Si dos personas llegarían al mismo resultado con la misma información, la parte descrita está cerca de poder automatizarse. Si aparecen desacuerdos, no son un fallo menor: señalan la excepción o condición que falta definir.
Automatizar después de aclarar la decisión mantiene el control sobre cada pedido. Así, el sistema se encarga de lo previsible y el equipo conserva la intervención donde todavía hace falta criterio.
