Respuesta a la revisión de Fase 1 — Respuestas a comentarios con dudas¶

Este documento es la tercera parte de la respuesta a la revisión de Fase 1 de FleteChat v1.0. Recoge las preguntas planteadas durante la revisión y entrega la respuesta a cada una. En algunos casos la respuesta es una aclaración del diseño previsto; en otros se devuelve una pregunta concreta al equipo de Zeverium porque la respuesta corresponde a su criterio de negocio.

Las otras dos partes de la respuesta se entregan como documentos separados:

• Impactos en el alcance — qué se incorpora a v1.0, qué se difiere a v1.1 y qué se descarta.
• Refinamientos dentro del alcance — observaciones que ajustan reglas o flujos dentro de lo ya previsto.

Las preguntas se agrupan por historia de usuario (o por documento de origen) para facilitar el cruce con los comentarios originales.

Resumen ejecutivo¶

Respuesta. Son dos conceptos distintos que vienen de US-064 (opt-out de comunicaciones proactivas) y US-057 (horario de mensajes proactivos):

• Opt-out granular: el cliente puede silenciar tipos específicos de comunicación proactiva sin silenciar todo. Por ejemplo: deshabilitar las notificaciones intermedias de estatus (en tránsito, embarcado) pero mantener las notificaciones críticas (llegada, despacho). No es "todo o nada".
• Horario razonable: las comunicaciones proactivas que inicia el sistema se entregan dentro del horario laboral del cliente (por defecto lunes a viernes, 7:00 a 19:00 hora local del cliente; parametrizable). Las notificaciones críticas se entregan siempre, sin importar el horario. El cliente que escribe al bot fuera de horario es siempre atendido — la restricción aplica solo a la mensajería proactiva, no a la conversacional reactiva.

US-003 — Titular y colaboradores¶

Respuestas.

• #4 — Pregunta abierta a Zeverium. Técnicamente el sistema no exige que el titular sea el representante legal de la empresa; la condición de titular se otorga a quien crea la cuenta. Imponer "el titular debe ser el RL" puede ser una política operativa que Zeverium decida adoptar (validada por el operador FleteChat al aprobar la cuenta) o dejarse a criterio del usuario.
• Pregunta concreta: ¿quieren que sea política exigir que el titular declare ser el representante legal de la empresa? Si sí, el flujo de alta agrega esa declaración explícita al consentimiento; si no, se mantiene como está.
• Respuesta de Zeverium (2026-05-26): se mantiene como está — no se exigirá que el titular declare ser el representante legal. Cualquier miembro verificado puede ser titular.
• #6 — Aclaración. Lo que el agente entrega en la conversación es una respuesta conversacional (texto en WhatsApp), no un reporte formal. Para reportes formales descargables existen dos caminos previstos:
• El cliente puede pedir el reporte descargable directamente al agente (US-028: "consulta conversacional de reportes" — el agente entrega además un enlace de descarga en formato exportable).
• Los reportes estructurados del backoffice (US-031, US-032) son para el operador FleteChat, no para el cliente. El resumen conversacional cumple la función de "responder rápido en chat"; el descargable cumple la función de "tener el documento en la mano".

US-006 — Edición de datos de cliente¶

Respuesta. Sí — se cubre como refinamiento de la historia. La edición de titular se habilita en el backoffice: el operador puede transferir la condición de titular a otro miembro verificado de la cuenta. Ver el detalle completo en el documento de refinamientos, bloque US-006 (#9).

US-009 — Selección de servicios opcionales¶

Respuesta. El catálogo de servicios contiene todos los servicios técnicamente disponibles que FleteChat puede operar (por ejemplo: seguro de carga marítima, seguro de carga aérea, despacho aduanal, manejo en destino, almacenaje, etc.). Cuando el bot ofrece opcionales para una cotización concreta, filtra el catálogo y solo muestra los que aplican a esa modalidad, ruta y tipo de operación.

Ejemplo: para una cotización marítima LCL, el bot no ofrece "seguro de carga aérea" aunque exista en el catálogo general — no aplica a ese embarque. La regla evita ofrecerle al cliente servicios que no podría usar para su operación, lo cual confundiría más que ayudar.

US-016 — Recordatorio automático del formulario operativo¶

Respuesta. Hay dos vías de "extensión" en el diseño actual:

1. Renovación automática al vencer (US-014): cuando una cotización vence sin haber sido aprobada, el bot reabre el flujo con los datos previos y emite una nueva cotización con la tarifa vigente al momento de renovar (no extiende la original, la sustituye). Ya cubierto.
2. Extensión activa por el asesor: antes de que venza, el asesor puede extender la vigencia de una cotización manualmente desde el backoffice como acción operativa especial, con justificación obligatoria. Esto queda en audit log.

Sobre el reporte automático de cotizaciones por vencer: hoy no está previsto en US-031/032. El asesor que quiere revisar qué cotizaciones están por vencer las filtra desde la vista de cotizaciones del backoffice (por fecha de vencimiento). Si Zeverium considera que vale la pena un reporte automatizado que liste y notifique proactivamente al asesor, lo evaluamos como ampliación menor de US-031.

• Pregunta concreta: ¿quieren un reporte automático (envío diario al asesor con "estas cotizaciones vencen en los próximos N días") o consideran suficiente que el asesor consulte el listado filtrado cuando lo necesite?
• Respuesta de Zeverium (2026-05-26): se deja todo como está — no se agrega el job de aviso proactivo. El asesor consulta el listado filtrado del backoffice cuando lo necesite.

US-020 — Instructivo para el operador logístico externo¶

Respuesta. Sí. Cuando un embarque ya aprobado se reasigna a otro operador logístico, el sistema:

1. Envía una notificación al operador anterior (por correo) indicando que el embarque E42 ha sido reasignado y ya no requiere su gestión.
2. Emite el instructivo al operador nuevo y se lo envía.
3. Registra ambos eventos en el audit log con autor, timestamp y motivo de la reasignación.

El operador anterior no recibe el instructivo del operador nuevo; solo la notificación de desasignación.

US-021 — Instructivo interno para el equipo FleteChat¶

Respuesta. Sí. Cuando se modifica un dato del embarque que afecta uno de los instructivos externos (operador, proveedor) ya emitidos, el sistema:

1. Regenera el instructivo afectado con los datos actualizados, marcado con número de versión incrementado y fecha de revisión.
2. Lo reenvía al destinatario correspondiente, con un mensaje que indica explícitamente que es una versión actualizada y resume qué cambió respecto a la versión anterior.
3. El instructivo interno (US-021) también se regenera y queda disponible en el backoffice para el equipo FleteChat.

Los destinatarios siempre tienen la versión más reciente; las versiones anteriores quedan archivadas para auditoría pero ya no son las válidas.

US-026 — Notificación proactiva al cliente¶

Respuestas.

• #35 — Aclaración. La cotización se entrega al cliente por dos canales: WhatsApp al número verificado y correo al email verificado. La aprobación formal se hace por clic en el enlace del correo (US-012, paso 3), no por mensaje en WhatsApp. Por lo tanto, un titular que no tiene número de WhatsApp verificado pero sí correo verificado puede recibir la cotización por correo y aprobarla por clic. Ese mismo titular no recibe las notificaciones proactivas de estatus por WhatsApp (porque su número no está verificado); las consulta entrando al portal o pidiéndoselas a un colaborador. Es un escenario válido aunque atípico — la mayoría de titulares tendrá ambos canales verificados.
• #49 — Aclaración. Si el cliente cambia de número y verifica el nuevo, todas las notificaciones futuras van al número nuevo. El número anterior se desmarca como activo para notificaciones (puede quedar asociado a la cuenta para histórico, pero sin marca de "destinatario activo"). Las notificaciones que estaban en cola y aún no se enviaron, si las hay, se redirigen al nuevo número. Esto es coherente con la gestión de números de US-003 y US-006.
• Refinamiento de Zeverium (2026-05-26): además, el historial de conversaciones y cotizaciones del número anterior se traslada al número nuevo, para que si el cliente solicita un reporte o hace referencia a una cotización pasada, el bot pueda atender la consulta desde el número actual. El número anterior queda archivado en la cuenta solo como referencia histórica.

US-028 — Consulta conversacional de reportes¶

Respuesta — pregunta abierta a Zeverium. El comentario sugiere preferir Excel sobre CSV. Las alternativas razonables son:

• (a) Solo CSV: universal, simple, abre en cualquier hoja de cálculo. Sin formato (números como texto plano, sin separadores de miles).
• (b) Solo Excel (.xlsx): formato preservado (números, fechas, anchos de columna), pero requiere que el destinatario use Excel o software compatible.
• (c) Ambos, el cliente elige: el enlace de descarga ofrece las dos opciones. Algo más de costo de implementación pero máxima flexibilidad.

Pregunta concreta: ¿qué formato prefiere Zeverium para los reportes descargables que ofrece el bot? Lo más usual en clientes B2B es la opción (b) o (c).

Respuesta de Zeverium (2026-05-26): opción (c) — ambos formatos disponibles, el cliente elige. La justificación de Zeverium: clientes de perfil bajo suelen preferir CSV; clientes corporativos y los asesores internos de FleteChat tienden a preferir Excel para hacer reportes o análisis adicionales sobre la data. Por defecto el bot ofrece ambos formatos en el enlace de descarga.

US-032 — Reportes estructurados por dimensión¶

Respuesta — aclaración + pregunta abierta de naming. En US-032, "Servicio" como dimensión de agrupación se refiere al tipo de operación logística contratada: la combinación de modalidad (marítimo / aéreo / terrestre), tipo de operación (importación / exportación / cross-trade) y servicios opcionales contratados (seguro, despacho, manejo en destino, etc.).

Ejemplo: un embarque puede tener servicio "Marítimo LCL importación con seguro y despacho destino" y otro "Aéreo exportación sin seguro". Agrupar por "Servicio" permite ver cuántos embarques de cada tipo se operan en un período.

Pregunta concreta sobre el naming: la palabra "Servicio" puede ser ambigua. ¿Zeverium prefiere otro término en la interfaz? Algunas alternativas: "Tipo de operación", "Producto", "Modalidad de servicio", "Servicio contratado". Es decisión de cómo se le presenta esa dimensión al operador en el backoffice.

Respuesta de Zeverium (2026-05-26): decisión diferida — Zeverium prefiere cerrar el naming cuando se arme la matriz de servicios/tarifas, momento en el que tendrán claros los términos a usar y cómo presentarlos. Hasta entonces se mantiene "Servicio" como placeholder en la UI; el reemplazo se aplica antes del go-live de los reportes estructurados (US-032).

US-036 — Devolución de la conversación al agente automático¶

Respuesta. Depende del motivo del handoff. Los tres escenarios típicos son:

1. Combinación no soportada (la más frecuente): el asesor crea una cotización manual desde el chat de handoff (ver el bloque US-033 #59 en el documento de refinamientos para el detalle del flujo). Una vez creada y enviada al cliente, el asesor devuelve la conversación al bot, que retoma para los pasos siguientes (formulario operativo, aprobación, instructivos).
2. Cliente pide aclaración compleja: el asesor responde dentro del chat, eventualmente con apoyo de otra área (operaciones, finanzas). Una vez resuelta la consulta, devuelve la conversación al bot con un comentario de cierre que el cliente recibe ("Listo, espero te haya sido útil; cualquier otra consulta estoy disponible o el bot continúa atendiéndote").
3. Cliente quiere modificar algo no estándar: el asesor maneja la negociación con el cliente, deja constancia en el embarque o cotización (con audit log) de lo que se acordó como excepción, y devuelve la conversación al bot.

Regla general: lo que el asesor hace antes de devolver es dejar el estado del sistema consistente (cotización creada, embarque actualizado, comentario interno registrado, etc.) para que el bot pueda continuar sin ambigüedad. No siempre "carga datos para cotizar"; depende del caso. Lo que sí es invariante: cuando el bot retoma, el sistema tiene la información actualizada y el bot la puede usar.

US-038 — Asignación de nivel corporativo a un cliente¶

Respuesta — confirma. Sí. La asignación del nivel corporativo a un cliente (US-038) y la consulta del nivel activo a la fecha de emisión de cada cotización son procesos internos del sistema, automáticos, sin intervención del cliente final ni mensaje al cliente.

El cliente nunca ve "tu nivel corporativo es X" ni "esta cotización aplica el nivel Y". Solo recibe la tarifa correspondiente. El nivel corporativo es información comercial interna que se gestiona desde el backoffice por roles autorizados (operator / admin) y queda en audit log cuando se asigna o se modifica.