Skip to main content

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:

  1. El dispatcher reevalúa cada tienda en cada ciclo: por defecto con no más de 60 segundos de separación, y hasta 300.
  2. Un pedido que no se pudo colocar en un ciclo se reintenta desde cero en el siguiente, incluido un intento nuevo con transportistas externos.
  3. 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í