Cómo evitar solicitudes incompletas con validación de datos

Una petición como “hay que pedir material”, “cambiad este pedido” o “preparad un envío” puede parecer suficiente para iniciar una conversación, pero no necesariamente para iniciar el trabajo. Si faltan una referencia, una fecha, una cantidad o el contexto de la petición, el equipo receptor debe preguntar, esperar una respuesta e interpretar lo que se quería decir. La tarea vuelve, en la práctica, al punto de partida.

Evitar solicitudes incompletas no consiste en convertir cada proceso en un formulario largo. Consiste en definir qué información mínima necesita el siguiente equipo para actuar correctamente y comprobarla antes de asignar el trabajo. El objetivo es que cada entrada sea una solicitud preparada: completa para su caso, comprensible y utilizable en las herramientas de gestión de la empresa.

El problema: el trabajo empieza antes de poder ejecutarse

El coste de una solicitud incompleta rara vez aparece como una incidencia aislada. Se reparte entre correos, mensajes, llamadas, tareas en espera y correcciones posteriores. Administración puede recibir una petición de compra sin proveedor ni centro de coste; mantenimiento, un aviso sin ubicación concreta; y operaciones, un cambio de pedido sin número de referencia. En todos los casos, alguien tiene que reconstruir la información antes de decidir qué hacer.

La mejora no depende necesariamente de incorporar otra aplicación. En Cataluña, el 54,6 % de las empresas de 10 o más personas ocupadas utilizaba servicios de cloud computing de pago en el primer trimestre de 2025. Esto aporta contexto: muchas pymes ya operan con entornos digitales donde pueden revisar cómo se recogen y validan los datos que entran en sus procesos. [1]

Definir cuándo una solicitud está preparada para trabajar

El primer paso es elegir un proceso concreto y acordar sus condiciones de entrada. Una solicitud preparada debe responder, como mínimo, a quién la realiza, qué necesita y cuándo lo necesita. Según el proceso, también necesitará una referencia de cliente, pedido, producto o proyecto; una ubicación; un responsable operativo; o un adjunto imprescindible. La pregunta útil para decidir cada dato es sencilla: “¿Puede el equipo receptor empezar correctamente sin esta información?”.

Conviene documentar estos criterios en una tabla operativa con seis columnas: tipo de solicitud, dato necesario, de dónde procede el dato, regla de validación, responsable de revisarlo y destino del dato. Por ejemplo hipotético, en una solicitud de compra el artículo o servicio, la cantidad y la fecha requerida podrían ser necesarios para empezar; el comentario libre sobre preferencias del solicitante podría ser opcional. Esta distinción evita pedir información por costumbre.

Aplicar reglas útiles sin convertir el formulario en un interrogatorio

No todos los campos deben ser obligatorios para todos los casos. Separa los datos en cuatro grupos: imprescindibles siempre; obligatorios solo en determinadas situaciones; datos que el sistema puede completar de forma automática, como la persona solicitante o la fecha; y datos útiles pero no necesarios para iniciar el trabajo. Si se marca una petición como urgente, por ejemplo, puede mostrarse entonces el motivo y la fecha límite, en lugar de exigir esos campos a todo el mundo.

Las validaciones más prácticas suelen ser de presencia, formato, rango, coherencia y lista controlada. La presencia impide enviar una petición sin datos mínimos; el formato comprueba una fecha o referencia; el rango evita cantidades negativas; la coherencia exige una justificación si se selecciona “urgente”; y una lista controlada reduce variantes al elegir departamento, categoría o transportista. W3C recomienda pedir solo la información necesaria, dar instrucciones y comunicar los errores de forma comprensible para que la persona pueda corregirlos. [2]

Diseñar la corrección y una ruta para las excepciones

Una regla solo ayuda si la persona entiende cómo cumplirla. Formula preguntas concretas, coloca una instrucción breve junto al campo y muestra ejemplos cuando el formato pueda generar dudas. En vez de “Referencia”, resulta más claro “Número de pedido o presupuesto aprobado”. En vez de “Error”, indica qué falta y cómo resolverlo: “Introduce una fecha de entrega posterior a hoy”. La guía de GOV.UK aconseja minimizar fallos de validación, aceptar formatos razonables cuando sea posible y ofrecer mensajes específicos orientados a la corrección. [5]

No todas las situaciones reales cabrán en una regla automática. Por eso es preferible crear una ruta identificada para excepciones, por ejemplo el estado “pendiente de completar por solicitante”. Si falta un dato que no puede verificarse automáticamente, la solicitud vuelve con el campo señalado y una explicación breve, en vez de generar un correo manual genérico. Esta ruta no debe ocultar el problema: debe quedar registrada para saber qué excepciones son frecuentes y decidir si hace falta ajustar el proceso.

Probar el cambio y medir si realmente reduce devoluciones

No rediseñes todos los formularios a la vez. Durante una semana, escoge el tipo de petición con más aclaraciones, revisa unas 20 solicitudes recientes y anota qué información faltaba, cuántas veces y qué consecuencia tuvo. Después configura una primera versión con los datos mínimos, pruébala con entre tres y cinco personas usuarias y recoge sus dudas. Si varias personas fallan en el mismo punto, probablemente deba revisarse la pregunta, la ayuda o la regla, no atribuir el fallo a quien rellena el formulario.

Compara la situación anterior y posterior con tres indicadores por tipo de solicitud: porcentaje de solicitudes completas a la primera, calculado como solicitudes listas para trabajar entre solicitudes recibidas; tasa de devolución, es decir, solicitudes devueltas entre solicitudes recibidas; y tiempo medio hasta que la petición queda preparada. Medir por separado compras, mantenimiento o cambios de pedido evita que una media global oculte dónde se concentra el retrabajo. La conclusión útil es práctica: cada devolución repetida debe convertirse en una pregunta mejor, un dato automático o una regla sencilla.

Preguntas frecuentes

¿Qué campos deben ser obligatorios en un formulario interno?

Solo los datos sin los que el equipo receptor no puede empezar correctamente. Suelen incluir quién solicita, qué necesita y cuándo; añade referencias, ubicación, responsable o adjuntos únicamente cuando sean necesarios para ese tipo de petición.

¿Es mejor bloquear una solicitud o dejarla pasar y pedir aclaraciones después?

Bloquea únicamente la ausencia de datos imprescindibles y ofrece una explicación clara para corregirla. Para casos no previstos, utiliza una ruta de excepción identificada, de modo que no se pierda la petición pero tampoco entre en el flujo ordinario como si estuviera completa.

¿Cómo saber si las validaciones están funcionando?

Establece una línea de partida antes del cambio y compara después el porcentaje de solicitudes completas a la primera, la tasa de devolución y el tiempo hasta que una solicitud queda preparada. Revísalos por tipo de proceso para detectar dónde conviene ajustar las reglas.