US-005 — Alta desde backoffice

Detalle de la historia¶

Historia¶

Como operador de FleteChat, quiero dar de alta un cliente nuevo directamente desde el backoffice, para atender inmediatamente a alguien que me contactó por teléfono, presencial o correo, sin tener que esperar a que escriba por WhatsApp.

Persona de usuario¶

Aplica a los roles admin y operator de FleteChat, que son quienes atienden canales distintos de WhatsApp y necesitan registrar prospectos con agilidad. No aplica al rol price_manager (gestor de precios) ni a usuarios del cliente final.

Contexto de negocio¶

Parte del volumen de prospectos llega por vías distintas a WhatsApp: un correo de contacto desde la web, una llamada comercial, una visita presencial. Si el alta solo existiera por el flujo conversacional, el operador tendría que pedirle al prospecto que abra WhatsApp y escriba, lo cual es fricción y pérdida de leads.

El alta desde backoffice replica los datos mínimos del flujo conversacional y deja al cliente creado como si se hubiera registrado él mismo, pendiente de completar la verificación cuando interactúe por primera vez con FleteChat.

Criterios de aceptación¶

Captura de datos¶

1. El operador dispone de un formulario en el backoffice para crear un cliente nuevo con: nombre completo, correo electrónico, al menos un número de teléfono y los campos de doble consentimiento que exigen US-063 (privacidad) y PR-240 (Condiciones Generales del Servicio) — canal de captación (llamada, presencial, correo, otro), fecha y hora en que el cliente otorgó cada aceptación, identificación del operador que la recibió y observación opcional para dejar evidencia (por ejemplo, referencia de correo, transcripción breve). Sin estos campos completos el sistema no persiste el cliente. El detalle de la doble aceptación off-WhatsApp y su ratificación electrónica posterior se desarrolla en el bloque correspondiente (AC 4–9).
2. El formulario valida el formato del correo y del número antes de permitir guardar.
3. Si el correo que se intenta registrar ya existe en otra cuenta, el sistema rechaza el alta y sugiere abrir la cuenta existente en lugar de crear una nueva.

Doble aceptación off-WhatsApp y ratificación electrónica¶

1. El formulario captura, además del consentimiento de privacidad, la aceptación de las Condiciones Generales del Servicio que el cliente otorgó off-WhatsApp. Ambas aceptaciones son independientes: el operador marca cada una por separado, indicando el canal por el cual el cliente la otorgó (presencial, llamada, correo, WhatsApp previo, otro), la fecha y hora, y la identificación del operador que recibió la declaración.
2. Sin ambas aceptaciones declaradas por el operador, el sistema no persiste el cliente.
3. El cliente creado desde backoffice queda marcado en el backoffice como "consentimiento pendiente de ratificación": la fuente de verdad legal del consentimiento es la ratificación electrónica del propio cliente, porque la declaración del operador es una constancia de tercero.
4. La primera vez que el cliente activa su cuenta interactuando con FleteChat por WhatsApp, FleteChat le pide ratificar electrónicamente las dos aceptaciones (política de privacidad y Condiciones Generales del Servicio) siguiendo la mecánica de US-001 AC 9–12: cada aceptación se persiste con timestamp, canal "WhatsApp", número y hash del contenido vigente (modelo declarado en PR-240 de US-063).
5. Tras la ratificación electrónica, FleteChat retira la marca "consentimiento pendiente de ratificación" y la sustituye por las dos aceptaciones ratificadas como fuente de verdad. La declaración original del operador se conserva como evidencia documental adicional, pero no es la fuente primaria.
6. Hasta la ratificación electrónica, el cliente puede operar con FleteChat: el operador puede registrar cotizaciones manuales, y el cliente puede iniciar conversaciones por WhatsApp; el sistema no bloquea operaciones por la marca "pendiente de ratificación" — ésta es informativa para el operador en el backoffice.

Estado inicial y verificación¶

1. El cliente creado desde backoffice queda en estado pendiente de verificación, igual que un cliente creado por WhatsApp.
2. La verificación se completa cuando el cliente escribe a FleteChat desde el número registrado o hace clic en el enlace que reciba al primer contacto.
3. Mientras el cliente no esté verificado, FleteChat no le emite cotizaciones ni inicia embarques al hablarle por WhatsApp. El operador puede trabajar con los datos del cliente en backoffice, pero no se envían cotizaciones al cliente hasta que se verifique.

Trazabilidad y permisos¶

1. Cada alta desde backoffice queda registrada con fecha, usuario operador y origen "backoffice", distinguible de las altas originadas por WhatsApp.
2. Solo los roles admin y operator pueden acceder al formulario de alta. Cualquier intento de acceso desde price_manager o cualquier otro rol sin permiso es rechazado con un mensaje claro.

Edge cases¶

• El operador intenta crear una cuenta con un número ya verificado en otra cuenta. El sistema rechaza el alta y dirige al operador a la cuenta existente.
• El operador no conoce todavía el correo del prospecto. El sistema exige correo como dato mínimo; si el operador no lo tiene, no puede completar el alta. Se documenta el comportamiento para que el operador lo sepa de antemano.
• Alta duplicada por distracción. Cuando el operador intenta crear una cuenta con nombre y número que ya existen, el sistema advierte y muestra el match antes de dejar guardar.

Cómo mediremos éxito¶

• Tiempo medio de alta: un operador completa un alta de cliente en menos de 90 segundos.
• Duplicados detectados antes de crear: el sistema bloquea el 100% de los intentos de alta con correo duplicado.
• Cero accesos de rol no autorizado: ningún usuario con rol price_manager accede al formulario.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P0 — necesario para operar canales no-WhatsApp desde el día uno.
• 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-030 — Datos mínimos para alta desde backoffice. Nombre completo, correo, un número de teléfono y los campos obligatorios de doble consentimiento exigidos por US-063 (privacidad) y PR-240 (Condiciones Generales del Servicio): canal por aceptación, fecha y hora por aceptación, operador receptor, observación opcional. No se habilitan otros campos en v1.0.
• PR-031 — Estado inicial. El cliente creado desde backoffice queda pendiente de verificación, igual que el creado por WhatsApp. La verificación ocurre al primer contacto por WhatsApp.
• PR-032 — Roles con permiso. Solo admin y operator pueden crear clientes desde backoffice; price_manager no tiene acceso a esta función.
• PR-250 — Doble aceptación off-WhatsApp y ratificación electrónica. Cuando el alta ocurre desde el backoffice, el operador registra dos aceptaciones independientes: política de privacidad y Condiciones Generales del Servicio. Cada aceptación se persiste con canal, fecha y hora, identificación del operador receptor y observación opcional. La declaración del operador es evidencia documental del consentimiento off-WhatsApp; la fuente de verdad legal es la ratificación electrónica del cliente al activar su cuenta por WhatsApp por primera vez (mecánica de AC 9–12 de US-001 sobre el modelo PR-240). Hasta la ratificación electrónica, el backoffice muestra el cliente como "consentimiento pendiente de ratificación"; la marca es informativa y no bloquea la operación. Tras la ratificación, las aceptaciones ratificadas reemplazan a la declaración del operador como fuente primaria; la declaración original se conserva como evidencia adicional.

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-030 a PR-032 y PR-250 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente