El proceso de Customer Request es un tipo de interacción proactiva donde el cliente contacta al equipo de Customer Service para pedir un servicio, realizar una consulta o solicitar una gestión administrativa específica.

A diferencia de una incidencia (donde algo ha fallado o el servicio se ha interrumpido), la solicitud representa una necesidad estándar del cliente que busca alcanzar un objetivo concreto o especifico dentro del flujo del negocio.

Algunos ejemplos son:

Gestión Logística:

• Change of date on the way / Cambio de fecha en camino
• Change of address on the way /Cambio de dirección en camino
• Shipping inquiry / Consulta envío

Comercial y Ventas:

• Accessory sale / Venta de accesorios
• Warranty registration / Registro de garantía
• Payment inquiry / Consulta pago

Información y Estado:

• Order inquiry / Consulta de orden
• General inquiry / Consulta general

# Administración de Datos:

• Data update / Actualización de datos
• Unsubscribe from promotional emails / Darse de baja de correos promocionales

Procesos y reglas de negocio:

2.01 Change of date on the way / Cambio de fecha en camino

Pendiente de revisar con Liliana: 1.06 Incorrect address on the way / Dirección incorrecta en tránsito y 1.07 Incorrect address in factory / Dirección incorrecta en fábrica. Van a la misma resolución.

Misma situación con la razón llamada Change of date in factory.

2.02 Change of address on the way / Cambio de dirección en camino

Pendiente de revisar con Liliana: 1.06 Incorrect address on the way / Dirección incorrecta en tránsito y 1.07 Incorrect address in factory / Dirección incorrecta en fábrica. Van a la misma resolución.

Misma situación con la razón llamada Change of address in factory.

# 2.03 Shipping inquiry / Consulta envío

Este motivo se selecciona cuando el cliente solicita información sobre el estatus de su pedido, ya sea su liberación, tránsito o fecha estimada de entrega. Su objetivo es proporcionar visibilidad completa sobre el envío y un seguimiento detallado.

Escenario Front: El cliente se comunica solicitando saber cuándo se entrega su producto. Cuando la entrega es por Onfleet, desde el Shipping Core en el apartado llamado Delivery Date, se brinda el día de la entrega de su producto. Si la entrega es por 3PL, se brinda la fecha de salida de su producto.

Escenario Back: En caso de que el caso se genere, se deberá brindar la información correspondiente, ya sea de la orden de entrega por paquetería 3PL u Onfleet.

Reglas de Negocio:

• Validar que no exista un caso duplicado bajo el mismo concepto.
• Si se requiere mover la orden y esta tiene el estatus "Pending Driver", "Wip Warehouse" o "Delivery to Carrier", se deberá gestionar mediante el proceso 1.06 o 1.07 de Logistics Issue.

Escalamiento (Internal Case):

No aplica.

Cierre en ZeCore permitidos (Resolution type):

• Sending requested information
• Successful survey
• Client goes to Store
• Dismissed (Solo si el caso está duplicado)

# 2.04 Accessory sale / Venta de accesorios

Esta razón se utiliza cuando un cliente requiere saber si algunos de los productos de las marcas Zebrands se pueden vender por separado (ejemplo: fundas de colchón, piezas de bases eléctricas cuando el producto se daña, controles de bases eléctricas, etc.). Por el momento (marzo de 2026), estas piezas no se venden por separado.

Escenario Front: Se brinda información al cliente de que, por el momento, en nuestras marcas no se realiza venta de productos parciales.

Escenario Back: Si se genera un caso, se brinda la información correspondiente a la solicitud del cliente, dependiendo de qué tipo de pieza o accesorio requiera comprar o reponer.

Reglas de Negocio:

• Validar que no exista un caso duplicado bajo el mismo concepto.
• Escalamiento (Internal Case):
• No aplica.

Cierre en ZeCore permitidos (Resolution type):

• Sending requested information
• Client goes to Store
• Dismissed (Solo si el caso está duplicado)

2.05 Warranty registration / Registro de garantía

Esta razón se utiliza para formalizar el registro de garantías de órdenes B2B en ZeCore. A diferencia del canal D2C, donde el registro es automático, las ventas B2B requieren una carga manual con el fin de centralizar la información y generar métricas precisas sobre el volumen de solicitudes recibidas por este concepto.

Escenario Front: Transfiere el chat al equipo Marketplace.

Escenario Back: N/A.

Equipo Marketplace: Pide ticket o comprobante de compra con datos generales (nombre, teléfono y correo) para generar el registro mediante un caso.

Reglas de Negocio:

• Validar que no exista un caso duplicado bajo el mismo concepto.
• El ticket o comprobante debe ser legible, sin alteraciones ni manipulaciones.
• Escalamiento (Internal Case):
• No aplica.

Cierre en ZeCore permitidos (Resolution type):

Warranty registered Dismissed (Solo si el caso está duplicado)

2.06 Payment inquiry / Consulta pago

Esta razón se utiliza para validar el estatus de la orden referente a un pago asociado. Es decir, en órdenes recién creadas, sirve para validar si el pago se reflejó con éxito y la orden está liberada, o para revisar si, por cuestiones de temporalidad, la orden está tardando en liberarse tras el pago.

Escenario Front: Analiza si la orden creada está liberada. Si lo está, se da la información de entrega; si no, o si tarda más de 24 horas en liberarse, se levanta un caso.

Escenario Back: De acuerdo con el caso generado, se valida en el canal de Google Chat "Validación de órdenes" el estatus del pago, para que la orden cambie de estatus y pueda ser liberada.

Reglas de Negocio:

• Validar que no exista un caso duplicado bajo el mismo concepto.
• En caso, de que la orden por el área de pagos mencione que tiene un error al liberarse, se debera seguir proceso 7 de Payments.
• Escalamiento (Internal Case):
• No aplica.

Cierre en ZeCore permitidos (Resolution type):

Sending requested information Dismissed (Solo si el caso está duplicado)

# 2.07 Order inquiry / Consulta de orden

Esta razón se genera cuando el cliente pide información sobre si la orden fue diferida a MSI, o solicita el estatus general de la misma (es decir, cómo se encuentra en el momento en que se comunica el cliente).

Escenario Front: El cliente se comunica solicitando saber cuándo se entrega su producto o si su orden fue liberada. Cuando la entrega es por Onfleet, desde el Shipping Core en el apartado llamado Delivery Date, se brinda el día de entrega. Si la entrega es por 3PL, se brinda la fecha de salida.

Escenario Back: En caso de que se genere el caso, se deberá brindar la información correspondiente, ya sea de la orden de entrega por paquetería 3PL u Onfleet.

Reglas de Negocio:

Validar que no exista un caso duplicado bajo el mismo concepto.

Si se requiere mover la orden y esta tiene el estatus "Pending Driver", "Wip Warehouse" o "Delivery to Carrier", se deberá gestionar mediante el proceso 1.06 o 1.07 de Logistics Issue.

Escalamiento (Internal Case):

No aplica.

Cierre en ZeCore permitidos (Resolution type):

Sending requested information. Dismissed (Solo si el caso está duplicado).

# 2.08 General inquiry / Consulta general

Esta razón existe cuando el cliente requiere conocer las características, garantías o materiales de los que está hecha su orden pendiente de entregar o ya entregada. Esta razón tiene fines informativos únicamente.

Escenario Front: El cliente se comunica y el agente responde las dudas referentes a las características de su producto. No se genera caso desde este segmento.

Escenario Back: En caso de generarse un caso desde Showroom o Telesales, se le comunica al cliente la respuesta a su duda sobre las características del producto o productos adquiridos.

Reglas de Negocio:

• Validar que no exista un caso duplicado bajo el mismo concepto.
• Escalamiento (Internal Case):

No aplica.

Cierre en ZeCore permitidos (Resolution type):

Sending requested information. Dismissed (Solo si el caso está duplicado).

# 2.09 Data update / Actualización de datos

Esta razón consiste en actualizar algún dato de la información o perfil del cliente (Lead), generado desde las plataformas oficiales de Zebrands.

Escenario Front: El cliente se comunica y requiere modificar su teléfono de contacto. El agente, desde el Shipping Core en el apartado Address, puede hacer la modificación al momento siempre y cuando el producto que aún no se entrega tenga el estatus "Pending Delivery Task", "Future Delivery" o "Pending Shipping", o incluso si ya fue entregado y la orden está en "Delivered".

Escenario Back: En caso de generarse un caso para modificar el teléfono de contacto, pero los productos a entregar de la orden tienen estatus de "Wip Warehouse", "Pending Driver" o "Delivered To Carrier", se retipifica el caso como "Logistics issue - Proceso 1.14 Additional references / Referencias adicionales", para que se considere el número de contacto actualizado si la entrega es con carrier 3PL. Si el carrier es Onfleet, se notifica al canal de Google Chat "Órdenes urgentes Log Onfleet/Customer Service", para que el encargado de logística de Onfleet notifique al repartidor cuando la orden esté en camino.

Reglas de Negocio:

Validar que no exista un caso duplicado bajo el mismo concepto.

Por ningún motivo se pueden generar cambios de nombre o correo electrónico del Lead generado, por cuestiones de seguridad y restricciones del sistema.

Escalamiento (Internal Case): No aplica.

• Cierre en ZeCore permitidos (Resolution type):

Applying requested change. Dismissed (Solo si el caso está duplicado).

# 2.10 Unsubscribe from promotional emails / Darse de baja de correos promocionales

Esta razón se gestiona cuando el cliente pide la baja de las notificaciones que le llegan por correo, ya sean promocionales o correos de seguimiento de casos u órdenes. Para solicitar la baja de correos, se debe ingresar en el siguiente enlace. El tiempo en el que se realiza este proceso es de 24 a 72 horas. De igual manera, se notifica el llenado de la solicitud en el canal de Google Chat llamado "Baja de correos".

Escenario Front: El agente puede hacer la baja de manera directa; no se genera caso para Back.

Escenario Back: En caso de caer un caso desde Showroom o TeleSales, se realiza el llenado desde el enlace de baja, se hace la notificación en el canal correspondiente y se le notifica al cliente sobre esta solicitud.

Reglas de Negocio:

Validar que no exista un caso duplicado bajo el mismo concepto.

• Escalamiento (Internal Case):
• No aplica.

Cierre en ZeCore permitidos (Resolution type):

Unsubscribed email. Dismissed (Solo si el caso está duplicado).