Saltar a contenido

US-040 — Alerta de vencimiento corporativo

Detalle de la historia

Historia

Como miembro del equipo comercial de FleteChat, quiero recibir una alerta cuando una asignación corporativa se aproxime a su vencimiento, para renegociar o renovar el contrato a tiempo y evitar que el cliente caiga a lista base sin aviso previo.

Persona de usuario

Aplica al grupo destinatario configurado por el admin en el backoffice (por defecto: rol admin + grupo comercial si existe). No aplica al cliente final: la alerta es interna y no dispara mensajes a WhatsApp del cliente. Si FleteChat quiere contactar al cliente para renovar, es una gestión comercial manual que arranca a partir de esta alerta.

Contexto de negocio

Las asignaciones corporativas tienen fecha de vencimiento (ver historia de asignación de nivel). Si nadie avisa a tiempo, el día siguiente al vencimiento el cliente queda sin nivel activo y el motor de cotización lo trata con lista de precios base, habitualmente más alta. El cliente lo nota a la primera cotización nueva, se queja, y el operador queda en posición defensiva. La alerta temprana permite que el equipo comercial levante el teléfono antes de que eso pase.

La alerta vive en el backoffice y en el correo de los destinatarios configurados. Es un mecanismo proactivo pero interno: no se comunica al cliente final por WhatsApp. La decisión de qué decirle y cuándo al cliente corporativo la toma la persona comercial, no el sistema.

Criterios de aceptación

Detección

  1. Un job diario identifica las asignaciones corporativas cuya fecha de vencimiento cae dentro de la ventana de aviso configurable (ver PR-162), incluyendo asignaciones que vencen hoy o ya vencieron y no fueron renovadas.
  2. Para cada asignación detectada, FleteChat envía una alerta al grupo destinatario configurado (ver PR-165) por los canales habilitados: correo electrónico y badge + lista visible en el backoffice.
  3. La alerta incluye: cliente (nombre), nivel corporativo, fecha de vencimiento, días restantes (o días vencidos si ya pasó), operador que gestionó la última asignación y un enlace directo al perfil del cliente en el backoffice.

Sin duplicados

  1. Una asignación dada recibe una sola alerta por la misma ventana de aviso (ver PR-163). Un flag en la asignación indica que la alerta ya fue emitida y evita reemisión en ejecuciones diarias subsiguientes.
  2. Si una asignación es renovada (se ajusta fecha de vencimiento hacia adelante con los mecanismos de US-038), el flag se limpia y la nueva ventana puede volver a generar alerta cuando corresponda.
  3. Si una asignación es terminada anticipadamente o el nivel se desactiva, la alerta pendiente no se emite.

Visibilidad en el backoffice

  1. El backoffice ofrece una vista "Asignaciones próximas a vencer" con filtros por días restantes (hoy, próximos 7, próximos 30), por nivel y por operador. La vista es consultable en cualquier momento por los roles admin y operator.
  2. La vista muestra también las asignaciones ya vencidas que aún no fueron renovadas, destacadas visualmente (por ejemplo en rojo), para evitar que se pierdan en el seguimiento comercial.

Audit log

  1. Cada generación de alerta queda registrada con timestamp, asignación alertada, canal usado (correo, backoffice), destinatarios y resultado del envío (éxito, fallo transitorio, fallo permanente).

Edge cases

  • Asignación renovada antes de que el job corra. El flag no se activa porque la nueva fecha de vencimiento queda fuera de la ventana de aviso; no se genera alerta inútil.
  • Ventana de aviso se amplía después de que la alerta ya fue emitida (por ejemplo, de 30 a 60 días). La alerta ya emitida no se reenvía; asignaciones que ahora quedan dentro de la nueva ventana y no habían alcanzado la ventana anterior sí generan alerta en la siguiente corrida.
  • Destinatario no puede recibir correo (buzón lleno, dirección rechazada). El job registra el fallo en el audit log y mantiene la alerta visible en el backoffice para que no se pierda la visibilidad. Un reintento puede quedar configurado a nivel de proveedor de correo.
  • Asignación cuya fecha de inicio es futura. Aún no es "activa"; no entra en la detección de vencimiento mientras no esté en vigor.
  • Asignación vencida hace mucho tiempo sin renovar. Sigue apareciendo en la vista de "asignaciones vencidas" hasta que el operador la cierre explícitamente o cree una nueva asignación para ese cliente. El correo inicial no se repite en cada corrida (ver PR-163).
  • Cliente al que se le desactivó el nivel por cambios de catálogo (ver historia de catálogo). Si la asignación sigue vigente con un nivel desactivado, la alerta se envía igual; el operador decide si renueva con un nivel distinto.

Tamaño, prioridad y tipo

  • Tamaño: S
  • Prioridad: P2 — mecanismo comercial preventivo; su ausencia no rompe la operación pero sí pierde oportunidades de renovación.
  • 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-162 — Ventana de aviso configurable. La ventana de días antes del vencimiento que dispara la alerta es un parámetro configurable por FleteChat desde el backoffice. Valor por defecto: 30 días.
  • PR-163 — Una alerta por asignación y ventana. Cada asignación recibe como máximo una alerta por la misma ventana de aviso. Un flag antiduplicado en la asignación previene que ejecuciones diarias subsiguientes generen alertas repetidas. Renovar o ajustar fechas limpia el flag y reinicia la detección.
  • PR-164 — Canal interno, no toca al cliente final. La alerta se envía a destinatarios internos de FleteChat (correo y backoffice). El cliente final no recibe notificación automática por WhatsApp; la comunicación comercial es manual y queda a criterio del operador.
  • PR-165 — Grupo destinatario configurable. Los destinatarios de la alerta son configurables por el admin desde el backoffice. Por defecto incluyen al rol admin y al grupo comercial si existe. Cambios al grupo se aplican a partir de la siguiente corrida del job diario.
  • PR-218 — Notificación al cliente corporativo del vencimiento próximo o efectivo de su nivel. Además de la alerta interna al equipo comercial (PR-164), FleteChat emite una notificación proactiva al cliente corporativo cuando su asignación entra en la ventana de aviso y, separadamente, el día en que el nivel queda vencido si aún no se renovó. La notificación va al titular de la cuenta por WhatsApp (y por correo verificado si la ventana de 24 h está cerrada, con plantilla Meta aprobada), con un texto genérico que informa fecha de vencimiento y canal de contacto comercial, sin exponer detalles del contrato ni precios. Esta notificación se clasifica como crítica en la matriz de US-057 (es una asignación esencial al servicio contratado), por lo que se envía con independencia de opt-out. Los tiempos (cuánto antes y si se repite el día del vencimiento) y el texto son configurables desde parámetros globales (ver US-046). La notificación es independiente de la gestión comercial manual: avisa al cliente y permite que el equipo comercial complemente con contacto dirigido.

Refinamiento y Definition of Ready

Notas

Fecha Participantes Acuerdo / Nota
2026-04-19 Kaeus Versión inicial.
2026-04-19 Kaeus Aprobación interna: pase a 🔵 Refinada.
2026-04-20 Kaeus Se añade PR-218 (notificación proactiva al cliente cuando su asignación corporativa entra en la ventana de aviso y el día del vencimiento efectivo). Refinamiento sobre PR-164, que mantiene la alerta interna; la notificación al cliente es complementaria y obligatoria. Clasificada como crítica. Resolución de hallazgos P6-03 y P6-13 de la revisión exhaustiva.

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