Tareas recurrentes: recurrencia vs plantilla vs SOP
El problema: lo repetitivo inunda el backlog (o desaparece)
En casi todo equipo hay un estrato de trabajo que vuelve: facturar cada mes, dar de alta a cada cliente nuevo, publicar el contenido de cada semana. Ese estrato se gestiona mal de dos formas opuestas e igual de caras. La primera: desaparece del sistema y depende de la memoria de alguien —y el mes que esa persona se va, la facturación se va con ella—. La segunda: todo se convierte en recurrencia y el backlog se llena de recordatorios que nadie atiende.
El costo del primer error es un incidente; el del segundo, ruido crónico: tarjetas vencidas acumuladas que enseñan al equipo a ignorar el tablero. La pregunta correcta no es «¿cómo registro esta tarea repetitiva?» sino «¿qué tipo de repetición es esta?». Y hay tres tipos.
Recurrencia, plantilla y SOP: tres herramientas distintas
La recurrencia repite por calendario, la plantilla repite por evento y el SOP documenta el cómo. Se eligen mal porque en la herramienta de turno las tres parecen lo mismo: una lista de tareas. La diferencia está en qué dispara la repetición y en cuánta variación tiene el trabajo:
| Enfoque | Qué es | Cuándo usarlo | Ejemplo |
|---|---|---|---|
| Recurrencia | La tarea se crea sola cada cierto tiempo, se hace y se cierra. | Trabajo corto, igual cada vez, disparado por fecha. | Facturación mensual: el 1.º de cada mes, sin variación. |
| Plantilla | Un paquete de tareas predefinido que se instancia cuando ocurre un evento. | Misma secuencia siempre, disparada por un suceso, no por el calendario. | Onboarding de cliente: 9 pasos desde que firma el contrato. |
| SOP | El documento que explica cómo se hace el trabajo, paso a paso. | El trabajo varía, lo ejecutan personas distintas o se quiere traspasar. | Publicación de blog: brief, borrador, revisión, SEO, publicación. |
El SOP es el único de los tres que transfiere conocimiento, y por eso es la pieza que convierte trabajo de especialista en trabajo de equipo. Cómo escribirlo para que la gente lo use de verdad —y no otro documento que nadie abre— está en cómo documentar procesos de un equipo.
La prueba rápida: si la tarea siempre es igual y dura minutos, recurrencia. Si cambia el día pero no los pasos, plantilla. Si cambian los pasos según quién lo haga, SOP —y probablemente también plantilla, con el SOP enlazado dentro.
Cómo elegir la periodicidad (cadencia real contra cadencia deseada)
El error más común al crear una recurrencia no es la herramienta sino la frecuencia: se programa la cadencia deseada —«facturaríamos idealmente cada semana»— en lugar de la real. A las tres semanas hay dos recurrencias vencidas, y cada vencida ignorada erosiona la credibilidad de todo el tablero: el equipo aprende que las fechas del sistema son sugerencias.
La regla honesta: empieza por la cadencia que hoy cumples de verdad, aunque te parezca poca, y aprieta solo cuando lleves un mes cumpliéndola. Si quieres pasar de facturación mensual a quincenal, primero demuestra que la mensual entra como reloj. La cadencia deseada es un objetivo de mejora, no una configuración.
Señal de cadencia mal puesta: la recurrencia se cierra tarde siempre, o se cierra «en blanco» —marcada como hecha sin revisar nada—. Ninguna de las dos es un problema de disciplina: es el calendario pidiendo un ajuste.
Automatizar sin nube: reglas, no robots
Automatizar lo repetitivo no exige integraciones complejas ni suscripciones: una regla de tres piezas cubre la mayoría de los casos. Disparador: «cuando una tarjeta entra a la columna Cliente firmado». Condición: «si el tipo de proyecto es web». Acción: «crear las 9 tareas de onboarding con dueño y fecha».
Esa estructura —trigger, condición, acción— reemplaza a la recurrencia en los casos donde el disparador real es un evento y no una fecha: la plantilla de onboarding no debería crear tareas cada lunes, sino en el momento en que algo cambia de columna. Bien puesta la regla, la automatización no ahorra tecleo: ahorra la memoria que falla.
Lo que todavía no conviene automatizar: lo que cambia de forma cada vez y lo que se hace menos de una vez al mes. Automatizar un proceso inmaduro solo consigue que el error se repita con puntualidad perfecta.
Cuándo matar una tarea recurrente
Una recurrencia no es un contrato vitalicio. Estas señales dicen que toca retirarla:
- Tres tandas seguidas cerradas sin revisar nada. El check de inercia es el síntoma clásico: se marca para que deje de sonar.
- Nadie sabe para qué existe. Si preguntas en el equipo y la respuesta es «siempre se hizo», ya no es un proceso: es una tradición.
- El evento que la originó ya no ocurre. El cliente cambió, el reporte se canceló, la plataforma migró.
- Vive fuera del tablero. Si la gente la apunta en otro lado para no verla en el sistema, la recurrencia ya perdió la batalla.
La revisión trimestral de recurrencias toma 15 minutos: recorre la lista, mata las muertas, ajusta las cadencias que se cerraron tarde siempre y pregunta por cada una la pregunta incómoda: «¿si dejáramos de hacerla, pasaría algo?». Lo que sobreviva a esa pregunta merece seguir en el calendario.
Si quieres manejar lo repetitivo en una herramienta local-first —checklists y SOPs junto al tablero, automatizaciones con reglas simples, tus datos en tu propia carpeta en JSON y sin cuenta— Hito está hecho para equipos de 1 a 15 personas.
👉 Prueba Hito gratis — recurrencias, plantillas y SOPs en tu carpeta, sin nube.
Preguntas frecuentes
¿Qué son las tareas recurrentes?
¿Cuándo usar una plantilla en vez de una tarea recurrente?
¿Qué es un SOP y cuándo conviene?
¿Cómo automatizar tareas repetitivas?
¿Cada cuánto revisar las tareas recurrentes?
Equipo Hito
Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.