Historial de cambios de un pedido: quién lo modificó y cuándo

La conversación que no se puede ganar

El historial de cambios de un pedido existe para terminar una discusión concreta: alguien cambió algo y nadie se hace cargo.

Sin registro, esa conversación se resuelve por memoria. Y la memoria de tres personas sobre un martes de hace tres semanas nunca coincide.

El problema de fondo no es quién tuvo la culpa. Es que sin registro no se puede aprender nada: no sabés si fue un error de una persona, un paso mal explicado o un proceso que invita a equivocarse.

Qué tiene que quedar anotado

La lista corta de lo que debería registrarse solo, sin que nadie lo escriba.

Evento	Qué queda
Creación	Quién lo creó y cuándo, sea una persona o la atención automática
Cambio de estado	De qué estado a cuál, quién y cuándo
Edición	Qué se modificó
Eliminación	Quién y cuándo
Comentario	El texto, el autor y el momento

Lo importante de esa lista no es qué incluye. Es que se escribe sola. Un registro que depende de que alguien se acuerde de completarlo está vacío justo el día que lo necesitás.

Lo que se registra solo y lo que no

Acá va el límite, porque una promesa sin límite no se puede evaluar.

La línea de tiempo cubre creación, cambios de estado, ediciones, eliminaciones y comentarios. No podés agregar una entrada a mano: si llamaste al cliente por teléfono, eso no entra como un evento del historial.

Lo que sí podés hacer es dejarlo como comentario en el pedido. Queda con tu nombre y con la fecha, en el mismo lugar, y cumple la misma función para el que lo lea después.

Lo que no se puede recuperar

Un pedido creado antes de que existiera el registro muestra su fecha de creación y nada anterior. Esa historia no se guardó y no hay forma de reconstruirla.

Vale la pena decirlo porque es la primera pregunta que aparece cuando alguien empieza a usar el historial: "¿y lo de antes?". Lo de antes no está.

Por qué no se reescribe

Una línea de tiempo que se puede editar no sirve para lo que existe.

Los eventos se anotan cuando pasan y quedan así. Si alguien cambió el estado por error y después lo volvió atrás, van a figurar los dos cambios, no el resultado limpio. Eso es lo correcto: el error forma parte de lo que pasó.

Qué mirar cuando algo salió mal

Un orden práctico para usarlo, en vez de leer todo de arriba abajo.

1. Empezá por el final. El último cambio antes de que apareciera el problema suele ser el que lo causó.
2. Mirá quién. Si siempre es la misma persona, es capacitación. Si son varias, es el proceso.
3. Mirá cuándo. Los errores concentrados en un horario suelen hablar de sobrecarga, no de descuido.
4. Leé los comentarios de ese día. Muchas veces la explicación ya está escrita ahí.

El paso dos es el que cambia la conversación con tu equipo. Cuando el registro muestra que se equivocaron cuatro personas distintas, el problema deja de ser de alguien.

Conclusiones

• Sin registro, la discusión se resuelve por memoria y nadie aprende nada.
• Lo que vale es que se anote solo, no que alguien se acuerde de completarlo.
• Cubre creación, estados, ediciones, eliminaciones y comentarios, y no admite entradas a mano.
• Los pedidos anteriores al registro no tienen historia recuperable.
• Si el registro muestra que se equivocaron varios, el problema es el proceso.