# Gestionar excepciones de pedidos: reglas, escalado y trazabilidad > Cómo diseñar la gestión de excepciones de pedidos: precio, stock, crédito, referencias y duplicados con reglas claras, responsables y trazabilidad. - Canonical: https://arkatai.com/gestionar-excepciones-de-pedidos/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: es - Published: 2026-09-01 --- Gestionar excepciones de pedidos es el centro de la operación, no la red de seguridad que se añade al final. Registrar un pedido perfecto es un flujo determinista. El coste administrativo aparece cuando el precio no coincide, falta stock, la referencia es antigua, el cliente está bloqueado o el documento contradice el acuerdo comercial. En muchas empresas esas excepciones viven en el conocimiento del equipo. Una persona sabe que el cliente A admite entrega parcial, que el B necesita autorización del director comercial y que la referencia antigua del C puede sustituirse por otra. El sistema solo puede operar si ese criterio se convierte en reglas verificables y si sabe detenerse cuando la decisión queda fuera de su mandato. Esta página profundiza en una parte del proceso de [automatizar pedidos B2B](/automatizar-pedidos-b2b/). El objetivo no es eliminar todas las excepciones, sino resolver automáticamente las conocidas y reducir el trabajo necesario para decidir las demás. ## Qué es una excepción de pedido Una excepción es una condición que impide completar el pedido por el camino normal. Debe poder expresarse con cuatro elementos: hecho observado, regla aplicable, riesgo o impacto y siguiente acción. “El pedido está raro” no es una excepción operable. “La línea 4 solicita 120 unidades de una referencia descatalogada y existe una sustituta aprobada para este cliente” sí lo es. La segunda formulación permite resolver, escalar y medir. Conviene distinguir entre dato ausente, dato inválido, contradicción entre fuentes, restricción de negocio y fallo técnico. Cada clase tiene un responsable y un tiempo esperado distintos. Una caída del ERP no debería acabar en la cola del comercial, y un descuento no autorizado no debería tratarse como error de integración. ## Taxonomía mínima | Clase | Ejemplos | Respuesta habitual | |---|---|---| | Identidad | Cliente o sociedad ambiguos | Solicitar dato o validar maestro | | Producto | Referencia desconocida o sustituida | Proponer equivalencia aprobada | | Comercial | Precio, descuento o mínimo incorrectos | Aplicar tolerancia o pedir autorización | | Inventario | Stock insuficiente o fecha imposible | Proponer parcial, sustitución o nueva fecha | | Riesgo | Crédito bloqueado o importe superior al límite | Detener y escalar | | Logística | Dirección nueva o condición especial | Validar con responsable | | Duplicidad | Pedido ya registrado o posible modificación | Enlazar, comparar y decidir versión | | Técnica | ERP no disponible o escritura incierta | Reintentar de forma idempotente | La taxonomía debe empezar pequeña y crecer con evidencia. Crear cien códigos antes de observar casos reales solo sustituye un buzón caótico por un formulario imposible. Las primeras clases salen de una muestra histórica y se revisan cuando aparecen excepciones no clasificadas. ## Regla, tolerancia y prohibición Para cada excepción se define qué puede hacer el sistema. Hay tres niveles útiles. Una **regla automática** resuelve un caso inequívoco: cambiar una referencia antigua por su sustituta oficial o normalizar una unidad según una tabla aprobada. Una **tolerancia** permite actuar dentro de un rango: aceptar una diferencia de redondeo o una fecha dentro de la ventana acordada. Una **prohibición** detiene siempre: cliente bloqueado, precio por debajo del mínimo o acción que excede el permiso concedido. El modelo puede ayudar a interpretar el documento, pero no inventa esos límites. Las reglas se versionan, tienen propietario y fecha de vigencia. Cada ejecución registra qué versión aplicó. Si una tarifa cambia, los pedidos posteriores usan la nueva; los anteriores conservan la evidencia de la que estaba vigente. ## Diseñar el escalado humano Escalar no significa enviar todo a una bandeja común. La excepción debe llegar a la persona capaz de resolverla: comercial para condiciones, crédito para bloqueos, operaciones para entregas y TI para fallos técnicos. La ficha de escalado debería contener: - pedido, cliente y línea afectados; - condición observada y fuente; - regla que impide continuar; - opciones permitidas; - impacto en fecha, margen o riesgo; - plazo para decidir; - acciones ya ejecutadas; - enlace a la evidencia original. También debe capturar la decisión de forma estructurada. “OK” en un correo no explica si se autorizó un descuento para ese pedido o si cambió la política general. La interfaz debe distinguir una excepción puntual de una nueva regla. El patrón general de reparto de autoridad está en [human in the loop](/human-in-the-loop/). ## Resolver sin esconder el riesgo Una tasa baja de escalado no siempre es buena. Puede significar que el sistema resuelve más, pero también que deja pasar casos que debería detener. Por eso autonomía y calidad se miden juntas. Para una clase concreta conviene observar falsos positivos —casos escalados que podían resolverse— y falsos negativos —casos resueltos que requerían decisión—. El coste no es simétrico. Escalar de más consume tiempo; aprobar un pedido por debajo del margen o a un cliente bloqueado puede producir una pérdida mucho mayor. Los umbrales deben reflejar ese impacto. Al principio el sistema puede operar en sombra: clasifica y propone una salida mientras la persona sigue resolviendo. Se comparan ambas decisiones y se amplía autonomía clase por clase. No se pasa de revisar todo a revisar nada mediante una sola cifra de confianza. ## Trazabilidad de una excepción Para reconstruir un caso hacen falta la entrada original, los datos extraídos, las fuentes internas consultadas, las reglas aplicadas, las propuestas generadas, la decisión humana y la acción final. La traza debe usar identificadores estables y tiempos, y evitar guardar más datos personales de los necesarios. La trazabilidad sirve para tres tareas diferentes. Permite explicar un error al cliente, evaluar si el sistema mantiene su calidad y descubrir reglas operativas que todavía solo viven en conversaciones. No debería ser un almacén de razonamientos opacos del modelo; debe conservar hechos y decisiones verificables. La arquitectura más amplia se describe en [observabilidad y trazabilidad de agentes](/observabilidad-y-trazabilidad-de-agentes/), pero en pedidos la unidad de auditoría debe ser siempre el caso completo. ## Métricas por clase de excepción Una media total borra lo importante. El cuadro operativo debería mostrar por clase: - volumen y porcentaje sobre pedidos; - tiempo hasta resolución; - porcentaje resuelto automáticamente; - minutos humanos empleados; - reincidencia por cliente o formato; - correcciones posteriores; - impacto en fecha, margen o servicio; - casos sin clasificación. La última métrica es especialmente útil. Si aumentan las excepciones “otras”, la taxonomía ha dejado de representar la realidad. Si una clase crece de repente, puede haber cambiado una tarifa, un catálogo, una plantilla o una integración. ## Convertir excepciones repetidas en mejora No todas las excepciones deben automatizarse. Algunas revelan un problema aguas arriba que conviene eliminar: referencias desactualizadas en el catálogo del cliente, acuerdos comerciales sin registrar o datos maestros inconsistentes. Resolverlas más deprisa puede ocultar la causa. La revisión periódica separa tres destinos. Una excepción estable y de bajo riesgo puede convertirse en regla automática. Una excepción causada por datos malos genera una corrección del sistema fuente. Una excepción infrecuente y de alto juicio permanece humana, pero con mejor contexto. Esa mejora continua es una razón para contratar la operación y no solo una implantación. El sistema cambia junto al proceso, y las métricas muestran dónde invertir el siguiente esfuerzo. ## Preguntas frecuentes ### ¿Qué excepciones se pueden automatizar primero? Las frecuentes, bien definidas y de bajo riesgo: equivalencias aprobadas, normalización de unidades o diferencias dentro de una tolerancia explícita. Las que afectan a crédito, margen o compromisos importantes suelen requerir aprobación hasta disponer de evidencia suficiente. ### ¿Una excepción significa que el agente ha fallado? No. Puede significar que el pedido está fuera del camino normal y el sistema lo ha detectado correctamente. El fallo sería ocultarla, resolverla sin autoridad o escalarla sin el contexto necesario. ### ¿Quién debe ser propietario de las reglas? El responsable de negocio del proceso. Tecnología puede implementarlas y Arkatai mantener su ejecución, pero precios, tolerancias, crédito y compromisos son decisiones de la empresa. ### ¿Cómo se evita que cada aprobación se convierta en una regla peligrosa? Separando una autorización puntual de un cambio de política. Las nuevas reglas requieren propietario, alcance, revisión y fecha de vigencia; no se infieren automáticamente de una respuesta aislada.