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