Un plazo parece una regla sencilla hasta que alguien pregunta si cuentan los fines de semana, qué ocurre cuando falta un documento o si una tarea reabierta conserva su fecha original. Si el proceso no responde de forma consistente, las personas improvisan: unas esperan, otras escalan y el equipo acaba resolviendo excepciones manualmente.
Definir vencimientos no consiste solo en mostrar una fecha en pantalla. Requiere acordar una política de negocio que determine cuándo comienza el cómputo, cómo se comporta ante cambios y qué consecuencias tiene llegar al límite. Esta guía ofrece un método para tomar esas decisiones en solicitudes, aprobaciones, entregas y tareas internas.
Por qué un plazo ambiguo se convierte en un problema operativo
Cuando dos participantes interpretan de forma distinta la misma fecha, pueden actuar de buena fe y aun así entrar en conflicto. Una persona puede considerar que el plazo empezó al enviar una solicitud; otra, cuando el equipo la revisó. Para operaciones, esa diferencia puede alterar prioridades, compromisos y métricas de cumplimiento.
La ambigüedad también genera trabajo invisible: mensajes para confirmar fechas, ajustes manuales, escalaciones y explicaciones repetidas. En los datos, puede aparecer como retraso aunque el reloj se haya iniciado antes de que el equipo pudiera actuar, o como cumplimiento pese a que el resultado llegó tarde según la expectativa de quien solicitó el servicio.
Antes de cambiar el sistema, identifica el problema concreto. Revisa incidencias, consultas frecuentes y tareas reabiertas. Si las discrepancias se concentran en el inicio del cómputo, aclarar la fecha de vencimiento no resolverá la causa. Una política útil debe poder explicarse en una frase y aplicarse igual en casos equivalentes.
Define el evento de inicio y la unidad del plazo
El primer acuerdo es el evento que pone en marcha el reloj. Puede ser el envío de una solicitud, la recepción de todos los datos obligatorios, la asignación a una persona o la aceptación de una tarea. Elige el evento que refleje cuándo empieza realmente la obligación que quieres medir. Si el trabajo no puede comenzar hasta recibir información completa, iniciar el plazo al crear el borrador suele distorsionar la expectativa.
Especifica qué significa que un envío esté completo y quién confirma esa condición. Si la validación se realiza más tarde, define si el inicio se produce al recibir la información o al aceptarla. Evita dejar esa decisión a criterio informal de cada equipo.
Después, elige la unidad:
- Horas: adecuadas cuando importa la rapidez continua y existe capacidad para atender fuera del horario habitual. Aclara si son horas corridas o de atención.
- Días naturales: cuentan todos los días del calendario. Son fáciles de entender, pero pueden incluir periodos en los que el equipo no opera.
- Días hábiles: reflejan calendarios laborales, aunque exigen definir qué calendario se usa, qué festivos se consideran y cómo se tratan distintas regiones.
No escojas una unidad por costumbre. Compárala con la promesa real del proceso y con la capacidad de cumplirla. Una política que depende de calendarios diferentes debe indicar cuál prevalece para cada solicitud, en vez de asumir que todos comparten los mismos días laborables.
Acuerda pausas, información pendiente y cambios de prioridad
Una pausa modifica el cómputo; por eso debe tener una causa reconocible, un responsable y un evento de reanudación. Por ejemplo, el reloj podría detenerse mientras se espera una respuesta de quien solicitó el servicio. En ese caso, define cómo se solicita la información, cuándo empieza la pausa y qué acción la termina: recibir una respuesta, validar que está completa o cerrar la consulta.
Evita la etiqueta genérica «en espera» si puede abarcar situaciones distintas. La espera de una persona externa no equivale necesariamente a una dependencia interna. Si ambas detienen el plazo, registra por separado los motivos; así podrás distinguir una demora ajena al equipo de un bloqueo operativo que sí requiere intervención.
Los cambios de prioridad también necesitan una regla. Una prioridad más alta no debería reiniciar automáticamente el reloj sin una razón de negocio. Decide si modifica la fecha objetivo, si afecta solo el orden de trabajo o si requiere aprobación. Registra quién autorizó el cambio y qué fecha estaba vigente antes de aplicarlo.
Para festivos, cierres y calendarios especiales, determina si el proceso usa una regla común o un calendario asociado a cada equipo. Cuando una solicitud cambia de equipo o región, especifica si conserva el calendario original o adopta el nuevo. La respuesta debe ser coherente con el compromiso comunicado, no solo con la organización interna.
Establece vencimientos, prórrogas y reaperturas
Un vencimiento necesita una consecuencia operativa definida. Puede activar un aviso, una escalación, una revisión de capacidad o una nueva decisión de prioridad. No presupongas que «vencido» significa automáticamente que la solicitud debe rechazarse o cerrarse: esa consecuencia debe ser explícita y adecuada al proceso.
Separa la fecha objetivo de la acción que se produce al alcanzarla. Una alerta puede avisar antes del límite para permitir actuar; la escalación puede ocurrir al vencimiento si no hay respuesta. Define también quién recibe cada aviso y qué debe hacer. Si nadie es responsable de responder a una alerta, el aviso añade ruido en vez de reducir retrasos.
Las prórrogas deben ser excepciones controladas, no una forma silenciosa de ocultar incumplimientos. Aclara quién puede concederlas, en qué circunstancias, si hace falta informar a las partes y cómo se conserva el historial de la fecha original y la nueva. Para reaperturas, decide si se retoma el plazo anterior, comienza uno nuevo o se aplica una regla distinta según la causa. Por ejemplo, corregir un defecto puede requerir un tratamiento diferente de añadir una petición nueva.
Conviene registrar motivo, responsable y momento de cada modificación. Así se puede reconstruir qué regla se aplicó y distinguir una extensión legítima de un ajuste para mejorar artificialmente los indicadores.
Comunica la fecha y sus consecuencias con claridad
Quien participa en el proceso necesita entender qué se espera y qué puede cambiar. Comunica la fecha límite junto con una explicación breve de cómo se calcula: por ejemplo, desde qué evento cuenta y si se incluyen días no laborables. No hace falta exponer cada detalle administrativo, pero sí evitar presentar una fecha como definitiva si depende de información pendiente o de una validación.
Cuando el plazo cambie, explica qué se modificó y por qué, quién debe actuar y cuál es el nuevo límite. Si una pausa depende de otra persona, indica qué información falta y qué ocurrirá cuando la aporte. La comunicación debe describir consecuencias reales, no insinuar sanciones que la política no contempla.
Adapta el mensaje al papel de cada participante. Una persona solicitante puede necesitar saber qué acción desbloquea el proceso; quien ejecuta la tarea, qué prioridad tiene y cuándo debe escalar. Mantener un lenguaje consistente entre mensajes, documentación y atención reduce interpretaciones contradictorias.
Prueba casos límite y asigna responsables
Antes de publicar una regla, recórrela con ejemplos concretos. Incluye al menos un caso normal, uno con información incompleta, uno que atraviese un fin de semana o festivo, un cambio de prioridad, una prórroga y una reapertura. Pregunta qué fecha corresponde en cada etapa, qué persona debe actuar y qué registro queda. Si dos equipos responden distinto, la regla todavía necesita precisión.
Una lista de comprobación práctica puede ayudar:
- ¿Está definido el evento que inicia el cómputo y cómo se determina que se ha producido?
- ¿La unidad y el calendario coinciden con la capacidad y la promesa del proceso?
- ¿Cada pausa tiene un motivo permitido y una condición de reanudación?
- ¿Se conocen las consecuencias del vencimiento, la prórroga y la reapertura?
- ¿Las personas reciben una explicación comprensible cuando la fecha cambia?
- ¿Hay una persona responsable de aprobar y revisar la política?
Asigna la propiedad de la regla a un rol concreto, por ejemplo, la persona responsable del producto o del proceso operativo. Revisa la política cuando cambien compromisos, calendarios o formas de trabajo, y observa señales como escalaciones repetidas, muchas prórrogas o disputas sobre el inicio. No cambies los plazos solo para mejorar una métrica: primero averigua si el problema está en la capacidad, la definición o una dependencia mal gestionada.
Una buena política de vencimientos no elimina todas las excepciones; permite tratarlas de manera explicable y consistente. Cuando inicio, pausas, cambios y consecuencias están acordados, el equipo puede anticipar bloqueos y las personas participantes saben qué esperar. Ese es el criterio práctico para decidir si un plazo está bien diseñado.