Cuánto vale un día de estante vacío.
marql encuentra los SKU a cero que seguían vendiéndose y valora la ausencia a partir de tus propias ventas, no del coste. Este playbook lleva esa cifra los dos pasos que la pantalla no da — por el margen y después por la sustitución — y pone las tres opciones reales una al lado de otra: pagar por que llegue antes, absorber el hueco o sustituir.
En riesgo
381 €
por semana — de los que 38 € son recomprables
- valorado por ventas, no por coste
- funciona con TPV y stock
- recuperable ≠ en riesgo
Pantallas del mercado demo Mercado Claro, capturadas el 1 de septiembre de 2026. Es el único idioma en el que las capturas de este playbook se leen tal cual: el tenant es español y marql AI responde en castellano. Las cifras están generadas y el tenant avanza su propio reloj, así que son una foto fija y no una constante.
El estante está vacío. La demanda no.
En Mercado Claro hay una referencia a cero en Madrid · Malasaña — Granola artesanal, dos días seguidos — y marql la valora como valora todo: a partir de las ventas de la propia tienda. La incidencia marca ≈381 € semanales en riesgo hasta que el estante se reponga. Ahí se para el producto y ahí empieza la decisión, porque 381 € no es lo que pierde la cadena y desde luego no es lo que vale pagar a un mensajero. Dos multiplicaciones separan la cifra de la pantalla de la cifra sobre la que un comprador puede actuar, y las dos la reducen.
- 381 €
- ventas semanales en riesgo
- 223 €
- margen dentro de esa cifra
- 38 €
- vale pagar por dos días
- 2
- días seguidos
De un estante a cero a una decisión con precio.
Cuatro etapas, y la tercera es la que suele saltarse: las opciones no cuestan lo mismo, y la más barata muchas veces es no hacer nada y dejarlo escrito.
Un SKU que se vendía está ahora a cero.
Un escaneo diario cruza la foto de stock con el histórico de ventas y levanta los SKU que facturaron en los últimos 30 días y hoy no tienen existencias. Las filas se agrupan en una incidencia por tienda, no una por SKU, y llegan ordenadas en carriles según el tipo de dinero en juego — una fuga semanal recurrente, ventas que se agotan, capital inmovilizado — con la barra bajo cada fila mostrando cuánto. La rotura ocupa su propio carril con 381 €, por debajo de tres fugas que valen más por semana y por encima del exceso de stock del que trata el primer playbook de esta biblioteca.
Escaneo diario · una incidencia por tienda · longitud de barra = dinero en juego
Un día de ausencia recibe una cifra, sacada de las ventas y no del coste.
La tasa sale de las ventas recientes del propio SKU, no de una media de categoría ni de un precio de tarifa. Eso es lo que convierte a este en el único playbook que funciona con un TPV y un feed de stock: hasta aquí no hace falta ningún dato de coste. La cifra es semanal porque ese es el periodo que lleva la incidencia. Pasarla a un día es trabajo del lector, no un número que el producto se invente.
Valorado con las ventas del propio SKU · sin datos de coste
Distingue una referencia que se paró de una que se apagó.
marql mira si hay algo pedido, si el mismo SKU está en stock en otro punto de la red y si esta tienda ya se ha quedado vacía antes. Una repetición en la misma dirección es un problema de suministro disfrazado de problema de estante, y el producto saca el recuento a la superficie en vez de dejarlo a la memoria — que es la diferencia entre arreglar una rotura y pagar por la misma todos los meses.
Pedido en curso · en otra tienda · recuento de repeticiones
Disponibilidad recuperada no es ingreso recuperado.
Cuando se confirma una acción, marql fija la línea base y la ventana de medición, y la ventana tiene que sobrevivir al pico de reposición: los primeros días tras rellenar un estante venden la demanda que se acumuló mientras estuvo vacío y adornan cualquier decisión medida contra ellos. Conviene ser exacto sobre dónde vive esto: en este tenant el registro de impacto es un informe fechado entre las vistas guardadas, con datos a 10 de agosto de 2026, no una superficie viva que se actualiza mientras miras. Una revisión que hay que abrir sigue siendo una revisión; una que nadie abre, no.
Informe fechado · línea base congelada al confirmar · ventana que supera el pico
Cero puede ser el número correcto.
La aritmética no está en discusión: el SKU se vendía y no tiene existencias. Lo que está en discusión es si alguien debe actuar. En al menos cinco situaciones corrientes el estante vacío es el estado buscado, y quien paga por adelantar el reparto en una de ellas está pagando un sobrecoste por deshacer la decisión de otro.
La referencia se está agotando a propósito
Un SKU descatalogado llega a cero exactamente según lo previsto, y el plan vive en la cabeza de un comprador o en una hoja que el producto nunca ha visto. La señal lee una referencia que vendió bien 28 días y se detuvo, que es justo lo que parece un agotamiento controlado desde los datos.
¿Hay algo pedido y hay ya un sustituto vendiéndose en la misma subcategoría? Un agotamiento planificado no tiene pedido abierto ni hueco en la facturación de la subcategoría — el sucesor ya la está absorbiendo.
La temporada acabó y la ventana no se ha enterado
La tasa lee las ventas recientes del SKU. En una referencia de temporada esa ventana pisa el final de la temporada y sigue citando una demanda que ya se fue. El estante está vacío porque nadie compra, no porque no haya llegado nada.
El mismo SKU, las mismas semanas del año pasado. Si entonces el ritmo cayó como cae ahora, la temporada terminó. Si el año pasado seguía vendiendo a estas alturas, no.
El sustituto ya está en el estante con otro código
Un cambio de formato, un cambio de proveedor o una reformulación dan al mismo producto un SKU nuevo. El código viejo baja a cero y ahí se queda, correctamente, mientras la demanda sigue intacta un código de barras más allá.
La facturación de la subcategoría en los mismos días. Si la subcategoría está plana mientras el SKU está a cero, la demanda no se fue: se movió, y no hay nada que recuperar.
Una serie limitada que nunca iba a reponerse
Una compra puntual, un fin de serie del proveedor, una colaboración con fecha de cierre impresa. Agotarse es el resultado para el que se diseñó la compra, y la alerta es una descripción del éxito.
¿Llegó a ser posible la reposición? ¿Existe una ficha de proveedor con plazo de entrega, o el pedido original era todo? Un SKU sin ruta de reposición no se puede adelantar a ningún precio.
El estante está vacío y el almacén no
El escaneo lee el recuento registrado, y el recuento registrado es estrictamente cero. El stock que está físicamente atrás, sin dar de alta o dado de alta en otra ubicación, se lee igual que el stock que no existe. Éste es el más frecuente de los cinco en una cadena real y el más barato de resolver.
¿Sigue habiendo ventas de un SKU que el sistema da a cero? Esa combinación es imposible y zanja la cuestión sin que nadie salga de la oficina. Si las ventas también se han parado, la comprobación es que alguien vaya al almacén — y la respuesta va al registro, porque un cero fantasma sin anotar vuelve cada semana.
En resumen
Ninguna de estas hace reaparecer el ingreso donde realmente estaba en riesgo. Lo que cambia es que cuatro de las cinco convierten la acción en «no hacer nada, y dejar escrito por qué», y la quinta en «ir a mirar» en lugar de «pagar por adelantar». marql sólo puede reconocer un motivo cuando el motivo está en los datos: un pedido abierto, una subcategoría plana, una ficha de proveedor. Un agotamiento que vive en la cabeza de un comprador le resulta invisible, y la anulación que deja constancia de ese agotamiento es el artefacto útil.
El estante estaba vacío. La decisión falló igual.
Cinco formas de equivocarse una vez que la señal era correcta, en el orden en que ocurren: el dinero equivocado, la urgencia equivocada, la dirección equivocada, la victoria equivocada y la contabilidad equivocada. Son escenarios construidos, no observados: detrás no hay las cifras de ninguna cadena.
Pagar un sobrecoste contra el ingreso en vez de contra el margen
381 € a la semana hacen que un mensajero de 100 € parezca evidente. Pero la decisión no recupera 381 €: recupera el margen bruto de las unidades que si no no se habrían vendido — unos 223 € con los márgenes de este tenant — y de eso, sólo la parte que no se va a otro producto y gana su margen igualmente. Recuperar dos días de una semana de siete vale unos 38 €. El mensajero pierde dinero, y en la pantalla no hay nada que lo diga.
Multiplica antes de decidir: ventas en riesgo, por margen, por la parte que no sustituiría, por los días realmente ganados dividido entre siete. Ese resultado es el techo del sobrecoste. En esta referencia es la décima parte de la cifra que se ve, no la mitad.
Adelantar una demanda que ya se ha ido
Un básico lleva nueve días fuera. El sobrecoste se paga el día ocho, el palé llega el nueve, y los clientes que vinieron a buscarlo la primera semana ya han rehecho su cesta en otro sitio. Las unidades llegan; la demanda no vuelve con ellas. Adelantar recompra los días que quita del principio del hueco, no los que ya se han gastado.
Días ganados, no días fuera. Si el reparto iba a llegar el viernes y el sobrecoste lo adelanta al miércoles, la aritmética va sobre dos días. Y en una referencia que lleva ausente más que un ciclo de compra, trata la tasa de recuperación como más baja que el valor por defecto de la calculadora, no como la misma.
Arreglarlo en el estante cuando la causa está aguas arriba
Una tienda se vacía, recibe un traslado y se vuelve a vaciar tres semanas después. Cada respuesta individual fue correcta y ninguna tocó el motivo: una cantidad de pedido por debajo del ritmo real de la tienda, un plazo de entrega dejado en un valor por defecto que nadie revisó, o una ruta de reparto que se salta esa dirección. El sobrecoste se paga todos los meses y el defecto nunca aflora, porque cada evento se cierra por su cuenta.
Cuenta los eventos por tienda en 30 días antes de elegir la acción. Una repetición no es una rotura de stock: es un defecto de compras o de logística que se presenta como tal, y adelantar el reparto cada mes es una suscripción al síntoma.
Sustituir por un producto peor y llamarlo ahorro
Se dirige al cliente al artículo de al lado, el total de caja del día aguanta y la incidencia se cierra como atendida. Pero el sustituto lleva menos margen, y la cadena ha cambiado una ausencia de margen alto por una presencia de margen bajo sin que nadie anote la diferencia. La línea de ingresos quedó plana, que es exactamente por lo que nadie miró la línea de margen.
La sustitución es una acción legítima y tiene precio: la diferencia de margen por unidad entre los dos SKU, por las unidades. Si esa diferencia se desconoce porque faltan precios de coste, entonces la sustitución es una acción sin valorar y debe registrarse como tal, no como una victoria.
Medir por encima del pico de reposición
El estante se rellena y los primeros días venden la demanda que se acumuló mientras estaba vacío. Medida contra esos días, cualquier acción parece un triunfo. Medida a lo largo del mes siguiente, la referencia está donde estaba y el registro ya ha apuntado la recuperación.
Línea base y ventana fijadas al confirmar la acción, nunca una vez conocidas las cifras, y la ventana lo bastante larga para contener ciclos semanales enteros en vez de los días inmediatamente posteriores a la reposición. Al registro de impacto hay que permitirle devolver «sin efecto» y «datos insuficientes»: un registro que sólo dice «probado» no está midiendo nada.
En resumen
Cuatro de los cinco son una acción equivocada elegida a partir de una cifra correcta, y el quinto es una acción correcta registrada de forma deshonesta — la misma forma que en el playbook 01, porque es el mismo fallo de nervio en el mismo punto del ciclo. Los dos que más pesan son el primero y el tercero: uno decide sobre un dinero que en realidad no está ahí, el otro sigue resolviendo un problema en la dirección equivocada.
Empieza por la que importa
¿Cuáles de los estantes vacíos de hoy compensa pagar por reponer antes?
¿Hay anomalías en los últimos 7 días?
1 anomalía detectada — sin alertas activas.
DATA FRESHNESS · POS synced 6 min ago · accounting 4 h ago
- 01¿Qué SKU están hoy a cero habiendo facturado en los últimos 30 días?
- 02¿Cuánto gana cada uno por día de venta y cuál es su margen?
- 03¿Cuáles tienen algo pedido y para cuándo está previsto?
- 04¿Cuáles están en stock en otro punto lo bastante cerca para trasladarlos?
- 05¿Qué tiendas se han vaciado más de una vez en los últimos 30 días, y con qué?
- 06Redacta el plan: acción, responsable, plazo y la ventana en la que se juzgará.
Qué hace falta para valorar un día de ausencia.
Existencias por SKU × ubicación
Una foto diaria, no un recuento en vivo. Sin ella este playbook no funciona en absoluto — y una conexión sólo de TPV muchas veces no la trae, que es lo primero que hay que comprobar y no lo último.
Ventas por SKU × ubicación
Cantidad, importe y fecha, al menos de los 28 días anteriores. Esto es lo que pone precio al día, y por eso el playbook funciona sin datos de coste.
Margen bruto del SKU
Sin él la ausencia se puede contar igualmente y ordenar por facturación, pero no se puede calcular el techo de lo que vale pagar por acortarla — así que la columna de decisión se queda vacía en vez de estimarse a partir de una media de la red.
Plazo de entrega y lo que hay pedido
Proveedor, pedidos abiertos y la fecha de entrega observada. Deciden cuántos días compra realmente un sobrecoste, que es el multiplicador del que depende toda la decisión.
Cómo se calculó
El escaneo, la ventana y la aritmética.
Las palabras del propio producto, del bloque que imprime bajo la incidencia: el escaneo recorre las filas diarias por producto — ventas, coste, stock — y nombra los SKU exactos que hay detrás del dinero, de modo que cada elemento listado lleva su propia aportación en € y no una parte de un total.
Filas diarias por SKU, normalmente una ventana de 7–28 días según la comprobación; las comprobaciones de tendencia comparan dos ventanas contiguas de igual longitud. La cifra se expresa por semana porque ése es el periodo que lleva la incidencia.
- margen en riesgo por semana = ventas semanales en riesgo × margen bruto
- recuperable = margen en riesgo por semana × (1 − tasa de sustitución)
- vale pagar por ganar un día = recuperable ÷ 7 × días ganados
- Sincronización TPV / ERP
- product_sales_daily · inventory_daily
- escaneo por SKU
- incidencia, agrupada por tienda
- inventory_daily
- qty_in_stock
- product_sales_daily
- product_ext_id, revenue
Dos cosas que este bloque no va a suavizar. Primera: el coste no aparece entre las columnas que lee la comprobación, que es exactamente por lo que este playbook funciona con un TPV y un feed de stock — e igualmente por lo que el paso del margen, más abajo, es la cifra del lector y no la del producto. Segunda: las dos superficies no coinciden. El 1 de septiembre de 2026 la incidencia marcaba ≈381 € semanales en Granola artesanal mientras marql AI, preguntado por el mismo SKU en el mismo minuto, respondía ~316,80 € semanales — unos 53 € al día con una demanda diaria media de 9,6 unidades y un precio de 5,50 €, multiplicado por seis días en lugar de siete. Unos 65 € de diferencia sobre una cifra de 381 €. Ninguno de los dos números está inventado y esta página no va a elegir favorito; lo que hace es señalar que una decisión de este tamaño no debería tomarse sobre una cifra que se mueve una sexta parte según en qué pantalla la leas.
Compruébalo con tus propias cifras
Las tres ecuaciones de arriba, con los campos a la vista. Se abre con las cifras de este playbook, así que lo primero que imprime son los 381 € de la cabecera convertidos en el número sobre el que realmente se decide — cambia cualquier campo y la aritmética le sigue.
- Margen en riesgo por semana
- 223 €
- Vale pagar, como mucho
- 38 €
Dos de estos cuatro campos son supuestos, no lecturas. El margen se abre en el 58,5 % combinado de este tenant porque la incidencia no lleva columna de coste para este SKU: usa el tuyo. La tasa de sustitución se abre en el 40 % porque una cifra plausible es más útil que un hueco, y es el único número aquí que nadie puede consultar sin datos de línea de ticket. No calcula el sobrecoste: eso es un presupuesto de tu proveedor o de tu mensajería. Y no sabe si los días que has puesto son días fuera o días ganados — el modo de fallo 02 es esa diferencia.
Tres opciones, tres mesas distintas.
Las tres acciones de este playbook pertenecen a tres ámbitos distintos, y ninguno puede tomar las otras dos. Es poco habitual — la mayoría de las decisiones se concentran — y explica por qué un estante vacío recibe tantas veces la respuesta que la persona más cercana puede dar en lugar de la correcta. El producto no lo deja a la costumbre: la hoja de pedido de abajo lleva la cantidad, la marca de tiempo del búfer del que salió y la frase «sólo el propietario o el COO pueden crear un borrador de pedido». El ámbito se aplica, no se sugiere.
Encargado de tienda
Sólo sus tiendas, y el único ámbito que posee un dato que ningún otro tiene: si el estante y el almacén coinciden.
- El contracaso 05: ir al almacén y anotar lo que se encontró allí.
- La sustitución en el estante: dirigir la demanda al SKU vivo más cercano, y decir a cuál.
- Si la referencia es físicamente vendible: dañada, mal etiquetada, caducada.
El sobrecoste de adelantar el reparto y el traslado. Ambos son costes incurridos fuera de este ámbito contra un beneficio medido dentro de él, y ninguno aparece siquiera en esta bandeja.
Días desde el cero registrado hasta el estante repuesto, y si los ceros fantasma que reportó siguieron reportándose.
Responsable de zona
Un grupo de tiendas, y el primer ámbito que puede ver el mismo SKU con stock en una dirección y ausente en otra.
- El traslado, porque éste es el primer ámbito que ve sus dos extremos.
- La elección entre mover stock y esperar — la comparación que tiene que incluir el día que cuesta el propio traslado.
- Qué estante vacío es problema de la red y cuál es local.
La compra que creó el hueco y el plazo de entrega contra el que se pidió. Una zona puede mover el stock que ya tiene; no puede hacer que llegue más.
Días de ausencia en el grupo, y cuánto se cerró moviendo stock en lugar de pagando por velocidad.
Propietario
Toda la red, y el único ámbito que ve la misma tienda vaciándose de forma repetida en lugar de una tienda vaciándose una vez.
- El sobrecoste de adelantar: la única acción aquí que gasta dinero para comprar tiempo.
- La cantidad de pedido y el plazo de entrega detrás del modo de fallo 03 — la causa, no el síntoma.
- La decisión de absorber un hueco y registrarla como decisión y no como descuido.
El único dato que posee el ámbito más pequeño: si el palé está en la trastienda. Todo sobrecoste pagado sobre un cero fantasma se autorizó en este ámbito y sólo podría haberse evitado en el otro extremo.
Sobrecoste gastado frente a margen recuperado, y si las tiendas que se vaciaron dos veces se vaciaron una tercera.
NETWORK REVENUE · LAST 30 DAYS
354 000 €−1.2%
Gran Vía
54 000 €−0%−2%Chamberí
39 900 €+2%−0%Barcelona Eixample
39 500 €−16%−17%—En resumen
Éstos son los tres ámbitos que trae el producto, no una afirmación sobre cómo debería organizarse una cadena. Una cadena con una mesa central de reposición tiene un puesto que ninguno de los tres describe, y este playbook no se lo va a inventar. Mapea tus propios títulos sobre los ámbitos y no al revés — y fíjate en que en esta decisión la acción más barata pertenece al ámbito más pequeño, que es lo contrario de lo habitual y la razón de que se salte.
Todo lo anterior, en una hoja de cálculo.
Nada de esto necesita marql. Lo que el producto automatiza es el escaneo diario de todos los SKU y ubicaciones; el método son tres decisiones y unos veinte campos, y para una tienda se hace a mano en una tarde. Quédatelo. Si la aritmética sigue cambiando lo que habrías hecho, ahí está el argumento para automatizarla.
¿Está vacío el estante o está vacío el registro?
El contracaso 05 y los modos de fallo 02 y 03 en un solo árbol. Se recorre antes de hablar de dinero, porque tres de sus cuatro finales no cuestan nada.
¿Ha vendido algo este SKU desde que el recuento se puso a cero?
- SíEl equivocado es el registro, no el estante. Encuentra el stock, corrige el recuento y anota la causa: un cero fantasma sin registrar vuelve cada semana y cuesta un sobrecoste cada vez.
- NoEl estante está realmente vacío. Continúa.
¿Se aplica alguno de los contracasos de la sección 03 — un agotamiento planificado, una temporada terminada, un sustituto con otro código, una referencia que nunca iba a volver?
- SíAnota cuál, quién lo decidió y cuándo debe revisarse. No hagas nada. Ese registro es lo que evita que esto llegue como sorpresa cada semana.
- NoLa demanda es real y no está atendida. Continúa.
¿Cuántas veces se ha quedado a cero esta tienda en los últimos 30 días?
- Más de unaTrata el patrón, no el evento. Compara la cantidad de pedido con el ritmo real de la tienda y el plazo de entrega con el observado antes de gastar nada en velocidad — ése es el modo de fallo 03.
- UnaUn evento aislado. Pasa a la parte 02.
¿Está el mismo SKU en stock en un punto lo bastante cerca para trasladarlo sin dejar corto a ese punto?
- SíCompara el traslado con el sobrecoste en la parte 03 — el traslado también cuesta un día, y la cobertura del punto que envía tiene que sobrevivirlo.
- NoLa elección es adelantar o absorber. Ve a la parte 02.
Uno de cinco finales: corregir el recuento, anotar un motivo y no hacer nada, arreglar la causa aguas arriba, trasladar, o poner precio a la espera en la parte 02.
Cuánto vale un día de ausencia
El modo de fallo 01 en forma de hoja: las tres multiplicaciones entre la cifra de la pantalla y la cifra sobre la que se decide. Cada línea es más pequeña que la anterior, y ahí está la gracia.
- Ventas semanales en riesgo, tal como las imprime la incidencia
- Directamente de la incidencia, o de una exportación de ventas. Hasta aquí no hace falta ningún dato de coste: la comprobación que la levanta no lee columna de coste.
- Demanda diaria media y precio de venta
- Anota los dos. En el SKU de la demo son 9,6 unidades al día a 5,50 €, de donde salen los ~53 € diarios — y multiplicarlo es como averiguas si la cifra semanal de tu pantalla usó seis días o siete.
- Ventas semanales en riesgo, reconciliadas
- Demanda diaria por precio, por siete. Si no cuadra con la cifra que imprimió la incidencia, has encontrado la misma discrepancia que encontró este playbook: anota cuál usas y por qué, porque todo lo de abajo la hereda.
- Margen bruto del SKU
- El margen del propio SKU, no el de la categoría ni el de la cadena. Si faltan precios de coste, párate aquí y ordena por facturación: un margen estimado convierte un techo en una conjetura con coma decimal.
- Margen en riesgo por semana
- Ventas en riesgo por margen. Adelantar el reparto recupera esto, nunca la línea de arriba.
- Parte de la demanda que sustituye
- Es un supuesto y debe quedar etiquetado como tal en la hoja. Nadie puede consultarlo sin datos de línea de ticket. Los básicos con un vecino cercano en el lineal sustituyen mucho; una referencia de destino, a la que la gente viene expresamente, sustituye muy poco.
- Margen recuperable por semana
- Margen en riesgo por uno menos la parte que sustituye. Divide entre siete y multiplica por los días que el sobrecoste gana de verdad: ese resultado, y no esta línea, es contra lo que se compara el sobrecoste.
Una cifra: lo que una semana de este estante vacío está costando de verdad en margen recuperable — y la tasa diaria debajo.
¿Compensa lo que cuesta llegar antes?
La bifurcación en sí. Tres opciones, una comparación, y una cuarta línea que casi nadie escribe: no hacer nada tiene precio y muchas veces es el más bajo de la página.
- Fecha de entrega sin intervenir
- La observada, no la contratada. Si los tres últimos repartos llegaron tarde, la observada es la real.
- Fecha de entrega pagando el sobrecoste
- Confirmada con el proveedor o la mensajería, no supuesta. Una fecha sin confirmar no compra nada.
- Días realmente ganados
- La diferencia entre las dos líneas anteriores. No los días ya pasados sin stock: ésos están perdidos a cualquier precio, que es el modo de fallo 02.
- Techo del sobrecoste
- Margen recuperable por semana, de la parte 02, entre siete y por los días ganados. Cualquier presupuesto por encima de esta línea pierde dinero incluso cuando funciona. En el SKU de la demo son unos 38 € por dos días, frente a los 381 € de la pantalla.
- Sobrecoste presupuestado
- Coste total de llegar antes, incluyendo todo lo que añade la ruta urgente: una carga parcial, una entrega fuera de horario, un conductor.
- Coste del traslado, si es posible
- Transporte más el día que tarda más el margen arriesgado en el punto que envía. Un traslado que vacía otro estante ha movido el problema, no lo ha resuelto.
- La decisión, y su precio
- Adelantar, trasladar, sustituir o absorber — y el número que la hizo la más barata de las cuatro. Absorber es una decisión con precio, y escribir ese precio es lo que la convierte en una.
Una acción elegida con la aritmética que la eligió, y un precio anotado para la opción no tomada.
Fija la medición antes de actuar.
El modo de fallo 05 en forma de hoja, y la única parte con plazo: todos los campos se rellenan antes de la acción, porque una vez conocido el resultado ninguno puede elegirse con honestidad. Las pistas nombran lo que exige el propio registro de marql, de modo que una hoja llevada a este estándar y el producto responden a la misma pregunta.
- La acción, en una frase
- Qué se hace, sobre qué SKU, en qué ubicación y a qué coste.
- Responsable
- Un nombre con un ámbito que pueda tomar realmente la acción — sección 07. En esta decisión las tres opciones pertenecen a tres ámbitos distintos.
- Línea base, congelada ahora
- La cifra contra la que se medirá el efecto, escrita y no recalculada después. En una hoja de cálculo, congelarla significa pegar el valor en vez de dejar una fórmula que se moverá.
- Ventana de medición
- Fechas exactas, elegidas ahora. Tiene que empezar después de que pase el pico de reposición, no durante, y cubrir ciclos semanales enteros: medir por encima de la reposición es el modo de fallo 05.
- La métrica
- Días sin stock de este SKU en esta ubicación. Una métrica: la segunda es la forma de elegir a posteriori el resultado que conviene. La facturación es mala elección aquí, porque se mueve por motivos que esta acción no causó.
- Controles emparejados
- Ubicaciones comparables que no recibieron la acción. marql no da una línea por probada con menos de cuatro tiendas de control emparejadas; sin pares recurre a la volatilidad de la propia unidad, que es una afirmación más débil y debe etiquetarse como tal.
- Qué anularía la ventana
- Una promoción sobre el SKU o su sustituto más cercano, un cambio de precio, un cambio de proveedor o una segunda rotura dentro de la ventana. Con cualquiera de ellos el veredicto honesto es no concluyente, no probado.
- Qué cuenta como sin efecto y qué como peor
- Los dos, escritos antes de conocerlos. Aquí «peor» es alcanzable: un sobrecoste pagado que compró menos días de los presupuestados ha gastado dinero para nada.
Una fila que puede cerrarse en seis direcciones — encontrado, midiendo, probado, sin efecto, no concluyente, peor. Si las tres últimas son inalcanzables en tu versión, las tres primeras no valen la pena.
En resumen
Ése es el método completo. Lo que añade marql no es una ecuación mejor: recorre el escaneo a diario sobre todos los SKU y ubicaciones en lugar del estante por delante del que alguien pasó, agrupa las filas por tienda para que una repetición se vea como patrón y no como nueve incidencias sueltas, y mantiene el registro para que una fila cerrada no pueda reabrirse en silencio y mejorarse. La aritmética de arriba es la misma en ambos casos — y la tasa de sustitución es un número que ninguno de los dos puede medir.
09 · Donde se detiene la prueba
Ingreso en riesgo
≠ recuperación probada.
381 € son ventas semanales en riesgo de un SKU en una ubicación — la cifra que lleva la propia incidencia, visible en la pantalla al principio de esta página. No es una pérdida: parte de esa demanda compra otra cosa en la misma visita y gana su margen igualmente. Qué parte lo hace es el único número de este playbook que nadie puede medir sin datos de línea de ticket, y marql no lo tiene, y por eso la calculadora lo pide en lugar de imprimirlo.
Tampoco es margen. Adelantar el reparto recupera el margen bruto de las unidades que si no no se habrían vendido — unos 223 € con los márgenes de este tenant — y la parte recuperable de eso, sobre los días que un sobrecoste compra realmente, ronda los 38 €. La cifra de la pantalla y la cifra sobre la que un comprador puede actuar se diferencian aquí en un factor de diez, y siempre en la misma dirección.
Y no es un efecto probado. Eso se registra sólo después de ejecutar la acción, congelar la línea base y cerrar la ventana de control más allá del pico de reposición. Cuando los datos son insuficientes o un factor externo distorsionó el resultado, el registro de impacto marca el efecto como no probado. El tenant demo avanza su propio reloj, así que toda cifra de aquí es una foto fija y no una constante.
Lo que el producto sí hace, y la pantalla de abajo es el ejemplo más claro, es imprimir las condiciones junto a la lectura: cuánto del día ha transcurrido de verdad frente a cuánto se esperaba a estas horas, y cuántas ubicaciones han reportado siquiera. Una cifra de ritmo sin esas dos líneas es ilegible, y la mayoría de los cuadros de mando omiten las dos.
De dónde salen estas pantallas
Las tres superficies por las que pasó la decisión
¿Listo para ver
los euros que ha encontrado?
La demo se construye sobre el TPV y la contabilidad que ya usas. Déjanos tus datos y elige una hora.