Respuesta a la revisión de Fase 1 — Impactos en el alcance¶

Este documento es la primera parte de la respuesta a la revisión de Fase 1 de FleteChat v1.0. Se concentra en las observaciones que cambian o amplían el alcance del producto: qué se incorpora a v1.0, qué se difiere a v1.1 y qué se descarta, con su justificación.

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

• Refinamientos dentro del alcance — observaciones que no expanden el alcance pero ajustan reglas, flujos o lenguaje dentro de lo ya previsto.
• Respuestas a comentarios con dudas — preguntas planteadas durante la revisión y su respuesta.

De las 71 anotaciones recibidas, 12 tocan el alcance del producto. Se clasifican en cuatro grupos: las que se incorporan a v1.0, las que se incorporan con un alcance acotado, las que se difieren a una iteración posterior, y una que se descarta por razones de canal. En todos los casos la razón se centra en cómo afecta la experiencia del cliente y del operador.

Resumen de decisiones¶

En total: 9 observaciones se incorporan a v1.0 (de las cuales 4 se aceptan con un alcance acotado que se explica abajo), 2 se difieren a v1.1, y 1 se descarta por una razón estructural del canal WhatsApp que se explica al final. Una observación adicional (#59) que en una primera lectura parecía cambio de alcance se reclasificó como refinamiento — se trata en el documento de refinamientos.

Se incorpora a v1.0¶

#34 + #38 — Código del operador logístico (US-018 / US-020)¶

"Se necesitará cargar un tercer código… el del operador logístico, ya que el operador tiene su propia numeración interna."

Se incorpora. El embarque seguirá teniendo el código corto que ve el cliente (tipo E42) y el código interno largo que se usa en documentos formales; se suma un tercer campo opcional para el código que maneja el operador. Lo carga el operador FleteChat cuando lo reciba del operador externo, y aparece en el instructivo PDF del operador como su referencia.

No hay sincronización automática entre los dos códigos: ambos viven en el embarque y la correlación es humana. El código de FleteChat sigue siendo el "maestro" para evitar conflictos cuando un operador trabaja con varios sistemas a la vez.

#62 — Navegación lateral en el chat de handoff (US-035)¶

"El operador debe poder desplazarse en el backoffice de la pantalla de la conversación a la plataforma de cotización, matriz de precios, etc., para poder resolver los problemas."

Se incorpora. La vista del chat de handoff incluirá una zona lateral donde el operador puede abrir el cotizador o la matriz de precios sin perder de vista al cliente. Si genera una cotización manual desde ahí (caso #59 del documento de refinamientos), queda automáticamente vinculada a la conversación. La idea es que el operador nunca tenga que abrir tabs nuevos ni "salir" del chat para resolver.

Consideración de hardware. Para que esta vista lateral sea cómoda, el operador necesita un monitor de tamaño adecuado (mínimo recomendado: 24" o equivalente, idealmente ≥27"). En pantallas pequeñas, la combinación de chat + cotizador/matriz simultáneos resulta apretada y reduce el beneficio de la navegación lateral. Esto se debe contemplar en la dotación de los puestos de trabajo del equipo FleteChat.

#64 — Control de conversaciones desatendidas (US-036)¶

"Hay que hacer algo para que FleteChat vea cómo resuelve si los asesores se descuidan."

El diseño actual ya contempla un cierre automático por tiempo de inactividad (configurable, hoy en 15 minutos). Se complementa con dos elementos:

Primero, el operador tendrá una bandeja con dos columnas: las conversaciones que tiene asignadas y las que están pendientes de tomar. Cada item muestra el cliente y cuánto tiempo lleva sin actividad. Eso reduce la posibilidad de descuido por simple falta de visibilidad.

Segundo, cuando una conversación se acerca al límite de inactividad (al 80% del tiempo configurado), el operador recibe un aviso visual para que pueda actuar antes de que la conversación regrese automáticamente al bot. Si igual se le pasa, el bot retoma con un mensaje claro al cliente explicando que sigue atendiendo y manteniendo el contexto.

Alarma sonora. El aviso visual se complementa con una alarma sonora opcional que el operador puede activar o silenciar desde su preferencia de usuario (con control de volumen, persistente entre sesiones). Se usan sonidos diferenciados por tipo de evento — nueva conversación entrante, mensaje nuevo en una conversación activa, y timeout inminente — para que cada señal sea reconocible sin mirar la pantalla. La alarma sonora es complemento, no reemplazo del aviso visual: si la pestaña está en segundo plano o el sonido del sistema apagado, el aviso visual sigue siendo la señal principal cuando el operador regresa a la pantalla.

#71 — Condiciones generales del servicio (US-063)¶

"Sería prudente que el cliente acepte las condiciones generales de los servicios; por ejemplo, que las fechas y los tiempos de tránsito siempre son estimados."

Se incorpora. Hoy el registro inicial pide el consentimiento de datos personales (lo exige la Ley 81). Se suma una segunda aceptación, en el mismo momento, para las Condiciones Generales del Servicio: tiempos de tránsito estimados, factores externos que pueden afectarlos, política de cancelación. Queda registrado con fecha, versión del documento aceptado y canal.

Una dependencia: se requiere que Zeverium entregue el texto de las Condiciones Generales que desea usar antes del go-live. Es trabajo paralelo al desarrollo.

Se incorpora con alcance acotado a v1.0¶

#11 — Bot explica Incoterms (US-008)¶

"El cliente puede no saber de Incoterms; FleteChat debería estar en capacidad de explicarle y emitir una cotización en base al Incoterm más común (usualmente FOB)."

Se acepta la parte pedagógica, no la parte de default automático. Cuando un cliente diga "no sé" o pregunte qué es FOB/CIF/etc., el bot le explica brevemente las dos o tres opciones más relevantes para su ruta y le pide que elija. No selecciona por el cliente.

La razón es que una de las reglas ya validadas es que el bot nunca asume parámetros del cliente sin confirmación (porque un Incoterm equivocado afecta precio, responsabilidades y documentación). Proponer FOB "por default" cuando el cliente dice que no sabe es, en la práctica, asumir. Si más adelante se quiere ir hacia un default automático, se evalúa en v1.1 con una política comercial definida (¿en qué rutas FOB es seguro?, ¿en cuáles no?).

#12 — Entrada "explícame el proceso" (US-007)¶

"Es muy común que el cliente comience escribiendo: 'necesito que me expliques el proceso para traer de China'."

Se acepta como un branch corto, no como un wizard educativo completo. Si el cliente abre la conversación con una petición de explicación general en vez de datos para cotizar, el bot responde con un párrafo conciso (los datos que va a necesitar, la modalidad, el tiempo de tránsito típico, los Incoterms más comunes) e inmediatamente invita a iniciar la cotización pidiendo los primeros datos.

El objetivo es ayudar a clientes nuevos a aterrizar, no convertir el bot en un curso. Si la conversación se queda en explicaciones y no avanza en dos intercambios, el bot ofrece pasarlo a un asesor humano.

#22 — Cuarto destinatario: aliado del operador logístico (US-012)¶

"El instructivo se podría enviar a un 4° remitente, que sería el aliado del operador logístico en origen (si es importación) o en destino (si es exportación)."

Se incorpora con un alcance bien delimitado.

Qué se incorpora a v1.0. Cada operador logístico en el catálogo puede tener asociados, opcionalmente, un aliado en origen y un aliado en destino (uno de cada, no más). Cuando se emite un instructivo al operador (US-020), el sistema verifica el tipo de operación del embarque y, si corresponde, envía también una copia del instructivo al aliado correspondiente:

• Importación → al aliado en origen del operador.
• Exportación → al aliado en destino del operador.

Si el operador no tiene aliado registrado para ese extremo, simplemente no se envía nada al aliado y el flujo continúa con los demás destinatarios. No es bloqueante.

El contenido del instructivo al aliado reutiliza el template del instructivo al operador (que ya no contiene información comercial, por PR-096), así que no requiere un PDF nuevo distinto.

Qué no se incorpora en v1.0 (límites del alcance):

• No se construye una matriz de configuración compleja del tipo "ruta × tipo de operación → qué aliado".
• No hay múltiples aliados por extremo (es un aliado en origen y un aliado en destino del operador, máximo).
• No hay reglas de visibilidad diferenciadas por destinatario más allá del PR-096 ya vigente. Operador y aliado ven el mismo instructivo técnico.
• No se modelan aliados con flujos operativos propios distintos al del operador principal (eso es un servicio estructuralmente distinto y aplicaría la regla del límite definido en #59).

Modelo del aliado. Cada operador del catálogo tiene dos campos opcionales: aliado_en_origen y aliado_en_destino. Cada aliado se modela como contacto simple asociado al operador (nombre, correo de coordinación operativa, teléfono opcional), no como una entidad operador completa. El aliado existe únicamente para recibir el instructivo correspondiente; no maneja tarifas, contratos ni configuración propia. Si más adelante un aliado se opera también como operador principal en otros embarques, se registra aparte como operador normal en el catálogo — son entidades distintas, sin vínculo automático.

Contenido del PDF al aliado. El aliado recibe el mismo PDF que el operador principal, sin cambios en encabezado ni en cuerpo. PR-096 ya excluye información comercial del instructivo al operador, así que el contenido es entregable a un aliado sin exponer precios ni márgenes. Un solo template, un solo PDF para ambos destinatarios.

#57 — Recordatorios y captura de razón de no aprobación (US-031)¶

"Las cotizaciones no aprobadas deberían generar recordatorios… con la opción de un botón 'NO APRUEBO'… y emitir una razón o comentario."

Se aceptan dos de las tres piezas en v1.0:

Sí van los recordatorios automáticos: el cliente recibe uno o dos avisos antes de que su cotización venza, con la opción de aprobar, pedir aclaración o declinar. La cantidad y los intervalos son configurables.

Sí va la captura de razón cuando el cliente declina espontáneamente: si el cliente dice "no me sirve" o "voy a esperar", el bot le pregunta brevemente por qué (precio, tiempo, otro proveedor, etc.) y eso queda en el reporte de no aprobación para análisis comercial.

El botón interactivo "NO APRUEBO" dentro del mensaje de WhatsApp se difiere a v1.1. Los botones interactivos de WhatsApp requieren plantillas aprobadas por Meta, tienen costo por uso y un ciclo de aprobación propio. Es preferible lanzar primero con captura conversacional (que da el 90% del valor) y, si después se ve que falta feedback porque los clientes no responden por texto, se suma el botón.

Se difiere a v1.1¶

#24 — Precio intermedio en re-cotización a la baja (US-014)¶

"Si la cotización nueva es más baja, ¿se podrá hacer un punto medio entre la nueva tarifa y la anterior? Para que el beneficio sea mutuo."

Es una idea comercialmente interesante, pero tiene una pregunta abierta que es de negocio, no técnica: ¿qué porcentaje del beneficio se reparte? ¿50/50? ¿80% para el cliente? ¿depende del nivel corporativo del cliente o de la ruta? Sin esa política definida, implementarlo es prematuro: una regla mal calibrada drena margen sistemáticamente o frustra al cliente.

Para v1.0 se mantiene la regla actual (la cotización renovada se presenta con la tarifa vigente al momento de renovar). Si en un caso concreto el asesor considera que vale la pena ofrecer un precio intermedio, lo hace de forma discrecional dentro del handoff. Para v1.1: si Zeverium define la política (qué porcentaje, en qué condiciones), se automatiza.

#47 — Operadores envían estatus por WhatsApp (US-025)¶

"¿Hay posibilidad de que los operadores logísticos informen al agente (mediante WhatsApp) los cambios de estatus y el agente los cargue directamente en el sistema?"

Se difiere a una iteración posterior. Tres razones:

Primera, hay una premisa ya validada en el levantamiento: en v1.0, la única fuente de actualización de estatus son los operadores FleteChat en el backoffice. Es una decisión consciente para no abrir riesgos de calidad de datos antes de tiempo.

Segunda, dar entrada por WhatsApp a operadores externos implica autenticación y autorización por ruta (qué operador puede actualizar qué embarque), parseo de mensajes no estructurados, y validación de origen para evitar suplantación si el WhatsApp del operador se ve comprometido. Es una integración que merece su propia historia.

Tercera, cuando llegue el momento de automatizar, probablemente sea preferible una integración por API con los operadores principales (más confiable que parsear WhatsApp libre) antes que abrir el canal WhatsApp masivamente.

En v1.0 el flujo es: el operador FleteChat recibe la novedad del operador externo por el canal que tenga (WhatsApp, email, llamada) y la carga manualmente en el backoffice (US-025). Eso mantiene el control de calidad mientras se decide la mejor arquitectura para la automatización en v1.1+.

Descartado — no aplicable al canal¶

#3 — Un número en dos cuentas (US-002)¶

"Tener un número para dos cuentas puede ser una posibilidad… FleteChat preguntará desde cuál cuenta desea hacer la cotización."

Se reconoce el caso (alguien que usa el mismo WhatsApp para trabajo y para algo personal). Tras analizarlo, se decide no implementarlo ni en v1.0 ni en versiones posteriores sobre el canal WhatsApp. La razón es de canal, no de costo de desarrollo.

WhatsApp identifica una conversación por el par de números (cliente ↔ FleteChat Business). No hay forma nativa de "subcanalizar" una conversación: el cliente y el bot comparten un único hilo lineal. No existen workspaces, perfiles, ni metadata adicional en el mensaje entrante que permita distinguir "este mensaje pertenece a mi cuenta empresa" de "este pertenece a mi cuenta personal". La única manera de soportarlo sería preguntar al cliente "¿desde cuál cuenta?" al inicio de cada interacción, lo que introduce fricción permanente a todos los demás clientes (la inmensa mayoría B2B opera con un solo número) y aun así no resuelve el problema cuando el cliente cambia de contexto a mitad de una conversación.

Además, la solución natural para separar trabajo y personal ya existe en el ecosistema: dos números (dual SIM, WhatsApp Personal + WhatsApp Business). Es la convención del canal, no un workaround forzado, y muchos usuarios B2B ya lo hacen.

Lo que sí queda abierto a futuro: si en una versión posterior FleteChat suma un canal con aislamiento nativo de conversación (por ejemplo, chat embebido en el portal web con login multi-cuenta, o app móvil propia), ese canal sí podría soportar varias cuentas para un mismo titular. Pero esa decisión va atada a habilitar un canal nuevo, no a refinar el reconocimiento por número en WhatsApp.

Resumen: la regla de FleteChat sigue siendo "un número = una cuenta" sobre el canal WhatsApp. Si surge el caso real, se maneja con dos números separados.