1- Logistics issue / Incidencias
* Definición del proceso:*
📖 Definición del proceso Se considera una incidencia logística a cualquier inconveniente, error o retraso que se presente desde que el producto sale del proceso de producción/almacén hasta que llega a las manos del cliente final.
Objetivo: Establecer lineamientos claros para la identificación, registro y gestión de incidencias logísticas, con el fin de que el equipo de atención y operaciones cuente con un procedimiento estandarizado para dar seguimiento y resolución a cualquier situación que afecte el proceso de entrega.
⚙️ Procesos y reglas de negocio
1.01 Delivery delay / Demora en entrega:
Se refiere a una anomalía en el flujo logístico donde un paquete, habiendo sido recolectado por la paquetería 3PL (Delivered to Carrier), excede el tiempo de tránsito estándar (7 días hábiles) sin llegar a su destino o sin mostrar actualizaciones en el rastreo. Esta incidencia es crítica porque genera incertidumbre en el cliente. El retraso puede deberse a saturación en los centros de distribución de la paquetería, falta de unidades de reparto, incovenientes con el repartidor, problemas de zonificación, etc. El objetivo principal es la "agilización" de la guía mediante el reporte de este incidente.
Escenario Front: El agente debe validar en el portal de la paquetería si el último evento tiene más de 7 días hábiles. Solicita dirección completa con referencias adicionales (color de casa, entre calles se encuentra) y teléfono de contacto. El agente crea el caso adjuntando estos datos.
Escenario Back: Analiza el historial de la guía. De acuerdo al Case levantado por Front, Showroom o Telesales con los datos necesarios, abre un Internal Case al Área Internally Scaled a "3PL" con Internal Case Type "Retraso de entrega 3PL". En caso de no tener respuesta en el Internal en un lapso de 84 h, escalar solicitud con Team Leaders y/o Supervisores.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. No generar reporte si la guía tiene menos de 7 días hábiles en camino. El conteo de días inicia a partir del estatus Delivered to Carrier o bien, desde que la paquetería recolecto el producto. Para Onfleet, solo aplica si la tarea lleva +24h vencida sin gestión del repartidor. Los días hábiles de paquetería 3PL se debe de considerar de lunes a viernes. Los días inhábiles de paquetería 3PL se debe de considerar sábado, domingo, días feriados o comunicados que brinde la misma paquetería desde su portal oficial. En entregas asignadas el mismo días en Onfleet no se genera caso, consideran que la entrega está en un horario abierto de 8 am a 8pm debido a temas externos como tráfico, manifestaciones, accidentes, etc. (Vease 1.02 Failed delivery / Entrega fallida) La paquetería 3PL solo hace entrega a pie de banqueta, la entrega es de 9 am a 9 pm, no hay fecha exacta de entrega y el repartidor no tiene como obligación llamar a los clientes, el monitoreo es desde la guía de rastreo. En caso de que el área de logistica, mencione que el producto o la orden estan extraviado, se retipifca caso de acuerdo al proceso 1.12 Lost package / Paquete extraviado
Escalamiento (Internal Case):
Generar a 3PL (Reason: Retraso de entrega 3PL). Cierre en ZeCore permitidos (Resolution type): Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
1.02 Failed delivery / Entrega fallida
Situación donde la paquetería intentó completar la entrega pero el flujo se vio interrumpido por causas externas al almacén o repartidor. Aqui las diferencias de Failed delivery en ambas paqueterías:
En Onfleet: Generalmente por ausencia del cliente o errores de ubicación de coordenadas. Requiere que el producto regrese físicamente al almacén para que el estatus cambie a Re-scheduled.
En 3PL: Se agotan los 3 intentos reglamentarios que realiza la paquetería. El producto entra en un periodo de "espera en sucursal" (5 días) antes de ser retornado o en algunos casos, directamente retorna hacia el almacén.
Escenario Front: Si en Shipping Core el estatus es Re-scheduled, el agente acuerda la fecha con el cliente y la actualiza en el sistema. Si el producto ya va de regreso a almacén, explica que debe esperar el arribo para reenvío y en este segundo escenario, se genera caso.
Escenario Back: Monitorea que los ítems en Delivered to carrier que fallaron cambien a Rescheduled de acuerdo al Case que genero Front, Showroom o Telesales. Si después de 72 horas no cambian, abre Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Retorno de producto en proceso" para forzar el retorno en sistema si es posible.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Si es el 3er intento fallido de 3PL, la orden debe retornar a almacén; no se puede pedir un 4to intento.
En Onfleet, si el cliente reporta que el chofer no llamó, no notifico por medio de WhatsApp y/o SMS, se debe de escalar queja en el canal de Google Chat de "Ordenes urgentes Log Onfleet/Customer Service".
En caso de que en la task asignada a Onfleet la dirección sea diferente a la registrada en Shipping core, habrá que modificar las coordenadas.
*Escalamiento (Internal Case): *
Generar a 3PL (Reason: Retorno de producto en proceso).
Para Onfleet: No aplica (notificar vía Google chat Ordenes urgentes Log Onfleet/ Customer Service).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
1.03 Unrecognized delivery / Entrega no reconocida
Es una de las incidencias más delicadas (Posible siniestro). Ocurre cuando el Shipping Core y el portal del transportista marcan el producto como Delivered, pero el receptor final asegura no tenerlo. Esto implica una discrepancia grave entre la evidencia de entrega (firmas, fotos) y la realidad del cliente. La definición incluye el protocolo de validar con vigilancia, local alrededor del domicilio, vecinos o familiares) antes de proceder a una investigación legal/logística por robo o entrega errónea.
Escenario Front: Realiza el "Sondeo de Seguridad" (¿preguntó a vecinos/familares/locales cercanos/vigilancia?). Solicita INE/Pasaporte vigente (obligatorio) junto con su dirección completa con referencias (color de casa, entre calles se encuentra) y teléfono de contacto.
Escenario Back: Del Case generado, genera Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Entrega no reconocida 3PL" adjuntando lo capturado por Front, Showroom o Telesales. Si Logística confirma extravío, cambia el estatus del ítem para permitir el nuevo envío.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
El tiempo para generar un reporte de entrega no reconocida por paquetería FedEx es de 21 días naturales desde que pasó a entregada la guía.
El tiempo para generar un reporte de entrega no reconocida por Estafeta es de 30 días naturales desde que pasó a entregada la guía.
El tiempo para generar un reporte de entrega no reconocida por flotilla interna por el momento es cuando el cliente lo reporte.
El case a gestionar con Entrega no reconocida se debe de realizar desde la orden original de garantía o de cambio de acuerdo al escenario.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Entrega no reconocida 3PL).
Cierre en ZeCore permitidos (Resolution type):
Resending product: Aplica Submitteo (Posventa) solo si el área de logística da el Vo.Bo. para el reenvío.
Dismissed: Si es caso duplicado.
Order delivered / Delivery acknowledged.
1.04 3PL error / Error de 3PL
Son incidencias operativas internas de FedEx, Estafeta o DHL que no son responsabilidad de la empresa ni del cliente. Ejemplos claros: el paquete fue enviado a una ciudad distinta (error de ruteo), la guía fue dañada y es ilegible en sus bandas de escaneo, o la paquetería perdió el paquete antes de siquiera intentar la entrega. Se diferencia de la demora (Vease 1.01 Delivery delay / Demora en entrega) porque aquí hay un error logístico tangible, no solo lentitud.
Escenario Front: Identifica anomalías como "Paquete en ciudad equivocada" o "Guía dañada" en el portal de rastreo. Informa al cliente que se está gestionando la redirección.
Escenario Back: De acuerdo al Case generado por Front, Showroom o Telesales se evanta Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Retraso de entrega 3PL" detallando el error observado. Da seguimiento diario hasta ver el paquete en la ruta correcta o alguna notificación que brinde el área de logística.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Solo aplica cuando la responsabilidad es 100% de la paquetería (error de surtido o ruteo).
Si el error de ruteo es por un código postal mal capturado por Customer Services, se tipifica como el proceso 1.06 Incorrect address on the way.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Retraso de entrega 3PL).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Resending product: Aplica Submitteo (Posventa) solo como excepción autorizada por Team Leaders o Supervisión.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.05 Out of stock / Falta de inventario
Esta incidencia se presenta cuando no existe disponibilidad suficiente de producto para cubrir todas las órdenes solicitadas por los cliente. Esto coloca la orden en Future Delivery o la marca como Re-scheduled con la razón Insufficient Stock en el Shipping Core. Es una incidencia de comunicación donde el objetivo es la gestión de la expectativa del cliente sobre la nueva fecha de producción.
Escenario Front: Detecta estatus Future Delivery o Re-scheduled con razón Insufficient Stock o Advance delivery mass re-scheduled en el Shipping Core. Ofrece contención (regalo o creditos para compras) si la fecha es muy lejana o cliente desea cancelar la orden. Valida con la plataforma de "Activos e Inactivos" la fecha de salida del producto. En caso de no tener fecha extendida, se realiza consulta en el canal de Google Chat de "Activos/Inactivos" para validar cuando abra fecha extendido del item.
Escenario Back: Si el caso viene de Front, Showroom o Telesales ya sea porque el cliente requiere evidencia del seguimiento, valida con la plataforma de "Activos e Inactivos" la fecha de salida del producto. En caso de no tener fecha extendida, se realiza consulta en el canal de Google Chat de "Activos/Inactivos" para validar cuando abra fecha extendido del item.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Prohibido prometer fechas de entrega sin confirmar la disponibilidad en la plataforma y/o canal de Activos/Inactivos.
Escalamiento (Internal Case):
Generar a Planeación (Reason: Confirmación de nueva fecha extendida).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.06 Incorrect address on the way / Dirección incorrecta en tránsito
Incidencia donde se detecta que los datos de destino son erróneos (calle, número, código postal) pero el producto ya está bajo custodia de la paquetería (Delivered to Carrier). Debido a que los sistemas de la paquetería 3PL no permiten cambios de dirección "en tránsito" por seguridad y evitar el envío del doble producto, el proceso define la necesidad de realizar un retorno para corregir los datos desde la raíz en el Shipping Core.
Escenario Front: El cliente avisa error de domicilio o el agente ve que en los portales de paquetería menciona que la dirección está incorrecta en el estatus de Delivered to Carrier. El agente levanta el caso con la dirección nueva completa con referencias (color de casa, entre calles se encuentra) y teléfono de contacto y advierte sobre el tiempo de retorno.
Escenario Back: Si el caso viene de Front, Showroom o Telesales, se solicita retorno mediante Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Cambiar status con retorno". Solo cuando el producto regrese a almacén, se edita la dirección y se libera.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
No intentar cambiar la dirección en Shipping Core si ya tiene guía generada.
Esta tipificación solo será valida cuando se encuentre dentro de los días hábiles de entrega estipulados por la paquetería.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Cambiar status con retorno).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Resending product: Aplica Submitteo (Posventa) solo como excepción autorizada por Team Leaders o Supervisión.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.07 Incorrect address in factory / Dirección incorrecta en fábrica
Esta incidencia se presenta en base a error de datos detectado mientras el producto aún está en nuestras instalaciones (Wip Warehouse o Pending Driver). Es una "ventana de oportunidad" crítica donde se debe actuar rápido para detener la salida del camión, ya que una vez que pase a Delivered to Carrier, el costo operativo y el tiempo de resolución se triplican. En caso de no ser posible, se debera solicitar retorno hacia almacén para modificar la dirección cuando la orden este en camino.
Escenario Front: Cliente reporta error. El agente ve que está en Pending Driver o Wip Warehouse. Levanta caso para detener la carga.
Escenario Back: De acuerdo al caso generado por Front, Showroom o Telesales, se solicita salida de acomodo de producto mediante Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Cambiar status para reprogramar 3PL". En caso de que no sea posible sacar el producto, se deberá de esperar a que la orden salga, este en Delivered to Carrier, para generar Internal Case a la misma área, sin embargo con Internal Case Type "Cambiar status con retorno" y se retipifica Reason del Case.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Si la orden va en camino , el caso se retipifica automáticamente como el proceso 1.06 Incorrect address on the way.
Esta tipificación solo será valida cuando se encuentre dentro de los días hábiles de entrega estipulados por la paquetería.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Cambiar status con retorno). (Nota: Aplica si el producto ya no puede salir; la opción "Sacar producto del acomodo" está inhabilitada por logística).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Resending product: Aplica Submitteo (Posventa) solo como excepción autorizada por Team Leaders o Supervisión.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.08 System error / Status not progressing / Error de sistema
Falla técnica en la comunicación de datos entre ZeCore. La orden parece estar "liberada" pero no avanza de un estatus a otro (ej. se queda en Pending Shipping por semanas a pesar de haber stock). No es un problema físico de almacén, sino un error que requiere la intervención del equipo de Tech (Soporte técnico) para liberar la orden manualmente.
Escenario Front: Detecta órdenes que no avanzan de Pending Shipping o Wip Warehouse tras 48h. Levanta case para Back.
Escenario Back: Al generarse el Case, se valida si hay error en sistema. Levanta ticket a GLPI e Internal Case al Area Internally Scaled a "Tech" para "desatorar" la orden en el flujo de salida.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Antes de escalar el Case o ticket, validar que la Sale Order no esté en In Payment o tenga alertas de fraude que hayan reportado desde el canal de Google Chat de "Validación de Ordenes.".
Escalamiento (Internal Case):
Generar a Tech (Reason: Error en proceso postventa).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.09 Incomplete delivery / Entrega incompleta
Esta incidencia pasa por error de surtido donde una Sale Order de varios artículos es fragmentada incorrectamente, como los sofás de Luuna. El cliente recibe, por ejemplo, la base de la cama pero no el colchón. Esto puede ocurrir porque un producto se quedó en Wip Warehouse mientras el otro salió, más que nada el sistema por error de sistema o falta de stock. Se enfoca en producto que se entregó vs. el qué quedó pendiente.
Escenario Front: El cliente reporta que recibió menos items de los esperados. El agente válida en Shipping Core cuántos productos salieron. Si falto uno por salir de almacén, informa la fecha de salida del faltante. Si es por falta de stock, solo se da la información de fecha de salida asignada del item.
Escenario Back: Al generarse el Case, si pasa mas de 72 h hábiles en estatus de Wip Warehouse y el o los productos no pasan a Delivered to Carrier, se realiza Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Retraso de entrega 3PL" para validar el porque el producto sigue detenido en almacén.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Retraso de entrega 3PL).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.10 Early shipment / Entrega anticipada
Incidencia por falta de alineación con la agenda del cliente o la entrega se reasigno de manera automática para adelantar la entrega. Ocurre cuando logística procesa la orden antes de la fecha solicitada (común en clientes que se están mudando). El riesgo es que el cliente no esté para recibir, generando una Entrega Fallida (Proceso 1.02 Failed delivery / Entrega fallida) innecesaria.
Escenario Front: Cliente molesto porque el paquete llega antes y no hay quién reciba. Si el estatus es Pending Shipping, Future Delivery o Pending Delivery Task se cambia la fecha manualmente.
Escenario Back: Si ya está en Delivered to Carrier, se intenta detener con la paquetería en el canal de Google Chat de "Ordenes urgentes Log Onfleet/Customer Service". (solo Onfleet). En 3PL mediante un Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Cambiar status con retorno", se le pide al cliente que no reciba para realizar el retorno.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Cambiar status con retorno). (Nota: Aplica si el producto ya no puede salir; la opción "Sacar producto del acomodo" está inhabilitada por logística).
Cierre en ZeCore permitidos (Resolution type):
Dismissed: Si es caso duplicado.
Order delivered.
1.11 Delivery driver incident / Incidente con repartidor
Problemas logísticos cuando la orden va en camino que impiden que el camión complete su ruta diaria en Onfleet. Incluye accidentes de tránsito, fallas mecánicas de la unidad, bloqueos por manifestaciones o condiciones climáticas extremas. A diferencia de la demora, aquí el paquete sí salió a ruta ese día, pero algo impidió que llegara a la puerta del cliente.
Escenario Front: Rastreo muestra "Incidencia en ruta" o desde el canal de Google Chat de "Ordenes urgentes Log Onfleet/Customer Service". Informan el incidente con el repartidor. Posterior al cliente que hubo un contratiempo técnico y la entrega se reprogramará a la brevedad.
Escenario Back: Al Case levantado, se levanta un Internal Case al Area Internally Scaled a "Onfleet" con Internal Case Type "Entrega incompleta - Sistema", para validar si el área de logística realizan el cambio de manera manual o manden la orden en Re-scheduled para que se realice el reagendamiento.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
No reagendar manualmente hasta que el estatus cambie a Rescheduled.
En caso de presentar este incidente en paquetería 3PL, se debe de realizar el proceso 1.01 Delivery delay / Demora en entrega.
Escalamiento (Internal Case):
Generar a Onfleet (Reason: Entrega incompleta - Sistema).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Resending product: Aplica Submitteo (Posventa) solo como excepción autorizada por Team Leaders o Supervisión.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.12 Lost package / Paquete extraviado
Confirmación oficial por parte de la paquetería de que el paquete no puede ser localizado y no será entregado. Esta incidencia activa el seguro de transporte y requiere la generación de una nueva orden de venta como "pérdida de producto".
Escenario Front: Explica al cliente que tras la investigación se determinó extravío y se procederá con el reenvío sin costo.
Escenario Back: De acuerdo al Case levantado, confirma con 3PL el extravío mediante un Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Paquete extraviado 3PL". Cambia estatus del ítem en ZeCore a "Re-scheduled" o se genera la nueva orden vinculada a la original, esto será de acuerdo a los comentarios que realice el área de logística en el Internal Case.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Es obligatorio contar con la confirmación de logistica para dar por perdido el paquete y poder hacer el reenvío del producto.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Paquete extraviado 3PL).
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar cancelación.
Resending product: Aplica Submitteo (Posventa) solo si logística da el Vo.Bo. en el Internal Case para el reenvío.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.13 Damaged package/product / Producto o empaque dañado
Esta incidencia es el compromiso de la calidad física del pedido. Se divide en dos:
Daño Estético: La caja llega rota pero el producto (protegido por vacío) está intacto.
Daño Funcional: El producto presenta golpes, suciedad o roturas.
Esta incidencia busca documentar fotográficamente el mal manejo por parte del transportista para ejecutar reclamos y garantías.
Escenario Front: Solicita 3 fotos: Caja externa, etiquetas y daño del producto. Si es solo caja, aplica contención. Si es producto, ofrece cambio por Defect Warranty.
Escenario Back: Retipifica caso como Defect Warranty y se realiza este proceso.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Escalamiento (Internal Case):
No aplica. Se gestiona directamente vía proceso de Defect Warranty.
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar devolución.
Dismissed: Si es caso duplicado.
Order delivered / Client goes to Store.
# 1.14 Additional references / Referencias adicionales
Esta incidencia sirve por la necesidad de robustecer la información del domicilio para garantizar el éxito de la entrega. No es un cambio de dirección, sino un complemento de datos con las referencias que proporcione el cliente. Esta información es vital para el equipo de Onfleet y 3PL para reducir el tiempo de búsqueda del domicilio si se avisa de manera anticipada .
Escenario Front: Si el estatus es Future Delivery, Pending Delivery Task o Pending Shipping, edita las referencias (En 3PL) o coordenadas (En Onfleet) directo en ZeCore. Si no te lo permite por estar en Wip Warehouse, Pending Driver o Delivered to Carrier, genera el caso con las señas particulares del domicilio. Si es en Onfleet, puedes no generar el caso, desde el canal de Google Chat de "Ordenes urgentes Log Onfleet/Customer Service" brindado esta información.
Escenario Back: Con el caso generado, escala las referencias mediante un Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Referencias adicionales". En Onfleet avisa en el desde el canal de Google Chat de "Ordenes urgentes Log Onfleet/Customer Service" para que el área de logistica lo notifique al repartidor asignado de la entrega de la orden.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto.
Las referencias no deben modificar la calle o número, solo añadir información descriptiva.
Para que la referencias en paquetería 3PL sean contempladas, necesitas pedir las referencias (color de casa, entre calles se encuentra) y telefono de contacto.
Para que la referencias en paquetería Onfleet sean contempladas, necesitas pedir las referencias (color de casa, entre calles se encuentra) y telefono de contacto junto con las coordenadas del cliente, esto debido a que desde el sistema de Onfleet el mapeo y entrega correcta se realiza en base a latitud y longitud del domicilio del cliente.
Escalamiento (Internal Case):
Generar a 3PL (Reason: Referencias adicionales).
Cierre en ZeCore permitidos (Resolution type):
Resending product: NO lleva Submitteo. Solo se levanta Internal Case al área de logística.
Dismissed: Si es caso duplicado.
Client goes to Store.
# 1.15 Carrier change / Cambio de paquetería
Esta incidencia se presenta cuando la empresa de mensajería asignada inicialmente no puede concretar la entrega por restricciones o bien, cuando el cliente solicita el cambio desde un inicio de paquetería para asegurar la recepción de su paquete. 2 de las restricciones pueden ser por:
Restricción de zona: La paquetería original no entra a esa colonia.
Eficiencia: Se decide mover de 3PL a Onfleet para una entrega más rápida o viceversa en situaciones muy especificas teniendo en cuenta que Onfleet entrega en parte de la Ciudad de México y Estado de México. O puede ser de mismo 3PL, de FedEx a Estafeta o viceversa.
Escenario Front: Identifica si el cliente quiere Onfleet por rapidez o FedEx por confianza. Verifica cobertura en el mapa de paqueterías. En caso de ser entre paqueterías 3PL, cambia el carrier en el Shipping Core estando en Future Delivery, Pending Delivery Task o Pending Shipping.
Escenario Back: Con el caso levantando, sin embargo, la orden esta Wip Warehouse, Pending Driver o Delivered to Carrier, se solicita salida de acomodo de producto mediante Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Cambiar status para reprogramar 3PL". En caso de que no sea posible sacar el producto, se debera de esperar a que la orden salga, este en Delivered to Carrier, para generar Internal Case a la misma área, sin embargo con Internal Case Type "Cambiar status con retorno" y se retipifica Reason del Case.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. No cambiar el carrier si el producto ya está en Wip Warehouse. Escalamiento (Internal Case): Generar a 3PL (Reason: Cambio de carrier con retorno o Cambiar status con retorno, según escenario).
Cierre en ZeCore permitidos (Resolution type): Resending product: NO lleva Submitteo. Dismissed: Si es caso duplicado. Client goes to Store.
# 1.16 Picking and packing error / Error de almacén
Falla humana al momento de generar una venta, reemplazo de producto, cambio de producto o de escaneo en el proceso de preparación. El cliente recibe un SKU distinto al comprado (ej. pidió un colchón matrimonial y recibió uno individual). La caja puede ser la correcta pero el contenido no, o viceversa. Requiere un proceso de logística inversa (recolección) y envío de reposición.
Escenario Front: Pide 3 fotos de la etiqueta de la caja recibida. Compara el SKU de la etiqueta vs la Sale Order. Levanta el caso con el proceso de "Defect warranty". Escenario Back: De acuerdo al caso levantado, gestiona el proceso "Defect warranty".
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. Escalamiento (Internal Case): No aplica. Se gestiona directamente vía proceso de Defect warranty. Cierre en ZeCore permitidos (Resolution type): Dismissed: Si es caso duplicado. (Nota: Recuerda que este caso se gestiona vía Proceso 3 Defect warranty).
# 1.17 Shipping/delivery of double product / Envío doble
Error de sistema o duplicidad de carga donde el cliente recibe dos veces el mismo pedido. Representa una pérdida de inventario para la empresa. La definición se centra en la honestidad del cliente, la recuperación del activo y la posible gratificación por el reporte del error.
Escenario Front: Agradece al cliente la honestidad. Ofrece compensación autorizado por Team Leaders y/o Supervisores si el cliente acepta. Genera el caso para recuperación de la unidad extra.
Escenario Back: Genera guía de retorno de FedEx (3PL) o asigna recolección en ruta (Onfleet) por fuera, es decir fuera de un proceso Posventa mediante Internal Case al Area Internally Scaled a "3PL" con Internal Case Type "Solicitud de Guia-Retorno 3PL" o por Onfleet mediante apoyo de Team Leaders / Supervisores. Monitorea el reingreso a almacén. Posterior a generar el retorno de producto, se genera otro con la Reason de "Product compensation" por devolver el producto que se le entrego doble.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. Escalamiento (Internal Case): Generar a 3PL (Reason: Solicitud de Guia-Retorno 3PL). Generar a Onfleet (Reason: Entrega de doble producto). Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) como parte del proceso para dar la compensación ofrecida por la honestidad.
Dismissed: Si es caso duplicado. Client goes to Store.
# 1.18 Labeling error / Error de etiquetado
En esta incidencia se presenta discrepancia entre la etiqueta externa pegada en la caja y el producto contenido. A diferencia del proceso 1.16 Picking and packing error / Error de almacén, aquí el problema viene desde la identificación del producto en fábrica. El cliente se confunde al ver un nombre de SKU diferente en la caja, aunque el producto interior sea el correcto.
Escenario Front: Sondea al cliente, por poner un ejemplo "¿La caja dice que es un colchón Queen pero al medirlo es King?". Si el producto interior es el correcto, cierra con contención.
Escenario Back: No aplica, ya que si el cliente desea un cambio, se tendra que hacer el proceso de "Satisfaction Warranty".
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. Escalamiento (Internal Case): No aplica. Se gestiona vía proceso de Satisfaction warranty si requiere cambio. Cierre en ZeCore permitidos (Resolution type): Dismissed: Si es caso duplicado. (Nota: Si requiere cambio, se hace vía proceso 4 Satisfaction Warranty).
# 1.19 Extended área / Zona extendida
Clasificación de códigos postales con baja densidad de entrega o difícil acceso geográfico. Las paqueterías 3PL no entregan diario en estas zonas, sino que acumulan carga para ir una vez por semana o cada quincena. El objetivo es informar al cliente que su tiempo de espera es mayor por su ubicación geográfica, no por un retraso operativo.
Cuando sí tienen cobertura pero lo consideran de difícil acceso, y por la misma situación, esperan a que tener varios paquetes para esa localidad o zona y así proceder con las entregas. El tiempo que puede estar un envio de zona extendida es de 7 hasta 15 días hábiles.
Esto se puede revisar desde la frecuencia de entrega de la paquetería en Estafeta y FedEx:
https://www.estafeta.com/frecuencia-de-entregas?frecuencia=true
https://www.fedex.com/es-mx/shipping-tools.html
Escenario Front: Valida el código postal en los links de FedEx/Estafeta. Informa al cliente que su entrega es "Frecuencia Semanal" (ej. solo jueves).
Escenario Back: Solo interviene si la paquetería local de la zona extendida reporta problemas de acceso o seguridad o la orden tiene mas de 15 días hábiles en transito.
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. No se considera retraso de entrega hasta que pasen 15 días hábiles en estas zonas. En caso de pasar este tiempo, se debe de seguir el proceso 1.01 Delivery delay / Demora en entrega. Escalamiento (Internal Case): No aplica.
Cierre en ZeCore permitidos (Resolution type):
Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar devolución. Resending product: Aplica Submitteo (Posventa) solo como excepción autorizada por Team Leaders o Supervisión. Client collects at location / Order delivered / Client goes to Store. Dismissed: Si es caso duplicado.
# 1.20 Rescheduling for late payment / Reasignación por pago tardío
Es Incidencia administrativa. La orden se "congeló" en estatus In Payment porque el pago no fue validado a tiempo para la ventana de entrega original. Una vez que Finanzas libera el pago, la orden queda en un estado de pausa (Rescheduled) esperando que el cliente elija una nueva fecha de entrega, ya que la original expiró.
Escenario Front: Si la orden dice se libera de Re-scheduled con la razon "Overdue In Payment", se reagenda orden, pide al cliente elegir una fecha disponible en el calendario actual. No se genera caso.
Escenario Back: Si se genera caso por otros medios, si el pago ya fue validado pero el sistema no liberó la orden, escala a Pagos para seguir el proceso en "Payments".
Reglas de Negocio:
Validar que no exista un caso duplicado bajo el mismo concepto. No se puede asignar fecha de entrega si el estatus sigue siendo In Payment. Escalamiento (Internal Case): No aplica (Se escala con pagos, no mediante Internal Case de Logística). Cierre en ZeCore permitidos (Resolution type):
- Product compensation / Economic containment: Aplica Submitteo (Posventa) si se ofrece para evitar devolución.
- Dismissed: Si es caso duplicado.
- Client goes to Store.
Escalamiento y Excepciones
¿Existen Excepciones de devolución?
Si, se tiene que analizar el motivo (del motivo depende que se haga una excepción). Esto lo autorizan los Team Leaders / Supervisores
Scriptsbold text
Con el objetivo de homologar la comunicación y optimizar la resolución al primer contacto, proporcionando al equipo de FRONT herramientas de respuesta rápidas, empáticas y técnicamente precisas.
Les brindamos estos scripts como ejemplo y referencia sobre como se gestionan estos procesos de acuerdo a la solicitud del cliente.
# 1.01 Delivery delay / Demora en entrega
Antes de mandar esto, valida que realmente hayan pasado más de 7 días hábiles (lunes a viernes) desde que la paquetería lo recolectó. Si lleva menos tiempo, informa que aún está en tiempo estándar.
¡Hola! 👋 Entiendo tu preocupación. Veo que tu paquete tiene una demora inusual con la paquetería. En este momento estoy levantando un reporte interno para agilizar la entrega. Para completarlo, ¿me confirmas tu dirección con algunas referencias de tu domicilio (color de casa, entre calles) y un teléfono de contacto, por favor?
# 1.02 Failed delivery / Entrega fallida
Revisa si es Onfleet (puedes reagendar si está en Re-scheduled) o 3PL (si ya fueron 3 intentos, forzosamente va de regreso a almacén).
# 1.03 Unrecognized delivery / Entrega no reconocida
Este es un tema delicado (posible robo/extravío). Es OBLIGATORIO hacer el "Sondeo de Seguridad" antes de levantar el caso para descartar que lo tenga un vecino o el vigilante.
¡Hola! El sistema nos marca el paquete como entregado. Para abrir una investigación oficial de inmediato, ¿podrías apoyarme verificando rápido si algún vecino, familiar o tu caseta de vigilancia lo recibió por error? Si no es así, requeriré una foto de tu INE/Pasaporte vigente para iniciar el reporte por entrega no reconocida junto con tu dirección con algunas referencias de tu domicilio (color de casa, entre calles) y un teléfono de contacto.
# 1.04 3PL error / Error de 3PL
Úsalo solo cuando veas en el rastreo que la paquetería lo mandó a otra ciudad por error de ellos o dañaron la guía. Dale tranquilidad al cliente de que ya lo notaste.
¡Hola! Monitoreando tu envío detectamos que la paquetería tuvo un error interno de ruta y mandó el paquete a otra estación. Ya estamos en contacto con ellos para redirigirlo a tu ciudad a la brevedad. Te mantendremos informado del avance.
1.05 Out of stock / Falta de inventario
JAMÁS prometas una nueva fecha sin haber validado primero la disponibilidad en la plataforma o en el canal de "Activos/Inactivos".
¡Hola! Te pido una enorme disculpa. Tu producto ha tenido una alta demanda y nos quedamos sin disponibilidad inmediata para el envío por el momento. La nueva fecha de salida de almacén está programada para el 00/00/2000. ¿Te gustaría mantener tu orden con esta nueva fecha o prefieres que revisemos otras opciones?
# 1.06 Incorrect address on the way / Dirección incorrecta en tránsito
Sé claro con el cliente en que, como el paquete ya está en el camión de la paquetería, forzosamente tiene que regresar a nuestro almacén para cambiarle la etiqueta. Tomará más tiempo.
¡Hola! Claro, con gusto actualizamos tu dirección. Como tu pedido ya va en camino con la paquetería, por seguridad debemos solicitar que retorne a nuestro almacén para generarle una nueva guía con los datos correctos. Esto modificará tu fecha de entrega, ¿estás de acuerdo en que procedamos con el retorno?
# 1.07 Incorrect address in factory / Dirección incorrecta en fábrica
¡Actúa rápido! Si el estatus es Pending Driver o Wip Warehouse, levanta el caso urgente para detener la carga antes de que salga.
¡Hola! Qué bueno que nos avisas a tiempo. Como tu pedido aún se encuentra en nuestro almacén, en este momento detengo la salida para actualizar tu dirección correctamente. Esto nos ayuda a asegurar que llegue al destino correcto sin mayor contratiempo. En caso de que la orden no pueda salir, se dara seguimiento cuando la orden este en camino, generemos el retorno para poder actualizar la nueva dirección.
# 1.08 System error / Status not progressing / Error de sistema
Valida primero en el chat de "Validación de órdenes" que la orden no esté detenida por falta de pago o sospecha de fraude. Si todo está en orden y lleva >48h atorada, levanta el caso.
¡Hola! Revisando tu orden, veo que hay un pequeño retraso técnico en la actualización de nuestro sistema. Voy a levantar un reporte con el área de soporte para que liberen tu pedido manualmente lo antes posible y pueda seguir su curso.
# 1.09 Incomplete delivery / Entrega incompleta
Revisa en Shipping Core cuántos productos salieron realmente. A veces las bases, SKUS compuestos y los colchones viajan separados.
¡Hola! Tienes toda la razón. Revisando el detalle de tu orden, tus productos se enviaron en partes separadas por logística de almacén. Lo que te hace falta tiene fecha de salida para el día 00/00/2000, por lo que muy pronto tendrás tu pedido completo.
# 1.10 Early shipment / Entrega anticipada
Si la orden no ha salido, cámbiale la fecha tú mismo. Si ya está con la paquetería, pídele al cliente que rechace la entrega para que retorne y se pueda reagendar.
¡Hola! Una disculpa si la entrega se adelantó a tus planes. Como el paquete ya va en ruta, te pido de favor que si llega el repartidor rechaces la entrega. Así el paquete regresará a almacén y podremos reagendarlo sin problema para el día que originalmente necesitabas.
# 1.11 Delivery driver incident / Incidente con repartidor
Aplica principalmente para Onfleet (lluvias fuertes, choques, fallas de la camioneta). NO reagendes manualmente hasta que el sistema marque Re-scheduled.
¡Hola! Nuestro chofer de nuestra flotilla interna tuvo un incidente imprevisto en su ruta de hoy que le impide llegar a tu domicilio. Te pido una enorme disculpa por este contratiempo técnico; tu entrega se reprogramará a la brevedad y te notificaremos la nueva fecha.
1.12 Lost package / Paquete extraviado**
No puedes dar este diagnóstico ni ofrecer reenvío hasta que tengas la confirmación OFICIAL de logística de que el paquete se perdió.
¡Hola! Lamento mucho informarte que, tras la investigación, la paquetería nos ha confirmado el extravío de tu paquete en sus instalaciones. Ten la tranquilidad de que tu compra está 100% protegida; en este momento procesaremos una nueva orden para enviarte tus productos sin ningún costo para ti.
# 1.13 Damaged package/product / Producto o empaque dañado
Para proceder con la garantía (Defect Warranty), necesitas evidencias claras. Si solo está rayada la caja pero el producto viene al vacío, tranquiliza al cliente.
¡Hola! Lamento mucho que tu pedido llegara en esas condiciones. Para poder ayudarte de inmediato y aplicar tu garantía, ¿podrías enviarme 3 fotos claras: una de la caja completa, otra de las etiquetas de envío y otra del daño directo en el producto? Con esto levantamos el reporte enseguida.
# 1.14 Additional references / Referencias adicionales
Recuerda que esto NO es para cambiar la calle o el número (eso sería los procesos 1.06/1.07), es solo para agregar detalles de color de fachada, portón, etc.
¡Hola! Claro que sí, tomo nota de inmediato. Agrego estas referencias a tu orden para que los repartidores puedan ubicar tu domicilio mucho más rápido y sin complicaciones el día de tu entrega.
# 1.15 Carrier change / Cambio de paquetería
Solo puedes hacerlo si la orden no ha llegado a Wip Warehouse. Revisa la cobertura antes de confirmar que sí podemos enviarlo por la paquetería que pide!
¡Hola! Entiendo tu solicitud. Sí es posible solicitar el cambio de paquetería para tu entrega. Ya validé la cobertura para tu zona y he realizado la actualización en el sistema para que se envíe por [Onfleet / FedEx / Estafeta].
# 1.16 Picking and packing error / Error de almacén
Pide fotos de la etiqueta que viene pegada en la caja para comprobar que no coincide con el SKU de la Sale Order.
¡Hola! Una enorme disculpa por esta confusión desde nuestro almacén. Efectivamente, si te enviamos un modelo distinto. Por favor, envíame 3 fotos de las etiquetas de la caja que recibiste para gestionar de inmediato la recolección y enviarte el artículo correcto.
1.17 Shipping/delivery of double product / Envío doble
Empatía y agradecimiento ante todo. Asegúrate de tener autorización de tu Team Leader / Supervisor antes de ofrecer la compensación.
¡Hola! Te agradecemos muchísimo tu honestidad al reportarnos este envío duplicado. Valoramos mucho tu confianza. Vamos a generar una guía para que deje el producto en una paquetería sin costo para la unidad extra y, como muestra de nuestro agradecimiento, queremos ofrecerte [mencionar compensación autorizada].
1.18 Labeling error / Error de etiquetado
Pídele al cliente que abra la caja y revise el producto real antes de generar un caso.
¡Hola! No te preocupes, a veces por temas de fábrica las cajas traen un nombre distinto en el exterior. ¿Podrías apoyarme abriendo el empaque y verificando el producto en su interior? Si efectivamente es el modelo incorrecto, te lo cambiamos sin ningún problema.
# 1.19 Extended area / Zona extendida
Si el CP aparece como zona extendida en los links de las paqueterías, NO es una demora (a menos que pasen más de 15 días). Explícale cómo funciona la ruta.
¡Hola! Revisando tu código postal, veo que pertenece a una zona catalogada como de "frecuencia semanal" por la paquetería, por lo que acumulan entregas para ir a tu área. El tiempo de tránsito ahí es de 7 a 15 días hábiles, por lo que tu paquete va en tiempo y forma hacia su destino.
# 1.20 Rescheduling for late payment / Reasignación por pago tardío
Nunca intentes agendar una fecha si la orden sigue en estatus In Payment. Solo cuando ya esté liberada y diga Re-scheduled.
¡Hola! Te confirmo que tu pago ya fue validado exitosamente. Como la validación tomó un poco más de tiempo, la fecha original que elegiste expiró en el sistema. Pero no te preocupes, aquí mismo podemos agendar una nueva. ¿Qué día de la próxima semana tienes disponibilidad?