Saltar a contenido

US-001 — Registro por WhatsApp

Detalle de la historia

Historia

Como cliente nuevo, quiero registrarme por WhatsApp conversando con FleteChat, para empezar a cotizar sin pasar por un formulario web ni crear una cuenta con contraseña.

Persona de usuario

Aplica al cliente que escribe por primera vez a FleteChat y cuyo número no está asociado a ninguna cuenta existente. No aplica a operadores de FleteChat (para ellos, el alta por backoffice es otra historia del mismo epic).

Contexto de negocio

El primer contacto es el momento en que FleteChat convierte —o no— a un prospecto en cliente. Obligar a ese prospecto a salir del chat, abrir un navegador y llenar un formulario quiebra la propuesta de valor conversacional y genera caída de prospectos.

El flujo de registro por WhatsApp elimina esa fricción: FleteChat recolecta los datos mínimos (nombre y correo) dentro del propio chat, confirma con el cliente antes de crearlo, y lo deja listo para cotizar. La verificación del correo se trata por separado en una historia específica (ver historia de verificación por enlace).

Diálogo de referencia

Primer contacto de un número desconocido

Cliente: Hola, quiero cotizar un envío desde China.

Agente: Hola, soy FleteChat, su asistente logístico. Con gusto le ayudo. Para empezar, ¿me dice su nombre completo?

Cliente: María Pérez.

Agente: Gracias, María. ¿A qué correo electrónico le envío la confirmación y las cotizaciones?

Cliente: maria@ejemplo.com

Agente: Perfecto. Registro entonces: María Pérez, correo maria@ejemplo.com, teléfono el que está usando ahora. Antes de continuar, necesito dos aceptaciones rápidas. ¿Confirma?

Cliente: Sí.

Agente: Primero, el tratamiento de sus datos. Los usamos para identificarla como cliente, cotizar y gestionar sus envíos, y comunicarle el estatus. Puede consultar la política completa aquí: https://fletechat.com/privacidad. ¿Acepta?

Cliente: Sí, acepto.

Agente: Gracias. Segundo, nuestras Condiciones Generales del Servicio: definen el alcance del servicio logístico, responsabilidades, vigencia de cotizaciones y reglas de cancelación. Texto completo aquí: https://fletechat.com/condiciones-generales. ¿Acepta?

Cliente: Sí.

Agente: Listo, ya está registrada. Le acabo de enviar un correo a maria@ejemplo.com con un enlace para verificar el número. Para poder emitirle una cotización necesito que confirme ese enlace; mientras tanto, si quiere, puedo ir tomando los datos de su envío para tener la cotización lista apenas verifique. ¿Desde dónde sale y a dónde va?

Cliente da correo ya asociado a otra cuenta

Cliente: maria@ejemplo.com

Agente: Ese correo ya figura en una cuenta existente. ¿Está usando un teléfono nuevo y quiere asociar este número a su cuenta? Si es así, le envío un enlace a maria@ejemplo.com para confirmarlo.

Criterios de aceptación

Detección y arranque del flujo

  1. Cuando un número que no está asociado a ninguna cuenta envía un mensaje a FleteChat, FleteChat inicia el flujo de registro antes de atender cualquier otra solicitud.
  2. El flujo inicia con el saludo y la presentación de FleteChat definidos en la historia de identidad.

Recolección de datos

  1. FleteChat solicita nombre completo y correo electrónico como datos mínimos; no pide ningún otro dato para completar el registro inicial.
  2. FleteChat valida el formato del correo antes de aceptarlo; ante un formato inválido, pide reintentar explicando brevemente el problema.
  3. Si el correo ya está asociado a otra cuenta, FleteChat no crea una cuenta nueva: ofrece al cliente asociar el número desde el que escribe a la cuenta existente (ver historia de multi-número) y, solo si el cliente lo rechaza, ofrece registrar con otro correo o hablar con un asesor.

Confirmación antes de crear

  1. Antes de crear la cuenta, FleteChat repite los datos recolectados (nombre, correo, número desde el que escribe) y pide confirmación explícita del cliente.
  2. Si el cliente corrige algún dato, FleteChat acepta la corrección y repite la confirmación.
  3. FleteChat no crea la cuenta hasta recibir la confirmación del cliente.

Doble aceptación: privacidad y Condiciones Generales del Servicio

  1. Tras la confirmación de datos y antes de persistir la cuenta, FleteChat ejecuta dos aceptaciones explícitas y separadas en este orden:
  2. Aceptación de la política de privacidad según la mecánica definida en US-063: el agente entrega el resumen de finalidades, destinatarios y derechos, junto con el enlace prominente a la política (ver US-062), y solicita la aceptación.
  3. Aceptación de las Condiciones Generales del Servicio: el agente presenta un resumen corto (alcance del servicio logístico, responsabilidades, vigencia de cotizaciones, reglas de cancelación) y el enlace al texto completo, que FleteChat sirve a partir del archivo markdown del repositorio leído en tiempo de ejecución (ver PR-240 declarada en US-063). El agente solicita la aceptación.
  4. FleteChat persiste por separado cada una de las dos aceptaciones con timestamp, canal "WhatsApp", número desde el que el cliente respondió y hash del contenido aceptado (texto de privacidad y texto de Condiciones Generales en su versión vigente al momento de la aceptación). El hash es el mecanismo declarado en PR-240 para reconstruir qué versión exacta del texto fue aceptada.
  5. Si el cliente rechaza la aceptación de la política de privacidad, FleteChat no persiste la cuenta y cierra cordialmente la conversación (ver US-063 edge cases). El comportamiento ante rechazo de las Condiciones Generales sigue el mismo patrón: no se persiste la cuenta y se cierra.
  6. FleteChat no crea la cuenta ni habilita capacidades operativas (cotizar, iniciar embarques) hasta tener registradas ambas aceptaciones.

Estado inicial y trazabilidad

  1. El cliente creado por WhatsApp queda en estado pendiente de verificación hasta que complete la verificación del número por correo.
  2. El cliente pendiente de verificación puede conversar con FleteChat y proveer datos operativos (origen, destino, modalidad, mercancía) para preparar una cotización, pero FleteChat no emite cotizaciones ni inicia embarques definitivos hasta que se verifique.
  3. Una vez verificado, FleteChat procesa automáticamente los datos ya recolectados y entrega la cotización solicitada sin pedirle al cliente que repita la información.
  4. El registro queda visible para los operadores de FleteChat en el backoffice, indicando que el origen fue WhatsApp.

Edge cases

  • Cliente abandona el flujo a mitad. Cuando el cliente vuelve a escribir, FleteChat retoma desde donde quedó (por ejemplo, pendiente del correo) sin volver a pedir los datos ya provistos.
  • Cliente se niega a dar el correo. FleteChat explica en una línea por qué se necesita (para verificación y comunicaciones) y, si el cliente persiste en no darlo, ofrece handoff a un asesor.
  • Cliente da un nombre evidentemente falso (por ejemplo, una sola letra o un emoji). FleteChat no entra a validar contenido; acepta lo que el cliente da y lo confirma. El operador puede corregir después desde backoffice.
  • Cliente responde con datos fuera de orden (da el correo antes que el nombre). FleteChat acomoda el flujo y pide lo que falta sin obligar al cliente a repetir lo ya dicho.
  • Cliente intenta cotizar antes de completar el registro. FleteChat explica que primero necesita los datos mínimos y continúa el flujo.
  • Cliente insiste en recibir una cotización antes de verificar el correo. FleteChat explica amablemente que la cotización se emite al verificar y ofrece seguir recolectando los datos del envío para acortar el tiempo post-verificación.

Cómo mediremos éxito

  • Tasa de finalización del registro conversacional: en una muestra de primeros contactos, el 90% o más completa el registro dentro de la misma conversación.
  • Tasa de abandono en el campo correo: menos del 10% abandona cuando FleteChat pide el correo.
  • Cero fricción post-registro: el cliente puede cotizar inmediatamente después de confirmar sus datos, sin pasos adicionales en el chat.

Tamaño, prioridad y tipo

  • Tamaño: M
  • Prioridad: P0 — puerta de entrada del cliente final al servicio.
  • 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-019 — Datos mínimos para registro. El registro conversacional requiere nombre completo y correo electrónico. El número de teléfono surge del propio mensaje. No se pide ningún otro dato en el flujo inicial.
  • PR-020 — Capacidades antes de verificar el correo. El cliente pendiente de verificación puede conversar con FleteChat y proveer todos los datos de su operación. FleteChat no emite cotizaciones ni inicia embarques definitivos hasta que el cliente complete la verificación. Los datos recolectados se conservan y la cotización se emite automáticamente al verificarse. La verificación se trata en su propia historia.
  • PR-021 — Correo duplicado. Si el correo que da el cliente ya existe en otra cuenta, FleteChat no crea una nueva cuenta. Interpreta que el cliente está escribiendo desde un teléfono nuevo y le ofrece asociar el número actual a la cuenta existente enviando un enlace de confirmación al correo titular (mecanismo definido en la historia de multi-número). Solo si el cliente rechaza la asociación, se ofrecen las alternativas de usar otro correo o hablar con un asesor.
  • PR-240 (referencia) — Condiciones Generales del Servicio como markdown del repositorio. La aceptación de Condiciones Generales del Servicio exigida en AC 9 y AC 10 sigue el modelo declarado en PR-240, definida en US-063: el texto vive como archivo markdown en el repositorio del proyecto, la aplicación lo lee en tiempo de ejecución, los cambios al texto se versionan por git y la aceptación se persiste con hash del contenido vigente al momento. US-001 no redeclara PR-240; la referencia aquí explicita que ese modelo gobierna el segundo paso del alta por WhatsApp.

Refinamiento y Definition of Ready

Notas

Fecha Participantes Acuerdo / Nota
2026-04-17 Kaeus Versión inicial.
2026-05-27 Kaeus v2.0 (sweep PR-245) — Aplicación de PR-245 (definida en US-035): "asesor humano" pasa a "asesor" en AC 5 (correo asociado a otra cuenta) y "handoff humano" pasa a "handoff a un asesor" en edge case del cliente que se niega a dar el correo. Filename y title se mantienen.
2026-05-27 Kaeus Audit cross-historia (consistency-audit-v2.0.md §"Bumps recomendados v1.x → v2.0"): se incorpora explícitamente la doble aceptación (privacidad + Condiciones Generales del Servicio) declarada en US-063 v2.0, que no estaba reflejada en el flujo de alta por WhatsApp. Cambios: (a) diálogo de referencia del primer contacto extendido con los dos pasos de aceptación; (b) bloque de AC nuevo "Doble aceptación: privacidad y Condiciones Generales del Servicio" (AC 9–12) que persiste cada aceptación por separado con timestamp, canal, número y hash del contenido aceptado (mecanismo declarado en PR-240); (c) re-numeración de los AC de estado inicial y trazabilidad (10–12 → 13–16); (d) sección Premisas incorpora PR-240 como referencia (no se redeclara).

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