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 y el correo electrónico de cada contacto de la cuenta (titular y colaboradores), y gestionar la lista de teléfonos de cada contacto (activo + históricos), conforme al modelo "teléfono activo único + históricos" definido en US-003 (PR-232).
2. Los cambios se validan con las mismas reglas del alta (formato de correo, formato de número, unicidad del correo del titular).

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.

Gestión de teléfonos por contacto¶

1. El operador ve, para cada contacto de la cuenta, su teléfono activo y sus teléfonos históricos con la fecha de activación y desactivación. Los históricos no se eliminan: se conservan para trazabilidad (PR-232 en US-003).
2. El operador puede cambiar el teléfono activo de un contacto. La acción dispara el flujo de verificación por enlace al correo del titular (US-004). Al confirmarse, el número anterior pasa a histórico y el nuevo queda como activo.
3. El operador puede desactivar a un colaborador completo (toda su línea de contactos), no solo su teléfono activo. El histórico de conversaciones del colaborador se conserva.

Transferencia operativa de titularidad¶

1. El operador puede transferir titularidad de la cuenta a un colaborador verificado de la misma cuenta. La transferencia exige autorización explícita del titular actual, capturada vía clic en enlace enviado a su correo (mismo mecanismo de PR-024 en US-003). Hasta que el titular actual confirme, la transferencia queda pendiente y no surte efecto.
2. Al confirmarse la transferencia, los roles intercambian: el colaborador pasa a ser titular y el titular anterior queda como colaborador (o se desactiva, a elección del operador en la solicitud). Ambos contactos reciben notificación por WhatsApp y por correo. El evento queda registrado en audit log con los dos contactos involucrados.
3. La transferencia es una excepción operativa explícita a PR-037: el agente conversacional sigue tratando al titular como inmutable; solo este flujo de backoffice puede modificarlo. Ver PR-234.

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 activo verificado del titular. El operador debe primero agregar y verificar un número alternativo (cambio de teléfono activo, AC 10).
• Transferencia de titularidad sin confirmación del titular actual. El sistema mantiene la solicitud en estado pendiente y no aplica el cambio. Si el titular actual no confirma en el plazo definido (PR-027 en US-004), la solicitud se cancela y queda en audit log.
• 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 teléfonos (activo + históricos) por contacto. 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.
• PR-232 — Teléfono activo único + históricos por contacto. Definida en US-003. Aplica en backoffice: la gestión de teléfonos de cada contacto respeta la regla "un único activo verificado a la vez; los anteriores quedan como históricos con fecha de desactivación".
• PR-234 — Transferencia operativa de titularidad. La titularidad de una cuenta se puede transferir desde backoffice de un titular a un colaborador verificado de la misma cuenta, exclusivamente con autorización explícita del titular actual capturada por clic en enlace enviado a su correo. El flujo es del backoffice; el agente conversacional no inicia ni resuelve transferencias (PR-037 sigue vigente para el agente). El evento queda en audit log con los dos contactos involucrados y dispara notificación por WhatsApp + correo a ambos.

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, PR-232 (referenciada) y PR-234 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente