Fuente: refinamiento de las 63 historias de usuario y de sus premisas locales. Formato: RN-XXX — <enunciado de la regla> con trazabilidad a las historias que la originan.
Las reglas de negocio capturan restricciones o políticas que el sistema debe respetar y que son decisión del negocio (FleteChat), no una elección técnica. Cada regla es observable por el cliente o por un auditor externo sin inspeccionar el código.
El agente siempre responde en el mismo idioma en el que escribe el cliente (español por defecto; inglés si el cliente escribe en inglés).
US-053
🟡
RN-002
El agente no utiliza jerga técnica interna (nombres de sistemas, campos de base de datos, códigos de estado) con el cliente final.
US-053
🟡
RN-003
El nombre del agente es único, acordado formalmente entre FleteChat y Kaeus, y no varía entre conversaciones ni entre sesiones.
US-053
🟡
RN-004
El registro lingüístico por defecto es formal ("usted"). El agente puede cambiar a informal ("tú") dentro de una misma conversación solo si el cliente lo hace primero.
Todo recurso que el sistema exponga al cliente final por WhatsApp se identifica con un código externo compuesto por una letra distintiva del tipo de recurso más un consecutivo numérico por cuenta; es único por cuenta, no reutilizable, y se resuelve siempre dentro del alcance de la cuenta del contacto que lo menciona.
US-010, US-018
🟡
RN-006
Las variantes de escritura de un código (p. ej. C-187, c187, "cotización 187") se normalizan y resuelven dentro del alcance de la cuenta del contacto; el sistema nunca cruza recursos entre cuentas aunque un mismo contacto pertenezca a varias.
El sistema persiste datos personales del cliente únicamente tras recibir consentimiento informado, explícito e inequívoco; sin consentimiento válido no se crea la cuenta.
US-001, US-005, US-063
🟡
RN-008
El consentimiento se vincula al titular (no al número o correo específico) y persiste ante cambios de correo, nombre o agregado de números; solo una nueva versión sustancialmente distinta de la política puede exigir re-consentimiento.
US-063, US-006
🟡
RN-009
El cliente puede ejercer los derechos Ley 81 (acceso, portabilidad, rectificación, eliminación, oposición) por WhatsApp; el procesamiento es manual por un operador de FleteChat con plazo de respuesta de 15 días hábiles.
US-061, US-064
🟡
RN-010
Datos con obligación legal de retención (facturas, documentación aduanera, embarques bajo normativa contable) no se eliminan antes del plazo normativo; el cliente recibe explicación clara del alcance real de la eliminación.
US-061
🟡
RN-011
La política de privacidad se publica en URL oficial, se versiona y las versiones anteriores quedan accesibles para trazabilidad; el consentimiento registrado guarda la versión vigente al momento de aceptarse.
Todas las cotizaciones en v1.0 se emiten en dólares estadounidenses (USD); no se soportan otras monedas aunque el cliente opere en otra jurisdicción.
US-010
🟡
RN-013
Toda cotización incluye desglose obligatorio línea por línea (tarifa base, servicios opcionales, impuestos/aranceles si aplican) con formato numérico consistente en dos decimales y separadores de miles.
US-010
🟡
RN-014
El precio, los servicios contratados, el nivel corporativo aplicado y los tiempos citados al cliente al emitir una cotización se capturan como snapshot inmutable; cambios posteriores en el catálogo no afectan cotizaciones ya emitidas.
US-010, US-012, US-014, US-038, US-044
🟡
RN-015
Los precios, tiempos, servicios y combinaciones modalidad + Incoterm + tipo de operación que FleteChat comunica al cliente provienen siempre del catálogo vigente del sistema; ante ausencia de dato, el agente lo declara en lugar de estimar.
US-010, US-011, US-059
🟡
RN-016
Toda cotización tiene una vigencia explícita (default 7 días corridos, configurable); vencida la cotización no puede aprobarse y el cliente recibe oferta de re-cotización con precios vigentes.
US-014
🟡
RN-017
La aprobación formal de una cotización se consuma con el click del cliente en el enlace del correo de instrucciones, confirmado por un segundo click en la página intermedia; esa aprobación formaliza el embarque y es irrevocable sin handoff con operador.
US-012, US-055
🟡
RN-018
La vigencia de la cotización es el único plazo que rige el flujo de aprobación; los enlaces intermedios (formulario, aprobación formal) no tienen expiración propia, se validan en cada uso contra la vigencia de la cotización.
Un cliente puede tener a lo sumo un nivel corporativo activo en cualquier fecha dada; el nivel activo determina la lista de precios aplicable a cotizaciones nuevas y no altera cotizaciones previas ni embarques en curso.
US-037, US-038
🟡
RN-020
El catálogo de niveles corporativos y la asignación de un nivel a un cliente son responsabilidad exclusiva del rol admin; la renovación o el cese de una asignación se realiza por el mismo rol.
US-037, US-038
🟡
RN-021
FleteChat notifica al cliente corporativo de forma proactiva cuando su asignación entra en la ventana de aviso y el día del vencimiento efectivo; esta notificación es crítica y se envía con independencia del opt-out del cliente.
Cada cuenta tiene un titular único e inmutable, y puede tener cero o más colaboradores autorizados por el titular con consentimiento explícito propio del colaborador.
US-003, US-063
🟡
RN-023
El titular ve la totalidad de la actividad de su cuenta, incluidas las operaciones de sus colaboradores; un colaborador ve únicamente sus propias conversaciones y operaciones.
US-003
🟡
RN-024
La asociación de un nuevo número a una cuenta (teléfono adicional del titular o colaborador) requiere consentimiento explícito del titular, materializado en el click sobre un enlace enviado a su correo verificado.
La verificación de un número se realiza únicamente por enlace enviado al correo electrónico verificado; no se ofrecen SMS, llamada u otros canales alternativos en v1.0.
US-004
🟡
RN-026
El enlace de verificación de número es válido por 2 horas; el cliente puede solicitar hasta cinco reenvíos por número en una ventana de 24 horas, y cada reenvío invalida los enlaces previos.
US-004
🟡
RN-027
Las consultas conversacionales de estatus están limitadas a una cantidad razonable por minuto y por número (default 10, configurable); superado el límite el sistema responde con mensaje de espera sin revelar información adicional.
US-023
🟡
RN-028
Los enlaces sensibles entregados al cliente (vista web de reportes, paquete Ley 81, formulario operativo, aprobación formal) son de un solo uso; un reenvío invalida los anteriores.
Toda notificación proactiva del sistema se clasifica como crítica o no crítica; los mensajes críticos se envían con independencia del horario configurado y del opt-out del cliente, los no críticos se envuelven en ambos.
US-057, US-064
🟡
RN-030
Las notificaciones proactivas fuera de la ventana de 24 horas de WhatsApp requieren plantilla aprobada por Meta; si la plantilla no existe o fue rechazada, la notificación crítica degrada a correo y se alerta a operaciones.
Los mensajes no críticos disparados fuera de la ventana horaria configurada se encolan y se envían al inicio de la ventana siguiente; las notificaciones críticas se envían inmediatamente.
US-057
🟡
RN-032
El opt-out del cliente es granular (total o por categoría) y reversible; el opt-out total no afecta a los mensajes clasificados como críticos.
El handoff al operador humano exige consentimiento explícito del cliente salvo que el propio cliente lo haya solicitado activamente; ningún handoff se activa de forma automática sin su aceptación.
US-033, US-058
🟡
RN-034
Mientras la conversación está en estado pending_handoff, el agente conversacional no responde mensajes nuevos; sin embargo, sigue detectando intents críticos del cliente (cancelación del handoff, opt-out, emergencia) y actúa sobre ellos sin esperar al operador.
US-033
🟡
RN-035
Toda devolución de la conversación al agente desde el operador genera notificación proactiva al cliente; ninguna devolución ocurre en silencio. Si la ventana de 24 horas está cerrada, la notificación usa plantilla Meta aprobada.
La secuencia de estatus de un embarque se compone según los servicios contratados al momento de su emisión y se congela inmutable para ese embarque; cambios posteriores en el catálogo no afectan embarques ya emitidos.
US-027
🟡
RN-037
La actualización manual de estatus por un operador valida que la transición respeta la secuencia dinámica del embarque; una reversión se registra como entrada nueva en el historial sin eliminar la anterior.
US-025
🟡
RN-038
La notificación proactiva de cambio de estatus se envía al contacto que aprobó el embarque y al titular de la cuenta; si son la misma persona, se envía una sola vez.
US-026
🟡
RN-039
La emisión de los instructivos operativos (proveedor, operador logístico, personal interno) es atómica al click de aprobación formal; el fallo de distribución a un canal no bloquea la emisión ni el envío a los demás canales.
Los catálogos de niveles corporativos, servicios logísticos, modalidades, Incoterms y tipos de operación usan soft delete; los elementos se desactivan para preservar referencias históricas y no se eliminan físicamente.
US-037, US-042, US-043, US-044
🟡
RN-041
La actualización manual de listas de precios y el import masivo desde Excel son responsabilidad del rol price_manager; toda aplicación masiva requiere preview y confirmación explícita antes de tocar la base de datos.
US-044, US-045
🟡
RN-042
Los parámetros globales del sistema (vigencias, umbrales, ventanas, plazos, retenciones, zona horaria) son gestionados exclusivamente por el rol admin, aplican a entidades nuevas desde el momento del cambio y quedan en audit log inmutable.
El backoffice de FleteChat admite exactamente tres roles en v1.0: admin (gestión completa), operator (atención operativa) y price_manager (listas de precios). Los permisos por rol no son granulares.
US-047
🟡
RN-044
El sistema requiere al menos un admin activo en todo momento; desactivar o degradar al último admin activo es rechazado por la UI y la API.
US-049
🟡
RN-045
Un cambio de rol o la desactivación de un usuario ofrece al admin la opción de forzar el cierre inmediato de las sesiones activas del usuario afectado, activa por defecto para desactivaciones y degradaciones.
US-049
🟡
RN-046
El audit log del sistema es inmutable: no se edita ni se borra desde UI o API. Las únicas excepciones son la eliminación automática por política de retención (mínimo 24 meses) y la anonimización de PII en entradas históricas cuando se ejecuta una solicitud válida de eliminación de datos del titular.
La cancelación conversacional aplica únicamente a flujos en curso (recolección de datos, confirmación pendiente). No revierte entidades ya formalizadas (cotización aprobada formalmente, embarque emitido, consentimiento registrado, solicitud Ley 81 en trámite); estos casos requieren handoff con operador.
US-055, US-012
🟡
RN-048
Ante fallo persistente de consulta al sistema tras los reintentos automáticos definidos, el agente comunica la situación al cliente con lenguaje claro (sin jerga técnica) y escala automáticamente a handoff humano sin exigir al cliente que elija qué hacer.
Cada regla es observable por el cliente o por un auditor sin inspeccionar el código.
Las reglas se expresan en tiempo presente y en voz activa.
Cuando una regla depende de un valor configurable (ej. "horas de no molestar"), la regla enuncia la política y remite al requerimiento funcional que fija el valor.