US-006 — Edición de datos del cliente

Detalle de la historia¶

Historia¶

Como operador de FleteChat, quiero corregir o actualizar los datos de un cliente desde el backoffice, para mantener al día la información cuando el cliente cambia de correo, de teléfono o corrige un error de tipeo en el alta.

Persona de usuario¶

Aplica a los roles admin y operator. No aplica a price_manager ni al cliente final: los clientes finales actualizan su información a través de la conversación con FleteChat, no editando un backoffice.

Contexto de negocio¶

Los datos de contacto cambian: una empresa migra su correo, un cliente corporativo pasa la atención a otra persona, un nombre se escribió mal en el alta inicial. Sin una interfaz de edición, el operador tendría que crear cuentas nuevas o pedir soporte técnico cada vez, lo cual es inviable.

La edición desde backoffice cubre los datos que el cliente final no puede o no quiere corregir por sí mismo, con una traza de auditoría que permite revisar quién cambió qué y cuándo.

Criterios de aceptación¶

Qué se puede editar¶

1. El operador puede editar el nombre, el correo electrónico y la lista de números de teléfono asociados a una cuenta.
2. Los cambios se validan con las mismas reglas del alta (formato de correo, formato de número, unicidad del correo).

Efectos del cambio de correo¶

1. Si el operador cambia el correo de la cuenta, las verificaciones de números que estaban pendientes se invalidan: los enlaces enviados al correo viejo dejan de funcionar, y los números siguen pendientes hasta que se emita un enlace nuevo al correo nuevo.
2. El cambio de correo se notifica al cliente final por WhatsApp para que quede enterado de la actualización.

Auditoría¶

1. Cada cambio queda registrado con antes, después, usuario operador y fecha.
2. El historial de ediciones de una cuenta es consultable desde el backoffice por admin y operator.

Permisos¶

1. Solo admin y operator pueden editar; cualquier intento de edición por price_manager u otro rol sin permiso es rechazado.
2. El cliente final no tiene acceso al backoffice ni a una interfaz web para editar sus datos; el canal del cliente final es WhatsApp.

Edge cases¶

• Edición que resultaría en correo duplicado. El sistema rechaza el cambio y muestra la cuenta existente con ese correo.
• Edición que remueve el último número verificado. El sistema rechaza el cambio: una cuenta activa no puede quedarse sin ningún número verificado. El operador debe primero agregar y verificar un número alternativo.
• Edición sobre una cuenta con embarques en curso. La edición procede, pero se registra en la auditoría para trazabilidad comercial.
• Dos operadores editan la misma cuenta casi al mismo tiempo. El sistema aplica los cambios en orden de llegada y registra ambos en el histórico; no hay bloqueo pesimista que frustre el trabajo del operador.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P1 — importante pero no bloquea el arranque; las cuentas se pueden operar incluso sin esta función durante un período corto.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-033 — Campos editables. En v1.0, se pueden editar nombre, correo y lista de números. No se habilitan campos adicionales.
• PR-034 — Cambio de correo invalida verificaciones pendientes. Todo enlace de verificación emitido al correo anterior deja de servir; los números pendientes siguen pendientes hasta que se emita un enlace al correo nuevo.
• PR-035 — Notificación al cliente. El cliente final recibe aviso por WhatsApp cuando cambian sus datos de contacto, como medida de transparencia.
• PR-036 — Sin autoservicio web. El cliente final no edita sus propios datos desde una web o portal; los cambios solicitados los aplica el operador desde backoffice.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-033 a PR-036 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente