Console Manuales de la consola de administración web (CMS, Marketing, Kiosk, Empleados). Primeros pasos Entrar, tu perfil, orientarte y por qué ves lo que ves. Entrar en la consola Dirigido a: cualquiera que use la consola por primera vez. Entrar Entras con tu identificador de empleado —el mismo que usa tu empresa para ti, no un correo electrónico— y tu contraseña. Si todavía no tienes contraseña, no puedes crearla tú. Te la establece alguien con permisos de gestión de empleados; indícale Empleados - Contraseña. Dos cosas que la consola puede decirte al entrar Tu cuenta tiene fecha de caducidad. Las cuentas de empleado caducan y, según se acerca la fecha, se te indica cuántos días quedan. Es un aviso, no un error: puedes seguir trabajando. Pide que la amplíen antes de que se agote, porque una vez caducada ya no puedes entrar ni para pedirlo. Tu contraseña puede aparecer marcada como débil. Si no cumple las reglas de robustez se te avisa, y conviene cambiarla — ver Tu perfil y tu contraseña. Ninguno de los dos mensajes te bloquea. Los dos conviene atenderlos el día que aparecen y no el día que se convierten en un problema. Si no puedes entrar Repasa esto en orden: Comprobación Qué hacer ¿El identificador es el correcto? Es tu identificador de empleado, no un correo ¿Tienes contraseña? Un empleado nuevo no tiene ninguna hasta que alguien se la pone ¿Ha caducado tu cuenta? Pide que la amplíen: esto no puedes hacerlo tú ¿Cliente o entorno correcto? La consola es por cliente; confirma que estás en la dirección adecuada Si los cuatro están bien y sigue fallando, pide a quien gestione empleados que confirme que tu ficha existe y está activa — ver Localizar a un empleado. Cuando ya has entrado Pon una contraseña que vayas a conservar si te la asignaron — Tu perfil y tu contraseña. Oriéntate — Moverte por la consola. Entiende por qué ves lo que ves — Qué puedes ver, y por qué. Tu perfil y tu contraseña Necesitas: nada más allá de haber entrado. Tu perfil es tu propia ficha. Qué muestra tu perfil Tus datos tal como constan en tu ficha de empleado: tu identificador, tu nombre y los datos de contacto —correo, teléfono, ciudad, dirección y fecha de nacimiento— que estén rellenos. Es una vista de tu ficha: la misma que ve un gestor de empleados en el área de Empleados, desde tu lado. Si algo aquí está mal, normalmente no puedes corregirlo tú. Pídeselo a quien gestione empleados — ver Editar un empleado. Cambiar tu contraseña Puedes cambiar tu contraseña cuando quieras, y deberías hacerlo si te la asignó otra persona. Las reglas son más estrechas que en la mayoría de sistemas, así que léelas antes de elegir: Regla Valor Longitud mínima 8 caracteres Longitud máxima 10 caracteres Debe contener Al menos una letra mayúscula El máximo es lo que pilla a todo el mundo. Una frase larga será rechazada: necesitas algo de entre 8 y 10 caracteres con al menos una mayúscula. Dentro de eso, prioriza algo impredecible sobre algo memorable pero adivinable, y no reutilices una contraseña de otro sitio. Si te dicen que tu contraseña es débil La consola marca al entrar una contraseña que no cumple las reglas. Ese aviso no te bloquea, así que es fácil ignorarlo durante meses. Cámbiala cuando lo veas. Es un minuto y ya tienes la pantalla abierta. Si la has olvidado No hay restablecimiento automático. Alguien con permisos de gestión de empleados te pone una nueva — ver Empleados - Contraseña. No puede decirte la anterior; solo puede sustituirla. Páginas relacionadas Entrar en la consola — primer acceso y qué significan los avisos Qué puedes ver, y por qué — tus roles y tu scope Empleados - Contraseña — para quien la va a establecer Moverte por la consola Dirigido a: quien se orienta en la consola por primera vez. Las áreas La consola se organiza por lo que haces, no por qué equipo lo gestiona. Área Qué haces ahí Capítulo Hub Operar pedidos en vivo: asignar, cancelar, registrar incidencias El Hub: qué es y quién puede hacer qué Reparto Configurar cómo se asignan los pedidos: zonas, transportistas, tiendas, dispatcher Qué hace el dispatcher Marketing Emitir promociones, vouchers, suscripciones, saldo de monedero Marketing: las cinco áreas CMS Mantener el contenido que ve el cliente y el árbol de reclamaciones CMS: qué cubre Informes Leer datos de rendimiento Informes y Métricas: cuál usar Métricas Investigar un pedido concreto Logs y líneas temporales de pedidos Empleados Mantener fichas de personal y repartidores Empleados: qué cubre esta área Roles Decidir quién puede hacer y ver qué Roles y scope: las dos ideas No verás todas. El menú refleja lo que permiten tus roles — ver Qué puedes ver, y por qué. Marcas Si tu empresa opera más de una marca, casi todas las pantallas trabajan con una marca cada vez y ofrecen un selector. Con una sola marca, el selector normalmente no aparece. Esto importa más de lo que parece: Los datos son por marca. Un informe, un listado de empleados, una promoción: todo delimitado a la marca en la que estás. Cambiar de marca cambia lo que estás editando. Crear una promoción en la marca equivocada es fácil y no siempre evidente después. Comprueba el selector antes de crear o cambiar nada. En vivo frente a histórico Una distinción que se repite en toda la consola, y elegir mal es lo que más tiempo hace perder: Quieres… Ve a Actuar sobre algo que está pasando Hub Entender algo que ya pasó Métricas Ver cómo fue un periodo Informes Cambiar cómo se comportará Reparto, Marketing, CMS Idioma La consola está disponible en más de un idioma, y la documentación existe en paralelo: cada página tiene su gemela en el otro idioma. Ten en cuenta que el idioma del contenido es distinto del idioma de la interfaz. Los banners y documentos se guardan por idioma y hay que rellenar cada uno — ver Recursos y fuentes. Dos páginas que conviene guardar Glosario — qué significan aquí marca, fuente, scope, hub y fecha de negocio. Preguntas frecuentes — las dudas que aparecen en todas las áreas. Cuando una pantalla no está Un área que falta en tu menú es casi siempre un permiso, no un fallo. Qué puedes ver, y por qué explica cómo distinguirlo y quién puede cambiarlo. Qué puedes ver, y por qué Dirigido a: quien se pregunta por qué su consola se ve distinta a la de un compañero. Dos cosas distintas deciden lo que obtienes. Casi todas las preguntas del tipo "¿por qué no puedo…?" son una de las dos. Decide Lo fija Tus roles Qué puedes hacer Quien gestione empleados Tu scope Qué datos puedes ver La misma persona, por separado Son independientes. Puedes tener permisos completos sobre una porción estrecha de datos, o solo lectura sobre todo. Por qué falta una opción del menú Porque tus roles no incluyen esa área. La consola muestra aquello sobre lo que puedes actuar; no lista cosas para luego negarlas. Si necesitas un área, pide el rol que la cubre — el catálogo está en Catálogo de roles, y la mayoría de puestos reales son dos roles combinados y no uno perfecto. Por qué ves menos filas que un compañero Porque tu scope es más estrecho. El scope filtra cada pantalla a las marcas, tiendas y fuentes que tienes permitidas. Es el comportamiento esperado, y los dos estáis viendo la respuesta correcta para vosotros. El informe de un responsable de tienda debe diferir del de un responsable regional. Es el "el informe está mal" más reportado, y normalmente no lo está. Ver Cómo funciona el scope en la práctica. Por qué puedes hacer algo en un sitio y no en otro Porque los permisos son granulares. Poder ver pedidos en el Hub no implica poder cancelar uno; son permisos distintos, a propósito, para que las acciones críticas se concedan a menos gente. Acceso por sección es la rejilla completa de quién llega a qué. Conseguir un cambio Si necesitas Pide Un área completa que no tienes Un rol — Catálogo de roles Una capacidad concreta Una excepción individual — Excepciones individuales de permisos Ver más datos Un scope más amplio — Configurar el scope de un empleado Quien gestione empleados puede hacer las tres. Una definición de rol totalmente nueva es más rara y pasa por una solicitud — ver Solicitar un rol nuevo o modificado. Antes de preguntar Comprueba si es scope o permiso: ¿ves la pantalla pero no los datos, o no ves la pantalla? Lo primero es scope, lo segundo es un rol. Decir cuál de los dos ahorra una ida y vuelta. Reparto y Dispatcher Cómo decide la asignación automática qué repartidor o transportista entrega cada pedido, y cómo configurarlo. Qué hace el dispatcher Dirigido a: responsables de operaciones y de reparto que configuran, supervisan o explican a su equipo la asignación automática de pedidos. Objetivo: entender qué hace el dispatcher y por qué toma una decisión concreta. El Dispatcher es el sistema que decide automáticamente qué repartidor (o transportista externo) entrega cada pedido, y cuándo. Funciona solo, con la periodicidad que tú defines, y reevalúa los pedidos pendientes de cada tienda en cada ejecución. Estas páginas explican la lógica de esas decisiones en términos de negocio: qué optimiza el algoritmo, qué determina la prioridad, qué opciones de configuración tienes y qué esperar —o no esperar— de él. Cómo leer este capítulo No hace falta leerlo de principio a fin. Casi todas las dudas se resuelven en una sola página: Si quieres saber… Ve a Qué significa un término Glosario del dispatcher Qué ocurre en cada ejecución El ciclo de asignación, paso a paso Por qué un pedido se quedó con un transportista externo Revisión de pedidos ya asignados a un transportista Por qué se eligió a un repartidor y no a otro Clasificación y prioridad de repartidores Por qué un pedido cambió de repartidor Cuándo un pedido cambia de repartidor Por qué un pedido se quedó sin asignar Last-Option: la red de seguridad final y las Preguntas frecuentes del dispatcher Cada cuánto se ejecuta, y cómo arrancarlo o pararlo Planes de programación: cómo funciona el ciclo automático Dónde se cambia un ajuste concreto Dónde vive cada ajuste Todo el flujo en una sola página Visión de principio a fin Una regla, sin la explicación Reglas de referencia rápida Cómo reportar algo que parece incorrecto Reportar una incidencia del dispatcher Una vez que el dispatcher ha tomado sus decisiones, el tablero en vivo donde una persona puede intervenir es el Hub — ver El Hub: qué es y quién puede hacer qué. Lo que no hace El dispatcher está acotado a propósito. No intenta encontrar un plan matemáticamente perfecto para todos los repartidores y todos los pedidos a la vez, nunca toca un pedido que ya ha salido de la tienda, y no reordena el trabajo solo porque un pedido sea más urgente que otro. Esos límites están listados en Límites conocidos del sistema: son decisiones de diseño, no fallos, y conocerlos ahorra mucho tiempo de conjeturas. Glosario del dispatcher Estos términos se usan de forma consistente en todo el capítulo de Reparto y Dispatcher. Término Significado Flota propia / Repartidores propios El personal de reparto de tu propio negocio: repartidores y, en algunos casos, personal de cocina que también reparte Transportista externo Un proveedor de reparto externo (por ejemplo una plataforma de mensajería) que se usa cuando tu flota propia no es la mejor opción Clientes prioritarios (Platinum) Función opcional que da a ciertos pedidos —normalmente de clientes de fidelización o VIP— más posibilidades de entregarse a tiempo, sin perjudicar injustamente a los pedidos normales Modo PG Método de asignación por orden de llegada (FIFO): los pedidos se asignan al mejor repartidor disponible en el orden en que entraron Google OR-Tools Motor avanzado de optimización de rutas, que se usa normalmente cuando hay más pedidos pendientes que repartidores disponibles, para planificar rutas más eficientes Last-Option Red de seguridad final, dentro del mismo ciclo, para pedidos que el proceso normal no ha podido colocar — ver Last-Option: la red de seguridad final Idle (libre) Repartidor sin ningún pedido asignado Waiting (esperando) Repartidor con pedidos asignados que todavía no ha salido de la tienda On The Way (en ruta) Repartidor que ya ha salido de la tienda para entregar al menos un pedido Zona de tienda Estar a unos 350 metros de la tienda: lo bastante cerca como para considerarse "en la tienda" a efectos de asignación Tiempo hasta la tienda Tiempo estimado para que un repartidor vuelva a la tienda Tiempo hasta la entrega Tiempo estimado para que un repartidor complete una entrega Ciclo de asignación / Ejecución Una ejecución completa del algoritmo sobre todas tus tiendas, lanzada automáticamente según la programación que definas Agrupación (clubbing) Agrupar más de un pedido en el mismo repartidor o transportista para un solo viaje Crítico Pedido todavía sin asignar que ya ha superado su hora prometida de entrega Pendiente Pedido todavía sin asignar que aún no va tarde El ciclo de asignación, paso a paso Cada vez que el dispatcher se ejecuta, procesa cada tienda de forma independiente, siguiendo cinco pasos en orden. Los cinco pasos # Paso Qué ocurre 1 Obtener datos Recoge los pedidos actuales, los repartidores disponibles y la configuración de tienda y de zonas. Aquí también se revisa cualquier pedido que siga con un transportista externo de un ciclo anterior — ver Revisión de pedidos ya asignados a un transportista. 2 Comprobación de caché Si nada ha cambiado desde la última ejecución, la tienda se omite en lugar de reprocesarse, para ahorrar tiempo y recursos. 3 Asignar pedidos El paso donde se toman las decisiones, explicado en Los tres mecanismos de asignación. Aquí confluyen la lógica de transportistas externos, la de flota propia y —opcionalmente— la de clientes prioritarios. 4 Posprocesado Se clasifican los resultados (asignaciones nuevas, pedidos aún pendientes, pedidos enviados a transportista externo, etc.), se identifican los pedidos agrupables en un mismo repartidor y todo lo que siga sin asignar recibe un último intento más flexible —ver Last-Option: la red de seguridad final— antes de marcarse como Pendiente o Crítico. 5 Guardar y notificar Se guardan las asignaciones finales, se avisa a los repartidores por notificación push y se procesan las alarmas correspondientes. El paso 2 es la razón de que una ejecución termine casi al instante para una tienda tranquila. Que una tienda se omita no es un error y no se pierde nada: el siguiente ciclo la recoge en cuanto algo cambie. Qué significa "de forma independiente, por tienda" Cada tienda se resuelve por su cuenta. Una falta de repartidores en una tienda nunca trae repartidores de otra, y una tienda cuyos datos no han cambiado se omite sin afectar al resto. Por eso, al reportar un problema del dispatcher, siempre hay que indicar la tienda — ver Reportar una incidencia del dispatcher. Dónde está el detalle Los pasos 1 y 3 concentran casi toda la toma de decisiones, y cada uno tiene su propia página: La revisión de pedidos que ya están con un transportista, del paso 1 → Revisión de pedidos ya asignados a un transportista La comprobación de si existe realmente un sustituto → ¿Cuándo existe una alternativa? La lógica de asignación del paso 3 → Los tres mecanismos de asignación El último intento del paso 4 → Last-Option: la red de seguridad final Revisión de pedidos ya asignados a un transportista Antes de evaluar cualquier asignación nueva, el dispatcher revisa todos los pedidos que ya están con un transportista externo de un ciclo anterior, es decir, aquellos que un transportista tiene adjudicados pero con los que todavía no ha salido de la tienda. Esto ocurre en el paso 1 de El ciclo de asignación, paso a paso, para cada tienda y en cada ciclo. Nunca afecta a pedidos nuevos ni a pedidos ya asignados a tu flota propia. Las tres preguntas, en orden Para cada pedido en manos de un transportista se hacen hasta tres preguntas. La primera que resuelve el pedido detiene la secuencia. 1. ¿El transportista lleva demasiado tiempo con este pedido? Lo rige Tiempo máximo para aceptar (configurado por tienda y por transportista — ver Dónde vive cada ajuste). Límite superado y existe una alternativa real ahora mismo → el pedido se cancela con el transportista de inmediato y queda libre para reasignarse en este mismo ciclo. Límite superado pero no existe alternativa → el pedido se deja exactamente como está. Cancelarlo solo lo dejaría peor, sin ningún sitio mejor al que enviarlo. Límite no alcanzado → se pasa a la pregunta 2. 2. ¿La propia estimación del transportista para llegar a la tienda se está desviando demasiado? Lo rige Tiempo máximo para llegar a la tienda (por tienda y por transportista). Si la hora estimada de llegada del transportista a la tienda se ha desviado más allá de este límite, el pedido se cancela de inmediato, exista o no una alternativa. Una estimación poco fiable del propio transportista es motivo suficiente para desistir. 3. ¿Seguimos dentro de la ventana de cancelación gratuita y nuestra flota propia tiene hueco? Lo rige Ventana de cancelación gratuita (por transportista, para toda la empresa). Si la respuesta a ambas es sí, el pedido se marca como sin asignar, pero solo en la memoria de trabajo del dispatcher. No se guarda nada y no se cancela nada con el transportista todavía. El pedido simplemente vuelve a entrar en el proceso normal de asignación de esa tienda, igual que cualquier otro pedido sin asignar de ese ciclo. No es una rutina especial de "probar con flota propia". A partir de aquí el dispatcher no tiene ninguna noción de que ese pedido estuviera con un transportista: pasa por Modo PG, Google OR-Tools y transportistas externos como todo lo demás, con las mismas reglas. Si el proceso normal le asigna un repartidor propio, ocurren dos cosas en orden estricto: Se envía una cancelación real al transportista externo original. Solo si esa cancelación tiene éxito, se guarda la nueva asignación al repartidor interno. Si la cancelación falla, el paso 2 no llega a ocurrir: no cambia nada y el pedido sigue con el transportista. Así se evita un estado confuso en el que un mismo pedido parece asignado en dos sitios a la vez. Si el proceso normal no lo coloca con ningún repartidor propio, se descarta la marca en memoria. El pedido vuelve a estar exactamente como estaba —válidamente asignado al transportista— como si nada hubiera pasado. En este caso nunca se envía ninguna cancelación. Las preguntas 1 y 2 se parecen pero comparan cosas distintas Es la principal fuente de confusión de esta página. Pregunta Qué compara realmente Consecuencia Tiempo máximo para aceptar Tiempo real transcurrido: ahora, frente al momento en que se entregó el pedido al transportista. Solo falla cuando ha pasado de verdad suficiente tiempo de reloj. Cancela, pero solo si existe una alternativa Tiempo máximo para llegar a la tienda La promesa del propio transportista: su estimación de llegada, frente al momento en que se le entregó el pedido. Nunca mira la hora actual. Puede fallar a los pocos segundos si su propia estimación ya es demasiado lejana. Cancela haya o no alternativas Ventana de cancelación gratuita El mismo tipo de comparación que Tiempo máximo para aceptar (ahora frente al momento de asignación), pero con otra consecuencia: superarla no cancela nada por sí misma. Solo abre la puerta al intento sin compromiso con la flota propia descrito arriba. Habilita el reintento sin riesgo Qué pasa si el intento con flota propia no sale bien El pedido se excluye deliberadamente de la pasada de respaldo a transportistas de ese mismo ciclo: no se vuelve a evaluar frente a transportistas en esta ejecución. Es intencionado. El pedido ya está válidamente asignado a un transportista, así que repetir la pasada de respaldo sería redundante en el mejor de los casos, y podría generar una segunda asignación en conflicto para un pedido que ya tiene una. El pedido continúa con su asignación existente hasta la siguiente comprobación relevante: un ciclo futuro, o un fallo real en el tiempo de entrega. Por qué esto importa Sin esta revisión, un pedido podría quedarse indefinidamente con un transportista lento o que no responde, o seguir ahí incluso después de que tu flota propia hubiera quedado libre para llevarlo antes. El intento con flota propia es deliberadamente libre de riesgo: si no cuaja, el pedido se queda exactamente como estaba, el transportista ni se entera, y nunca se cancela nada sin tener ya un sustituto confirmado. ¿Cuándo existe una alternativa? La primera pregunta de Revisión de pedidos ya asignados a un transportista solo cancela a un transportista lento si existe una alternativa real dispuesta a asumir el pedido. Esa comprobación tiene dos mitades independientes: si tu flota propia podría llevarlo, y si otro transportista externo podría llevarlo. Se diferencian mucho en profundidad. Basta con que una de las dos sea cierta. Flota propia: una sola comprobación Comprobación Qué verifica Dónde se configura Hueco de capacidad Al menos un repartidor de flota propia (interno o contratado) tiene sitio para un pedido más Máximo de pedidos por repartidor — ver Dónde vive cada ajuste Es a propósito una comprobación rápida y optimista. Solo pregunta "¿hay algún repartidor con un hueco libre?", no si ese repartidor está lo bastante cerca, está libre o puede realmente asumir este pedido. Existe únicamente para responder "¿merece la pena siquiera cancelar el pedido del transportista?". La evaluación real llega después, cuando el pedido vuelve al proceso normal de asignación. Transportistas externos: varias comprobaciones, y solo los que van por detrás Primero, una regla de alcance importante: aquí solo se miran los transportistas que van por detrás del actualmente asignado en el orden configurado para esa zona. Los transportistas anteriores de la lista nunca se consideran en este punto, aunque cumplieran todo. La búsqueda se detiene en el primero que pase todas las comprobaciones; no busca el "mejor". Para cada transportista candidato, por orden, debe cumplirse todo lo siguiente: Comprobación Qué verifica Activo y tipo de pedido compatible El interruptor principal del transportista está activo y aplica al tipo de pedido y canal de venta Compatibilidad de pago Los pedidos en efectivo no superan su límite de contra reembolso; los pedidos con tarjeta solo se le ofrecen si acepta tarjeta Restricciones de producto Ningún producto del pedido cae en una categoría excluida para ese transportista Capacidad en esta tienda Al transportista le queda hueco en su bolsa de capacidad compartida para esa tienda Distancia La distancia de la tienda al cliente está dentro del rango permitido del transportista Horario de operación La hora actual está dentro del horario configurado para ese transportista en esa tienda El primer candidato que pase las seis cuenta como "existe una alternativa", y la búsqueda se detiene ahí. Lo que deliberadamente no se comprueba aquí: la verificación normal de ventana de entrega se omite. En este punto el sistema solo confirma que un transportista podría asumir el pedido estructuralmente —activo, pago, productos, capacidad, distancia, horario—. Si podría entregarlo a tiempo se evalúa después, si llega a ofrecérsele el pedido. Todos estos ajustes viven en la configuración general o por tienda del transportista — ver Dónde vive cada ajuste. Los tres mecanismos de asignación Todo pedido se resuelve finalmente con uno —o una combinación— de tres mecanismos. Mecanismo Cuándo se usa Modo PG (FIFO) Tienes suficientes repartidores propios para cubrir los pedidos pendientes Google OR-Tools Hay más pedidos pendientes que repartidores propios, así que hace falta planificar rutas más eficientes Transportistas externos Tu red de reparto externa Cuál de los dos, Modo PG o Google OR-Tools, se usa en una tienda concreta se decide automáticamente a partir de la proporción entre pedidos pendientes y repartidores disponibles, salvo que fuerces un modo en el plan de programación. Ver Planes de programación: cómo funciona el ciclo automático. Cómo se combinan La configuración de la zona decide si el transportista externo tiene el primer intento o si solo actúa como red de seguridad. Todo lo demás funciona igual en ambos casos. Zona estándar — flota propia primero: Solver propio (Modo PG o Google OR-Tools). Reintento con repartidores libres en tienda que el solver no haya usado. Respaldo con transportista externo, como último recurso. Zona con transportista primero: Transportista externo, un intento. Si lo acepta, listo. Solver propio (Modo PG o Google OR-Tools). Reintento con repartidores libres. Sin más respaldo: el pedido ya tuvo su turno con transportista externo. La regla que mantiene el equilibrio Cada pedido recibe exactamente un intento con cada tipo de recurso —flota propia y transportista externo— por ciclo de asignación. La configuración de la zona solo decide cuál va primero, nunca cuántos intentos recibe un pedido: Tipo de zona Orden de intentos Intentos totales Estándar Flota propia → Transportista 2 Transportista primero Transportista → Flota propia 2 Siempre dos. Nunca tres, nunca uno. Antes de dejar el pedido para el siguiente ciclo Queda un intento más flexible dentro del mismo ciclo — ver Last-Option: la red de seguridad final. Si tras eso el pedido sigue sin asignar, la siguiente ejecución programada empieza completamente de cero, incluido un intento nuevo con transportista externo. Cuándo ocurre eso lo marca el plan de programación de la tienda. Last-Option: la red de seguridad final Después de que el solver propio y el intento con transportista externo hayan tenido cada uno su única oportunidad, algunos pedidos pueden seguir sin asignar. En lugar de dejarlos para el ciclo siguiente, el dispatcher hace un intento más —por tienda, al final del mismo ciclo— llamado Last-Option. Qué problema resuelve Last-Option solo mira los pedidos que siguen sin asignar tras el proceso normal. Su objetivo es simple: evitar dejar un pedido completamente sin asignar si existe alguna forma razonable de colocarlo, aunque eso implique ser más flexible que las reglas normales. Cómo se buscan los candidatos Los candidatos se obtienen de forma distinta según su procedencia, y Last-Option relaja algunas comprobaciones que el proceso normal sí aplica. Origen Cómo se elige el candidato Qué se relaja Flota propia (internos y contratados) El mejor repartidor disponible, por capacidad y por cuándo podría salir No se vuelve a comprobar la ventana de entrega habitual Transportistas externos Cualquier transportista ya probado y descartado antes en este mismo ciclo No se revisa el motivo original del descarte: solo si desde entonces ha liberado capacidad Se elige el candidato que pueda empezar la entrega antes. Orden de procesamiento Los pedidos se procesan de uno en uno, empezando por el más urgente, según la hora prometida de entrega. El estado de cliente prioritario (Platinum) no influye en qué pedido entra antes en Last-Option. Platinum solo afecta al orden de varios pedidos que ya están en la ruta del mismo repartidor. Paso a paso Se recogen los pedidos que siguen sin asignar tras el solver propio y el intento con transportista. Se ordenan por hora prometida, el más urgente primero. Para cada pedido, por turno, se reúnen candidatos: el mejor repartidor propio disponible —capacidad comprobada, ventana de entrega no revisada—; los transportistas descartados antes en este ciclo, reconsiderados solo si han liberado capacidad. Se elige el candidato que pueda empezar la entrega antes. Si no hay ninguno, el pedido se queda sin asignar y se marca como Crítico o Pendiente. Si ni siquiera Last-Option puede colocarlo El pedido se clasifica como Crítico (ya pasada su hora prometida) o Pendiente (aún no va tarde). La siguiente ejecución programada lo reintenta desde cero, incluido un intento nuevo con transportista externo. Contrapartida a tener en cuenta: como Last-Option relaja la comprobación normal de tiempo de entrega para los repartidores propios, un pedido colocado por esta vía puede acabar con una estimación de llegada algo más tardía de lo que permitiría la tolerancia normal. Es intencionado: mejor ponerlo en marcha con un pequeño retraso que dejarlo sin asignar. Clasificación y prioridad de repartidores Los repartidores se ordenan por tres factores: su estado actual, su tipo y lo cerca que están de la tienda. Por estado Estado Descripción Idle (libre) No tiene ningún pedido asignado; totalmente disponible Waiting (esperando) Tiene pedidos asignados, pero ninguno ha salido aún de la tienda On The Way (en ruta) Tiene al menos un pedido ya en reparto Por tipo Tipo Descripción Prioridad Repartidor interno Tu personal de reparto dedicado La más alta Personal de cocina que reparte Personal de cocina que también puede repartir cuando hace falta Media Contratado externo de flota propia Repartidor de flota propia contratado externamente Más baja Transportista externo Plataforma de reparto externa Según las reglas de zona y configuración Estado y ubicación combinados La "zona de tienda" son unos 350 metros alrededor de la tienda. Categoría Estado Ubicación Prioridad 1 Libre En la tienda La más alta 2 Libre Lejos de la tienda Alta 3 Esperando En la tienda Media 4 Esperando Lejos de la tienda Más baja 5 En ruta Repartiendo La más baja El razonamiento es directo: un repartidor libre que ya está en la tienda es la opción más rápida posible, así que siempre se prefiere. Un repartidor que ya está repartiendo es el último recurso, porque asignarle un pedido nuevo significa añadirlo a una ruta existente. Dónde importa realmente "en la tienda o lejos" Esta distinción no se usa solo para la tabla anterior. Cambia decisiones reales en varios sitios: Velocidad de asignación. Un repartidor libre en la tienda se asigna al instante, sin más comprobaciones. Uno libre pero lejos debe pasar antes una comprobación de tiempo de entrega. Prioridad de reasignación. Es uno de los factores principales al decidir si un pedido cambia de repartidor — ver Cuándo un pedido cambia de repartidor. Registro de llegada. Cuando se confirma que un repartidor está en la tienda en el momento de asignarle un pedido, se registra una marca de llegada en ese pedido. Alarmas de retraso en recogida. Esa misma determinación dispara la alarma que avisa de que un repartidor lleva demasiado tiempo en la tienda sin salir con un pedido listo. Detección de repartidor bloqueado. Un repartidor considerado "en la tienda" nunca se marca como bloqueado: estar en la tienda es un estado válido y esperado. Estado del repartidor en las pantallas operativas. Etiquetas como "En tienda", "En ruta" o "Fuera" salen de esta misma comprobación. Si el dispatcher se reejecuta o no. Si el estado "en tienda" de ningún repartidor ha cambiado desde la última ejecución —y todo lo demás sigue igual—, la tienda puede omitirse. Ver El ciclo de asignación, paso a paso. Cambio previsto, actualmente en pruebas internas. Hoy, determinar si un repartidor está "en la tienda" usa una distancia de conducción estimada comparada con el umbral de ~350 m, no una distancia en línea recta. Se va a sustituir por un cálculo en línea recta, porque una estimación de ruta puede ser imprecisa justo alrededor de una tienda. El cambio todavía no está activo en todas las cuentas; esta página se actualizará cuando se publique. Clientes prioritarios (Platinum) Esta página solo aplica si tu cuenta tiene activada la evaluación de clientes prioritarios (Platinum). No forma parte del flujo principal: funciona como una capa adicional por encima de él, solo en las tiendas donde esté activada y solo cuando haya pedidos Platinum que considerar. Qué hace Cuando está activada, el dispatcher ejecuta una doble simulación para cada tienda antes de decidir: Ejecución normal — los pedidos se procesan en su orden habitual. Ejecución Platinum primero — los pedidos Platinum pasan al principio de la cola y reciben algo más de flexibilidad en el tiempo de entrega. Se comparan ambos resultados y el dispatcher elige el que mejor protege a los pedidos Platinum sin perjudicar en exceso a los pedidos normales. Cómo se toma la decisión ¿Hay pedidos Platinum en riesgo en la ejecución normal? No → se usa la ejecución normal tal cual. La segunda simulación ni siquiera se lanza. Sí → se continúa. Se ejecuta la simulación Platinum primero. Se cuenta cuántos pedidos normales quedarían nuevamente perjudicados. Por debajo del umbral de impacto → se usa el resultado Platinum primero. Igual o por encima del umbral → se descarta y se usa el resultado normal. Un pedido Platinum se considera "en riesgo" si no se asignaría en absoluto, o si su entrega estimada quedaría fuera de una ventana aceptable de riesgo de reembolso. Qué puedes configurar Ajuste Qué controla Activar / desactivar Enciende o apaga toda la capa Minutos de margen Flexibilidad adicional de tiempo de entrega concedida específicamente a la simulación Platinum primero Umbral de impacto Número máximo de pedidos normales que pueden quedar nuevamente perjudicados antes de descartar el resultado Platinum primero Lo que deliberadamente no hace La protección Platinum funciona únicamente a través de la doble simulación anterior. No hay reequilibrado de rutas existentes para hacer sitio a un pedido Platinum: ese límite y los demás están listados en Límites conocidos del sistema. El estado Platinum tampoco interviene en la reasignación ordinaria (Cuándo un pedido cambia de repartidor) ni en el orden de la cola de Last-Option (Last-Option: la red de seguridad final). Si la capa no está activada, los pedidos Platinum se tratan exactamente igual que cualquier otro pedido. Cuándo un pedido cambia de repartidor Antes de cada intento de asignación, el dispatcher comprueba si un pedido ya asignado a un repartidor debería pasar a otro distinto, pero solo por prioridad del repartidor, nunca por lo urgente o importante que sea el pedido en sí. Cuándo se permite una reasignación Situación Resultado El pedido aún no tiene repartidor Se asigna libremente El repartidor asignado ya no está disponible Se asigna libremente Se vuelve a considerar al mismo repartidor No hace falta cambiar nada El nuevo repartidor tiene mejor prioridad Se reasigna El repartidor actual tiene prioridad igual o mejor Se mantiene La prioridad se define en Clasificación y prioridad de repartidores. Escenarios habituales Repartidor actual Repartidor candidato Resultado Externo Interno Se reasigna — mejor tipo Libre, en la tienda Libre, en la tienda Sin cambio — igual de buenos Libre, lejos de la tienda Libre, en la tienda Se reasigna — mejor ubicación Esperando, en la tienda Libre, lejos de la tienda Sin cambio — el actual sigue siendo mejor Externo, lejos de la tienda Externo, lejos de la tienda Sin cambio — no hay mejora real Pasar la comprobación de prioridad no garantiza la entrega Pasarla solo significa que el dispatcher intentará la asignación. Todavía tiene que verificar que el nuevo repartidor puede entregar a tiempo: Situación del repartidor ¿Se comprueba el tiempo de entrega? Libre, en la tienda No — siempre es la opción más rápida posible Libre, lejos de la tienda Sí Esperando (ya tiene pedidos) Sí — debe poder entregarlos todos En ruta Sí — se recalcula la ruta completa Si la comprobación de tiempo falla, la asignación se revierte y el pedido queda disponible para el siguiente repartidor de la lista. No se pierde. Reglas que nunca cambian Los pedidos que ya están en reparto —el repartidor ha salido de la tienda— nunca se reasignan. Los pedidos asignados manualmente por un empleado, y no por el dispatcher, quedan completamente bloqueados frente a la reasignación automática. Un repartidor interno puede quitarle un pedido a uno externo. Al revés nunca se permite. Planes de programación: cómo funciona el ciclo automático El dispatcher se ejecuta según una programación que defines por tienda, o por grupo de tiendas. La programación y el comportamiento de asignación se configuran juntos, en el mismo plan. Cómo funciona el ciclo automático Cada plan define cada cuánto debe ejecutarse el dispatcher para un grupo de tiendas. Opcionalmente puedes restringir la ejecución a una franja horaria diaria, por ejemplo solo entre las 08:00 y las 23:00. Si una ejecución falla, el ciclo no se rompe: la siguiente se programa automáticamente mientras el plan siga activo. Si una ejecución cae fuera de la franja configurada, se omite en ese ciclo, pero la programación continúa y se reanuda con normalidad al volver dentro de la franja. Ajustes de programación Ajuste Por defecto Qué hace Nombre del plan — Etiqueta para identificar el plan. Opcional, texto libre Tiendas — Las tiendas a las que aplica el plan. Un plan puede cubrir varias Activo Desactivado Si el ciclo automático está funcionando para este plan Intervalo de ejecución 60 segundos Cada cuánto se reejecuta el dispatcher. Rango permitido: 60–300 segundos Franja horaria diaria Ninguna Hora de inicio y fin opcionales. Si no se define, el plan funciona 24/7 Última ejecución — Solo lectura. Cuándo se ejecutó realmente este plan por última vez Ajustes de comportamiento de asignación Ajuste Por defecto Qué hace Modo de asignación Automático Fuerza Modo PG o Google OR-Tools, o deja la elección automática (recomendado) Estrategia de ruta Automática Solo relevante cuando se usa Google OR-Tools Tiempo de parada en cliente 5 min Tiempo adicional contabilizado en cada parada en casa del cliente Tiempo de parada en tienda 3 min Tiempo adicional contabilizado en cada parada en tienda Máximo de pedidos por repartidor 3 Cuántos pedidos como máximo se agrupan en un repartidor propio. Rango: 1–5 Margen para repartidor desconectado 5 min Cuánto se tolera a un repartidor brevemente desconectado antes de considerarlo no disponible Aplicar resultados Activado Si se desactiva, la ejecución es solo una simulación y no cambia nada Margen de tiempo extra 10 min Holgura adicional permitida. Solo relevante para Google OR-Tools Mínimo de pedidos para aceptar un plan 0 Cuántos pedidos debe asignar Google OR-Tools con éxito para que se acepte su plan Clientes prioritarios (Platinum) Desactivado Activa y configura la capa Platinum — ver Clientes prioritarios (Platinum) Estimaciones con tráfico Desactivado Estimaciones de tiempo más precisas, con mayor coste Tipo de estimación de tráfico — Optimista, pesimista o estimación más probable. Solo se usa si las estimaciones con tráfico están activas Reutilización de tiempos de regreso — Avanzado. Controla con qué agresividad se reutilizan tiempos de repartidor a tienda ya calculados en lugar de recalcularlos Ajustes de reparto a nivel de tienda Otros dos ajustes viven en la tienda, no dentro del plan de programación. Se configuran desde los ajustes de dispatcher de la tienda y controlan cuánto retraso se tolera antes de considerar un pedido en riesgo. Ajuste Aplica a Qué hace Tolerancia de retraso de flota propia Tu flota propia — internos y contratados, tratados por igual La tolerancia usada al comprobar si tu flota propia puede entregar a tiempo. Si una tienda no tiene ningún repartidor interno, este valor se sustituye automáticamente por la tolerancia de transportistas de abajo, para que una tienda 100 % contratada no quede sujeta a un criterio más estricto del que puede cumplir Tolerancia de retraso de transportistas Transportistas externos La tolerancia usada para decidir si se puede confiar en que un transportista entregue a tiempo. Se aplica siempre a los transportistas, tenga o no la tienda repartidores internos La capacidad funciona distinto que la tolerancia de retraso. Tu flota propia tiene un límite por repartidor: cada vehículo lleva como máximo el número configurado a la vez. Los transportistas externos tienen una única bolsa compartida por tienda y por empresa transportista: por ejemplo "este transportista puede llevar 10 pedidos simultáneos en esta tienda", tenga los mensajeros que tenga en la calle. Por eso un transportista puede aparecer como lleno en una tienda aunque parezca que tiene repartidores de sobra: el límite está puesto a nivel de empresa, no por mensajero. Activar y pausar un plan Esta es la parte que más confusión genera. Acción ¿Arranca el ciclo? ¿Detiene el ciclo? Crear un plan con Activo encendido Sí — Crear un plan con Activo apagado No — queda inactivo — Editar un plan existente y encender Activo Sin efecto — solo actualiza el valor guardado — Editar un plan existente y apagar Activo — Sí, a partir de la siguiente ejecución Usar la acción dedicada Activar Sí — Usar la acción dedicada Pausar — Sí Eliminar un plan — Sí Recomendación: no confíes en editar el campo Activo desde un formulario de edición general. Usa siempre las acciones dedicadas Activar y Pausar: editar el campo directamente puede dejar un plan marcado como activo pero sin estar funcionando realmente. Dónde vive cada ajuste Más allá del plan de programación, hay varias partes del producto con ajustes que afectan directamente a las decisiones del dispatcher. Esta página los lista según dónde irías realmente a cambiarlos, e incluye solo los ajustes editables. Para el plan de programación en sí, ver Planes de programación: cómo funciona el ciclo automático. Zonas Se editan desde los ajustes de disponibilidad de repartidores de la zona. Ajuste Qué controla Prioridad propia frente a transportista Si los pedidos de esta zona van directamente a transportistas externos primero, o empiezan por tu flota propia como es habitual Regla de orden de transportistas Cuando hay más de un transportista disponible para la zona, en qué orden se prueban: tu orden configurado, menor coste primero, o menor tiempo primero Transportistas permitidos Qué transportistas pueden recibir pedidos de esta zona Tipos de repartidor propio permitidos Qué tipos de repartidor propio pueden repartir en esta zona. Dejarlo vacío bloquea por completo a todos los repartidores propios en la zona Margen de tiempo adicional Minutos extra añadidos al tiempo previsto en casa del cliente para los pedidos de esta zona, por ejemplo para compensar accesos difíciles Las zonas también muestran un campo de desviación del tiempo de entrega, junto a campos de precios como gastos de envío o importes mínimos de pedido. Son editables en la misma pantalla pero no los usa el dispatcher: la desviación del tiempo de entrega la consume la web de pedidos, no la lógica de asignación. Tiendas Se editan desde los ajustes de dispatcher de la tienda. Ajuste Qué controla Tolerancia de retraso propia / de transportistas Ver Planes de programación: cómo funciona el ciclo automático para entender cómo funcionan juntas Distancia máxima para personal de cocina Hasta dónde se puede enviar a un repartidor de cocina desde la tienda. Ponlo a cero para eliminar la restricción Las tiendas también tienen horarios de apertura y cierre, por día y por turno, configurados en otra parte del producto. El dispatcher no los usa. Transportistas externos: ajustes generales Se editan desde la configuración general del transportista. Aplican a toda la empresa, en todas las tiendas. Ajuste Qué controla Activo Interruptor principal. Mientras esté desactivado, este transportista nunca se considera, en ninguna tienda Tipo de pedido / canal de venta Restringe a qué tipos de pedido y canales de venta se le puede ofrecer Punto de integración La conexión usada para llegar a la plataforma del transportista. Normalmente se configura una sola vez, en el alta Coste de entrega por defecto Se usa para estimar y ordenar a este transportista cuando no hay precio en vivo Margen mínimo de preparación Cuánto tiempo debe faltar todavía para que un pedido pueda ofrecérsele Importe máximo contra reembolso Los pedidos en efectivo por encima de este importe no se le ofrecen Acepta tarjeta Si se le pueden ofrecer pedidos pagados con tarjeta Familias de producto excluidas Categorías de producto —por ejemplo artículos con restricción de edad— que nunca se le ofrecen Distancia máxima Distancia máxima de tienda a cliente para la que se le ofrecen pedidos Ventana de cancelación gratuita Minutos tras la asignación durante los cuales el pedido todavía puede recuperarse sin penalización. Ver Revisión de pedidos ya asignados a un transportista Descripción Etiqueta interna del transportista En este nivel también existe un ajuste de "tiempo de entrega por defecto", pero ya no se usa: se movió a los ajustes por tienda de abajo para poder afinarlo con más precisión. Transportistas externos: ajustes por tienda Se editan desde los ajustes del transportista para una tienda concreta. Añaden detalle específico de tienda sobre los ajustes generales anteriores, para el mismo transportista. Ajuste Qué controla Tiempo máximo para llegar a la tienda Si el repartidor del transportista no llega dentro de este tiempo tras aceptar, el pedido se cancela y se reasigna Tiempo estimado para llegar a la tienda (alternativo) Se usa cuando no hay estimación en vivo para este transportista en esta tienda Tiempo máximo para aceptar Si el transportista no acepta el pedido dentro de este tiempo, se libera para reasignación Tiempo de entrega por defecto La estimación de entrega que se usa cuando no hay media histórica para este transportista en esta tienda Agrupación permitida Si el repartidor de este transportista puede llevar más de un pedido por viaje en esta tienda Capacidad en esta tienda Bolsa compartida para este transportista en esta tienda, no un límite por mensajero Horario de operación Días y turnos en los que este transportista está disponible en esta tienda. Fuera de ese horario se omite por completo Reglas de referencia rápida Resumen en una página de las reglas que más se consultan. Cada una enlaza con la página que la explica a fondo. Regla Comportamiento Pedidos ya en reparto Nunca se revalidan ni se reasignan; solo se usan para estimar cuándo vuelve el repartidor Pedidos aún sin salir Pueden reasignarse si aparece un repartidor mejor Comprobaciones de reasignación Se ejecutan antes de cada intento de asignación Criterio de reasignación Solo prioridad del repartidor; nunca lo urgente que sea el pedido Pedidos asignados manualmente Totalmente bloqueados frente a la reasignación automática Repartidores internos frente a externos Los internos pueden quitar pedidos a los externos. Al revés, nunca Intentos por ciclo Exactamente uno con flota propia y uno con transportista. La zona decide el orden, no la cantidad Clientes prioritarios (Platinum) No se tienen en cuenta en la reasignación ordinaria; solo dentro de su propia capa opcional Pedido ya con un transportista Todavía puede recuperarse para la flota propia antes de que el transportista lo recoja, si se está dentro de la ventana de cancelación gratuita y hay hueco Un pedido con transportista nunca se cancela a ciegas Nunca se cancela nada sin tener ya un sustituto confirmado Sin asignar al final de un ciclo Se marca como Crítico o Pendiente y se reintenta desde cero en la siguiente ejecución programada Dónde ampliar Tema Página Orden de repartidores Clasificación y prioridad de repartidores Reglas de reasignación Cuándo un pedido cambia de repartidor Recuperar un pedido de un transportista Revisión de pedidos ya asignados a un transportista El último intento Last-Option: la red de seguridad final Límites de diseño Límites conocidos del sistema Límites conocidos del sistema Son límites de diseño intencionados, no fallos. Conocerlos mantiene las expectativas realistas y ahorra tiempo cuando algo parece incorrecto pero no lo es. No hay reequilibrado proactivo El dispatcher nunca saca un pedido normal de la ruta de un repartidor solo para hacer sitio a un pedido Platinum. La protección Platinum funciona únicamente mediante la doble simulación descrita en Clientes prioritarios (Platinum). Los pedidos en reparto están congelados Una vez que un repartidor ha salido de la tienda con un pedido, el dispatcher no vuelve a tocar ese pedido. Se sigue usando para estimar cuándo quedará libre ese repartidor, pero no puede reasignarse, revalidarse ni cancelarse desde el algoritmo. Las decisiones son locales, no globales Cada decisión de asignación compara al repartidor actual con un repartidor candidato. El dispatcher no intenta encontrar una solución óptima global para todos los repartidores y todos los pedidos a la vez. Por eso dos decisiones que individualmente parecen correctas pueden, juntas, resultar mejorables vistas en retrospectiva. La urgencia del pedido no es un criterio de reasignación Solo cuenta la prioridad del repartidor al decidir si se reasigna. Un pedido normal muy urgente no se adelanta por sí mismo a otro menos urgente. Ver Cuándo un pedido cambia de repartidor. Last-Option puede superar la tolerancia normal de retraso Como último recurso, un pedido puede colocarse con una estimación de llegada algo más tardía de lo que permitiría la tolerancia normal, en lugar de quedarse sin asignar. Ver Last-Option: la red de seguridad final. Una tienda sin cambios se omite Si nada ha cambiado en una tienda desde la última ejecución, se omite en lugar de reprocesarse. Una ejecución que parece "no haber hecho nada" en una tienda tranquila está funcionando correctamente — ver El ciclo de asignación, paso a paso. Visión de principio a fin El recorrido completo de los pedidos de una tienda en un solo ciclo, reuniendo todo lo de este capítulo. Un ciclo, una tienda Obtener pedidos y repartidores de esta tienda. Aquí se revisan los pedidos que siguen con un transportista externo de un ciclo anterior — ver Revisión de pedidos ya asignados a un transportista. ¿Es una zona con transportista primero? Sí → se prueba primero con un transportista externo. Si lo acepta, ese pedido está resuelto. No → se pasa directamente al paso 3. Solver propio — Modo PG o Google OR-Tools, elegido automáticamente salvo que fuerces uno. Si los clientes prioritarios (Platinum) están activados y aplican, este paso se sustituye por la doble simulación descrita en Clientes prioritarios (Platinum). Todo lo anterior y lo posterior se mantiene igual. Reintento con repartidores libres de la tienda que el solver no haya usado. Respaldo con transportista externo, pero solo para pedidos de zona estándar. Un pedido de una zona con transportista primero ya tuvo su turno y no recibe otro. Posprocesado — se clasifican los resultados y se identifican los pedidos agrupables en un mismo repartidor. ¿Sigue sin asignar? No → guardar y notificar. Sí → el último intento flexible descrito en Last-Option: la red de seguridad final. Si lo coloca, guardar y notificar. Si no, el pedido se marca como Crítico o Pendiente y el siguiente ciclo lo reintenta desde cero. Guardar y notificar — se escriben las asignaciones, se envía la notificación a los repartidores y se procesan las alarmas. Las dos cosas que conviene recordar Cada pedido recibe exactamente dos intentos por ciclo —uno con flota propia y otro con transportista externo—, más la red de seguridad Last-Option al final. La configuración de la zona cambia el orden de esos dos intentos, nunca la cantidad. Nunca se cancela nada sin un sustituto preparado. Un pedido que ya está con un transportista solo se recupera cuando se ha encontrado una asignación real en la flota propia y la cancelación con el transportista ha tenido éxito. Páginas relacionadas El ciclo de asignación, paso a paso — los cinco pasos en detalle Los tres mecanismos de asignación — cómo se combinan Modo PG, Google OR-Tools y transportistas Last-Option: la red de seguridad final — qué ocurre en el paso 7 Límites conocidos del sistema — lo que este flujo deliberadamente no hace Reportar una incidencia del dispatcher Si algo parece incorrecto —un pedido asignado al repartidor "equivocado", retrasado o atascado sin asignar—, la forma más rápida de resolverlo es reportarlo con la información adecuada a la primera. Las capturas por sí solas, sobre todo de pantallas que no vienen al caso, rara vez ayudan. Los datos concretos y coherentes entre sí, sí. Qué incluir Dato Por qué importa Request ID Identifica la ejecución exacta del dispatcher implicada. Aparece en el resumen de ejecución de la vista de detalle del plan, en el Planificador, y tiene el aspecto req_1785152470621_6v3uobxk86e. Es lo más útil que puedes aportar, más incluso que la tienda, porque apunta a una única ejecución concreta ID de pedido / número de ticket Sin él no se puede rastrear el pedido afectado Tienda De qué tienda es la ejecución afectada Fecha y hora aproximada Acota qué ciclo hay que revisar Qué esperabas Por ejemplo: "debería haber ido a un repartidor libre en la tienda", "debería haberse quedado con el repartidor original" Qué ocurrió realmente Por ejemplo: "estuvo 12 minutos sin asignar", "se reasignó a otro repartidor", "fue a un transportista en lugar de a nuestra flota" ¿Puntual o recurrente? Un pedido aislado y un patrón en muchos pedidos apuntan a causas muy distintas ¿Era un pedido de cliente prioritario (Platinum)? Ayuda a descartar o confirmar la capa Platinum opcional Cambios de configuración recientes Una zona, tienda o transportista modificado poco antes ayuda a separar causa de coincidencia Qué evidencia ayuda de verdad Una captura de la pantalla de detalle del pedido concreto, con las marcas de tiempo y la asignación actual, no de un panel o listado sin relación. Si hay varios pedidos afectados, lista todos sus identificadores en lugar de describirlos en general ("varios pedidos a la hora de comer"). Si sospechas que se saltó a un repartidor o transportista concreto, nómbralo, en lugar de decir "no eligió al correcto". Qué evitar Reportar sin el Request ID o sin el ID de pedido. Son los dos datos que nada más puede sustituir. Afirmaciones generales como "el algoritmo está roto" o "hoy no funciona", sin pedido, tienda y hora concretos. Adjuntar muchas capturas sin relación en lugar de la única pantalla relevante para el pedido. Antes de reportar Hay dos comportamientos que se confunden con frecuencia con fallos. Comprobarlos primero puede ahorrar una ida y vuelta: Una tienda en la que nada ha cambiado se omite, no se procesa — ver El ciclo de asignación, paso a paso. Editar el campo Activo de un plan no arranca ni detiene el ciclo. Usa las acciones Activar y Pausar — ver Planes de programación: cómo funciona el ciclo automático. Cuanto más claro y concreto sea el reporte, antes podrá cruzarse con la ejecución real que produjo el comportamiento que describes. Preguntas frecuentes del dispatcher ¿Por qué un pedido cambió de repente de repartidor? Quedó disponible un repartidor con mejor prioridad: por ejemplo uno libre en la tienda, o uno interno donde antes solo había uno externo. Ver Cuándo un pedido cambia de repartidor para las reglas exactas. ¿Por qué un pedido sigue sin asignar después de una ejecución? En condiciones normales todo pedido debería acabar asignado: a tu flota propia, a un transportista, mediante una pasada de respaldo o a través de la red de seguridad Last-Option. Un pedido que sigue sin asignar al final de un ciclo suele apuntar a una de estas causas: Falta real de capacidad — ningún repartidor disponible, propio o externo, puede llegar al cliente dentro de la ventana de entrega aceptada. Desajuste de zona y tipo de repartidor — la zona del pedido no permite el tipo de repartidores disponibles en ese momento. Ten en cuenta que dejar vacíos los tipos de repartidor propio permitidos en una zona los bloquea a todos. Datos incompletos del pedido — por ejemplo coordenadas de entrega ausentes o inválidas. Un problema técnico durante esa ejecución — conviene reportarlo si se repite en la misma tienda. Se reintentará automáticamente en el siguiente ciclo, pero si ocurre a menudo merece investigarse en lugar de darlo por normal. ¿Qué es Last-Option? ¿Significa que mi pedido recibe peor servicio? Last-Option es una red de seguridad final, dentro del mismo ciclo, para pedidos que el proceso normal no ha podido colocar. Relaja la comprobación habitual de tiempo de entrega para evitar dejar un pedido sin asignar, por lo que puede aceptar una estimación de llegada algo más tardía, pero solo cuando no existe mejor alternativa y solo después de que el proceso normal haya tenido su oportunidad completa. Ver Last-Option: la red de seguridad final. ¿Por qué no puedo activar o desactivar un plan simplemente editándolo? Editar un plan solo actualiza su configuración guardada; no arranca ni detiene el ciclo automático. Usa siempre las acciones dedicadas Activar y Pausar. Ver Planes de programación: cómo funciona el ciclo automático. ¿Qué cambia realmente al activar los clientes prioritarios (Platinum)? Añade un paso de evaluación que intenta proteger a los pedidos Platinum de entregarse tarde, pero solo si hacerlo no perjudica a demasiados pedidos normales al mismo tiempo. Si no está activado, los pedidos Platinum se tratan exactamente igual que cualquier otro. Ver Clientes prioritarios (Platinum). ¿Cada cuánto se ejecuta realmente el dispatcher? Según el intervalo que hayas puesto en el plan: mínimo 60 segundos, máximo 300. Si una ejecución falla, la programación no se rompe; la siguiente se programa con normalidad. ¿Un pedido que ya está con un transportista externo puede volver a mi flota propia? Sí, pero solo antes de que el repartidor del transportista haya salido de la tienda con él, y solo si se cumplen dos condiciones: el pedido sigue dentro de la ventana de cancelación gratuita del transportista, y hay un repartidor propio con capacidad disponible en ese momento. Aun así, el cambio solo se produce si la cancelación con el transportista tiene éxito primero. Si algo de eso no se cumple, el pedido simplemente se queda con el transportista y no cambia nada. Ver Revisión de pedidos ya asignados a un transportista. Un transportista parece tener repartidores de sobra, ¿por qué aparece como "lleno" en mi tienda? La capacidad de un transportista es una única bolsa compartida por tienda y por empresa transportista, no un límite por mensajero. Ver la nota sobre capacidad en Planes de programación: cómo funciona el ciclo automático. ¿Por qué una ejecución parece no haber hecho nada en una de mis tiendas? Si nada ha cambiado en esa tienda desde la última ejecución, se omite deliberadamente en lugar de reprocesarse. Ver El ciclo de asignación, paso a paso. Pausar y reanudar el reparto Necesitas: Pausar / reanudar reparto — lo tienen admin, hub_manager, dispatcher_manager y branch_manager. Consultar el estado solo requiere acceso de lectura a tiendas. Pausar el reparto detiene la entrada de nuevos pedidos a domicilio en una tienda durante un tiempo determinado, sin cerrar la tienda ni tocar los pedidos ya en curso. Pausar una tienda Abre los controles de reparto de la tienda. Elige Pausar e indica la duración en minutos. Confirma. La pausa está acotada en el tiempo: cuando se cumple la duración, el reparto se reanuda solo. No hace falta acordarse de volver a activarlo. Si la tienda ya está pausada, volver a pausar no acumula tiempo. Se te indicará que ya está pausada en lugar de ampliarla silenciosamente; consulta antes el estado actual si tu intención es alargar una pausa. Reanudar antes de tiempo Reanudar termina la pausa de inmediato, antes de cumplirse la duración. Úsalo cuando el motivo de la pausa desaparece antes de lo previsto: una acumulación en cocina que se resuelve, repartidores que se incorporan al turno. Consultar el estado actual La vista de estado responde a dos preguntas: si la tienda está pausada ahora mismo y, en ese caso, qué la va a reactivar. Consúltala antes de pausar, para no confundir una pausa existente con una nueva. Trabajos de pausa activos Cada pausa crea un trabajo que reanudará la tienda cuando se cumpla su tiempo. Por tienda — ver el trabajo activo de una tienda y cuándo se reanudará. De toda la cadena — ver todos los trabajos de pausa activos a la vez. Útil durante una incidencia, cuando varias tiendas se han pausado en momentos distintos y por personas distintas. Emergencia: cancelar todas las pausas Existe una acción para toda la cadena que cancela de golpe todos los trabajos de pausa activos. Es un control de emergencia, no rutinario. Afecta a todas las tiendas pausadas en ese momento, incluidas las que otras personas hayan pausado por motivos que quizá desconozcas. Consulta antes el listado de trabajos de toda la cadena para saber exactamente qué vas a reactivar, y avisa a las tiendas afectadas. Úsalo cuando se han aplicado pausas en bloque por error, o cuando una incidencia ha terminado y necesitas volver a poner todo en marcha sin entrar tienda por tienda. Lo que pausar no hace No detiene el dispatcher en esa tienda. Los pedidos ya aceptados se siguen asignando con normalidad — ver El ciclo de asignación, paso a paso. No cambia los horarios de apertura de la tienda, que se configuran en otro sitio y no los usa el dispatcher. No cancela ni reasigna pedidos existentes. Qué puedes ver y qué no Las acciones por tienda quedan filtradas por tu scope: solo puedes pausar, reanudar o consultar tiendas que estén dentro de él. El listado de trabajos de toda la cadena y la cancelación de emergencia no son específicos de una tienda, así que se limitan a roles con control de reparto sin restricción por tienda. Zonas de reparto Necesitas: Zonas de reparto — ver para consultar, Zonas de reparto — editar para cambiar algo. Lo tienen admin, dispatcher_manager y polygon_manager. Una zona es un área de reparto con un polígono en el mapa y un conjunto de reglas que deciden qué repartidores y transportistas la atienden. Las zonas son la mayor palanca sobre el comportamiento del dispatcher — ver Dónde vive cada ajuste para qué hace cada regla. Consultar zonas El listado muestra todas las zonas de la marca, con su tienda y si tienen polígono dibujado. Una vista aparte muestra las zonas junto a su configuración de disponibilidad de repartidores, que es donde se ve de un vistazo si una zona está configurada para probar primero con transportistas. La vista de mapa necesita una clave de Maps configurada para la marca. Si el mapa aparece en blanco mientras el listado sí muestra zonas, es un problema de configuración, no de zonas ausentes. Editar la disponibilidad de repartidores de una zona Aquí se controlan las reglas que el dispatcher usa realmente: prioridad de flota propia frente a transportista, la regla de orden de transportistas, qué transportistas se permiten, qué tipos de repartidor propio se permiten y el margen de tiempo adicional. La trampa que conviene repetir: dejar vacíos los tipos de repartidor propio permitidos no significa "todos los tipos". Bloquea a todos los repartidores propios de la zona, y sus pedidos solo podrán ir a transportistas. Es la causa más habitual de que todos los pedidos de una zona acaben siendo externos. Dibujar y eliminar polígonos El polígono de una zona define su límite geográfico. Crear o actualizar un polígono dibujándolo en el mapa y guardando. Eliminar un polígono deja la zona sin límite. Una zona sin polígono no puede corresponder con ninguna dirección, así que no le llegarán pedidos. Eliminar el polígono equivale, por tanto, a desactivar la zona, aunque la zona siga existiendo. Mover una zona a otra tienda Una zona —junto con su polígono— puede migrarse a otra tienda. Úsalo cuando una tienda se traslada o cuando un área se reasigna entre tiendas, en lugar de eliminar la zona y volver a dibujarla, lo que haría perder el límite. Cambios masivos por fichero Para cualquier cosa que vaya más allá de unas pocas zonas, usa las herramientas de fichero. Acción Qué hace Exportar zonas Descarga la configuración actual de zonas en CSV. Exporta siempre antes de un cambio masivo: es tu marcha atrás Importar zonas Aplica configuración de zonas desde un CSV Importar polígonos desde KML Carga masivamente límites de zona desde un fichero KML, el formato que exportan las herramientas de mapas La importación KML es parcial por diseño: las filas válidas se importan aunque otras fallen. Obtienes lo que funcionó más un informe de lo que no, en lugar de un rechazo total. Lee el informe: una importación parcialmente correcta deja el resto de tus zonas intactas y todavía pendientes de atención. Cambio de zonas por horario Las zonas pueden cambiar según un horario, de modo que un área se atienda de forma distinta a distintas horas del día. Estas reglas se cargan desde un CSV. A diferencia de la importación KML, esta es de todo o nada: si alguna fila es inválida, no se aplica nada. Corrige el fichero y vuelve a importar. Antes y después de un cambio masivo Exporta primero. La exportación es la única marcha atrás que tienes. Aplica la importación. Lee el resultado con atención, especialmente en KML, donde el éxito parcial es lo normal. Comprueba una zona de muestra en el mapa. Confírmalo con un pedido real en esa área, si puedes. Las copias de seguridad de zonas se conservan y se pueden restaurar — ver Copias de seguridad y restauración de configuración. Transportistas externos Necesitas: Transportistas — ver para consultar, Transportistas — editar para cambiar. Lo tienen admin, dispatcher_manager y third_party_manager. Los ajustes por tienda también son accesibles para hub_manager. La configuración de transportistas existe en dos niveles, y saber cuál estás editando es la mitad del trabajo. Nivel Aplica a Ajustes típicos Marca Todas las tiendas de la marca Si el transportista está activo, reglas de pago, exclusiones de producto, distancia máxima, ventana de cancelación gratuita Tienda Un transportista, en una tienda Límites de tiempo, capacidad en esa tienda, horario de operación, agrupación, tiempo de entrega por defecto Ambos niveles están detallados campo a campo en Dónde vive cada ajuste. Configuración a nivel de marca La vista de marca lista todos los tipos de transportista disponibles y su configuración actual. Editar aquí cambia ese transportista en todas partes. El interruptor principal Activo es de marca. Desactivar aquí un transportista lo retira de todas las tiendas de inmediato, digan lo que digan los ajustes por tienda. Si solo quieres dejar de usarlo en una ubicación, cambia los ajustes de esa tienda. Configuración a nivel de tienda La vista por tienda muestra los mismos transportistas con sus ajustes para esa tienda concreta. Aquí se afina lo que realmente varía según la ubicación: cuánto tiempo tiene el transportista para aceptar, cuánto para llegar a la tienda, cuántos pedidos simultáneos puede llevar allí y en qué horario opera. Dos de ellos rigen el comportamiento descrito en Revisión de pedidos ya asignados a un transportista: Tiempo máximo para aceptar y Tiempo máximo para llegar a la tienda. Se parecen y comparan cosas completamente distintas; esa página tiene la comparación. La capacidad es por empresa, no por mensajero La capacidad de un transportista en una tienda es una única bolsa compartida para esa empresa transportista. "Diez pedidos simultáneos en esta tienda" son diez, tenga los mensajeros que tenga cerca. Esta suele ser la explicación cuando un transportista parece ocupado en su propia aplicación pero aparece como lleno para el dispatcher. Cambios masivos por fichero Para trabajos de transportistas a nivel de cadena, usa las herramientas de fichero en lugar de editar tienda por tienda. Acción Qué hace Exportar configuración por tienda Descarga los ajustes por tienda actuales en CSV. Exporta antes de cada cambio masivo Importar configuración por tienda Aplica ajustes por tienda desde un CSV Las copias de seguridad de la configuración de transportistas se conservan y se pueden restaurar — ver Copias de seguridad y restauración de configuración. Cuando a un transportista nunca se le ofrecen pedidos Repasa esto antes de reportar un problema. Un transportista se omite por completo si se cumple cualquiera de estas condiciones: Está desactivado a nivel de marca. La hora actual está fuera de su horario de operación para esa tienda. Su bolsa de capacidad en esa tienda está llena. La zona del pedido no lo incluye entre los transportistas permitidos — ver Zonas de reparto. El pedido falla alguna de sus comprobaciones estructurales: tipo de pago, una familia de producto excluida, o la distancia. La lista ordenada completa de esas comprobaciones está en ¿Cuándo existe una alternativa? Ajustes de reparto de la tienda Necesitas: Configuración de tienda — ver para consultar, Configuración de tienda — editar para cambiar. Lo tienen admin, hub_manager, dispatcher_manager y branch_manager. Cada tienda tiene sus propios ajustes de dispatcher, separados del plan de programación que rige cuándo se ejecuta. Son dos cosas que se configuran en sitios distintos y se confunden con facilidad: el plan decide cuándo y cómo se ejecuta el dispatcher, la tienda decide cuánta tolerancia se aplica en esa ubicación. Listado de tiendas El listado muestra todas las tiendas dentro de tu scope. Un branch_manager ve la suya; un rol de cadena las ve todas. Si falta una tienda que esperabas, es una cuestión de scope y no de configuración — ver Cómo funciona el scope en la práctica. Ajustes de dispatcher de una tienda Dos ajustes son los importantes, y ambos están explicados a fondo en Planes de programación: cómo funciona el ciclo automático: Tolerancia de retraso de flota propia — cuánto retraso se acepta al comprobar si tus repartidores pueden entregar a tiempo. Tolerancia de retraso de transportistas — lo mismo, para los transportistas externos. Hay aquí una regla que sorprende: si una tienda no tiene ningún repartidor interno, la tolerancia de flota propia se sustituye automáticamente por el valor de transportistas. Una tienda 100 % contratada no queda sujeta a un criterio más estricto del que puede cumplir. Esto no se configura: ocurre solo. Un tercer ajuste, distancia máxima para personal de cocina, limita hasta dónde se puede enviar a un repartidor de cocina desde la tienda. Ponerlo a cero elimina la restricción por completo, en lugar de bloquear a todos los repartidores de cocina. Horas prometidas de entrega Cada tienda expone los tiempos de entrega que puede prometer a un cliente. Alimentan el tiempo que se le indica al cliente al hacer el pedido, y la hora prometida frente a la que luego trabaja el dispatcher para decidir qué va tarde — ver las definiciones de Crítico y Pendiente en el Glosario del dispatcher. Productos y promociones por tienda La vista de una tienda también lista los productos y promociones activos allí. Es una comprobación de solo lectura: útil cuando un pedido se comporta de forma inesperada y quieres confirmar qué ofrece realmente esa tienda, y no lo que dice el catálogo de la marca. Qué está en otro sitio Si buscas Está realmente en Cada cuánto se ejecuta el dispatcher en esta tienda El plan de programación — Planes de programación: cómo funciona el ciclo automático Qué repartidores y transportistas atienden un área La zona — Zonas de reparto Tiempos y capacidad de un transportista en esta tienda Ajustes por tienda del transportista — Transportistas externos Pausar el reparto temporalmente Pausar y reanudar el reparto Horarios de apertura de la tienda La configuración general de la tienda. El dispatcher no los usa Copias de seguridad y restauración de configuración Necesitas: el permiso de ver o editar de aquello que contenga la copia, no un permiso de copias aparte. Una copia de zonas requiere acceso a zonas de reparto; una de transportistas, acceso a transportistas; una de empleados, acceso a empleados. Cada vez que exportas configuración se guarda una copia de seguridad. Puedes listarlas, descargarlas, restaurar una o eliminarla. Qué se copia Tipo de copia Qué cubre Permiso que sigue Zonas Configuración de zonas de reparto Zonas de reparto Zonas por horario Reglas de cambio de zona por horario Zonas de reparto Transportistas externos Configuración de transportistas por tienda Transportistas Empleados Configuración de empleados y repartidores propios Empleados Como cada copia sigue el permiso de su propio contenido, quien puede restaurar una copia de zonas no necesariamente puede restaurar una de empleados. El acceso lo decide lo que la copia contiene, y se comprueba al abrirla. Consultar copias El listado se puede filtrar por tipo. Cada entrada indica qué cubre y cuándo se tomó. Los nombres de fichero siguen el patrón backup--.csv, de modo que un fichero descargado sigue siendo identificable fuera de la consola. Descargar La descarga entrega el CSV exactamente como se capturó. Dos buenos motivos para descargar en lugar de restaurar: Para inspeccionar antes de restaurar. Abre el CSV y confirma que contiene lo que esperas, sobre todo si la copia es antigua. Para comparar. Comparar la exportación de ayer con la de hoy responde a "¿qué ha cambiado realmente?" más rápido que revisar pantallas. Restaurar Restaurar vuelve a aplicar una instantánea capturada. Lee esto antes de restaurar. Una restauración reinstaura la configuración tal como estaba en el momento de la captura. Todo lo cambiado desde entonces —por ti o por cualquier otra persona— queda sobrescrito para las entidades de esa instantánea. Si dos personas han estado editando zonas esta semana, restaurar la copia de la semana pasada descarta ambos conjuntos de cambios, no solo el que querías deshacer. La secuencia segura: Exporta ahora, creando una copia fresca del estado actual. Es tu camino de vuelta. Descarga la copia que pretendes restaurar y léela. Restaura. Verifica en una zona, tienda o transportista real que el resultado es el que querías. Eliminar Eliminar borra una copia de forma permanente. Hazlo para limpiar ruido, no para ordenar después de un cambio: las copias antiguas son justo lo que necesitas cuando un problema se detecta tarde. Antes de eliminar, comprueba que no sea la última instantánea buena conocida anterior a un cambio importante. Páginas relacionadas Zonas de reparto — donde se exportan e importan las zonas Transportistas externos — exportación de configuración de transportistas Dónde vive cada ajuste — qué controla realmente cada campo restaurado Hub El tablero de pedidos en vivo: asignación, incidencias, acciones críticas y alarmas. El Hub: qué es y quién puede hacer qué Dirigido a: operadores de hub, responsables de turno y jefes de operaciones que trabajan con el tablero de pedidos en vivo. Necesitas: como mínimo Hub — pedidos y estado. Cada acción concreta requiere además su propio permiso, listados abajo. El Hub es la vista operativa en vivo de los pedidos en curso. Donde el dispatcher decide automáticamente, el Hub es donde interviene una persona: asignar un repartidor a mano, cambiar una hora prometida, registrar una incidencia o —rara vez— forzar el cierre de un pedido. Para qué sirve el Hub El dispatcher ya asigna la mayoría de los pedidos por su cuenta, en cada ciclo. Abres el Hub cuando hace falta una persona: un pedido que el algoritmo no ha podido colocar, un cliente que llama preguntando por su hora, un repartidor que nunca recogió, una tienda con las alarmas disparadas. Si lo que quieres es entender por qué un pedido se asignó como se asignó, eso es lógica del dispatcher y no del Hub — ver Qué hace el dispatcher. Qué permiso necesita cada acción El acceso es granular a propósito. Tener la vista del Hub no implica tener las acciones críticas. Acción Permiso Quién lo suele tener Ver pedidos y estado Hub — pedidos y estado hub_operator y superiores Ver el código de recogida Hub — código de recogida Separado de asignar, deliberadamente Asignar un repartidor Hub — asignar hub_operator y superiores Desasignar un repartidor Hub — desasignar hub_manager Cambiar la hora prometida Hub — modificar ETA hub_manager, branch_manager Registrar una incidencia Hub — incidencias hub_manager, branch_manager Cancelar un pedido Hub — cancelar hub_manager Forzar la entrega Hub — forzar entrega hub_manager Ver alertas de repartidor Hub — alertas de repartidor hub_operator y superiores Ver alarmas de tienda Hub — alarmas de tienda hub_operator y superiores Archivar alarmas Hub — archivar alarmas hub_manager Cambiar umbrales de alarma Configuración de alarmas — editar alarms_config_manager Un hub_operator tiene deliberadamente las acciones del día a día pero no forzar entrega, cancelar ni cambiar la hora prometida. Ver Acceso por sección para la rejilla completa. El código de recogida es un permiso distinto del de asignar, aunque en la práctica suelan tenerlo las mismas personas. Mantenerlos separados hace que leer un código de recogida no venga nunca acompañado de la capacidad de mover pedidos entre repartidores. Las páginas de este capítulo Tarea Página Encontrar un pedido, entender el tablero El tablero de pedidos Ver un pedido en detalle Detalle del pedido y código de recogida Poner un pedido en un repartidor, o quitarlo Asignar y desasignar un repartidor Cambiar lo prometido al cliente Cambiar la hora prometida Registrar qué salió mal Registrar una incidencia Detener un pedido por completo Cancelar un pedido Cerrar un pedido que el sistema no pudo cerrar Forzar una entrega Ver tiendas y alertas de repartidor Tiendas y alertas de repartidor Ver y atender alarmas de tienda Alarmas de tienda Ajustar cuándo saltan las alarmas Configuración de alarmas Revisar alarmas ya atendidas Alarmas archivadas Qué puedes ver y qué no Todo en el Hub queda filtrado por tu scope. Un branch_manager ve los pedidos de su tienda; un rol de cadena los ve todos. Dos compañeros mirando el mismo tablero pueden ver legítimamente pedidos distintos — ver Cómo funciona el scope en la práctica. El tablero de pedidos Necesitas: Hub — pedidos y estado. El tablero de pedidos es la lista de trabajo de los pedidos actualmente en juego en las tiendas de tu scope. Filtrar por tienda El filtro principal es tiendas: elige una, varias, o déjalo abierto a todo lo que esté dentro de tu scope. Es el primer filtro al que recurrir. Un rol de cadena mirando todas las tiendas a la hora de comer está leyendo cientos de filas; acotar a las dos tiendas que realmente tienen problemas hace el tablero usable. El filtro de tiendas acota dentro de tu scope, nunca lo amplía. Si una tienda no aparece siquiera en la lista, es cuestión de scope y no de filtro. Ver Cómo funciona el scope en la práctica. Identificar un pedido Todo pedido se identifica por cuatro datos en conjunto, y los necesitas todos para referirte a uno: Dato Qué es Tienda A qué tienda pertenece el pedido Número de ticket El número de pedido en esa tienda Origen De dónde vino el pedido: web, app móvil, un agregador, etc. Marca Qué marca, cuando la cadena opera más de una Un número de ticket por sí solo no es único entre tiendas. Por eso Reportar una incidencia del dispatcher y cualquier conversación con soporte piden tienda, número de ticket y origen, y no solo un número. Leer el tablero Para cada pedido, el tablero muestra con quién está, en qué estado se encuentra y la hora prometida frente a la que se mide. Dos términos son los más importantes, y vienen del dispatcher y no del Hub: Pendiente — todavía sin asignar, pero aún no va tarde. Crítico — todavía sin asignar y ya pasada su hora prometida. Ambos están definidos en el Glosario del dispatcher. Un pedido en Pendiente es normal entre ciclos; un pedido en Crítico es el tablero pidiéndote que intervengas. Cuando un pedido parece atascado Antes de actuar a mano conviene saber si el dispatcher realmente ha desistido o simplemente todavía no se ha ejecutado: El dispatcher reevalúa cada tienda en cada ciclo: por defecto con no más de 60 segundos de separación, y hasta 300. Un pedido que no se pudo colocar en un ciclo se reintenta desde cero en el siguiente, incluido un intento nuevo con transportistas externos. Solo después de eso una intervención manual aporta algo. Los motivos legítimos por los que un pedido se queda sin asignar están en las Preguntas frecuentes del dispatcher: falta real de capacidad, una zona que no permite ningún tipo de repartidor disponible, o datos de dirección incompletos. La asignación manual tiene una consecuencia duradera. Un pedido asignado por una persona queda bloqueado de forma permanente frente a la reasignación automática: el dispatcher no volverá a moverlo, aunque segundos después quede libre un repartidor mucho mejor. Asigna a mano cuando quieras anular al algoritmo, no para meterle prisa. Desde aquí Un pedido en profundidad → Detalle del pedido y código de recogida Ponerlo en un repartidor → Asignar y desasignar un repartidor No va a llegar a la hora prometida → Cambiar la hora prometida Detalle del pedido y código de recogida Necesitas: Hub — pedidos y estado para la vista de detalle; Hub — código de recogida para ver el código de recogida, que es un permiso aparte. La vista de detalle es la pantalla que merece la pena capturar al reportar un problema: reúne las marcas de tiempo y la asignación actual. Abrir un pedido Un pedido se identifica por tienda, número de ticket y origen en conjunto — ver El tablero de pedidos. La vista de detalle los necesita todos, y por eso se abre desde el tablero y no escribiendo un número. Qué te dice Te preguntas La vista de detalle responde ¿Quién lo tiene ahora? El repartidor o transportista actual, y desde cuándo ¿Va a llegar tarde? La hora prometida frente a la estimación actual ¿Qué ha pasado ya? Marcas de tiempo de cada paso, incluida la llegada a la tienda cuando se ha registrado ¿Hay algo registrado sobre él? Las incidencias anotadas en el pedido El código de recogida El código de recogida es el que usa un repartidor o transportista para recoger el pedido. Está detrás de su propio permiso, separado del de asignar. En la práctica suelen tenerlo las mismas personas, pero mantenerlos aparte permite dar a alguien la capacidad de leer un código —a un repartidor por teléfono, por ejemplo— sin darle también la de mover pedidos entre repartidores. Trata el código de recogida como cualquier otra credencial de recogida. Léeselo a quien va a recoger; no lo pegues en un chat de grupo ni en un ticket, y tápalo en las capturas antes de adjuntarlas a una solicitud de soporte. Usarla en una solicitud de soporte Si vas a reportar algo, esta pantalla es la evidencia que ayuda. Incluye: La tienda, el número de ticket y el origen — un número de ticket solo no es único. Las marcas de tiempo visibles y la asignación actual. Si el dispatcher está implicado, el Request ID del Planificador, que apunta a una ejecución exacta. Lo que no ayuda es una captura del tablero, ni de un panel sin relación. Lista completa en Reportar una incidencia del dispatcher. Desde aquí Cambiar el repartidor → Asignar y desasignar un repartidor Cambiar la hora prometida → Cambiar la hora prometida Registrar qué salió mal → Registrar una incidencia Asignar y desasignar un repartidor Necesitas: Hub — asignar para asignar y para ver los repartidores disponibles. Desasignar es un permiso aparte, Hub — desasignar, que normalmente solo tiene hub_manager. Ver quién está disponible Abre el pedido y pide los repartidores disponibles. La lista se construye para ese pedido concreto: tiene en cuenta su tienda y las reglas de su zona, así que no es simplemente "todo el mundo en turno". Si la lista está vacía o es más corta de lo que esperas, los motivos son los mismos con los que trabaja el dispatcher: capacidad, restricciones de zona por tipo de repartidor, distancia, horarios de transportistas. ¿Cuándo existe una alternativa? lista las comprobaciones de transportista en orden. Asignar un repartidor propio frente a un transportista Son operaciones realmente distintas, y la diferencia despista: Repartidor propio Transportista externo Qué eliges El repartidor concreto La empresa transportista, no un mensajero Quién elige al mensajero Tú El transportista Qué puedes prever Exactamente quién va Solo que el transportista lo aceptó Con un transportista estás entregando el pedido a una empresa. Qué mensajero suyo aparece, y cuándo, lo decide ella. Por eso los tiempos del transportista los gobiernan los límites de Transportistas externos y no tu elección. Tus tipos de repartidor propio son fijos. Los tipos de transportista disponibles dependen de lo que esté configurado y activo para tu marca, así que la lista varía entre marcas y puede cambiar sin que cambie el Hub. Asignar Abre el pedido — ver Detalle del pedido y código de recogida. Solicita los repartidores disponibles. Elige un repartidor propio, o un transportista. Confirma. Esto es permanente en un sentido concreto. Un pedido asignado por una persona queda bloqueado para siempre frente a la reasignación automática. El dispatcher no lo moverá después, ni aunque aparezca un repartidor libre en la tienda instantes más tarde. Es el comportamiento buscado: una asignación manual se trata como una anulación deliberada, no como una sugerencia. Ver Cuándo un pedido cambia de repartidor. Desasignar Desasignar quita al repartidor del pedido y lo devuelve al juego. Es un permiso aparte y superior al de asignar porque deshace la acción de otra persona, incluida la del dispatcher. Úsalo cuando una asignación se hizo por error, o cuando el repartidor asignado ha dejado de estar disponible y quieres devolver el pedido al conjunto. Tras desasignar, el pedido vuelve a tratarse como no asignado y el siguiente ciclo del dispatcher lo considerará con normalidad. Desasignar un pedido que ya está con un transportista no es lo mismo que cancelar con ese transportista. Si tu intención es detener al transportista, ver Cancelar un pedido, que gestiona el lado del transportista de forma atómica. Lo que no puedes hacer Un pedido ya en reparto no se puede reasignar. Una vez que el repartidor ha salido de la tienda, el dispatcher lo congela y el Hub también. Ver Límites conocidos del sistema. No puedes asignar fuera de tu scope. Tanto los pedidos como los repartidores están filtrados a lo que puedes ver. Cambiar la hora prometida Necesitas: Hub — modificar ETA. Lo tienen hub_manager y branch_manager. La hora prometida es lo que se le dijo al cliente, y lo que el sistema usa para medir el retraso. Cambiarla es lo correcto cuando la promesa original ya no es alcanzable y se ha informado al cliente; no es una forma de hacer que un pedido tarde parezca puntual. Elegir una nueva hora Las horas nuevas salen de las horas prometidas disponibles de la tienda, el mismo conjunto que ofrece el flujo de pedido. Elige de entre ellas en lugar de inventar una hora: reflejan lo que esa tienda puede comprometer realmente. Las horas prometidas de la tienda forman parte de su configuración — ver Ajustes de reparto de la tienda. Puede que se te pida confirmar Esta es la parte que conviene conocer de antemano. Cuando el cambio tiene consecuencias que el sistema quiere que reconozcas, el primer intento no se aplica. En su lugar se te muestran las advertencias concretas y se te pide confirmación. Confirmar reenvía el mismo cambio, ahora con tu reconocimiento adjunto. Qué verás Qué significa El cambio se aplica de inmediato No hay efectos secundarios que señalar Advertencias y una petición de confirmación Hay consecuencias reales: léelas y confirma si aun así lo quieres La confirmación ha caducado Has tardado demasiado. Empieza de nuevo; las advertencias se reevalúan contra el estado actual La confirmación no es deliberadamente un "¿estás seguro?" genérico. Las advertencias dicen qué va a pasar. Léelas: para eso existe el paso, y el estado puede haber cambiado desde que abriste el pedido. Pedidos que ya están con un transportista Cuando el pedido está con un transportista externo, el cambio va primero al transportista, y solo después se registra en tu lado. Ese orden importa: la llamada al transportista es la mitad irreversible y la que puede fallar. Hacerla primero significa que un fallo deja ambos lados sin cambios, en vez de dejar tus registros con una hora nueva mientras el mensajero del transportista sigue trabajando con la anterior. Si el transportista rechaza el cambio, la hora prometida no se actualiza. No es un fallo: es el sistema negándose a registrar una promesa que el transportista no ha aceptado. Antes de cambiarla ¿Se ha avisado al cliente? La hora prometida es un compromiso, y cambiarla en silencio solo traslada dónde aparece la decepción. ¿El problema real es la asignación? Si el pedido simplemente está sin asignar, asignarlo puede ser la solución — ver Asignar y desasignar un repartidor. ¿Es un patrón? Un pedido es una incidencia; una tienda incumpliendo sus horas prometidas toda la comida es una cuestión de configuración o de capacidad. Ver Ajustes de reparto de la tienda. Páginas relacionadas Registrar una incidencia — para dejar constancia de por qué cambió la hora El tablero de pedidos — cómo se juzgan Pendiente y Crítico frente a la hora prometida Ajustes de reparto de la tienda — de dónde salen las horas prometidas Registrar una incidencia Necesitas: Hub — incidencias para registrar una. Consultar el catálogo solo requiere Hub — pedidos y estado. Una incidencia deja constancia de qué salió mal en un pedido concreto, para poder explicarlo después y contabilizarlo entre pedidos. El catálogo de incidencias Las incidencias se eligen de un catálogo, no se escriben libremente. El catálogo es lo que las hace contabilizables: "cuántas veces pasó esto el mes pasado" solo tiene respuesta si todo el mundo elige la misma entrada para la misma situación. Junto a la entrada del catálogo se añade un comentario. La entrada dice de qué tipo fue el problema; el comentario dice qué pasó realmente en ese pedido. Registrar una Abre el pedido — ver Detalle del pedido y código de recogida. Elige la incidencia del catálogo. Escribe un comentario con los detalles: qué pasó, qué se hizo, quién estuvo implicado. Guarda. Escribir un comentario que se pueda leer El comentario lo lee semanas después alguien que no estaba allí. Lo que ayuda: Horas. "El repartidor llegó a las 19:40, el pedido no estuvo listo hasta las 19:55" es mejor que "el pedido salió tarde". Nombres o identificadores, no roles. "El mensajero del transportista X no llegó" es mejor que "el mensajero no apareció". Qué se hizo al respecto. Si se llamó al cliente, si se ofreció una devolución. El desenlace con el cliente. Si quedó satisfecho. Lo que no ayuda: "tarde", "problema", "ver llamada". Una incidencia es un registro, no una acción Registrar una incidencia no cambia el pedido. No lo reasigna, ni lo cancela, ni cambia la hora prometida, ni avisa a nadie automáticamente. Si el pedido además necesita algo de eso, hazlo aparte: Además necesitas… Página Pasarlo a otro repartidor Asignar y desasignar un repartidor Cambiar lo prometido al cliente Cambiar la hora prometida Detenerlo por completo Cancelar un pedido Cerrarlo como entregado Forzar una entrega Registra la incidencia además de ejecutar la acción, no en su lugar. Un pedido con la entrega forzada y sin una incidencia que explique por qué es el caso más difícil de reconstruir después. Cuándo registrar una Siempre que haya pasado algo que alguien vaya a necesitar que le expliquen después: una entrega tarde, un artículo ausente o equivocado, un fallo de repartidor o transportista, una reclamación del cliente ligada a ese pedido, o cualquier uso de cancelar o forzar entrega. La consistencia importa más que el volumen. Un tipo de incidencia que nadie registra es indistinguible de un problema que nunca ocurre. Cancelar un pedido Necesitas: Hub — cancelar. Normalmente solo hub_manager: deliberadamente no se le da a hub_operator. Cancelar detiene un pedido por completo. Es una de las dos acciones críticas del Hub, junto con Forzar una entrega. Antes de cancelar Comprobación Por qué ¿Cancelar es realmente lo que se quiere? Si el pedido solo va a llegar tarde, cambiar la hora prometida puede servir mejor al cliente — ver Cambiar la hora prometida ¿Se ha avisado al cliente? Una cancelación de la que se entera porque no llega la cena es otra conversación muy distinta de una acordada ¿El pedido ya está en reparto? Si el repartidor ha salido con él, cancelar aquí no lo hace volver ¿Sabes el motivo? Es obligatorio, y es lo que leerá quien revise esto más adelante Cancelar Abre el pedido. Elige cancelar. Escribe el motivo de cancelación — obligatorio, y merece la pena escribirlo bien. Confirma. Si el pedido está con un transportista Cuando un transportista externo tiene el pedido, la cancelación cubre ambos lados a la vez: el pedido se cancela con el transportista y se libera en tu lado como una sola operación, no como dos. Esto importa porque el fallo que evita es feo. Cancelar solo tu lado dejaría al transportista con un pedido vivo y un mensajero de camino a recoger algo que ya nadie espera que recoja. Si el lado del transportista falla, la cancelación no se aplica a medias en silencio. Comprueba después el estado del pedido en lugar de dar por hecho que salió bien, y reintenta en vez de volver a cancelar desde otra pantalla. Escribe un motivo de verdad El motivo es la única explicación que perdura. Lo lee quien atienda el seguimiento del cliente, y quien revise las tasas de cancelación de esa tienda. Útil: "El cliente llamó para cancelar: pidió dos veces por error, se mantiene el ticket 4471." Inútil: "cancelar", "error", "cliente". Registra también una incidencia Cancelar deja constancia de que el pedido se detuvo, con tu motivo. No clasifica la cancelación en nada contabilizable. Si la cancelación vino de algo que salió mal —y no de que el cliente simplemente cambiara de idea—, registra además una incidencia para que aparezca en los recuentos. Ver Registrar una incidencia. Lo que cancelar no hace No hace volver a un repartidor que ya salió con el pedido. No emite una devolución. Eso se gestiona donde gestionéis las devoluciones. No avisa al cliente automáticamente. Da por hecho que hay que decírselo. Forzar una entrega Necesitas: Hub — forzar entrega. Normalmente solo hub_manager. Es la acción con más consecuencias del Hub: lee la página entera antes de usarla. Forzar la entrega cierra un pedido como entregado cuando el flujo normal no pudo cerrarlo, casi siempre porque el dispositivo del repartidor no registró la entrega, o porque un transportista externo nunca informó de que había terminado. Qué hace realmente Registra el pedido como entregado, con un repartidor y una distancia que aportas tú, no que el sistema haya observado. Ahí está todo el sentido y todo el riesgo: estás afirmando algo que el sistema no pudo confirmar. Todo lo que hay aguas abajo —recuentos de entregas, cifras de repartidores, informes basados en distancia— se fía de tu palabra. Úsalo solo si la entrega ocurrió de verdad Forzar la entrega corrige un fallo de registro, no uno operativo. Situación ¿Forzar entrega? El cliente recibió el pedido; la app nunca lo registró ✅ Sí, es exactamente esto El transportista entregó pero nunca lo informó ✅ Sí El pedido va muy tarde y quieres quitarlo del tablero ❌ No, sigue en curso El pedido nunca se entregó ❌ No, cancélalo No estás seguro de si se entregó ❌ No, averígualo primero Forzar un pedido que nunca se entregó mete una entrega falsa en tus registros de forma permanente. No hay una marcha atrás limpia. Ante la duda, confirma con el repartidor o el cliente antes de actuar. Cómo hacerlo Abre el pedido — ver Detalle del pedido y código de recogida. Elige forzar entrega. Indica quién lo entregó: un repartidor propio o el transportista. Para un repartidor propio nombras a la persona concreta; para un transportista basta con la empresa, porque el mensajero es suyo. Indica la distancia estimada de la entrega. Confirma. La distancia importa La distancia que introduces se usa como la distancia de la entrega. Alimenta las cifras de repartidores y cualquier informe o liquidación basada en distancia. Estímala con honestidad desde la tienda hasta la dirección de entrega. Un valor de relleno —cero, o un número redondo puesto para pasar el campo— corrompe en silencio todo lo que se calcule a partir de él, y nadie lo notará hasta que alguien cuestione los números meses después. Registra siempre también una incidencia Una entrega forzada sin incidencia es lo más difícil de reconstruir después: el registro muestra una entrega normal, sin nada que explique por qué una persona tuvo que cerrarla a mano. Registra una incidencia describiendo por qué hizo falta forzar: fallo de dispositivo, silencio del transportista, lo que fuera. Ver Registrar una incidencia. Si no lo tienes claro Haz algo reversible. Cambia la hora prometida, registra una incidencia, o deja el pedido en paz y escala. Todas las demás acciones del Hub se pueden sortear después; esta no. Tiendas y alertas de repartidor Necesitas: Hub — pedidos y estado para la vista de tiendas, Hub — alertas de repartidor para las alertas. Junto al tablero de pedidos, el Hub muestra el estado de tus tiendas y levanta alertas sobre repartidores. La vista de tiendas Una vista operativa por tienda de las que están dentro de tu scope: qué tiene cada una en juego ahora mismo, para detectar de un vistazo cuál necesita atención en lugar de leer todo el tablero de pedidos. Úsala como punto de entrada en un servicio con volumen. Localiza la tienda que se ve mal y luego baja a sus pedidos. Esta es la vista operativa de una tienda en el Hub. Cambiar cómo se comporta una tienda —tolerancias de retraso, pausar el reparto— se hace en otro sitio; ver Ajustes de reparto de la tienda y Pausar y reanudar el reparto. Alertas de repartidor Las alertas de repartidor señalan repartidores cuyo comportamiento hay que mirar, no pedidos que van tarde. La más habitual es la de retraso en la recogida: un repartidor lleva demasiado tiempo en la tienda sin salir con un pedido que ya está listo. Se dispara con la misma determinación de "en la tienda" que usa el dispatcher para la prioridad, unos 350 metros. Ver Clasificación y prioridad de repartidores para qué significa "en la tienda" y en qué otros sitios se usa. Otras cubren repartidores que parecen bloqueados o no disponibles de formas que afectarán a la asignación si se dejan estar. Actuar sobre una alerta Una alerta es un aviso, no una instrucción. Determina cuál de estos casos es: Qué encuentras Qué hacer El repartidor está realmente retenido en la tienda Una conversación operativa, no una acción en la consola El dispositivo o la conexión del repartidor se ha caído Puede que haya que reasignar sus pedidos — Asignar y desasignar un repartidor El repartidor ha terminado pero el sistema no lo sabe Puede que el pedido necesite Forzar una entrega; lee antes esa página La alerta salta demasiado en muchos repartidores El umbral está mal — Configuración de alarmas Una alerta suelta habla de un repartidor. Esa misma alerta saltando a la vez en muchos habla del umbral, o de algo sistémico en esa tienda. No vayas resolviendo cincuenta alertas una a una: revisa antes el umbral. Alertas, alarmas e incidencias Tres cosas que suenan parecido y son realmente distintas: Qué es Dónde Alerta de repartidor El sistema señalando el estado de un repartidor Esta página Alarma de tienda El sistema señalando el estado de una tienda Alarmas de tienda Incidencia Una persona dejando constancia de qué salió mal en un pedido Registrar una incidencia Las dos primeras se levantan automáticamente y tú respondes a ellas. La tercera la creas tú y queda como registro permanente en un pedido. Alarmas de tienda Necesitas: Hub — alarmas de tienda para verlas. Archivar requiere Hub — archivar alarmas, normalmente hub_manager. Las alarmas de tienda señalan que una tienda necesita atención, a diferencia de las alertas de repartidor, que señalan a una persona, y de las incidencias, que registras tú. Qué te dicen Una alarma salta cuando una tienda cruza un umbral configurado: demasiada carga, demasiadas cancelaciones, demasiados pedidos incumpliendo su hora prometida. Qué cuenta como "demasiado" es configurable por tipo de alarma — ver Configuración de alarmas. Una alarma es una señal, no un diagnóstico. Te dice dónde mirar, no qué está mal. Cómo atenderlas Mira la tienda, no la alarma. Abre sus pedidos y observa qué está pasando de verdad. Decide si es un problema operativo o de umbral. Una tienda con alarma durante un pico real es el sistema funcionando. Todas las tiendas con alarma cada mediodía significa que el umbral está mal. Actúa sobre el problema de fondo, si lo hay: reasignar, pausar el reparto, cambiar una hora prometida. Archiva la alarma una vez atendida. Archivar Archivar marca una alarma como atendida y la saca de la vista activa. No la borra: las alarmas archivadas siguen disponibles para revisión — ver Alarmas archivadas. Archiva cuando la alarma esté atendida o entendida, no simplemente vista. Una alarma archivada sin haberla mirado es peor que una que sigue activa, porque ahora parece resuelta para todos los demás. Archivar es un permiso superior al de ver, a propósito. Cualquiera en turno puede ver qué está saltando; decidir que algo está atendido es un criterio de responsable de turno. Cuando el tablero está lleno de alarmas Las alarmas que saltan constantemente dejan de leerse. Si una tienda o un tipo de alarma está permanentemente encendido: Contrasta el umbral con lo que esa tienda puede hacer de forma realista — Configuración de alarmas. Comprueba si es una misma causa raíz produciendo muchas alarmas, y no muchos problemas. Plantéate si las tolerancias de retraso de la tienda encajan con su realidad — Ajustes de reparto de la tienda. Ajustar un umbral para que salte cuando alguien deba actuar, y calle el resto del tiempo, vale más que despachar una lista larga. Páginas relacionadas Tiendas y alertas de repartidor — el equivalente del lado de repartidores Configuración de alarmas — dónde se configuran los umbrales Alarmas archivadas — revisar lo ya atendido Registrar una incidencia — dejar constancia de qué salió mal en un pedido concreto Configuración de alarmas Necesitas: Configuración de alarmas — ver para consultar, Configuración de alarmas — editar para cambiar. El rol dedicado es alarms_config_manager; admin también lo tiene. La configuración de alarmas decide cuándo salta una alarma. Aplica a toda la cadena, no por tienda. Las tres familias Tipo Vigila Ejemplo de lo que detecta Pedido Pedidos individuales Pedidos que llevan demasiado tiempo, o que han pasado su hora prometida Repartidor Repartidores Un repartidor demasiado tiempo en la tienda sin salir: la alerta de retraso en la recogida Tienda Tiendas Una tienda con demasiada carga, o con demasiadas cancelaciones Cada familia contiene varias alarmas individuales. Puedes consultar una familia, abrir una alarma y cambiar sus umbrales o desactivarla. De cadena, no por tienda Esto es lo que hay que interiorizar antes de tocar nada: un umbral aplica a todas las tiendas. Ajustar una alarma porque una tienda céntrica y con mucho volumen hace ruido también la reajusta para las tranquilas de extrarradio, donde puede que ya no salte nunca. Siempre estás cambiando un problema de falsos positivos en una tienda por uno de falsos negativos en otra. Si la necesidad real es realmente por tienda, un umbral de cadena no puede expresarla. Pon el umbral para la mayoría y gestiona el caso atípico operativamente, en vez de mover el número hasta que esa tienda calle. Cambiar un umbral Abre la familia de alarmas: pedido, repartidor o tienda. Abre la alarma concreta. Cambia el umbral, o desactiva la alarma. Guarda. Los cambios afectan a lo que salte a partir de entonces. No limpian retroactivamente las alarmas ya levantadas: esas se limpian archivándolas, ver Alarmas de tienda. Elegir un número Un buen umbral salta cuando alguien debe actuar y calla el resto del tiempo. Los dos fallos son reales: Demasiado sensible Demasiado laxo Salta constantemente Salta poco o nunca La gente deja de leer las alarmas Los problemas reales pasan desapercibidos Los problemas reales quedan enterrados en ruido Te enteras por las reclamaciones de clientes El segundo es más peligroso; el primero es más frecuente, y provoca el segundo, porque un tablero de alarmas que nadie lee es funcionalmente una alarma que nunca salta. Antes de cambiar un número, mira qué saltó realmente en las últimas una o dos semanas. Ajustar a partir de un turno malo concreto produce un umbral moldeado por un caso atípico. Desactivar una alarma Apagar una es legítimo cuando no aplica a vuestra forma de operar. No es la solución para una alarma que salta demasiado: eso es cuestión de umbral, y apagarla elimina la señal en lugar de afinarla. Anota qué apagaste y por qué. Una alarma desactivada en silencio hace un año es indistinguible de una que nunca salta. Páginas relacionadas Alarmas de tienda — actuar sobre las alarmas de tienda Tiendas y alertas de repartidor — actuar sobre las alertas de repartidor Alarmas archivadas — el histórico con el que ajustar Alarmas archivadas Necesitas: Alarmas archivadas — ver. Exportar requiere el permiso de exportación de métricas. hub_manager tiene la consulta; la exportación de cadena suele ser de admin. Archivar una alarma no la borra. Las alarmas archivadas se conservan y se pueden revisar después: el histórico es donde aparecen los patrones que ningún turno suelto deja ver. Dónde están Las alarmas archivadas viven en Métricas, no en el tablero del Hub en vivo. La separación es deliberada: el Hub es para lo que hay que atender ahora, Métricas es para lo que pasó. Para qué sirve el histórico Pregunta Cómo la responde el histórico ¿Esta tienda siempre está así? Compara su volumen de alarmas con tiendas equiparables en el mismo periodo ¿Nuestro umbral es sensato? Una alarma que se archiva en segundos cada vez está saltando demasiado pronto — ver Configuración de alarmas ¿Sirvió de algo aquel cambio? Compara las semanas anteriores y posteriores a un cambio de configuración ¿Sobre qué alarmas no actúa nadie? Un tipo de alarma que siempre se archiva de inmediato, sin que pase nada más, es ruido Ajustar umbrales con el histórico Esta es la razón principal de que exista el histórico. Antes de cambiar un umbral en Configuración de alarmas, mira qué hizo realmente esa alarma durante un periodo representativo: una quincena, no un turno malo. Hay dos patrones sobre los que merece la pena actuar: Salta constantemente y siempre se archiva al momento. Demasiado sensible. Súbelo, o apágala si no aplica a vuestra forma de operar. No salta nunca, pero el problema aparece en las reclamaciones de clientes. Demasiado laxo. Bájalo. Recuerda que los umbrales son de cadena: un cambio hecho para callar una tienda cambia todas. Exportar El histórico se puede exportar para analizarlo fuera de la consola. La exportación es un permiso aparte y superior al de consulta, porque una exportación deja atrás por completo los controles de acceso de la consola. Un fichero exportado ya no está filtrado por scope. Quien abra la hoja de cálculo verá todo lo que contenga, con independencia de lo que pudiera ver en la consola. Trata las exportaciones en consecuencia, y prefiere compartir una conclusión antes que el fichero en bruto. Páginas relacionadas Alarmas de tienda — la vista en vivo y el archivado Configuración de alarmas — dónde se cambian los umbrales Tiendas y alertas de repartidor — alertas del lado de repartidores Marketing Códigos promocionales, vouchers, promociones personales, suscripciones y saldo de monedero. La pantalla de Marketing Para acceder a la sección de gestión de códigos deberá acceder al menú MARKETING del panel central de la consola. En la barra lateral encontrará todas las secciones disponibles para consultar, editar, crear o expirar códigos: Códigos promocionales, Cupones, Promociones personales, Suscripciones de fidelidad y Wallets. Cada sección cargará una tabla con los datos sobre dichos códigos. En la parte superior de cada sección encontrará las opciones disponibles: Marcas: si usted dispone de varias marcas aparecerá un desplegable con dicha lista, deberá seleccionar la adecuada para su consulta. Si solo tiene una marca, este desplegable no aparecerá. Exportar CSV: obtiene en formato CSV los datos de la tabla cargada en la parte inferior. Importar CSV: carga una sección para poder importar un archivo CSV con los códigos nuevos que quiera utilizar. Cada sección tendrá unas especificaciones diferentes acordes a los códigos que desee importar. Solo se admiten archivos CSV y deberán cumplir estrictamente las especificaciones. Especificaciones e importación del CSV Si selecciona Mostrar especificaciones CSV se mostrará en pantalla toda la información necesaria para dicha sección: cómo debe ser la primera fila de cada CSV y, a continuación, una tabla con los campos necesarios, la descripción de cada campo y los valores permitidos. El botón SELECCIONAR CSV solo se habilitará si se han completado todos los campos requeridos (si los hubiese). Una vez seleccionado el archivo, si este es validado (cumple todos los requisitos), aparecerá un mensaje "Archivo validado correctamente" junto al archivo seleccionado, y se habilitará el botón Subir CSV. En el momento en que comience la importación aparecerá un mensaje informando sobre el estado del proceso, y al finalizar se mostrará un mensaje de confirmación. Si el archivo seleccionado no es válido, aparecerá el mensaje "No validado" junto al archivo, seguido de una lista con todos los errores encontrados. En ese momento solo podrá seleccionar otro archivo con esos errores corregidos; hasta obtener la validación correcta, el botón de subida no se habilitará. Otras acciones disponibles Nuevo código / cupón / …: se utiliza para dar de alta un solo registro en dicha sección. Cada sección tendrá sus propias especificaciones; si no se completan todas, el botón para guardar no se habilitará. Filtros de búsqueda: cada sección contiene filtros distintos; en algunos deberá rellenar varios campos para poder filtrar según ese criterio. Podrá reiniciar los filtros siempre que lo desee. Marketing: las cinco áreas Dirigido a: personal de marketing y de atención al cliente que emite promociones, vouchers, suscripciones y saldo de monedero. Necesitas: un permiso por área. Son independientes: tener uno no concede nada en los demás. Marketing cubre cinco áreas independientes. Se parecen y se comportan de forma parecida, pero cada una tiene sus datos, su permiso y sus reglas. Área Qué contiene Permiso Códigos promocionales Campañas y los cupones generados a partir de ellas Códigos promocionales — ver / editar Vouchers Vouchers de un solo uso por un importe fijo Voucher manager — ver / editar Promociones personales Promociones asociadas a clientes concretos Customer promo manager — ver / editar Suscripciones de fidelización Suscripciones de cliente Subscriptions manager — ver / editar Monederos Saldo de monedero del cliente y sus movimientos Wallet manager — ver / editar Cada área tiene además su propio permiso de importación CSV, distinto también de ver y editar. Quien puede editar registros de monedero no necesariamente puede importar saldo en bloque. Encontrar las pantallas Las cinco están bajo el menú Marketing, cada una con su sección en la barra lateral y la misma fila de opciones arriba: selector de marca, exportar, importar. La pantalla de Marketing recorre esa disposición con capturas, incluido el panel de especificaciones CSV que ofrece cada sección. Dos cosas comunes a las cinco Antes de usar cualquier área, lee estas dos páginas. Explican mecánicas que se repiten en todas y que causan la mayor parte de la confusión: Cómo funcionan los cambios masivos — el patrón comprobar → aplicar → seguir, y la regla que protege lo ya canjeado. Importar desde un CSV — qué aceptan los importadores y cómo se comportan los fallos. La regla que hace esto seguro En todas las áreas, las operaciones masivas actúan solo sobre registros que no se han canjeado. Un voucher que el cliente ya usó, un saldo ya gastado, un cupón ya aplicado a un pedido: nada de eso lo toca una actualización o un borrado masivo. Esto es lo que hace que los cambios masivos sean recuperables en la práctica: el peor caso es que cambies registros que nadie ha usado todavía. Donde esto sorprende es cuando el recuento sale más pequeño de lo esperado. Normalmente no es un problema de filtro: son los canjes quedando fuera, exactamente como debe ser. Elegir el área correcta Quieres… Área Lanzar una campaña con códigos que el cliente introduce Códigos promocionales Dar a un cliente un voucher de valor fijo Vouchers Asociar una oferta a clientes concretos Promociones personales Gestionar la suscripción de un cliente Suscripciones de fidelización Añadir o ajustar saldo de un cliente Monederos Se solapan menos de lo que parece. Un voucher es un importe fijo; un código promocional es una regla de campaña; el saldo de monedero es un balance. Elegir por qué recibe el cliente acierta casi siempre. Las páginas de este capítulo Tema Página La mecánica masiva común Cómo funcionan los cambios masivos La mecánica de importación común Importar desde un CSV Campañas, cupones, ofertas Códigos promocionales Importar códigos promocionales Importar códigos promocionales Vouchers de valor fijo Vouchers Ofertas para clientes concretos Promociones personales Suscripciones Suscripciones de fidelización Localizar el monedero de un cliente Monederos: localizar a un cliente Añadir y ajustar saldo Monederos: gestionar registros Qué puedes ver y qué no Todo aquí está delimitado a la marca en la que trabajas, y filtrado además por tu propio scope — ver Cómo funciona el scope en la práctica. Cómo funcionan los cambios masivos Las cinco áreas de Marketing se presentan en Marketing: las cinco áreas. Monederos, vouchers, promociones personales y códigos promocionales permiten cambiar muchos registros a la vez. Todos siguen la misma forma de tres pasos, y aprenderla una vez sirve para los cuatro. Los tres pasos Paso Qué hace Permiso 1. Comprobar Cuenta qué se vería afectado. No cambia nada El permiso de ver del área 2. Aplicar Lanza el cambio como un trabajo en segundo plano El permiso de editar del área 3. Seguir Sigue el trabajo hasta que termina El permiso de editar del área El paso de comprobación es deliberadamente inocuo y deliberadamente independiente. Existe para que veas el alcance antes de comprometerte con él. Haz siempre la comprobación. Tarda segundos y es la única vista previa que tienes. Un recuento que se ve raro —muy alto o muy bajo— significa que tus criterios están mal, y descubrirlo ahora es mucho más barato. El paso 2 corre en segundo plano Aplicar no termina mientras esperas. Devuelve un trabajo que se ejecuta por su cuenta, y tú sigues su progreso. Esto importa de tres maneras: Cerrar la pantalla no lo detiene. El trabajo continúa. El progreso se consulta por sondeo, así que la cifra que ves puede ir ligeramente por detrás de la realidad. Un trabajo en curso no es un trabajo fallido. Dale tiempo a un cambio grande antes de dar por hecho que algo va mal. Los registros ya canjeados nunca se tocan Toda operación masiva actúa solo sobre registros que no se han canjeado. Área Qué queda protegido Monederos Saldo ya gastado Vouchers Vouchers ya usados Promociones personales Promociones ya aplicadas a un pedido Códigos promocionales Cupones ya canjeados No puedes cambiar ni retirar retroactivamente un valor que el cliente ya recibió. Por eso las operaciones masivas son recuperables en la práctica, y por eso también un recuento sale a veces más bajo de lo esperado. Borrar y actualizar son operaciones distintas La actualización masiva cambia campos —normalmente fechas o importes— en los registros que coinciden. El borrado masivo los elimina. Ambas están protegidas por la misma regla de no canjeados y ambas tienen su propia comprobación. No son variantes de una misma acción: elige la que quieres. Los códigos promocionales funcionan distinto — lee esto Los códigos promocionales usan las mismas tres palabras para una operación materialmente distinta. En monederos, vouchers, promociones personales En códigos promocionales Comprobar cuenta los registros coincidentes Comprobar pregunta si la campaña tiene algún cupón canjeado Aplicar actualiza los registros coincidentes Aplicar borra la campaña entera y sus cupones, y solo si ninguno se ha canjeado Es decir: en códigos promocionales, "aplicar cambios masivos" es un borrado, condicionado a que la campaña esté completamente sin usar. Si aunque sea un cupón se ha canjeado, no procede. Para retirar una campaña que sí se ha usado, caduca en su lugar — ver Códigos promocionales. Es el solape de nomenclatura más peligroso del capítulo. En cuatro áreas "aplicar" significa actualizar; en códigos promocionales significa borrar una campaña. Comprueba en qué pantalla estás antes de pulsarlo. Una secuencia segura Ajusta tus criterios de forma estrecha. Comprueba y lee el recuento. Si el recuento te sorprende, para y averigua por qué. Aplica. Sigue hasta que termine. Revisa un par de registros afectados. Si un trabajo parece atascado Dale tiempo proporcional al recuento: decenas de miles de registros tardan. Si el progreso realmente deja de avanzar, no relances el "aplicar": un segundo trabajo con los mismos criterios puede sumarse al primero. Repórtalo indicando el área, los criterios y aproximadamente cuándo lo lanzaste. Importar desde un CSV Cuatro de las áreas descritas en Marketing: las cinco áreas aceptan un CSV, para emitir algo a muchos clientes de una vez. Importación Qué crea Permiso Promociones personales Una promoción por cliente, desde una lista de teléfonos Promociones personales — importar Suscripciones de fidelización Una suscripción por cliente, desde una lista de teléfonos Suscripciones — importar Saldo de monedero Saldo por cliente, desde una lista de teléfonos Wallet codes — importar Vouchers Códigos de voucher Voucher codes — importar Los códigos promocionales también se importan desde CSV, pero con un seguimiento de progreso que las demás no tienen; tienen su propia página, Importar códigos promocionales. Cada permiso de importación es independiente de los de ver y editar del área. Poder crear registros de monedero de uno en uno no implica poder cargar miles desde un fichero. Listas de teléfonos Tres de las cuatro identifican al cliente por número de teléfono. El fichero es una lista de teléfonos más lo que necesite la importación: un importe, unas fechas. Los teléfonos son donde fallan estas importaciones. Antes de importar: Comprueba que el formato coincide con cómo se guardan los teléfonos en esta marca: con prefijo de país o sin él, con espacios o sin ellos. Si no coincide, las filas no encuentran a ningún cliente, en silencio. Cuidado con el daño de la hoja de cálculo. Excel y Google Sheets tienden a quitar ceros a la izquierda y a convertir números largos en notación científica. Una columna con formato de texto sobrevive; una con formato de número puede que no. Elimina duplicados. El mismo teléfono dos veces suele significar que ese cliente recibe el beneficio dos veces. Antes de cualquier importación Empieza con unas pocas filas. Importa cinco, confirma que quedaron como querías y luego importa el resto. Esto detecta problemas de formato al precio de cinco registros en vez de cinco mil. Ten claro qué pasa con un cliente que ya tiene algo. Que una segunda importación sume o sustituya decide si relanzar un fichero es seguro. Guarda el fichero. Es el único registro de qué enviaste exactamente, y la única forma de revertirlo si hace falta. Las importaciones no son transaccionales Una importación que falla a medias no deshace lo que ya hizo. Unos clientes habrán recibido el beneficio y otros no. Por eso importa la prueba pequeña, y por eso relanzar un fichero entero tras un fallo parcial es arriesgado: las filas que ya funcionaron pueden aplicarse por segunda vez. Si una importación falla a medias, averigua dónde se detuvo antes de decidir qué hacer; no la reenvíes sin más. Después de importar Comprueba dos o tres clientes del fichero y confirma que recibieron lo previsto, con el importe y las fechas correctas. La pantalla de consulta del área es el sitio: Promociones personales, Suscripciones de fidelización, Monederos: localizar a un cliente o Vouchers. Si necesitas deshacer una No hay "deshacer importación". Lo que tienes es un borrado masivo, que elimina los registros coincidentes no canjeados — ver Cómo funcionan los cambios masivos. Todo lo que los clientes ya canjearon se queda. Es el límite honesto de revertir una importación: puedes recuperar lo que no se ha usado, no lo que sí. Códigos promocionales Necesitas: Códigos promocionales — ver para consultar, Códigos promocionales — editar para crear o cambiar algo. Los códigos promocionales se organizan como campañas que generan cupones. Entender bien esa relación hace evidente el resto de la pantalla. Término Qué es Código promocional La regla: en qué consiste el descuento y cuándo es válido Campaña Un código promocional más el conjunto de cupones generados a partir de él Cupón Un código individual que el cliente introduce realmente Una campaña se crea junto con su primer cupón. Después le vas añadiendo más cupones según haga falta. Consultar El listado principal admite filtros y paginación. Desde una campaña puedes abrir sus cupones generados —los códigos individuales— y verlos o editarlos de uno en uno. Ofertas activas es una vista aparte: las ofertas vigentes para una tienda dada, con el detalle de cualquiera de ellas. Úsala para responder "qué puede ofrecer esta tienda ahora mismo", que no es la misma pregunta que "qué campañas existen". Crear Para crear Usa Un código promocional suelto Crear código promocional Una campaña, con su primer cupón Crear campaña Otro cupón en una campaña existente Añadir cupón Crea primero la campaña y añade después los cupones. Crear códigos sueltos que en realidad debían ser una campaña te deja sin poder gestionarlos en conjunto más adelante. Editar Dos ediciones distintas, en dos niveles: El código promocional — sus fechas, el día de renovación y las horas en que es válido. Un cupón generado concreto — un código específico dentro de una campaña. Editar el código cambia la regla de la campaña. Editar un cupón cambia un único código de cara al cliente. Si un cliente reporta un problema con un código, el nivel correcto suele ser el cupón. Caducar frente a borrar Es la decisión que más importa, y no son intercambiables. Caducar Borrar Qué hace Pone la fecha de fin en hoy: el código deja de funcionar desde ya Elimina la campaña y sus cupones por completo Cupones canjeados Sin problema, el histórico se conserva Bloqueado. No procede si algún cupón se ha canjeado Reversible El registro sigue existiendo No Cuándo usarlo Una campaña viva debe detenerse Una campaña creada por error y nunca usada Caducar es casi siempre la respuesta correcta. Detiene la campaña conservando el registro de lo ocurrido, que es justo lo que necesitas cuando un cliente pregunta por qué dejó de funcionar su código. Existe además una caducidad masiva, que marca todos los cupones de una campaña como usados de una vez. Úsala para cerrar una campaña del todo en lugar de dejar cupones sin canjear rondando. Borrar una campaña es la operación que en esta pantalla aparece como "aplicar cambios masivos", un solape de nomenclatura que en el resto de Marketing significa otra cosa. Lee Cómo funcionan los cambios masivos antes de usarla. Si el código de un cliente no funciona Comprueba en este orden: ¿La campaña sigue dentro de sus fechas? Incluidas las horas válidas, no solo los días. ¿Ese cupón concreto ya se canjeó? Abre los cupones generados y míralo. ¿La oferta está vigente para esa tienda? Consulta las ofertas activas de esa tienda: una campaña puede existir sin ofrecerse en todas partes. ¿Se caducó de forma masiva? Una campaña cerrada tiene todos sus cupones marcados como usados. Páginas relacionadas Importar códigos promocionales — cargar códigos desde un fichero Cómo funcionan los cambios masivos — antes de cualquier operación masiva aquí Promociones personales — para ofertas asociadas a clientes concretos Importar códigos promocionales Necesitas: Códigos promocionales — editar. Los códigos promocionales son la única importación con seguimiento completo del trabajo. A diferencia de las otras importaciones CSV de Importar desde un CSV, aquí ves el progreso de una importación en curso y se te avisa si ya tienes una en marcha. Una importación activa a la vez, por persona La importación lleva el control de tu trabajo activo. Antes de empezar, la pantalla te dice si ya tienes uno en curso. Es una protección, no una limitación. Evita el accidente habitual: lanzar una importación, no ver respuesta inmediata y volver a lanzarla, lo que aplicaría el mismo fichero dos veces. Qué ves Qué significa Sin importación activa Vía libre para empezar Una importación activa La tuya sigue en curso. Obsérvala en lugar de lanzar otra Una importación activa que no reconoces Algo que lanzaste antes y dejaste. Mira su progreso antes de limpiarla Ejecutar una Comprueba que no tienes ya una importación activa. Sube el CSV. Sigue el progreso mientras se ejecuta. Confirma el resultado antes de decirle a nadie que los códigos están activos. Progreso La cifra de progreso se consulta por sondeo, así que va ligeramente por detrás: que un número no se mueva durante unos segundos es normal. Los ficheros grandes tardan proporcionalmente más. Cerrar la pantalla no detiene la importación. Se ejecuta hasta el final por su cuenta, y puedes volver a su progreso. Limpiar un trabajo activo atascado Puedes limpiar tu importación activa. Conviene ser preciso sobre qué significa eso: Limpiar elimina el registro de que tienes una importación en curso. No deshace las filas ya importadas, y no es un botón de cancelar. Úsalo cuando un trabajo esté realmente terminado o abandonado y te esté impidiendo empezar otro, no para detener una importación en marcha de la que te has arrepentido. Si limpias un trabajo y relanzas el mismo fichero, las filas que ya se importaron pueden aplicarse dos veces. Comprueba antes qué llegó a entrar. Antes de importar Aplican los consejos generales de Importar desde un CSV, en particular: Prueba primero con unas pocas filas. Confirma que el formato se acepta antes de comprometer un fichero grande. Guarda el fichero. Es tu registro de qué se emitió exactamente. Las importaciones no son transaccionales. Un fallo a medias deja en su sitio las filas anteriores. Después de importar Abre el listado de códigos promocionales y confirma que existen con las fechas y la validez esperadas — ver Códigos promocionales. Si deben formar parte de una campaña, confírmalo también, porque la relación con una campaña es difícil de añadir después. Si sale mal Eliminar códigos importados usa el borrado de campaña descrito en Códigos promocionales, que solo procede cuando nada se ha canjeado. En cuanto los clientes empiezan a usar códigos, se quedan: caduca la campaña en su lugar. Vouchers Necesitas: Voucher manager — ver para consultar, Voucher manager — editar para crear o cambiar. Importar requiere Voucher codes — importar, que es otro permiso distinto. Un voucher es un importe fijo que el cliente puede canjear una vez. Más simple que un código promocional: no hay campaña ni regla, solo un valor y un periodo de validez. Consultar El listado muestra los vouchers disponibles —los que no se han canjeado— de la marca. Los vouchers canjeados no están en este listado. Es deliberado: la pantalla es para los que siguen en juego. Si buscas uno que el cliente dice haber usado, su ausencia aquí es la respuesta. Crear uno Crea el voucher con su importe y su validez. Es la vía correcta para un cliente concreto: una compensación, un gesto comercial, algo puntual. Para muchos vouchers a la vez, impórtalos — ver Importar desde un CSV. Editar Puedes actualizar un voucher existente: su importe, sus fechas. Solo se pueden cambiar los vouchers que no se han canjeado, que es la misma regla que protege las operaciones masivas. Caducar Caducar termina uno o varios vouchers de inmediato. Úsalo cuando un voucher se emitió por error, o cuando se retira una promoción. Caducar es la opción segura: el registro sobrevive, así que sigue habiendo una respuesta cuando el cliente pregunte qué pasó. Cambios masivos Los vouchers siguen el patrón estándar — lee antes Cómo funcionan los cambios masivos. Las operaciones masivas de vouchers coinciden por fecha de inicio, fecha de fin, importe y días de validez en conjunto. Los cuatro forman el criterio; no son filtros que puedas rellenar a medias y confiar en la suerte. Operación Efecto Comprobar Cuenta los vouchers no canjeados que coinciden con los cuatro criterios Actualización masiva Actualiza todos los vouchers no canjeados coincidentes Borrado masivo Elimina todos los vouchers no canjeados coincidentes Como el criterio es una combinación, es fácil abarcar más de lo previsto. Haz la comprobación y lee el recuento: es la única vista previa. Solo se ven afectados los vouchers no canjeados. Un cliente que ya usó el suyo conserva el beneficio, hagas lo que hagas aquí. Elegir entre un voucher y saldo de monedero Se parecen y se comportan distinto: Voucher Saldo de monedero Forma Un importe fijo, de un solo uso Un balance que se va gastando Bueno para Un gesto concreto con un valor claro Crédito continuo, devoluciones, saldo de fidelización Caducidad Por voucher Por registro de saldo Si el cliente debe tener "10 € de descuento en un pedido", eso es un voucher. Si debe tener "10 € para gastar", eso es saldo de monedero — ver Monederos: gestionar registros. Páginas relacionadas Cómo funcionan los cambios masivos — antes de cualquier operación masiva Importar desde un CSV — emitir vouchers en bloque Monederos: gestionar registros — la otra forma de crédito Promociones personales Necesitas: Customer promo manager — ver para consultar, … — editar para cambiar. Importar requiere Promociones personales — importar, otro permiso distinto. Una promoción personal asocia una oferta existente a un cliente concreto. Mientras que un código promocional es algo que cualquier cliente puede introducir, esto se le concede a una persona. Qué se puede asociar La vista de promociones disponibles lista lo que se puede asociar para una tienda dada. Deliberadamente no es el catálogo completo: muestra ofertas que están: ocultas — no anunciadas públicamente, pensadas para concederse de forma individual; añadidas manualmente — diseñadas exactamente para esto; no caducadas. Si una oferta que esperabas no aparece, suele ser por una de esas tres razones: es una oferta pública en lugar de concedible, o ha caducado. Es el listado haciendo su trabajo, no un registro que falte. Consultar registros existentes Busca registros de promociones de cliente para ver qué tiene ya un cliente, o para revisar qué se concedió en una campaña de concesiones individuales. Conceder una Localiza la oferta en promociones disponibles para la tienda correspondiente. Crea el registro sobre el cliente. Fija las fechas entre las que es válida. Para muchos clientes a la vez, importa una lista de teléfonos — ver Importar desde un CSV. Cambiar y eliminar Acción Se aplica a Nota Actualizar fechas Solo registros no canjeados Ampliar o acortar la validez Borrar Solo registros no canjeados Elimina la concesión por completo Ambas se limitan a registros que el cliente no ha usado. Una vez canjeada, una promoción personal forma parte del histórico de ese cliente y se queda. Para retirar una oferta que el cliente no ha usado, acortar las fechas es más suave que borrar: el registro sobrevive, así que hay respuesta si pregunta. Cambios masivos Las promociones personales siguen el patrón estándar — lee antes Cómo funcionan los cambios masivos. Aquí el criterio es un código de promoción u oferta: actúas sobre todos los registros que conceden esa oferta concreta. Operación Efecto Comprobar Cuenta los registros que coinciden con el código de promoción/oferta Actualización masiva Cambia las fechas de inicio y fin en todos los registros no canjeados coincidentes Borrado masivo Elimina todos los registros no canjeados coincidentes Así se corrige una campaña de concesiones que salió con las fechas equivocadas, sin tocar a los clientes que ya usaron la suya. Elegir entre esto y un código promocional Promoción personal Código promocional Quién puede usarla Un cliente concreto Cualquiera que tenga el código Cómo la recibe Se le concede Introduce un código Buena para Recuperación, trato VIP, compensación Campañas públicas Si te encuentras concediendo la misma oferta a cientos de clientes de uno en uno, probablemente la herramienta adecuada sea una campaña con cupones — ver Códigos promocionales. Páginas relacionadas Cómo funcionan los cambios masivos — antes de cualquier operación masiva Importar desde un CSV — conceder desde una lista de teléfonos Códigos promocionales — la alternativa de campaña pública Suscripciones de fidelización Necesitas: Subscriptions manager — ver para consultar, … — editar para cambiar. Importar requiere Suscripciones — importar, otro permiso distinto. Una suscripción da a un cliente un beneficio continuado durante un periodo, en lugar de un código o un importe de un solo uso. Es el área más pequeña de Marketing: consultar, crear, actualizar, caducar. Aquí no hay operaciones masivas; los cambios son por suscripción, o mediante una importación. Encontrar una suscripción Busca de las dos formas: Por cliente — todo lo que tiene ese cliente. Más recientes — consulta las últimas suscripciones de la marca, para una vista general de lo emitido. Buscar por cliente es la vía habitual cuando alguien contacta. Crear una Crea la suscripción sobre el cliente con su periodo. Para muchos clientes a la vez, importa una lista de teléfonos — ver Importar desde un CSV. Actualizar Una suscripción existente se puede actualizar, normalmente sus fechas. Úsalo para ampliarla, o para corregir una introducida mal. Caducar Caducar fija el fin de la suscripción en hoy. Detiene el beneficio a partir de ahora sin eliminar el registro de que existió. Aquí no hay borrado, y es el diseño correcto: una suscripción que un cliente ha tenido forma parte de su histórico. Caducar es la respuesta completa a "esto debe parar". Como la caducidad cae en hoy y no en una fecha que elijas, surte efecto de inmediato. Si el cliente debe conservar el beneficio hasta el final de un periodo pagado, actualiza la fecha de fin en lugar de caducar. Situaciones habituales Situación Qué hacer El cliente dice que su suscripción terminó antes de tiempo Revisa la fecha de fin; actualízala si se introdujo mal El cliente quiere cancelar Caduca, o pon la fecha de fin al final de su periodo pagado Suscripción creada sobre el cliente equivocado Caduca esa y crea la correcta. No hay borrado Emitir suscripciones en bloque Importa una lista de teléfonos — Importar desde un CSV Elegir entre una suscripción y las alternativas Suscripción Promoción personal Saldo de monedero Forma Beneficio continuado durante un periodo Una oferta concreta, concedida una vez Un balance que se gasta Termina por Fecha Uso, o fecha Gastarse, o fecha Si el beneficio es "envío gratis durante tres meses", eso es una suscripción. Si es "20 % en su próximo pedido", eso es una promoción personal — ver Promociones personales. Páginas relacionadas Importar desde un CSV — emitir suscripciones en bloque Promociones personales — ofertas concedidas de un solo uso Monederos: gestionar registros — beneficios con forma de saldo Monederos: localizar a un cliente Necesitas: Wallet manager — ver. La mayor parte del trabajo con monederos empieza con un cliente al teléfono. Esta página explica cómo pasar de lo que el cliente puede decirte a lo que necesitas en pantalla. Empieza por el número de teléfono Los clientes conocen su número de teléfono. Rara vez conocen su ID de cliente. La búsqueda por teléfono resuelve un número a un cliente, que es el identificador que usan el resto de pantallas de monedero. Empieza aquí. Si la búsqueda no encuentra a nadie, la causa habitual es un formato que no coincide —prefijo de país, espacios— y no que el cliente no exista. Prueba la variante que guarda la marca antes de concluir que no tiene cuenta. La misma trampa afecta a las importaciones CSV, ver Importar desde un CSV. Consulta el saldo Con el cliente identificado, el saldo responde a la primera pregunta: cuánto crédito tiene ahora mismo. El saldo es el resultado neto de sus registros de monedero. Cuando no coincide con lo que el cliente espera, los registros explican por qué: algunos pueden haber caducado, otros pueden estar ya gastados. Lee los registros Los registros de monedero son los movimientos individuales que componen el saldo. Buscarlos, filtrados a ese cliente, muestra cómo se llegó a ese saldo. Aquí es donde se responde a "tenía 20 € y ahora tengo 5": o el crédito se gastó, o un registro llegó a su fecha de fin. Abre el pedido que hay detrás de un registro Cuando un registro está vinculado a un pedido, puedes abrir el detalle completo de ese pedido. Esto cierra el círculo en la disputa más habitual: "me cobraron aunque tenía saldo". El detalle del pedido muestra qué se aplicó realmente. Un orden de trabajo para una llamada Teléfono → cliente. Confirma que tienes a la persona correcta. Saldo. ¿Qué tiene ahora? Registros. ¿Cómo llegó a eso? Detalle del pedido, cuando un registro apunta a uno. ¿Qué se aplicó realmente? Para el paso 4 normalmente puedes explicar la diferencia sin cambiar nada, que es el mejor desenlace: añadir saldo para cerrar una conversación oculta la causa de fondo. Cuando la respuesta es que algo está mal Si los registros muestran realmente un error, corregirlo está en Monederos: gestionar registros: crear un registro de corrección, ajustar uno o caducarlo. Es preferible un registro nuevo de corrección a editar el histórico. Deja el original visible junto a la corrección, que es lo que necesita ver quien revise esto más adelante. Páginas relacionadas Monederos: gestionar registros — crear y ajustar saldo Cómo funcionan los cambios masivos — antes de tocar muchos registros Vouchers — para un gesto de importe fijo en lugar de un saldo Monederos: gestionar registros Necesitas: Wallet manager — editar para crear o cambiar registros. Consultar solo requiere el permiso de ver. Importar saldo requiere Wallet codes — importar, otro permiso distinto. Un registro de monedero es un movimiento de saldo. El saldo del cliente es el neto de sus registros, así que nunca editas un saldo directamente: añades o ajustas los registros que hay detrás. Añadir saldo Crea un registro sobre el cliente con su importe y las fechas entre las que es válido. Es la vía manual: compensación, gesto comercial, corrección. Para muchos clientes a la vez, importa una lista de teléfonos — ver Importar desde un CSV. Pon una fecha de fin de forma deliberada. Un saldo con una vida innecesariamente larga es un pasivo que queda en los libros; un saldo que caduca antes de lo que el cliente espera se convierte en una reclamación. Elige la fecha a propósito en lugar de aceptar un valor por defecto. Ajustar un registro De un registro existente se pueden actualizar la fecha de fin y el importe. Úsalo para corregir un error real de introducción de datos. Para cualquier cosa que el cliente ya haya visto, es preferible añadir un registro de corrección: editar el original reescribe lo que se le dijo al cliente y deja a todo el mundo sin poder ver qué pasó. Caducar registros Caducar termina uno o varios registros de inmediato. El saldo deja de poder gastarse a partir de ahora, y el registro sigue visible. Es la herramienta adecuada para saldo emitido por error, o para cerrar una promoción. Es más suave que borrar y conserva la explicación. Cambios masivos Los monederos siguen el patrón estándar — lee antes Cómo funcionan los cambios masivos. El criterio son fecha de inicio, fecha de fin, importe y, opcionalmente, un comentario. Operación Efecto Comprobar Cuenta los registros no canjeados que coinciden con los criterios Actualización masiva Actualiza todos los registros no canjeados coincidentes Borrado masivo Elimina todos los registros no canjeados coincidentes El comentario es el criterio más útil que tienes. Si etiquetas un lote con un comentario distintivo al crearlo, después puedes actuar exactamente sobre ese lote y sobre nada más. Sin él estás casando por fechas e importe, lo que acabará alcanzando registros de otra campaña que casualmente los compartan. El saldo ya gastado nunca se ve afectado, hagas lo que hagas aquí. Decidir qué hacer Situación Acción Hay que compensar a un cliente Crear un registro Saldo emitido con el importe equivocado Crear un registro de corrección; no editar el original Saldo emitido al cliente equivocado Caducarlo y crearlo en el cliente correcto Todo un lote emitido con las fechas equivocadas Actualización masiva, casando por el comentario del lote Un lote que nunca debió salir Borrado masivo: elimina solo lo que nadie ha gastado Antes de cualquier operación masiva Haz la comprobación y lee el recuento. Si no es lo que esperabas, tus criterios están mal, sobre todo si estás casando sin comentario. Aplica y sigue hasta que termine. Revisa un cliente del lote en Monederos: localizar a un cliente. Páginas relacionadas Monederos: localizar a un cliente — búsqueda, saldo y registros Cómo funcionan los cambios masivos — el patrón común Importar desde un CSV — emitir saldo en bloque Vouchers — un importe fijo de un solo uso en lugar de un saldo CMS Contenido web: árbol de reclamaciones, recursos, banners y documentos. CMS: qué cubre Dirigido a: editores de contenido que mantienen lo que ven los clientes en los canales de pedido. Necesitas: CMS — ver para consultar, CMS — editar para cambiar, CMS — borrar para eliminar. Tres niveles distintos. El CMS cubre la capa de contenido de la experiencia de pedido: las imágenes y textos que ve el cliente, y la estructura de reclamaciones que hay detrás de atención al cliente. Dos áreas Área Qué contiene Recursos Banners, logos, documentos y la presentación de promociones, productos, ingredientes y métodos de pago Reclamaciones El árbol de tipos de reclamación que se usa al registrar una reclamación de cliente Comparten permisos, pero por lo demás son independientes. Tres niveles de permiso, no dos La mayoría de áreas de la consola tienen ver y editar. El CMS tiene un tercero: Nivel Te permite Ver Consultar recursos y el árbol de reclamaciones Editar Crear y cambiar recursos, y añadir o editar nodos de reclamación Borrar Eliminar un nodo del árbol de reclamaciones Borrar está separado a propósito. Quitar un nodo del árbol cambia cómo se categorizan las reclamaciones a partir de ese momento, y eso es más difícil de revertir que editar una etiqueta. cms_editor es el rol pensado para esta área y tiene los tres. El contenido es por fuente Este es el concepto que hace comprensible el resto del CMS. Los recursos se guardan por fuente: web, app, quiosco, cada agregador. La misma marca puede mostrar un banner distinto en web y en app, porque son registros distintos. Así que cuando editas un recurso siempre lo estás editando para una fuente. Cambiar el banner de la web no cambia el de la app. Esto también significa que "el banner no ha cambiado" suele ser la fuente equivocada seleccionada y no un guardado fallido. Comprueba el selector antes de volver a subir la imagen. Tu propio scope puede limitar además qué fuentes ves — ver Cómo funciona el scope en la práctica. Las páginas de este capítulo Tema Página Tipos de recurso y el selector de fuente Recursos y fuentes Encontrar contenido incompleto Validación de contenido El árbol de reclamaciones El árbol de reclamaciones Editar banners, paso a paso CMS - Recursos: Banners Documentos por idioma CMS - Recursos: Documentos La pantalla de recursos CMS - Recursos Cargar reclamaciones desde un fichero CMS - Carga CSV de Reclamaciones Recursos y fuentes Necesitas: CMS — ver para consultar, CMS — editar para cambiar. Los recursos son los registros de contenido detrás de lo que ve el cliente. Esta página cubre el modelo; CMS - Recursos recorre la pantalla con capturas. Los tipos de recurso Tipo Qué controla Banners Imágenes promocionales y a dónde enlazan Logos Imagen de marca Promociones Cómo se presentan las promociones Productos Cómo se presentan los artículos Ingredientes Cómo se presentan ingredientes y extras Métodos de pago Qué opciones de pago aparecen, y cómo Editar aquí cambia la presentación, no el comportamiento. Las reglas de una promoción viven en Códigos promocionales; lo que ve el cliente cuando se le ofrece vive aquí. Lo mismo vale para productos y métodos de pago. Elige siempre primero la fuente Cada recurso pertenece a una fuente: web, app, quiosco, un agregador. Seleccionar la fuente es lo primero que haces, no algo posterior. Si un tipo no tiene contenido para la fuente elegida, la pantalla lo dice. Esa es una respuesta real: significa que no hay nada configurado para esa combinación, no que la pantalla haya fallado. Qué ves Qué significa Contenido en el listado Ese tipo está configurado para esa fuente "No hay datos disponibles" Nada configurado para ese tipo y esa fuente Una fuente que no aparece Fuera de tu scope, o no habilitada para la marca Idiomas Varios tipos de recurso son por idioma además de por fuente, en particular banners y documentos. Un banner existe una vez por idioma, y cada idioma necesita su propia imagen y su destino. Eso significa que un recurso no está completo hasta que todos los idiomas están rellenos. Una traducción que falta aparece como un hueco solo para los clientes de ese idioma, que es justo el tipo de cosa que internamente no nota nadie. CMS - Recursos: Banners cubre el flujo de banners por idioma, y CMS - Recursos: Documentos el de documentos. Antes de dar por terminado Confirma que la fuente que editaste era la que querías. Revisa todos los idiomas de ese recurso, no solo aquel por el que te preguntaron. Ejecuta la lista de validación para detectar lo que quedó incompleto — ver Validación de contenido. Validación de contenido Necesitas: CMS — ver. La lista de validación muestra los recursos incompletos: los huecos que, si no, solo aparecerían como algo que falta en la pantalla de un cliente. Por qué existe Los recursos se guardan por fuente y, en varios tipos, por idioma. Eso produce muchas combinaciones, y un hueco en cualquiera de ellas es invisible salvo que lo busques: los clientes afectados son los de esa fuente concreta, en ese idioma concreto. La validación es esa búsqueda, hecha por ti. Cuándo ejecutarla Momento Por qué Tras un cambio masivo de contenido La forma más rápida de ver qué no entró Antes de lanzar una campaña Un banner que falta en una fuente es una campaña que se lanzó a medias Al añadir una fuente o un idioma nuevo Todo es un hueco hasta que deja de serlo De forma rutinaria El contenido se degrada según cambian productos y promociones a su alrededor Ejecutarla antes de un lanzamiento vale más que después. Un hueco detectado la víspera es un arreglo; detectado al día siguiente, es una incidencia. Cómo leerla Cada entrada apunta a una combinación concreta: un tipo, una fuente y, cuando aplica, un idioma. Es suficiente para ir directo a la pantalla correcta y rellenarlo. Trabaja por fuente en lugar de bajando por la lista. Arreglar de una pasada todo lo que falla en la web es más rápido que saltar entre fuentes, porque mantienes el mismo selector. No todo lo listado es un problema Un hueco solo es un problema si esa combinación debería tener contenido. Si tu marca no usa el quiosco, que los recursos de quiosco estén vacíos es lo correcto. Aprende qué combinaciones importan en tu marca; a partir de ahí la lista es corta y cada entrada significa algo. Páginas relacionadas Recursos y fuentes — el modelo detrás de las combinaciones CMS - Recursos — la pantalla, con capturas El árbol de reclamaciones Necesitas: CMS — ver para consultar, CMS — editar para añadir o cambiar, CMS — borrar para eliminar. El árbol de reclamaciones es la estructura de tipos de reclamación que se usa al registrar una reclamación de cliente. Es lo que hace las reclamaciones contabilizables: un árbol que todos usan igual convierte molestias sueltas en un patrón sobre el que actuar. Consultar El árbol es una jerarquía de nodos: categorías amplias arriba, tipos concretos debajo. Consúltalo para ver la estructura actual antes de cambiar nada. Añadir y editar un nodo Añade un nodo bajo el padre correcto, o edita uno existente. Cambiar una etiqueta la cambia en todas partes, incluidas las reclamaciones ya registradas bajo ella. Eso suele ser lo que quieres al corregir una redacción. No lo es cuando cambia el significado: si el nodo debe significar ahora otra cosa, añade uno nuevo y deja de usar el anterior. Borrar un nodo Borrar tiene su propio permiso, y con motivo. Quitar un nodo cambia cómo se pueden categorizar las reclamaciones a partir de ese momento, y las reclamaciones ya registradas bajo él pierden la estructura que las explicaba. Antes de borrar, pregúntate: Pregunta Si la respuesta es sí ¿Se han registrado reclamaciones bajo él? Es preferible dejar de usarlo a borrarlo ¿Es un duplicado de otro nodo? Consolida deliberadamente, y anota cuál absorbió a cuál ¿Se creó por error y nunca se usó? Se puede borrar sin problema Mantén el árbol pequeño Un árbol que crece un nodo por incidencia deja de ser útil: con sesenta opciones nadie elige de forma consistente, y los recuentos no significan nada. Dos pruebas antes de añadir un nodo: ¿Otra persona elegiría este nodo para la misma reclamación? Si se solapa con uno existente, se usará de forma inconsistente. ¿Actuarías distinto ante esto que ante el nodo vecino? Si no, no hace falta que esté separado. Cargar muchos de una vez El árbol se puede cargar desde un fichero en lugar de construirlo nodo a nodo — ver CMS - Carga CSV de Reclamaciones, que cubre el formato y el flujo en detalle. Como en toda importación, empieza pequeño y confirma la estructura antes de cargarlo todo. Páginas relacionadas CMS - Carga CSV de Reclamaciones — carga masiva, en detalle CMS: qué cubre — permisos y las dos áreas del CMS Registrar una incidencia — el registro por pedido del Hub, que es otra cosa CMS - Carga CSV de Reclamaciones Resumen El sistema de carga de CSV para la Gestión de Reclamaciones permite subir y gestionar los datos del flujo de reclamaciones mediante dos archivos CSV: uno en inglés y otro en árabe. El sistema incluye validación, funcionalidad de vista previa y gestión de errores para garantizar la integridad de los datos. Leyenda de códigos de referencia Acciones Código Definición X Ir al siguiente nodo Q Pregunta al cliente QP Pedir prueba al cliente, subir foto S Mostrar el pedido del cliente para elegir un artículo CB Devolver llamada al cliente R Reembolso R30 Reembolso del 30% del artículo por defecto T Valoración TT Transferencia del ticket a un agente para evaluación manual QD Cuadro de diálogo QPD Cuadro de diálogo y subida de foto PHONE Facilitar el teléfono del repartidor en el campo variable {%phone%} R100P150 Reembolso del 100% del valor del pedido, hasta 150 SAR Estado Código Definición CA Cerrado - Abandonado C Cerrado O Abierto Condiciones Código Definición NOPHONE El teléfono del repartidor no está disponible YESPHONE El teléfono del repartidor está disponible RP Reembolso de Garantía Platinum procesado RNP Reembolso de Garantía no procesado GSE Suscripción Gold caducada GSNE Suscripción Gold no caducada GTP El cliente pasó de Gold a Platinum PSE Suscripción Platinum caducada PSNE Suscripción Platinum no caducada SLABD30 Incumplimiento del SLA de entrega - Garantía Platinum de 30 min desde el inicio teórico de producción hasta la llegada al cliente NOSLAB30 No se ha incumplido el SLA de entrega Platinum de 30 min SLABPU15 Incumplimiento del SLA de recogida - Garantía Platinum de 15 min desde el inicio teórico hasta el fin real de producción NOSLAB15 No se ha incumplido el SLA de recogida Platinum de 15 min SLABD Incumplimiento del SLA de entrega (SLA = 40 min) SLABPU Incumplimiento del SLA de recogida (SLA = 15 min) N Sin condición ITEMCHECKS El artículo seleccionado del pedido debe ser únicamente un acompañamiento NOSLAB Sin incumplimiento de SLA en recogida ni en entrega CHECKCUSTY Se han añadido personalizaciones a la pizza CHECKCUSTN No se han añadido personalizaciones a la pizza ORSPT El pedido es para recoger en tienda (Pickup/Takeaway) ORSD El pedido es a domicilio (Delivery) SLABD20 El incumplimiento del SLA está entre 1 y 20 min SLABD2035 El incumplimiento del SLA está entre 20 y 35 min SLABD3550 El incumplimiento del SLA está entre 35 y 50 min SLABD50+ El incumplimiento del SLA supera los 50 min WMP Hay saldo disponible en el monedero (wallet) de la cuenta WMPF El saldo del monedero es 0 EXEMPT Si el reembolso se concede con Exempt en la Acción, no debe contabilizarse en el perfilado futuro del cliente Variables Código Inglés Árabe {%wallet%} (%AMOUNT%) in your wallet (%AMOUNT%) في محفظتك. {%wallet%} (%Loyalty Points%) rewards points (%Loyalty Points%) نقطة مكافأة. {%wallet%} (%AMOUNT%) in your wallet & (%Loyalty Points%) rewards points (%AMOUNT%) في محفظتك و (%Loyalty Points%) نقطة مكافأة. {%currency%} SAR ريال سعودي. {%currency%} AED درهم إماراتي. (El contenido de esta tabla corresponde a los textos exactos que el sistema inserta en inglés y árabe; no se traduce para no alterar las cadenas reales usadas en producción.) Niveles de fidelización (Loyalty Tiers) Código Definición S Silver (Plata) G Gold (Oro) P Platinum (Platino) Tipos de cliente Código Definición H Healthy (saludable / sin incidencias) A Alert (en seguimiento) B Abusive (abusivo) Flujo del proceso de carga 1. Selección de archivos CSV en inglés: contiene la estructura principal del flujo de reclamaciones con todos los datos de los nodos. CSV en árabe: contiene las traducciones al árabe de las descripciones de los nodos. Formato de archivo: solo se admiten archivos .csv. Requisito: ambos archivos deben seleccionarse antes de continuar. 2. Validación de archivos El sistema realiza una validación exhaustiva en el siguiente orden: Validación de formato: comprueba la estructura del archivo y las columnas requeridas. Validación de datos: valida los tipos de datos y los campos obligatorios. Validación de flujo: verifica la lógica del flujo de los procesos de reclamación. 3. Ejecución de la carga Los archivos se suben a las tablas de la base de datos de pruebas (test). Los datos existentes de las reclamaciones de la marca seleccionada se sustituyen por los nuevos. La carga se realiza mediante transacciones, lo que garantiza la consistencia de los datos. Requisitos de formato de archivo Estructura del CSV en inglés Columnas obligatorias (distinguen mayúsculas/minúsculas): NODE_ID - Identificador numérico (obligatorio, único) CUST_ID - ID de cliente (numérico, obligatorio) PARENT_NODE_ID - Referencia al nodo padre (numérico o NULL) DESCRIPTION - Descripción del nodo en inglés (obligatorio, no vacío) SHORT_NAME - Nombre corto para mostrar (obligatorio) CUSTOMER_TYPE - Clasificación del tipo de cliente LOYALTY_TIER - Indicador de nivel de fidelización ACTION - Tipo de acción para este nodo CONDITION - Lógica condicional (si aplica) LAST_NODE - Indicador de nodo final STATUS - Estado del nodo Separador de columnas: punto y coma ( ;) Estructura del CSV en árabe Columnas obligatorias (distinguen mayúsculas/minúsculas): NODE_ID - Debe coincidir con el NODE_ID del CSV en inglés (numérico, obligatorio) CUST_ID - Debe coincidir con el CUST_ID del CSV en inglés (numérico, obligatorio) PARENT_NODE_ID - Referencia al nodo padre (numérico o NULL) Description (Arabic) - Traducción al árabe (obligatorio, no vacío) SHORT_NAME - Nombre corto en árabe Separador de columnas: punto y coma ( ;) Proceso de validación Paso 1: Validación del formato del archivo El sistema comprueba: ✅ El archivo contiene cabeceras y al menos una fila de datos ✅ Están presentes todas las columnas obligatorias ✅ El número de columnas coincide en todas las filas ✅ La codificación del archivo es compatible con UTF-8 Errores de formato habituales: Faltan columnas obligatorias Separador de columnas incorrecto (debe ser ;) Archivos vacíos o que solo contienen la cabecera Número de columnas distinto entre filas Paso 2: Validación del tipo de datos El sistema valida: ✅ NODE_ID es numérico ✅ CUST_ID es numérico ✅ PARENT_NODE_ID es numérico o NULL ✅ Los campos de texto obligatorios no están vacíos ✅ Las descripciones en árabe contienen texto válido Errores de datos habituales: Valores no numéricos en campos de ID Campos de descripción vacíos Codificación de caracteres inválida Faltan valores en campos obligatorios Paso 3: Validación del flujo Comprobaciones avanzadas de validación: ✅ Integridad de la jerarquía de nodos ✅ Relaciones padre-hijo ✅ Detección de referencias circulares ✅ Validación de nodos finales ✅ Consistencia del tipo de acción ✅ Validación del patrón de variables Indicadores de estado de la carga Iconos de estado del archivo 🔄 Validando: validación del archivo en curso ✅ Validado: el archivo ha superado todas las comprobaciones ⏳ En espera: archivo en cola para validación ⚠️ Aviso: archivo seleccionado pero no validado ❌ Error: la validación ha fallado Mensajes de estado de la carga 📤 "Uploading" (Subiendo): los archivos se están procesando en el servidor ✅ "Files uploaded successfully" (Archivos subidos correctamente): la carga finalizó sin errores ❌ "Upload failed" (Error en la carga): error del servidor durante el proceso de carga Mensajes de error y soluciones Errores de selección de archivo Error Solución "Select both English and Arabic CSV files" Debe seleccionar tanto el CSV en inglés como el CSV en árabe "Both files must be validated" Haga clic en "Validate Files" tras seleccionar ambos archivos Errores de validación de formato Error Causa Solución "File must contain header and at least one data row" Archivo vacío o sin datos Asegúrese de que el archivo tiene cabecera y filas de datos "Missing required column: [COLUMN_NAME]" No se encuentra una columna obligatoria Añada la columna que falta a la cabecera del CSV "Row X: Column count mismatch" Número de columnas inconsistente Asegúrese de que todas las filas tienen el mismo número de columnas "Error reading CSV file" Corrupción del archivo o problema de codificación Vuelva a guardar el archivo como CSV UTF-8 con separador de punto y coma Errores de validación de datos Error Causa Solución "Row X: NODE_ID must be numeric" NODE_ID no numérico Asegúrese de que NODE_ID contiene solo números "Row X: CUST_ID must be numeric" CUST_ID no numérico Asegúrese de que CUST_ID contiene solo números "Row X: PARENT_NODE_ID must be numeric or NULL" Referencia de nodo padre inválida Use números o exactamente "NULL" "Row X: Arabic description is required" Falta el texto en árabe Añada la descripción en árabe para todos los nodos Errores de procesamiento en el servidor Error Causa Solución "No valid English CSV data found" Archivo en inglés vacío o inválido Revise el formato y los datos del archivo en inglés "No valid Arabic CSV data found" Archivo en árabe vacío o inválido Revise el formato y los datos del archivo en árabe "English CSV row X: Invalid NODE_ID" Fallo de validación en el servidor Revise el formato y la unicidad del NODE_ID "Arabic CSV row X: Missing Description (Arabic)" Fallo de validación en el servidor Asegúrese de que todas las descripciones en árabe están presentes "Maximum 2 files allowed" Se han subido demasiados archivos Suba exactamente 2 archivos (inglés + árabe) Errores de validación del flujo Error Causa Solución "The flow of both files must be validated" No se ha realizado la validación del flujo Haga clic en el botón "Validate Flow" "The files have flow validation errors that must be corrected" La validación del flujo encontró incidencias Revise el cuadro de diálogo de validación de flujo para ver los errores concretos Guía de resolución de problemas Problema: los archivos no se suben Compruebe: Que ambos archivos estén seleccionados Que ambos archivos se hayan validado correctamente Que la validación de flujo haya finalizado sin errores Que la marca seleccionada sea la correcta Problema: la validación falla repetidamente Soluciones: Descargue los datos actuales para ver el formato esperado Compruebe la codificación del archivo (debe ser UTF-8) Verifique que el separador de columnas es el punto y coma ( ;) Asegúrese de que no hay caracteres ocultos ni formato adicional Problema: la validación del flujo muestra errores Acciones: Abra el cuadro de diálogo de validación de flujo Revise los mensajes de error concretos Compruebe las relaciones padre-hijo en los datos Verifique la integridad de la jerarquía de nodos Corrija los datos y vuelva a validar Problema: la carga falla tras la validación Investigación: Compruebe la conexión con el servidor Verifique los límites de tamaño de archivo Revise la consola del navegador en busca de errores Contacte con el administrador del sistema si el problema persiste Notas técnicas Comportamiento del sistema Entorno: las cargas de CSV siempre van al entorno de pruebas (test) Sustitución de datos: los datos de reclamaciones existentes se sustituyen por completo al subir un CSV en el entorno de pruebas Seguridad transaccional: las cargas fallidas no corrompen los datos existentes Procesamiento de archivos: los archivos se procesan de forma secuencial durante la validación Límites de memoria: los archivos grandes pueden provocar problemas de rendimiento en el navegador Buenas prácticas Preparación del archivo Use una codificación consistente: guarde los archivos CSV como UTF-8 Compruebe los separadores: use el punto y coma ( ;) como separador de columnas Valide los NODE_ID: asegúrese de que los NODE_ID coinciden entre el archivo en inglés y el archivo en árabe Revise las descripciones: verifique que todas las descripciones sean coherentes y estén completas Prevención de errores Uso de plantillas: use una exportación de datos existente como plantilla para nuevas cargas Validación de datos: revise los datos en una hoja de cálculo antes de exportar Estrategia de copia de seguridad: conserve los archivos originales como copia de seguridad antes de procesarlos Pruebe con un conjunto de datos pequeño: valide el proceso con un subconjunto de datos primero Estrategia de carga Validación secuencial: complete la validación de archivos antes de la validación de flujo Revisión antes de subir: compruebe todos los mensajes de validación antes de la carga final Selección de marca: verifique que la marca correcta está seleccionada antes de subir Momento de la carga: realice las cargas en horas de bajo tráfico CMS - Recursos Para acceder a la sección de gestión de recursos, deberá acceder al menú WEB CMS del panel central. Seguidamente deberá acceder al menú RECURSOS. Una vez en RECURSOS, en la barra lateral encontrará todas las secciones disponibles para consultar y editar los recursos: Banners, Formas de pago, Ingredientes, Logos, Productos, Promociones y Varios. Selección de origen Una vez seleccionado el tipo de recurso, si dicho recurso no tuviese datos se mostrará en pantalla "No hay datos". Ejemplo: Recurso: Banners - Origen: AI Si por el contrario hay recursos disponibles, aparecerán en pantalla las siguientes opciones: Desplegable origen: para seleccionar el origen que se quiere mostrar (Web, App, Kiosko, Tienda, JustEat, UberEats, Stuart, Tablet, etc.). Ejemplo: Recurso: Banners - Origen: Web Filtro de búsqueda y parámetros Filtro de búsqueda: para buscar en la tabla mostrada. Ejemplo: Recurso: Banners - Origen: Web Parámetros admitidos para los recursos seleccionados, según el origen elegido. Ejemplo: Recurso: Banners - Origen: Web Ejemplo: Recurso: Formas de pago - Origen: Web Si no hubiese parámetros definidos, aparecerá el siguiente mensaje y no se podrán editar dichos recursos, a menos que se contacte con el administrador: "Para editar estos recursos contacte con su administrador". Edición de recursos Botón Editar: para editar los recursos seleccionados de la tabla. Ejemplo: Recurso: Banners - Origen: Web Si el archivo es correcto, el botón de Guardar se habilitará. Si se guarda y no ocurre ningún error durante la subida, aparecerá un mensaje de confirmación. Si el archivo no es correcto, aparecerá un mensaje "Formato incorrecto" con los parámetros incorrectos del archivo. Vista previa y formatos Botón Vista previa: para ver la vista previa de las imágenes seleccionadas de la tabla. Ejemplo: Recurso: Banners - Origen: Web Botones de tamaño (000px x 000px) (solo visibles si están definidos varios tamaños): al seleccionar uno, aparecerá la tabla de dicho formato. Ejemplo: Recurso: Promociones - Origen: Web CMS - Recursos: Banners Para editar un banner se deberá seleccionar el tipo de redirección y seleccionar un archivo correcto. Idiomas Cada banner tiene su correspondiente banner en idioma Catalán e Inglés. Cada banner en su respectivo idioma deberá tener asignada una imagen y una redirección. URL de destino Para añadir la redirección de los banners hay 3 opciones disponibles (solo se podrá elegir una): PRODUCTO → seleccionar de la lista el producto al que se quiere redirigir desde el banner. PROMOCIÓN → seleccionar de la lista la promoción a la cual se quiere redirigir desde el banner. URL → se deberá escribir la URL completa y correcta de la página a la que se quiera redirigir al cliente, siempre y cuando no sean ni ofertas ni productos concretos. Ejemplo: Redirigir a la landing page "promocion-sala" URL: https://www.pizzeriascarlos.es/promocion-sala/ CMS - Recursos: Documentos Para actualizar los documentos deberá acceder al menú WEB CMS y seguidamente RECURSOS. Idiomas Cada idioma tiene sus correspondientes documentos. Solo se puede subir un documento a la vez. Actualizar un documento Para actualizar un documento se deberá seleccionar un archivo con la extensión válida e inferior al tamaño máximo. En este caso, archivo PDF con un tamaño inferior a 2 MB. Si el archivo seleccionado es correcto, el botón de Guardar se habilitará. Una vez se haya guardado correctamente, aparecerá un mensaje de confirmación: Informes y Métricas Ventas, productos, promociones, tendencias, operaciones, alertas y logs por pedido. Informes y Métricas: cuál usar Dirigido a: dirección y analistas que leen datos de rendimiento, y personal de operaciones que investiga un pedido concreto. Necesitas: Informes de ventas para Informes, Métricas para Métricas. Son permisos distintos. La consola tiene dos áreas de datos, y elegir la correcta ahorra mucho tiempo. Informes Métricas Responden a "¿Cómo nos ha ido?" "¿Qué le pasó a este pedido?" Forma Agregada: totales, desgloses, tendencias Por pedido: logs, líneas temporales Periodo Una fecha de negocio o un rango Actividad reciente Lector típico Dirección, analistas, responsables de área Soporte, operaciones, quien investiga Si buscas números, quieres Informes. Si buscas el histórico de un pedido, quieres Métricas. Qué hay en Informes Informe Responde a Ventas Facturación del periodo Ventas por producto Qué artículos se vendieron, agrupados por familia Promociones Cuánto se usó cada promoción Ventas por tendencia El patrón de lunes a domingo, por categoría Operaciones Foto operativa: estados de pedidos, personal en turno, carga del día, pedidos concretos Alertas operativas Tiendas que ahora mismo están fuera de un umbral que tú fijas Qué hay en Métricas Vista Responde a Logs de pedidos Qué pedidos tuvieron actividad y qué se hizo con ellos Línea temporal del pedido La secuencia completa de acciones sobre un pedido Alarmas archivadas Alarmas ya atendidas Permisos Para esto Necesitas Abrir cualquier informe Informes de ventas Abrir logs y líneas temporales Métricas Exportar desde Métricas Métricas — exportar, un permiso aparte y superior Ver alarmas archivadas Alarmas archivadas report_viewer es el rol pensado para esto: informes, métricas y visibilidad de tiendas, nada más. Combina bien con un rol operativo — ver Combinaciones habituales de roles. Todo está delimitado por scope Cada cifra se filtra a tu scope antes de que la veas. Dos compañeros ejecutando el mismo informe el mismo día pueden obtener totales distintos, porque ven tiendas o marcas distintas. Es el "el informe está mal" más frecuente, y normalmente no lo está. Ver Cómo funciona el scope en la práctica antes de investigar más. Las páginas de este capítulo Tema Página Filtros, fechas y el panel Filtros, fechas y favoritos Facturación Informe de ventas Artículos vendidos Informe de ventas por producto Uso de promociones Informe de promociones Patrones semanales Ventas por tendencia La pantalla de operaciones Informe de operaciones Alertas de tienda por umbral Alertas operativas El histórico de un pedido Logs y líneas temporales de pedidos Sacar datos Exportar datos Filtros, fechas y favoritos Necesitas: Informes de ventas. Todos los informes se gobiernan con el mismo conjunto de filtros. Entenderlo una vez sirve para todo el capítulo. Los filtros Filtro ¿Obligatorio? Notas Marca Sí, en casi todos Los informes se construyen por marca. Con una sola marca puede venir preseleccionada Tiendas No Vacío significa todas las tiendas dentro de tu scope Fuentes No Web, app, agregadores. Solo aplica donde el filtro de fuentes está activo Fecha de negocio Sí El día que cubre el informe Fecha de fin Solo en modo rango Convierte un día en un periodo Franja horaria No Acota a una parte del día Los valores disponibles se cargan desde tu propio scope, así que el listado de tiendas es lo que puedes ver, no todo lo que existe. Modo día frente a modo rango Día — una fecha de negocio. Lo habitual para preguntas operativas. Rango — fecha de inicio y de fin, para una semana, un mes, una comparación. Cambiar de modo altera lo que significan algunos informes. Un gráfico de 15 días en modo rango se ancla en la fecha final, no en la inicial. La fecha de negocio no es la fecha natural Esta es la que más despista. Una fecha de negocio cubre una jornada comercial que, con servicio nocturno, se prolonga pasada la medianoche. Un pedido hecho a la 01:30 del sábado pertenece normalmente a la fecha de negocio del viernes. Así que "las ventas de ayer" significa la fecha de negocio de ayer, no el día natural. Cuando un total parece que le falta la última franja de la noche, comprueba en qué fecha cayeron los pedidos nocturnos. Que dos informes difieran en aproximadamente el importe de una noche es casi siempre esto, no un fallo. La franja horaria La hora de inicio y de fin acotan el informe a una parte del día: el servicio de comidas, el pico de la noche. La franja aplica dentro de cada fecha de negocio del rango. Poner 19:00–23:00 sobre una semana te da siete noches, no un tramo continuo. Favoritos y el panel El panel carga sus widgets en un único lote, así que aparece como una vista completa en lugar de pieza a pieza. Úsalo para las cifras que miras a diario. Para cualquier cosa que necesites segmentar, ve al informe: el panel es un resumen, no una vista filtrada. Conseguir un informe fiable Fija primero la marca. Casi todos la necesitan, y cambiarla después reinicia otras elecciones. Confirma el modo, día o rango. Fija la fecha de negocio, recordando que no es la fecha natural. Añade tiendas y fuentes solo si quieres acotar. Vacío significa "todo lo que puedo ver", que suele ser lo que quieres. Comprueba el número de tiendas frente a lo que esperas. Menos tiendas de las previstas es una cuestión de scope — ver Cómo funciona el scope en la práctica. Páginas relacionadas Informes y Métricas: cuál usar — elegir el área correcta Informe de operaciones — la pantalla más sensible a los filtros Exportar datos — sacar cifras de la consola Informe de ventas Necesitas: Informes de ventas. El informe de ventas da la facturación del periodo que selecciones, filtrada por tu scope. Cómo leerlo Fija la marca, el modo y la fecha de negocio — ver Filtros, fechas y favoritos — y el informe cubre exactamente ese periodo para las tiendas que puedes ver. En modo día responde a "cómo fue ayer". En modo rango responde a "cómo fue el mes pasado", y es la forma adecuada para comparar periodos. Antes de comparar dos periodos Las comparaciones fallan por motivos mundanos más a menudo que por motivos interesantes: Comprobación Por qué ¿El mismo conjunto de tiendas? Abrir o cerrar una tienda cambia el total sin cambiar el rendimiento ¿Las mismas fuentes? Un agregador activado a mitad de periodo mueve volumen sin crearlo ¿Días comparables? Cuatro fines de semana frente a cinco es ya un 20 % de diferencia ¿La misma franja horaria? Una franja aplicada a un periodo y no al otro no es una comparación Cuando el total parece incorrecto Fecha de negocio, no fecha natural. El servicio nocturno cae en la fecha de negocio anterior. Explica casi todos los "falta una noche" — ver Filtros, fechas y favoritos. Tu scope. Ves tus tiendas, no todas. El total distinto de un compañero puede ser correcto para ambos — ver Cómo funciona el scope en la práctica. Cancelaciones. Una tasa alta de cancelación hunde la facturación mientras el número de pedidos se mantiene — revisa Alertas operativas. Páginas relacionadas Informe de ventas por producto — el mismo periodo desglosado por artículo Informe de promociones — cuánto se regaló en ese periodo Ventas por tendencia — el patrón semanal detrás del total Informe de ventas por producto Necesitas: Informes de ventas. Ventas por producto muestra qué se vendió realmente, por artículo, agrupado en familias. Para qué sirve El total de ventas te dice la facturación. Esto te dice qué la produjo: qué artículos se movieron y qué familias sostienen el periodo. Preguntas típicas que responde: ¿Qué artículos merece la pena mantener en carta? ¿Ha entrado bien un producto nuevo, o está parado? ¿Ha cambiado el mix de familias respecto al mes pasado? Leer la agrupación Los artículos se agrupan en familias, así que puedes leerlo a dos niveles: la vista de familia para la forma de la carta, la de artículo para decisiones concretas. Una familia que parece plana puede esconder un artículo creciendo y otro cayendo. Abre la familia antes de concluir que no ha cambiado nada. Combinarlo con otros informes Pregunta Mira también ¿Estas ventas las movió el descuento? Informe de promociones ¿Es un producto de diario o de fin de semana? Ventas por tendencia ¿La facturación llegó de verdad? Informe de ventas Un artículo que solo se vende acompañado de mucha promoción es un caso de negocio distinto de uno que se vende a precio completo. Los dos informes juntos dicen cuál tienes. El scope también aplica aquí Las cifras cubren las tiendas dentro de tu scope para el periodo elegido. Un producto que parece ausente puede simplemente no venderse en las tiendas que ves — ver Cómo funciona el scope en la práctica. Informe de promociones Necesitas: Informes de ventas. El informe de promociones muestra el uso agrupado por código de promoción: cuántas veces se aplicó cada uno en el periodo. Para qué sirve Responde a lo que marketing realmente necesita: qué promociones se están usando y, por tanto, cuáles merece la pena repetir. Leído junto a Informe de ventas e Informe de ventas por producto, responde además a la pregunta difícil: si la promoción trajo negocio o descontó negocio que ya venía. Cómo leerlo El uso se agrupa por código, así que una campaña aparece como el código que introdujeron los clientes. Si lanzaste varios códigos para una misma campaña, los verás por separado; agrúpalos tú, o lanza las próximas como una campaña con varios cupones para que se mantengan juntos — ver Códigos promocionales. Preguntas que merece la pena hacerle Patrón Qué suele significar Mucho uso, ventas planas Estás descontando negocio que ya tenías Poco uso, amplia distribución El código no llega a la gente, o no resulta atractivo Uso concentrado en pocas tiendas Conocimiento local, o la oferta solo aplica ahí El uso se corta de golpe a mitad de periodo La campaña llegó a su fecha de fin, o se caducó — revisa Códigos promocionales Uso cero es un hallazgo Una promoción sin uso merece investigarse antes de repetirla. Las causas habituales tienen arreglo: la campaña no estaba vigente para esas tiendas, las fechas u horas válidas excluían el periodo de servicio, o los códigos nunca se distribuyeron. La página Códigos promocionales lista las comprobaciones en orden. Páginas relacionadas Códigos promocionales — crear, caducar y diagnosticar campañas Promociones personales — ofertas concedidas a clientes concretos Informe de ventas — si la facturación se movió Ventas por tendencia Necesitas: Informes de ventas. Ventas por tendencia presenta el periodo como una matriz de lunes a domingo, desglosada por categoría. Para qué sirve Los totales esconden la forma de una semana. Este informe la muestra: qué días sostienen el negocio, cuáles están tranquilos y si eso cambia según la categoría. Es el informe para decisiones sobre la semana más que sobre el total: personal, horarios de apertura, cuándo lanzar una promoción. Leer la matriz Las filas son categorías y las columnas días de la semana. La lectura útil es a lo largo de una fila: una categoría plana toda la semana se comporta de forma distinta a otra que se dispara el fin de semana. En un rango de varias semanas, cada día agrega todas sus apariciones, así que un rango de cuatro semanas te da cuatro lunes combinados. Eso es lo que hace el patrón legible en lugar de ruidoso. Cuidado con la longitud del rango Un rango desigual distorsiona la matriz. Treinta días contienen cinco de unos días de la semana y cuatro de otros, así que esas columnas no son comparables. Usa semanas completas cuando quieras comparar días. Usa el rango que quieras cuando solo busques el total de cada día. Qué hacer con ello Patrón A considerar Un día entre semana siempre flojo Una promoción dirigida a ese día, o menos personal Peso de fin de semana en una sola categoría Carta o precios específicos para esos días Un día que ha cambiado de forma hace poco Compara con un rango anterior antes de dar por hecha una tendencia Páginas relacionadas Informe de ventas — el total detrás del patrón Informe de ventas por producto — qué artículos mueven cada categoría Informe de operaciones — la forma de un solo día, hora a hora Informe de operaciones Necesitas: Informes de ventas. El informe de operaciones es la pantalla más amplia del capítulo. Responde a "qué está pasando operativamente", mientras que el resto responde a "cuánto hemos facturado". Estado de pedidos y desglose Contadores de en qué punto están los pedidos, más un desglose completo por tipo de pedido —domicilio, recogida, para llevar y en sala— cada uno dividido en franjas de tiempo. Las franjas son lo valioso. Un total alto te dice que hay volumen; las franjas te dicen si los pedidos avanzan o se acumulan en el tramo lento. Personal en turno Quién está activo ahora mismo, agrupado por puesto, junto al estado de todas las tiendas abiertas. Un empleado cuenta como activo cuando ha fichado la entrada del turno y todavía no ha fichado la salida. Es decir, es una vista en vivo de quién está realmente, no de quién estaba planificado. Léelo junto a los contadores de pedidos: mucho volumen con poco personal es la situación sobre la que actuar, y ninguna de las dos cifras lo dice por sí sola. Requiere marca. Las tiendas son opcionales, y vacío significa todas las de tu scope. El gráfico de 15 días Una serie temporal del total de pedidos en franjas fijas de 15 minutos, para la fecha de referencia y los 14 días de negocio anteriores. La fecha de referencia es la fecha de negocio en modo día, y la fecha final en modo rango: conviene saberlo antes de concluir que el gráfico muestra el periodo equivocado. Catorce días de histórico son lo que hace legible el día de hoy. Una hora floja solo significa algo frente a cómo suele ser esa hora. Listado, recuento y detalle de pedidos Tres vistas del mismo conjunto: Vista Úsala para Recuento Cuántos pedidos cumplen los filtros, sin cargarlos Listado Los pedidos en sí Detalle El detalle línea a línea de un pedido Haz primero el recuento cuando no tengas claro cómo de amplios son tus filtros: es mucho más rápido que cargar un listado que vas a descartar. El detalle está delimitado por pedido, así que solo puedes abrir pedidos de tiendas, marcas y fuentes dentro de tu scope. Histórico de cambios de configuración El cambio de configuración más reciente por tienda. Es el informe que responde a "¿ha cambiado algo?" cuando el comportamiento de una tienda se mueve. Antes de investigar una tienda que ha empezado a incumplir sus horas prometidas, comprueba si se tocaron sus ajustes — ver Ajustes de reparto de la tienda. Páginas relacionadas Alertas operativas — la versión por umbrales de esta pantalla Filtros, fechas y favoritos — fecha de negocio, modos y franjas horarias El tablero de pedidos — la vista en vivo del Hub, para actuar en lugar de leer Alertas operativas Necesitas: Informes de ventas. Tres informes que devuelven solo las tiendas que ahora mismo están fuera de un umbral que tú fijas. Donde el informe de operaciones lo muestra todo, estos muestran únicamente lo que requiere atención. Los tres Alerta Marca una tienda cuando Umbral por defecto Carga de reparto Los pedidos pendientes por repartidor activo superan el umbral 2 Cancelaciones El porcentaje de pedidos válidos cae por debajo del umbral 90 % Puntualidad El porcentaje de puntualidad está por debajo del umbral y el tiempo medio de entrega supera el máximo 80 % y 60 min Cada umbral es un parámetro que pasas al ejecutar el informe, no un ajuste guardado. Cámbialo y vuelve a ejecutar para ampliar o estrechar lo que devuelve. La alerta de puntualidad exige las dos condiciones Es la que peor se lee. Una tienda solo se marca cuando está a la vez por debajo del porcentaje de puntualidad y por encima del límite de tiempo medio. Es deliberado. Una tienda que incumple su objetivo por poco pero entrega rápido es un problema distinto de una lenta en todo, y solo la segunda merece interrumpir a alguien. Si quieres la vista más laxa, sube el valor de minutos máximos en lugar de bajar el porcentaje. Estas no son las alarmas del Hub Fáciles de confundir, realmente distintas: Alertas operativas Alarmas de tienda Dónde Informes Hub Umbral Se pasa en cada ejecución, por ti Configurado para toda la cadena Ciclo de vida Se recalcula cada vez que ejecutas Se levanta y luego se archiva Uso Revisar un periodo Actuar durante el servicio Usa estas para revisar; usa Alarmas de tienda para llevar el turno. Una forma de trabajar que funciona Ejecuta las tres con sus valores por defecto para ayer. Para cada tienda que aparezca, abre el Informe de operaciones filtrado a ella. Revisa el histórico de cambios de configuración: ¿cambió algo? Si aparecen varias tiendas a la vez, sospecha de una causa común antes de ir una por una. Si la misma tienda aparece todos los días, el umbral está describiendo lo normal en esa tienda. O arreglas la tienda o lo aceptas: una tienda permanentemente marcada es ruido. Páginas relacionadas Informe de operaciones — la foto completa detrás de una alerta Alarmas de tienda — el equivalente en vivo, para toda la cadena Configuración de alarmas — dónde se configuran los umbrales del Hub Ajustes de reparto de la tienda — las tolerancias contra las que se mide una tienda Logs y líneas temporales de pedidos Necesitas: Métricas. Los logs de pedidos responden a "qué le pasó a este pedido", la pregunta que los Informes no pueden responder porque agregan. El listado paginado Pedidos con actividad registrada, filtrados por tienda, marca y fuente dentro de tu scope. Úsalo para localizar el pedido que te interesa y abrir después su línea temporal. La línea temporal La secuencia completa de acciones registradas sobre un pedido, en orden. Un pedido se identifica por tienda, número de ticket y origen en conjunto: el número de ticket por sí solo no es único entre tiendas. Ver El tablero de pedidos para el porqué. La línea temporal es lo que responde a: Pregunta Qué buscar ¿Quién lo gestionó y cuándo? La secuencia de acciones y sus marcas de tiempo ¿Se reasignó? Los cambios de asignación, y si los hizo una persona o el dispatcher ¿Por qué llegó tarde? Dónde está realmente el hueco: cocina, recogida o ruta ¿Alguien lo forzó o lo canceló? Esas acciones aparecen aquí, con quién las hizo Usarla en una investigación Consigue los identificadores. Tienda, número de ticket, origen. Abre la línea temporal. Léela de principio a fin antes de formar una teoría: el evento interesante suele estar antes de lo esperado. Busca el hueco. Fíjate en la pausa larga, no en el último evento. Cruza con el dispatcher si el hueco está en la asignación: un Request ID de ese momento lo ata a una ejecución concreta. Ver Reportar una incidencia del dispatcher. Métricas frente al Hub Ambos muestran pedidos, con propósitos distintos: Métricas Hub Marco temporal Lo que ya pasó Lo que está pasando Propósito Explicar Actuar ¿Puedes cambiar algo? No Sí Si el pedido sigue vivo y necesita intervención, trabaja en el Hub — ver El tablero de pedidos. Si ya terminó y hay que explicarlo, trabaja aquí. Páginas relacionadas Exportar datos — sacar esto de la consola Alarmas archivadas — el histórico del lado de alarmas El tablero de pedidos — el equivalente en vivo Exportar datos Necesitas: Métricas — exportar. Es un permiso aparte y superior a Métricas, y normalmente lo tiene admin y no todo el que puede leer métricas. Se pueden exportar dos cosas: logs de acciones de pedidos y alarmas archivadas. Ambas salen como ficheros de datos para analizar fuera de la consola. Por qué exportar es un permiso aparte Leer dentro de la consola está delimitado. Cada pantalla filtra a las tiendas, marcas y fuentes que tienes permitidas, cada vez que la abres. Un fichero exportado es una instantánea sin esa protección. Una vez es un fichero en el portátil de alguien, se puede abrir, reenviar y combinar por cualquiera, con independencia de lo que pudiera ver en la consola. El scope se aplicó al exportar; no viaja con el fichero. Por eso la exportación está detrás de su propio permiso, y por eso conviene pensarlo antes de usarla. Antes de exportar Pregúntate Porque ¿Necesito las filas en bruto o una respuesta? Una conclusión compartida en un mensaje es más segura y normalmente más útil que una hoja de cálculo ¿Puede responderlo el informe? Informes y Métricas: cuál usar — los informes agregados a menudo responden sin datos en bruto ¿Quién acabará teniendo este fichero? Da por hecho que todo el entorno de quien lo recibe ¿Hace falta que lleve datos de cliente? Estrecha los filtros antes de exportar, no después Exportar Filtra hasta lo que realmente necesitas: la exportación respeta tus filtros y tu scope. Exporta. Guárdalo donde corresponda y bórralo cuando termine el análisis. Unos filtros estrechos son el principal control que tienes. Una exportación de una tienda y un día es un objeto muy distinto de una de toda la cadena y un mes. Qué obtienes La exportación refleja exactamente lo que podías ver al ejecutarla. No es un dato vivo: reabrir el fichero una semana después muestra el estado del momento de exportar, no el actual. Para cualquier cosa recurrente, vuelve a exportar en lugar de reutilizar un fichero antiguo, y saca la respuesta de la consola siempre que puedas. Páginas relacionadas Logs y líneas temporales de pedidos — lo que se está exportando Alarmas archivadas — el otro histórico exportable Cómo funciona el scope en la práctica — qué hace el scope y qué deja de hacer al exportar Empleados Fichas de personal, hubs, repartidores contratados e importación/exportación. Empleados: qué cubre esta área Dirigido a: RR. HH. y cualquiera que mantenga fichas de personal y su acceso a la consola. Necesitas: Empleados — ver para consultar, Empleados — editar para cambiar. El área de Empleados contiene las fichas de tu personal: quién trabaja dónde, quiénes reparten y quién puede entrar en la consola. Qué cubre Tarea Página Localizar a alguien y leer su ficha Localizar a un empleado Cambiar sus datos o dónde trabaja Editar un empleado Añadir un repartidor contratado Empleados externos Mover muchas fichas a la vez Importar y exportar empleados Dar una contraseña de consola Empleados - Contraseña Empleados, roles y repartidores Tres cosas que se asocian a una persona y se gestionan en sitios distintos: Qué es Dónde La ficha del empleado Quién es, dónde trabaja Aquí Su acceso a la consola Qué puede hacer y ver Gestionar roles desde la consola Su configuración de repartidor Cómo lo trata el dispatcher Aquí, en la ficha, para repartidores Crear un empleado no le da acceso a la consola, y darle un rol no le da una contraseña. Son tres pasos separados, deliberadamente: la mayoría de empleados no entran nunca en la consola. Todo es por marca El área de Empleados trabaja dentro de la marca en la que estás, y se filtra además por tu scope. employee_manager es el rol pensado para ella y está delimitado a nivel de marca. Que un compañero vea un listado distinto es normal — ver Cómo funciona el scope en la práctica. Hubs Los empleados se asocian a hubs, las agrupaciones operativas a las que pertenecen tus tiendas. El listado de hubs está disponible al editar a alguien, y determina de qué operación se le cuenta parte. Acierta con esto antes de preocuparte por los roles: un hub correcto sin rol es un empleado normal; un rol con el hub equivocado es alguien apareciendo en los números de otra operación. Lo que esta área no hace No fija contraseñas. Eso es Empleados - Contraseña. No concede permisos. Eso es Gestionar roles desde la consola. No configura los mensajeros de los transportistas. El personal de un transportista es suyo, no tuyo — ver Transportistas externos. Localizar a un empleado Necesitas: Empleados — ver. El listado de empleados El listado muestra el personal de la marca en la que estás y dentro de tu scope. Busca por nombre o identificador; si la persona existe y es visible para ti, aparece. Que alguien no salga en el listado suele ser scope y no una ficha inexistente. Un usuario delimitado a una marca no ve al personal de otra aunque la ficha exista. Revisa Cómo funciona el scope en la práctica antes de crear un duplicado. Crear un empleado duplicado porque el original no era visible es el error más caro de esta área: parte su histórico en dos fichas. La ficha del empleado Al abrir a alguien ves sus datos y, si es repartidor, su configuración de repartidor al lado. Esa combinación es lo valioso. De un repartidor puedes ver en un solo sitio quién es, a qué hub pertenece y cómo lo trata el dispatcher, en vez de reconciliar dos pantallas. En quien no reparte, la sección de repartidor simplemente no aparece. Hubs Los hubs disponibles de la marca se pueden listar con independencia de un empleado concreto. Úsalo para comprobar la estructura de hubs antes de asignar a alguien, sobre todo si los nombres se parecen. Qué revisar en una ficha Si buscas Dónde ¿Está en la operación correcta? Su hub ¿Puede repartir? La configuración de repartidor de la ficha ¿Puede entrar? Sus roles —Gestionar roles desde la consola— y su contraseña ¿Por qué el dispatcher no lo usa? Tipo de repartidor y disponibilidad, más Clasificación y prioridad de repartidores Páginas relacionadas Editar un empleado — cambiar lo que has encontrado Empleados externos — añadir un repartidor contratado Importar y exportar empleados — trabajar en bloque Editar un empleado Necesitas: Empleados — editar. Editar actualiza los datos de un empleado existente, su hub y —en repartidores— cómo lo trata el dispatcher. Cambiar datos Abre al empleado y cambia lo que haga falta. La ficha es la fuente única de quién es esta persona, así que mantenerla exacta importa más allá de esta pantalla: los informes agrupan por hub y el dispatcher lee de aquí la configuración de repartidor. Mover a alguien de hub Cambiar el hub de un empleado lo mueve de operación. Esto cambia a qué operación cuenta a partir de ahora. El histórico no se reasigna retroactivamente, así que un cambio a mitad de periodo deja el trabajo de esa persona repartido entre ambos hubs en ese periodo. Es correcto, y conviene saberlo antes de que alguien pregunte por qué los números de un hub se ven raros. Mueve a la gente en un cambio de periodo siempre que puedas. Configuración de repartidor En quienes reparten, la ficha lleva la configuración que usa el dispatcher, incluido su tipo de repartidor, que decide cómo se ordena frente a los demás. De ahí se derivan dos cosas, ambas explicadas en Clasificación y prioridad de repartidores: Los repartidores internos van por delante de los contratados. Cambiar el tipo de alguien cambia quién gana cuando ambos son candidatos a un pedido. El tipo también decide qué se les puede dar. Una zona que solo permite ciertos tipos de repartidor propio se salta a todos los demás. Así que un repartidor que "nunca recibe pedidos" suele ser una cuestión de tipo y no de disponibilidad: revisa también los tipos permitidos de la zona en Zonas de reparto. Lo que editar no cambia No se cambia aquí Cámbialo en Qué puede hacer en la consola Gestionar roles desde la consola Qué datos puede ver Configurar el scope de un empleado Su contraseña Empleados - Contraseña Actualizar el puesto de alguien no actualiza su acceso a la consola. Si una persona cambia de función en el negocio, hay que atender a las tres cosas, y es fácil hacer una y olvidar las otras. Después de un cambio importante En un repartidor, confirma que el cambio tuvo el efecto buscado observando si el dispatcher empieza a usarlo como esperas en el siguiente ciclo, a no más de 60–300 segundos. Ver El ciclo de asignación, paso a paso. Empleados externos Necesitas: Empleados — editar. Un empleado externo es un repartidor contratado que forma parte de tu propia flota: alguien que reparte para ti pero no está en tu nómina. La distinción que importa Tres tipos de repartidor, fáciles de confundir: Qué son Se gestionan Repartidor interno Tu propio personal Aquí, como empleado normal Repartidor externo / contratado Contratado, pero parte de tu flota Aquí — esta página Transportista externo Una empresa de reparto a la que entregas pedidos Aquí no — Transportistas externos El del medio es del que trata esta página. Un repartidor contratado sigue siendo tu flota: el dispatcher lo asigna individualmente, por nombre, igual que a tu personal. Un transportista externo es una empresa: le entregas el pedido y ella elige al mensajero. Si estás configurando una plataforma de mensajería, estás en el sitio equivocado; ve a Transportistas externos. Crear uno Crea el empleado externo en la marca, y después fija su hub y su configuración de repartidor como harías con cualquier repartidor — ver Editar un empleado. Cómo los trata el dispatcher Los repartidores contratados van por debajo de los internos. Cuando ambos podrían llevar un pedido, gana el interno, y un interno puede quitarle un pedido a un contratado, nunca al revés. El orden completo está en Clasificación y prioridad de repartidores. Dos consecuencias que conviene conocer: Una zona que no lista su tipo nunca les dará trabajo. Dejar vacíos los tipos de repartidor permitidos bloquea a toda la flota propia, contratados incluidos — ver Zonas de reparto. Una tienda sin repartidores internos se trata con más margen. Su tolerancia de retraso de flota propia se sustituye automáticamente por el valor de transportistas, para que una tienda 100 % contratada no quede sujeta a un criterio que no puede cumplir — ver Ajustes de reparto de la tienda. Añadir varios a la vez Usa la importación CSV en lugar de crearlos de uno en uno — ver Importar y exportar empleados. Páginas relacionadas Transportistas externos — empresas de reparto, que no son esto Clasificación y prioridad de repartidores — cómo se ordenan los tipos Zonas de reparto — qué tipos de repartidor permite una zona Importar y exportar empleados Necesitas: Empleados — ver para exportar, Empleados — editar para importar. Exportar La exportación produce un CSV de los empleados de tu marca y dentro de tu scope. Dos buenos motivos para exportar, más allá de editar en bloque: Como instantánea previa a un cambio masivo. Es tu marcha atrás y cuesta segundos. Para revisar. Leer cien fichas en una hoja de cálculo es más rápido que pasar por cien pantallas. Un fichero exportado ya no está filtrado por scope. Contiene datos de personal, así que trátalo en consecuencia — la misma advertencia que en Exportar datos. Importar La importación aplica configuración de empleados desde un CSV. La secuencia que evita problemas: Exporta primero. Te da a la vez el estado actual y el formato exacto de columnas que espera la importación. Edita el fichero exportado en lugar de construir uno desde cero. Prueba con unas pocas filas. Confirma que quedaron como querías antes de comprometer el resto. Importa el resto. Revisa dos o tres personas en el listado de empleados. Las importaciones no son transaccionales Un fallo a medias deja aplicadas las filas anteriores y sin aplicar las posteriores. No hay rollback, y por eso importa la exportación del paso 1 y por eso hay que averiguar dónde se detuvo antes de reenviar. Relanzar un fichero entero tras un fallo parcial puede volver a aplicar filas que ya habían funcionado. Copias de seguridad La configuración de empleados está cubierta por el sistema de copias: las exportaciones se conservan y se pueden descargar o restaurar — ver Copias de seguridad y restauración de configuración. Restaurar una copia de empleados sigue el permiso de empleados, no uno de copias aparte. Y como toda restauración, reinstaura la instantánea en bloque: lo cambiado desde entonces, por quien sea, queda sobrescrito en las fichas que cubre. Lo que la importación no toca Roles, scope y contraseñas no forman parte de la configuración de empleados. Importar cien empleados no da acceso a la consola a ninguno — ver Gestionar roles desde la consola. Empleados - Contraseña Para asignar o cambiar una contraseña a un empleado deberá acceder al menú EMPLEADOS. En el buscador introduzca el parámetro de búsqueda; si el usuario existe, aparecerá en la tabla posterior: Una vez localizado el usuario, haga clic en esa línea; se abrirá una nueva ventana con toda la información de dicho usuario: Definir o cambiar la contraseña En la sección de contraseña podrá generar una contraseña para dicho usuario (si no la tiene) o cambiar una existente por una nueva. Una vez restablecida o creada, aparecerá un mensaje en la parte superior y dicho usuario podrá acceder a la consola. Solo los usuarios con los roles "Gestor de Empleados" o "Administradores" podrán crear o restablecer las contraseñas. Roles y permisos Quién puede hacer qué en la consola, y qué datos ve cada empleado. Roles y scope: las dos ideas Dirigido a: administradores de la plataforma que deciden quién puede hacer qué en la consola. Necesitas: las secciones Asignaciones y Scope, disponibles para admin y employee_manager. El acceso en la consola se basa en dos ideas independientes. Mantenerlas separadas es la clave de todo el modelo. Concepto Qué define Dónde se configura Roles Lo que un empleado puede hacer — acciones y módulos Asignado al empleado; uno o varios Scope Qué datos puede ver — marcas, tiendas, fuentes Configurado una sola vez, por empleado Un empleado puede tener varios roles a la vez. Los permisos de todos ellos se combinan. El scope, en cambio, es siempre compartido: se aplica por igual a todo lo que ese empleado puede hacer. Por qué importa esta separación Significa que nunca tienes que elegir entre "puede operar el hub" y "solo puede ver dos tiendas". Se responden por separado: Le das hub_operator → puede trabajar en el hub. Configuras su scope a las tiendas 1 y 2 → solo verá los datos de esas dos tiendas, en el hub y en todo lo demás. Añadir más adelante un segundo rol —informes, por ejemplo— no amplía los datos que ve. El scope se mantiene. Las tres cosas que vas a configurar Si quieres… Ve a Permitir que alguien haga algo nuevo Gestionar roles desde la consola Cambiar qué datos puede ver Configurar el scope de un empleado Conceder o bloquear una capacidad concreta, solo para esa persona Excepciones individuales de permisos Los roles deciden qué puede hacer alguien; su ficha de personal es cosa aparte — ver Empleados: qué cubre esta área. Dónde seguir Scope: qué datos puede ver un empleado — los dos modos y las tres dimensiones Catálogo de roles — cada rol y para quién es Acceso por sección — la rejilla completa de rol contra sección de la consola Scope: qué datos puede ver un empleado Cada empleado tiene un único scope, que controla qué datos ve en toda la consola. Los dos modos Modo Qué significa Customer Acceso completo a todos los datos de toda la cadena Explicit Acceso restringido a marcas, tiendas y/o fuentes específicas Las tres dimensiones de un scope explícito Cuando el scope es explícito, se pueden combinar estos filtros: Dimensión Qué filtra Ejemplo Marcas Qué marcas son visibles Solo la marca "X" Tiendas Qué tiendas concretas son visibles Tiendas 1, 2 y 5 Fuentes Qué fuentes de pedido son visibles Solo Glovo y Uber Eats Cómo se combinan: Cada dimensión reduce más la vista: se acumulan, nunca se amplían entre sí. Dejar una dimensión vacía significa "sin restricción" para esa dimensión. Las agrupaciones de tiendas —conjuntos predefinidos— están soportadas y se combinan con tiendas elegidas individualmente. Ejemplos Configuración Lo que ve el empleado Marca = "Marca Ejemplo" Todas las tiendas y fuentes de esa marca Tiendas = 1, 2, 3 Todas las marcas que operan en esas tiendas Marca = "Marca Ejemplo" + Tiendas = 1, 2 Solo los datos de esa marca, en esas dos tiendas Tiendas = 1 + Fuentes = Glovo, Uber Solo datos de Glovo y Uber en la tienda 1, donde aplique el filtro de fuente Nota sobre Fuentes El filtro de fuentes es una dimensión complementaria con activación limitada. No todos los módulos lo usan: solo tiene efecto en secciones donde filtrar por origen del pedido tiene sentido. Entre ellas: Informes — datos de ventas solo de agregadores concretos Métricas — líneas temporales y logs de pedidos filtrados a ciertos canales CMS — configuración de contenido delimitada a fuentes específicas Hub — casos especiales en los que un operador solo gestiona pedidos de ciertos orígenes En los módulos donde el filtro de fuentes no está activado, el empleado ve todos los pedidos dentro de su scope de marca y tienda, independientemente de esta configuración. Por eso Fuentes encaja mejor en roles especializados que necesitan una vista más estrecha dentro de una sección concreta, y no como restricción de uso general. Lo que el scope no hace El scope nunca concede nada: solo reduce. Un empleado con el scope limitado a unas tiendas y sin ningún rol de informes sigue sin poder abrir los informes. El scope decide qué datos; los roles deciden qué acciones. Ver Roles y scope: las dos ideas. Catálogo de roles Cada rol cubre un área de responsabilidad. Si alguien necesita dos áreas, dale dos roles — ver Combinaciones habituales de roles. Rol Para quién Qué cubre admin Administrador del cliente Todo excepto gestionar las definiciones de roles. Es el rol más alto que se asigna a empleados del cliente hub_manager Jefe de operaciones Hub completo —asignar, forzar entrega, cancelar, modificar ETA, incidencias, alarmas— más configuración de tienda, pausar reparto, métricas y alarmas archivadas hub_operator Operador de turno del hub Operaciones básicas del hub, sin las acciones críticas. Ver tiendas y métricas branch_manager Responsable de tienda Su propia tienda: ver pedidos, modificar ETA, incidencias, alarmas, alertas de repartidor, pausar reparto, configuración de tienda branch_viewer Acceso de solo lectura a tiendas Solo consulta de la configuración de tiendas. Rol de apoyo, pensado para combinarse con otros dispatcher_manager Técnico de logística Ejecución del dispatcher, planificador, configuración de tienda, pausar reparto, zonas de reparto, transportistas externos, métricas report_viewer Dirección y analistas Informes, métricas, ver tiendas polygon_manager Configuración de zonas de reparto Zonas de reparto, ver tiendas cms_editor Editor de contenidos Árbol de reclamaciones, recursos, imágenes employee_manager RR. HH. y configuración de personal Empleados y repartidores propios, además de asignaciones de roles, scope y excepciones third_party_manager Configuración de flota externa Configuración de transportistas externos, a nivel de marca alarms_config_manager Configuración de umbrales de alarma Umbrales de alarma de pedidos, repartidores y tiendas, para toda la cadena Dos roles que no vas a asignar super_admin es un rol técnico interno de PizzaGest. Tiene acceso total y se salta todas las comprobaciones; nunca se asigna a empleados del cliente. admin es su equivalente del lado del cliente para el día a día: el mismo alcance operativo, salvo que los denies individuales le siguen aplicando y no puede modificar las definiciones de roles. Cómo se suman los permisos Los roles se construyen a partir de un catálogo de permisos atómicos —actualmente más de cincuenta—, cada uno correspondiente a una acción concreta como "asignar un repartidor" o "exportar métricas". Un rol es un subconjunto con nombre de ese catálogo. Cuando un empleado tiene varios roles, sus permisos se combinan sin duplicados. Añadir un rol nunca resta nada. El número de permisos por rol cambia según se publican módulos nuevos. En lugar de memorizar una cifra, consulta lo que concede realmente un rol en Acceso por sección, o abre el rol en la pantalla de Catálogo de roles. Módulos añadidos recientemente La configuración del chatbot, la gestión de la API externa, el agente de voz, los códigos promocionales y los códigos de voucher son accesibles hoy únicamente para admin. Está pendiente decidir si tendrán un rol propio o se incorporan a los existentes, según la necesidad operativa. Si alguno de ellos tiene que llegar antes a un empleado que no es admin, la vía prevista es una excepción individual — ver Excepciones individuales de permisos. Acceso por sección La rejilla completa de lo que alcanza cada rol. Leyenda: 👁 solo lectura · ✏️ lectura y escritura · — sin acceso. Todo el acceso que se muestra aquí queda además filtrado por el scope del empleado — ver Scope: qué datos puede ver un empleado. Sección admin hub_manager hub_operator dispatcher_manager branch_manager report_viewer polygon_manager cms_editor employee_manager third_party_manager alarms_config_manager Hub — pedidos y estado ✏️ ✏️ ✏️ básico — 👁 — — — — — — Hub — forzar entrega / cancelar ✏️ ✏️ — — — — — — — — — Hub — modificar ETA ✏️ ✏️ — — ✏️ — — — — — — Alarmas de tienda ✏️ ✏️ 👁 — 👁 — — — — — — Alertas de repartidor ✏️ 👁 👁 — 👁 — — — — — — Configuración de umbrales de alarma ✏️ — — — — — — — — — ✏️ Alarmas archivadas ✏️ 👁 — — — — — — — — — Dispatcher ✏️ — — ✏️ — — — — — — — Planificador ✏️ — — ✏️ — — — — — — — Configuración de tienda ✏️ ✏️ 👁 ✏️ ✏️ 👁 👁 — — — — Pausar / reanudar reparto ✏️ ✏️ — ✏️ ✏️ — — — — — — Transportistas externos — marca ✏️ — — ✏️ — — — — — ✏️ — Transportistas externos — tienda ✏️ — — ✏️ — — — — — — — Zonas de reparto ✏️ — — ✏️ — — ✏️ — — — — Métricas ✏️ 👁 👁 👁 — 👁 — — — — — Informes de ventas ✏️ — — — — 👁 — — — — — Empleados y repartidores propios ✏️ — — — — — — — ✏️ — — CMS — reclamaciones y recursos ✏️ — — — — — — ✏️ — — — Configuración del chatbot ¹ ✏️ — — — — — — — — — — Gestión de la API externa ¹ ✏️ — — — — — — — — — — Agente de voz ¹ ✏️ — — — — — — — — — — Códigos promocionales ¹ ✏️ — — — — — — — — — — Códigos de voucher ¹ ✏️ — — — — — — — — — — Gestión de roles y asignaciones ✏️ — — — — — — — ✏️ — — ¹ Módulos añadidos recientemente, accesibles hoy solo para admin. Ver Catálogo de roles. Cómo leer esta tabla super_admin tiene ✏️ en todas las filas; se omite para que la tabla siga siendo legible. branch_viewer es un rol de apoyo de solo lectura sobre la configuración de tiendas; se omite por el mismo motivo. Combínalo con otro rol en lugar de usarlo solo. "✏️ básico" en hub_operator significa las acciones habituales del hub, pero no las críticas: se excluyen forzar entrega, cancelar y modificar ETA. Gestión de roles y asignaciones se divide en dos: employee_manager puede asignar roles existentes, configurar el scope y gestionar excepciones, pero no puede crear ni editar definiciones de roles. Ver Gestionar roles desde la consola. Si un rol casi encaja No busques un rol que coincida exactamente con una persona. O combinas dos roles (Combinaciones habituales de roles), o mantienes el rol más cercano y añades una sola excepción (Excepciones individuales de permisos). Combinaciones habituales de roles Como un empleado puede tener varios roles y todos comparten un único scope, la mayoría de los perfiles reales se construyen combinando dos o tres roles en lugar de buscar una coincidencia perfecta. Perfil real Roles Scope Jefe de operaciones que además consulta informes hub_manager + report_viewer Customer, o explícito por tiendas Jefe de operaciones que gestiona umbrales de alarma hub_manager + alarms_config_manager Customer, o explícito por tiendas Jefe de operaciones que además opera el dispatcher hub_manager + dispatcher_manager Customer, o explícito por tiendas Operador de turno que además consulta informes hub_operator + report_viewer Explícito — sus tiendas Responsable de tienda con acceso a informes branch_manager + report_viewer Explícito — sus tiendas Responsable de marca que no opera pedidos employee_manager + polygon_manager + third_party_manager Explícito — marca Técnico de zonas de reparto polygon_manager Explícito — marca Dirección, solo datos report_viewer Customer Administrador completo admin Customer Por qué hub_manager no incluye el dispatcher hub_manager se centra deliberadamente en las operaciones del hub. Si tu jefe de operaciones también necesita el dispatcher, el planificador o los transportistas externos, asígnale hub_manager + dispatcher_manager. Cada rol mantiene su área de responsabilidad y los permisos se combinan automáticamente. Es preferible a ampliar hub_manager, porque deja las dos responsabilidades visibles y se pueden retirar por separado. Reglas prácticas Combina roles, no pidas roles nuevos. La mayoría de necesidades son una combinación que ya existe. Una definición de rol nueva requiere una solicitud al equipo de desarrollo — ver Solicitar un rol nuevo o modificado. Los roles solo suman. Asignar un segundo rol nunca reduce lo que concedía el primero, ni amplía los datos visibles. Eso solo lo controla el scope. Usa excepciones para el caso puntual. Si un perfil coincide con un rol existente salvo por una única capacidad, mantén el rol y añade un grant o un deny individual — ver Excepciones individuales de permisos. Cómo funciona el scope en la práctica Cuatro comportamientos explican casi todas las preguntas del tipo "¿por qué esta persona ve eso?". Los roles se suman Un empleado con hub_manager + report_viewer puede operar el hub y consultar informes. Ninguno de los dos roles restringe al otro, y el orden en que los asignes da igual. El scope filtra los datos automáticamente Tener acceso a un módulo no significa ver todos sus datos. El sistema filtra todo al scope del empleado. Un report_viewer cuyo scope está limitado a la marca "Pizza Express" abre la misma pantalla de informes que los demás, pero solo ve las cifras de esa marca. No hay nada oculto ni en gris: simplemente esos datos no están en sus resultados. Conviene explicarlo directamente a las personas. Que dos compañeros comparen el mismo informe y vean totales distintos es el comportamiento esperado, no un fallo. El scope se aplica igual a todos los roles A diferencia de sistemas antiguos, el scope no se configura por rol. Si un empleado puede ver las tiendas 1, 2 y 3, eso aplica a todo lo que haga: hub, informes, métricas, configuración de tienda, todo. Es una simplificación deliberada: permite razonar sobre la visibilidad de un empleado mirando una sola configuración, en lugar de reconciliar varias. Las excepciones individuales mandan sobre los roles Puedes conceder o denegar un permiso concreto a un empleado concreto, opcionalmente con fecha de caducidad. Un deny siempre gana, conceda lo que conceda su rol. Ver Excepciones individuales de permisos. Cómo encajarlo todo Cuando alguien reporta que no puede hacer algo, comprueba en este orden: ¿Tiene un rol que conceda esa acción? → Acceso por sección ¿Hay un deny sobre esa persona? → Excepciones individuales de permisos ¿Los datos están simplemente fuera de su scope? → Configurar el scope de un empleado La mayoría de los casos se resuelven en el paso 3, y hasta que lo compruebas parecen un permiso que falta. Gestionar roles desde la consola La consola gestiona roles, asignaciones, scopes y excepciones individuales a través de cuatro secciones. Sección Qué permite Permisos necesarios Catálogo de roles Ver, crear, editar y eliminar definiciones de roles: su nombre y los permisos que incluyen roles:read / roles:write Asignaciones Asignar y desasignar roles a empleados, activarlos y desactivarlos employees:read / employees:write Scope Configurar a qué datos accede cada empleado: marcas, tiendas, fuentes employees:read / employees:write Excepciones Crear grants o denies individuales sobre un permiso concreto de un empleado, con fecha de caducidad opcional employees:read / employees:write Quién llega a cada sección Catálogo de roles está restringido a super_admin, el rol técnico propio de PizzaGest. Crear o cambiar una definición de rol pasa por el equipo de desarrollo, que revisa el cambio antes de aplicarlo. Ver Solicitar un rol nuevo o modificado. Asignaciones, Scope y Excepciones están disponibles para admin y employee_manager. Son las tres que usarás en el día a día: asignar roles existentes, configurar el scope y gestionar excepciones. La separación es deliberada. Cambiar lo que significa un rol afecta a todos los empleados que lo tienen, en toda la cadena, así que se revisa. Cambiar quién tiene un rol afecta a una persona y lo haces tú directamente. Asignar un rol a un empleado Abre Asignaciones. Busca al empleado. Añade el rol o los roles que necesita — ver Catálogo de roles y Combinaciones habituales de roles. Confirma su scope aparte, en Scope. Un rol nuevo no cambia el scope existente. Una asignación se puede desactivar en lugar de eliminar, lo que conserva el registro y suspende el acceso. Asignar un rol no le da a nadie forma de entrar. Establecer o restablecer su contraseña es una tarea aparte, desde la pantalla de Empleados — ver Empleados - Contraseña. Salvaguardas Protegen frente a los cambios más difíciles de deshacer: Un rol con asignaciones activas no se puede eliminar. Los permisos asociados a un rol se validan contra el catálogo de permisos del sistema, de modo que una errata no puede crear un permiso que no haga nada. Cada asignación y cada excepción registra quién la creó, para auditoría. Los denies individuales siempre prevalecen sobre lo que concede un rol. Páginas relacionadas Configurar el scope de un empleado — las tres dimensiones en la práctica Excepciones individuales de permisos — grants y denies Solicitar un rol nuevo o modificado — cuando ninguna combinación encaja Configurar el scope de un empleado Necesitas: employees:read y employees:write — los tienen admin y employee_manager. El scope se configura una vez por empleado y aplica a todo lo que hace. Ver Scope: qué datos puede ver un empleado para el modelo; esta página es la tarea. Antes de empezar Decide cuál de los dos modos necesita la persona: Customer — necesita legítimamente toda la cadena. Dirección, analistas, operaciones a nivel de cadena. Explicit — todos los demás. Cualquiera vinculado a tiendas concretas o a una marca concreta. En caso de duda, elige explícito y amplía después. Ampliar un scope más adelante es cambiar un campo; descubrir que alguien lleva meses viendo las cifras de otra marca, no. Configurar un scope explícito Abre Scope y busca al empleado. Cambia el modo a Explicit. Rellena solo las dimensiones que realmente quieras restringir: Marcas — déjalo vacío para "todas las marcas". Tiendas — tiendas individuales, agrupaciones, o ambas. Fuentes — solo si la restricción importa de verdad; ver la advertencia más abajo. Guarda y comprueba el resultado en una pantalla que use el empleado, por ejemplo Informes. Dejar una dimensión vacía significa sin restricción en esa dimensión, no "sin acceso". Un scope explícito con todas las dimensiones vacías equivale a acceso total. Usar agrupaciones de tiendas Las agrupaciones son conjuntos predefinidos de tiendas. Se combinan con las tiendas seleccionadas individualmente en lugar de sustituirlas, así que puedes dar a alguien una región más una tienda suelta sin enumerar la región tienda por tienda. Es preferible una agrupación a una lista larga de tiendas: cuando más adelante se añada una tienda a esa región, el scope del empleado la recoge automáticamente. Advertencia sobre Fuentes El filtro de fuentes solo surte efecto en los módulos que lo implementan: Informes, Métricas, CMS y algunos casos del Hub. En el resto, el empleado ve todo lo que hay dentro de su scope de marca y tienda. Esto significa que una restricción por fuente no es una forma fiable de ocultar datos en general. Úsala para enfocar un rol especializado, no para imponer un límite. Si el límite importa, exprésalo con marcas o tiendas. Comprobar el resultado La verificación más rápida es mirar una pantalla con volumen de datos, como Informes o la lista de pedidos del hub, y confirmar que el empleado ve lo que pretendías: ni más, ni menos. Recuerda que el scope no concede nada. Si no ve absolutamente nada, revisa sus roles antes de tocar el scope — ver Cómo funciona el scope en la práctica. Excepciones individuales de permisos Necesitas: employees:read y employees:write — los tienen admin y employee_manager. Una excepción concede o deniega un permiso concreto a un empleado concreto, por encima de lo que digan sus roles. Úsala cuando una persona encaja con un rol existente en todo salvo en un detalle. Los dos tipos Tipo Efecto Uso típico Grant Añade un permiso que sus roles no incluyen Un operador de turno que además necesita cancelar pedidos, sin darle el rol de jefe entero Deny Retira un permiso que sus roles sí incluyen Un responsable de tienda que no debería poder pausar el reparto La regla que resuelve los conflictos Un deny siempre gana. Prevalece sobre cualquier grant, venga del rol que venga, e incluso sobre un grant explícito. No hay orden que razonar ni prioridad que configurar. Es deliberado: hace que un deny sea una forma fiable de retirar una capacidad, sin tener que auditar qué roles podrían estar devolviéndola. super_admin es la única excepción: se salta todas las comprobaciones, incluidos los denies. admin no; a admin los denies individuales le aplican con normalidad. Crear una Abre Excepciones y busca al empleado. Elige el permiso. Elige grant o deny. Opcionalmente, pon una fecha de caducidad. Guarda. El registro conserva quién la creó, para auditoría. Usa la fecha de caducidad La mayoría de las excepciones nacen con intención temporal: cubrir una ausencia, una campaña de temporada, una prueba de acceso más amplio. Muy pocas acaban siendo temporales en la práctica, porque nadie se acuerda de retirarlas. Poner la fecha de caducidad al crearla convierte ese problema en un no-problema. Si el acceso resulta ser permanente, la solución correcta es cambiar el rol, no una excepción que no termina nunca. Cuándo no usar una excepción Cuando dos roles ya lo cubren. Si la persona necesita un área completa, asigna el rol de esa área — ver Combinaciones habituales de roles. Las excepciones son para permisos sueltos, no para montar un área a base de piezas. Cuando varias personas necesitan lo mismo. Tres excepciones idénticas son señal de que el rol está mal planteado. Solicita un cambio de rol — ver Solicitar un rol nuevo o modificado. Para restringir datos. Las excepciones controlan acciones, no visibilidad. Para limitar lo que alguien ve, configura su scope — ver Configurar el scope de un empleado. Revisarlas Las excepciones son la parte del modelo de acceso que más se desvía con el tiempo, porque cada una es invisible desde el catálogo de roles. Revisa la lista periódicamente y retira las que ya no tengan motivo. Solicitar un rol nuevo o modificado Crear o editar una definición de rol está restringido al equipo técnico de PizzaGest. Como administrador del cliente asignas roles existentes, configuras el scope y gestionas excepciones, pero el catálogo de roles en sí pasa por una solicitud. Esta página explica por qué, y cómo plantear bien esa solicitud. Por qué se revisa Una definición de rol es compartida. Cambiar lo que significa hub_manager lo cambia para todos los empleados que lo tienen, en todas las tiendas, de inmediato. A diferencia de una asignación —que afecta a una persona y es fácil de revertir—, un cambio de rol tiene alcance de cadena, así que se revisa antes de aplicarse. Prueba esto primero La mayoría de las solicitudes acaban siendo innecesarias. Por orden de preferencia: Combina roles existentes. Dos o tres roles juntos cubren casi todos los perfiles reales — ver Combinaciones habituales de roles. Añade una excepción individual. Si un rol encaja salvo por una capacidad, concede o deniega ese permiso — ver Excepciones individuales de permisos. Comprueba que no sea un problema de scope. "No ve los datos" casi siempre es scope, no permisos — ver Cómo funciona el scope en la práctica. Un rol nuevo es la respuesta correcta cuando el mismo patrón de combinación más excepción se repite en varias personas. Qué incluir en la solicitud Dato Por qué importa El puesto, en lenguaje llano "Supervisor regional de 12 tiendas" dice más que una lista de permisos Qué debe poder hacer Las acciones, nombradas como aparecen en la consola Qué no debe poder hacer A menudo es la mitad más importante, y la que suele faltar El rol existente más cercano Y en qué se queda corto exactamente Cuántas personas lo tendrán Una persona suele ser una excepción; varias suelen ser un rol Si es permanente Una necesidad de temporada se cubre mejor con excepciones con caducidad Qué ocurre después La solicitud se analiza frente al catálogo existente, en parte para construir el rol adecuado y en parte para comprobar que no se solapa con otro de una forma que complique razonar sobre el modelo. Si se crea un rol nuevo, aparece en el Catálogo de roles y lo asignas como cualquier otro. Mientras tanto No hace falta dejar a nadie bloqueado. Asigna el rol más cercano y cubre la diferencia con excepciones, idealmente con una fecha de caducidad acorde a tu plazo previsto. Cuando llegue el rol nuevo, asígnalo y retira las excepciones. Referencia Glosario, cómo reportar un problema y preguntas frecuentes transversales. Glosario Términos usados en toda la consola. El vocabulario específico del dispatcher —estados de repartidor, Last-Option, tiempos— está en el Glosario del dispatcher. Término Significado Marca Una identidad comercial dentro de tu empresa. Casi todas las pantallas trabajan con una marca cada vez, y los datos están separados por marca Tienda Una ubicación física. En algunas pantallas aparece como sucursal Hub Una agrupación operativa de tiendas. Los empleados pertenecen a un hub, y determina a qué operación cuenta su trabajo Fuente De dónde vino un pedido: web, app, quiosco o un agregador. El contenido y algunos informes se separan por fuente Scope Qué datos puede ver un empleado: marcas, tiendas, fuentes. Se fija una vez por persona y se aplica en todas partes Rol Qué puede hacer un empleado. Una persona puede tener varios; los permisos se combinan Permiso Una capacidad concreta, como asignar un repartidor o exportar métricas. Los roles se construyen con ellos Excepción Conceder o denegar un permiso a una persona, por encima de sus roles. Un deny siempre gana Fecha de negocio La jornada comercial a la que pertenece un pedido. Los pedidos nocturnos pertenecen a la fecha de negocio anterior, no a la natural Hora prometida La hora de entrega que se le dio al cliente, y contra la que se mide el retraso Flota propia Tus repartidores, en nómina o contratados Transportista externo Una empresa de reparto externa a la que entregas pedidos. El mensajero lo elige ella, no tú Canjeado Una promoción, voucher o saldo que el cliente ya ha usado. Las operaciones masivas nunca tocan lo canjeado Cambio masivo Cambiar muchos registros a la vez, mediante comprobar → aplicar → seguir Importación Cargar registros desde un CSV. Nunca es transaccional: un fallo parcial deja aplicadas las filas anteriores Copia de seguridad Instantánea conservada de una exportación, que se puede descargar o restaurar Alarma Se levanta automáticamente cuando una tienda cruza un umbral. Vive en el Hub y se archiva una vez atendida Alerta Se levanta automáticamente sobre un repartidor, o la devuelve un informe por umbral en Informes Incidencia Un registro que escribe una persona sobre un pedido, explicando qué salió mal Request ID Identifica una ejecución del dispatcher. Lo más útil que puedes aportar al reportar un problema de dispatcher Tres que se confunden con facilidad Alarma, alerta, incidencia. Las dos primeras las levanta el sistema y tú respondes; la tercera la escribes tú y se queda en el pedido. Ver Alarmas de tienda, Tiendas y alertas de repartidor y Registrar una incidencia. Repartidor contratado frente a transportista externo. Un repartidor contratado es parte de tu flota y se asigna por nombre. Un transportista es una empresa: le entregas el pedido y elige al mensajero. Ver Empleados externos. Rol frente a scope. Los roles deciden acciones, el scope decide datos. Ver Roles y scope: las dos ideas. Reportar un problema Cómo reportar un problema de la consola para que se resuelva sin tres rondas de preguntas. Para problemas específicos del dispatcher hay una lista más completa en Reportar una incidencia del dispatcher: el Request ID que pide es lo que los hace rastreables. Comprueba primero estas tres Buena parte de los reportes se resuelven aquí, sin que intervenga nadie más: Síntoma Causa probable "No veo la pantalla" Tus roles — Qué puedes ver, y por qué "Veo menos filas que mi compañero" Tu scope — Cómo funciona el scope en la práctica "Al total le falta una noche" Fecha de negocio, no natural — Filtros, fechas y favoritos Ninguna es un fallo, y las tres se responden en un minuto. Qué incluir Dato Por qué Dónde estabas El área y la pantalla, no solo "la consola" Qué hiciste Los pasos, en orden Qué esperabas A menudo la línea más útil, y la que más se olvida Qué pasó en su lugar Incluida la redacción exacta de cualquier mensaje Cuándo Fecha y hora aproximada Quién Tu identificador: determina tus roles y tu scope, así que determina qué deberías haber visto Marca Si tu empresa tiene más de una ¿Puntual o recurrente? Una vez y un patrón apuntan a causas distintas Identificar un pedido concreto Un pedido necesita tienda, número de ticket y origen en conjunto. El número de ticket por sí solo no es único entre tiendas, así que un reporte con solo un número no se puede rastrear. Si el dispatcher está implicado, añade el Request ID del Planificador: apunta a una ejecución exacta. Qué evidencia ayuda Una captura de la pantalla concreta con el problema, con el mensaje visible. De un pedido, su pantalla de detalle con las marcas de tiempo, no un listado. Si hay varias cosas afectadas, todos los identificadores en lugar de "unos pedidos esta mañana". Qué no ayuda "Está roto" o "hoy no funciona", sin pantalla, hora y ejemplo. Capturas de paneles sin relación. Describir el arreglo que quieres en lugar del comportamiento que viste. Di qué pasó; la causa a menudo no está donde se manifiesta. Antes de reportar un problema de permisos Di cuál de los dos es: ves la pantalla pero no los datos, o no ves la pantalla. Lo primero es scope, lo segundo un rol. Esa frase suele resolverlo al momento. Preguntas frecuentes Preguntas que cruzan áreas. Cada capítulo tiene su detalle; esto es el índice de las que aparecen en todas partes. Acceso ¿Por qué no veo un área que otros sí ven? Tus roles deciden qué áreas aparecen. Ver Qué puedes ver, y por qué. ¿Por qué veo menos filas que un compañero con el mismo informe? Tu scope es más estrecho, y los dos estáis viendo la respuesta correcta para vosotros. Ver Cómo funciona el scope en la práctica. Tengo el rol pero sigo sin poder hacer una cosa concreta. Los permisos son granulares, y una excepción de tipo deny prevalece sobre un rol. Revisa Acceso por sección y luego Excepciones individuales de permisos. ¿Cómo consigo una contraseña? Te la pone alguien con permisos de gestión de empleados. No hay restablecimiento automático — ver Entrar en la consola. Datos y cifras Dos informes difieren en el importe de una noche. La fecha de negocio no es la natural; los pedidos nocturnos pertenecen a la jornada anterior. Ver Filtros, fechas y favoritos. Informes y Métricas no coinciden sobre un pedido. Leen almacenes de datos distintos. Un pedido presente en Informes y ausente en Métricas no generó eventos de log: no se ha perdido. Ver Informes y Métricas: cuál usar. Un cambio masivo afectó a menos registros de los que decía la comprobación. Se excluyen los canjeados entre la comprobación y la aplicación, y los que ya lo estaban. Ver Cómo funcionan los cambios masivos. Pedidos ¿Por qué un pedido cambió de repartidor solo? Quedó disponible un repartidor con mejor prioridad. Ver Cuándo un pedido cambia de repartidor. ¿Por qué sigue un pedido sin asignar? Normalmente capacidad, una zona que no permite ningún tipo de repartidor disponible, o datos de dirección incompletos. Ver las Preguntas frecuentes del dispatcher. Desasigné un pedido y el transportista vino igual. Desasignar no cancela con el transportista. Cancelar sí, de forma atómica. Ver Asignar y desasignar un repartidor. Un pedido que asigné a mano nunca se reasignó. Las asignaciones manuales quedan bloqueadas de forma permanente frente a la reasignación automática. Es lo previsto. Ver El tablero de pedidos. Contenido y promociones Cambié un banner y no cambió nada. Casi siempre es la fuente equivocada: el contenido se guarda por fuente, y por idioma en banners y documentos. Ver Recursos y fuentes. El código promocional de un cliente no funciona. Revisa fechas y horas válidas, si ese cupón ya está canjeado, y si la oferta está vigente para esa tienda. Ver Códigos promocionales. Un transportista parece disponible pero aparece lleno. La capacidad de un transportista es una bolsa compartida por tienda y por empresa, no por mensajero. Ver Transportistas externos. Importaciones y exportaciones Una importación falló a medias. ¿Puedo relanzarla sin más? No con seguridad. Las importaciones no son transaccionales, así que las filas anteriores ya están aplicadas y relanzar puede aplicarlas dos veces. Averigua antes dónde se detuvo — ver Importar desde un CSV. ¿Puedo deshacer una importación? Solo para registros que nadie haya canjeado, con un borrado masivo. Lo ya usado se queda. ¿Por qué exportar es un permiso aparte? Porque un fichero exportado ya no está filtrado por scope. Ver Exportar datos. Si sigues atascado Reportar un problema lista qué incluir para que se resuelva a la primera.