Managing Recurring Work: Ops Boards Beyond Projects

Project management has a bias built into its name: it assumes work ends. But a huge share of what teams actually do never ends — the monthly close, the content calendar, employee onboarding, vendor renewals, the IT queue, security reviews, payroll, the weekly newsletter. This work has no launch date and no done state. It has cadences, queues, and service levels. And when teams manage it with project tools and project thinking, the same failures appear everywhere: recurring tasks that live in one person's head, request queues with no intake discipline, "urgent" defined by volume of the requester's voice, and quality that depends entirely on who happened to do the task this month.

Recurring work deserves its own operating system. This guide builds one: the three shapes recurring work takes, board designs for each, how to set service levels you can actually keep, templates that make the hundredth run as good as the tenth, and the metrics that matter when "on time and on budget" doesn't apply.

The three shapes of recurring work

Almost everything operational falls into one of three shapes, and each needs different machinery. Misdiagnosing the shape is the root of most ops-board misery.

Shape	Trigger	Examples	Core machinery
Cadenced	The calendar	Monthly close, payroll, weekly newsletter, quarterly access review	Recurring checklist + owner + deadline
Request-driven	Someone asks	IT tickets, design requests, contract reviews, data pulls	Intake form + triaged queue + SLA
Threshold-driven	A condition trips	Certificate expiry, stock reorder, license renewal, backup failure	Monitored trigger + runbook + owner

The diagnostic question is "what starts an instance of this work?" A team that puts its monthly close in a request queue will do the close whenever someone remembers to ask. A team that handles design requests as calendar items will batch them into uselessness. Sort your recurring work into the three buckets first — the rest of the system follows from the sort.

One more distinction worth making early: recurring work is not interrupt work. A request with a three-day SLA is recurring work; a production outage is an interrupt. Interrupts preempt everything and are handled by on-call machinery. Requests wait their turn in a queue. Teams that let every request behave like an interrupt don't have an ops process — they have a doorbell.

Cadenced work: the checklist is the process

Calendar-triggered work fails in two characteristic ways: it silently depends on one person's memory, and its quality drifts because each run is improvised. Both have the same fix — the run becomes a checklist instance generated from a template, on a board, with an owner and a deadline.

Take the monthly close as the worked example. The template is a task set:

1. Lock the AP inbox — day 1, owner: AP
2. Reconcile bank accounts — day 2, owner: Staff accountant
3. Accruals and prepaids posted — day 3
4. Revenue recognition run and reviewed — day 3
5. Flux analysis on variances >10% or >$25k — day 4
6. Controller review and sign-off — day 5
7. Reporting package to leadership — day 5

On the first of each month, the template stamps out a fresh group of tasks — dated, owned, checkable. Now the close has four properties it lacked as tribal knowledge: anyone can see where this month's run stands; a sick day doesn't stall it (the next person picks up the checklist, not a mystery); the deadline pressure lands on the step that's late, not diffusely on "finance"; and improvements compound, because when step 5's threshold proves too noisy, you edit the template and every future month inherits the fix.

That last property is the quiet superpower. The template is the process. Process improvement stops being a meeting and becomes an edit. This pairs naturally with lightweight written procedure — the checklist says what and when, and links to the SOP that says how; the division of labor between the two is covered in SOPs for small teams.

Two design details that separate working cadenced boards from decorative ones:

• Relative dates, not absolute ones. Template steps are dated "day 2 of the run," not "the 2nd" — closes, onboardings, and event run-ups all slide, and absolute dates rot instantly.
• A named run owner per instance, rotating if you like. "The team" owns nothing. Rotation is actually desirable here: it spreads the knowledge, stress-tests the template (the newcomer finds every gap the veteran silently papered over), and converts bus-factor risk into documentation improvements.

Request queues: intake is destiny

Request-driven work lives or dies at intake. A queue fed by Slack DMs, hallway asks, and emails to whoever-answered-last isn't a queue — it's a popularity contest with tickets. The design sequence:

1. One front door

All requests enter through one channel: a form feeding a board. Ruthlessly. The form asks only what triage needs: what do you need, when do you genuinely need it (a date, and why that date), who's it for, and links to context. Every field beyond that costs you compliance — people route around long forms, and a bypassed front door is worse than none because it looks like coverage.

The social contract makes or breaks this: requests through the front door get triaged within a stated time and get status visibility; requests around it get redirected, politely and every single time, including when the requester is senior. One exception granted for rank produces ten more within a month.

2. Triage, on a clock

Someone — a rotating triage duty, not everyone-and-therefore-no-one — reviews new requests on a stated rhythm (daily for an IT queue, twice weekly for a design queue). Triage does four things in under two minutes per item: accepts or bounces it (with a reason and a redirect), sizes it roughly (S/M/L is plenty), assigns a priority tier, and either queues it or, for genuinely small items, just does it — a "two-minute rule" lane keeps trivial requests from queuing behind large ones.

3. Statuses that requesters can read

The board's columns are the requester's status page: New → Triaged → In progress → Waiting on requester → Done. That fourth column matters more than it looks — a huge fraction of ops cycle time is spent waiting for the requester to answer a clarifying question, and without a dedicated status, that wait is invisibly charged to your team's reputation. Make it visible and the conversation changes from "why is my request slow?" to "it's been waiting on your brand assets since Tuesday."

Openbook teams typically build this as a Kanban room (the queue, with card templates for common request types and per-column limits) fed by a Table Board or form intake, with requesters given viewer access so "what's the status?" becomes a look instead of a message. Whatever the tool, the invariants are one door, clocked triage, and requester-visible status.

Threshold-driven work: the quiet third shape

The third shape — work triggered when a condition trips — is the one teams forget, because between trips it is invisible. Certificates expire, domains lapse, licenses renew, stock runs low, a backup fails, a contractor's access outlives the contract. Nobody "does" this work weekly, so it lives nowhere, until the day it becomes a P1 with a story attached.

The machinery has three parts:

1. A registry. One table of every known threshold: the thing, the condition, the check date or monitoring source, the owner, and the action link. Building it is an afternoon of unglamorous archaeology — grep the team's past incidents and calendar reminders for everything that ever expired by surprise, and ask each teammate "what do you keep a personal reminder for?" Personal reminders are the shadow registry; the exercise moves them into daylight.
2. A detection path per row. Some conditions can be monitored automatically (cert expiry, disk space, backup status) — those alert into the request queue like any other item, pre-tiered. The rest get a cadenced proxy: a monthly fifteen-minute "registry sweep" task, itself template-generated like any cadenced run, whose checklist is literally the registry rows due for a look. The sweep converts threshold work into cadenced work, which you already know how to run.
3. A pre-written response. Each row links to the two-paragraph runbook for its trip: what to do, who to tell, what "resolved" means. Written on a calm Tuesday, not during the outage. When the trip happens, the work enters the queue as a normal tiered item with its runbook attached — no heroics, no archaeology.

The payoff profile is unusual: months of nothing, then one afternoon where the renewal that would have taken down single sign-on for two hundred people is instead a routine P3 handled a month early. Threshold work is the cheapest insurance in operations, and the registry is the whole premium.

SLAs: promises you can measure

A service-level agreement for internal work sounds corporate until you watch a team without one: every requester assumes their item is next, the ops team disappoints everyone slightly, and priority goes to the best negotiator. An SLA replaces negotiation with a published promise. Keep it to a small table:

Tier	What qualifies	First response	Resolution target
P1 — Broken	Work-stopping: can't access systems, payroll error, site down	1 business hour	Same day
P2 — Blocked soon	Deadline within a week depends on it	4 business hours	3 business days
P3 — Standard	Everything else	1 business day	10 business days

Rules that keep an SLA honest:

• The tier is assigned at triage, by your team, using the published definitions — not chosen by the requester, or everything becomes P1 by Thursday. The requester supplies the deadline-and-why; triage maps it to a tier.
• Two clocks, not one. First response ("a human has seen this and here's what happens next") and resolution are separate promises. The first is cheap and buys enormous goodwill; most requester frustration is uncertainty, not speed.
• Set targets from data, not aspiration. Measure your actual cycle times for a month first, then publish targets you hit ~90% of the time. An SLA you meet 60% of the time teaches everyone to ignore SLAs; under-promising by 20% and over-delivering builds the trust you'll spend during a crunch.
• Publish the exceptions calendar. The close week, the conference run-up, December: response targets double, announced in advance. An SLA with honest seasonal exceptions beats a uniform one that quietly fails every quarter-end.

And the standing rule underneath all of it: SLAs are a queue-discipline mechanism, and queues only behave when work-in-progress is capped. An ops team that starts everything finishes nothing on time; per-person and per-column limits are what make the resolution clock keepable. The math and the arguments are in WIP limits: the most underrated tool — for ops teams they are not optional garnish, they are the engine.

Templates: the hundredth run as good as the tenth

Cadenced work got templates above; request work deserves them too. Any request type you see more than a few times a month should have a card template: pre-filled checklist, standard subtasks, the definition of done, and links to the relevant SOP. New-hire onboarding is the canonical case — accounts, hardware, access grants, intro meetings, week-one check-in — and the canonical horror story when it's improvised per hire.

The template library becomes the team's real process documentation, better than any handbook page because it's executed, not just written. Three habits keep the library alive:

• Post-run edits. The person who just completed a run has a 24-hour window of perfect knowledge about what the template got wrong. Make "edit the template" a standard last checklist item — literally step n of the template is "update this template."
• Version the big ones. For compliance-adjacent runs (access reviews, close, audits), note what changed between template versions and when. When the auditor asks "what was your process in March?", the answer is a template version, not archaeology.
• Prune quarterly. A library of forty templates where eight get used is a library of eight templates and thirty-two decoys. Usage is visible on the board; archive the decoys.

Ops metrics: flow, not milestones

Project metrics — percent complete, milestone attainment, budget variance — are meaningless for a queue that never ends. Ops work is measured as flow. Four numbers cover a team, reviewed monthly:

1. Throughput — items completed per week, by type. The baseline for every capacity conversation: "the queue grew by 30 requests and our throughput is 25/week" is an argument; "we're swamped" is a mood.
2. Cycle time — request-to-done, as a distribution, not an average. The 85th percentile is your honest promise: "most requests finish inside six days" means the 85th percentile is six days. Averages hide the long tail, and the long tail is what requesters remember.
3. Aging WIP — the single best early-warning signal. Any in-progress item older than ~2× the typical cycle time for its type gets looked at this week: it's blocked, oversized, or abandoned, and all three deserve action before the retro.
4. SLA attainment — percent of items meeting their tier's targets, by tier. Trending down two months running means the promise, the staffing, or the intake filter needs to change; pick one deliberately instead of letting the misses choose.

Notice what's absent: utilization. Aiming for everyone-busy-always is how queues explode — queueing math is brutal about this, with wait times rising steeply as utilization approaches 100%. Ops teams need visible slack to absorb arrival spikes; the slack isn't waste, it's what the SLA is made of.

Review the four numbers in a monthly ops retro — same retro discipline as any team, pointed at the system: which request types blew their SLA and why, which templates need editing, what should stop coming through the queue entirely because it deserves automation or self-service.

Staffing patterns: shields and rotations

The hardest recurring-work problem isn't the work — it's protecting the people doing it from being interrupted into uselessness, especially on hybrid teams where the same people carry both project and ops load. Three patterns, in ascending order of team size:

• Duty rotation (teams of 3–8). One person per week is the interrupt shield: they own triage, the two-minute lane, and anything urgent, while everyone else works the queue and projects uninterrupted. The duty week is scheduled at reduced other-commitments — a shield who's also expected to deliver project work protects nothing. Rotation spreads queue knowledge and caps burnout, and the handoff note ("watch ticket 214, vendor is flaky this week") becomes a compact ops journal.
• Split allocation (teams of 8–20). Standing sub-teams: some fraction of people on the queue this cycle, the rest on improvement projects (automation, self-service, template work), rotating monthly. The improvement lane is what stops an ops team from being a hamster wheel — its explicit charter is to shrink the queue's future volume.
• Product-ized service (20+). The queue gets a real owner, published SLAs, a self-service catalog for the top request types, and its own roadmap. At this scale the intake form's biggest job is deflection to self-service — the best ticket is the one the requester resolved themselves in less time than the form would have taken.

Whichever pattern fits, make the recurring load visible in planning. The classic failure is sprint-planning a team to 100% project capacity while 40% of their actual week is queue work — the mechanics of blending the two on one board, per team flavor, are laid out in agile beyond software.

Failure modes: a short bestiary

• The memory-shaped process. The renewal that only Priya knows about, discovered when Priya is on leave and the certificate expires. Test: could someone else run this from what's written down? If not, it's not a process yet — template it this month, before the calendar tests you.
• The everything-urgent queue. No tiers, or requester-assigned tiers, so the queue is sorted by loudness. Fix at triage, with published definitions and the standing sentence: "Tell me the deadline and what it's for, and we'll tier it."
• The frozen middle. Board looks busy, throughput near zero — twenty items in progress, all waiting on something. The fixes are the Waiting on requester column, aging-WIP review, and hard WIP limits, in that order.
• The improvement-free wheel. Same queue, same volume, same complaints, year over year, because 100% of capacity goes to serving the queue and 0% to shrinking it. Ring-fence the improvement lane even when — especially when — the queue is loud.
• The stealth second door. Six months in, an exec's assistant has a private channel to the team, and the front door is quietly optional again. Re-close it, publicly and kindly; the SLA only protects the people who use the queue if the queue is the only way in.

Where to start, in order

1. Inventory and sort. List every piece of recurring work your team does; tag each cadenced, request-driven, or threshold-driven. The list will be longer than anyone expects — that's the point.
2. Template your top three cadenced runs this month, with relative dates, run owners, and "edit this template" as the final step.
3. Open one front door for requests: minimal form, board behind it, triage duty on a clock. Measure cycle times for four weeks before publishing SLA targets.
4. Publish the three-tier SLA with both clocks, set from your measured 85th-90th percentile, with the exceptions calendar attached.
5. Install the flow metrics and the monthly ops retro, and give the improvement lane a protected slice of capacity from day one.

If you'd rather not bolt this together from a form tool, a spreadsheet, and a project app, Openbook covers the whole loop in one space — Table Boards and Kanban rooms with templates for the queues and runs, dashboards wired live to the boards for the flow metrics, and check-ins for the duty handoffs. Explore the room types on the features page, start free, and give your recurring work the system your projects already have.