Business Operations Template

Why most operations templates stop being used

Operations work doesn't behave like a project. There's no delivery date to converge on and no final column that means finished forever. The same categories of task come back every week, and a template that assumes an end state stops fitting within a month.

Requests arrive through too many channels. Email, chat, a forwarded message from a manager, each gets triaged differently depending on who saw it first, and there's no single point where every ask is treated the same way before anyone starts on it.

Recurring tasks live in someone's calendar reminders, not the board. The reconciliation, the reorder, the inspection: they happen because one person remembers to do them, which means they stop happening the week that person is out.

Vendor follow-ups stall silently. A renewal or a quote request has no visible due date once it's sent, so it sits unresolved for weeks with nobody quite owning the fact that it's stalled.

"Done" doesn't reset. A project board's done column fills once and stays filled; an operations board that copies the same pattern ends up with a done column holding eighteen months of one-off entries nobody looks at, mixed in with tasks that will simply reappear next week regardless.

None of these are failures of effort. Most operations teams work hard and still end up here, because the tool they're using was built for work with a start and an end, and operations work has neither. The fix isn't a better spreadsheet; it's a board shaped for the way the work actually repeats.

What a normal week looks like on the board

There's no kickoff and no wrap-up on an operations board, just a cycle that resets and runs again, which is worth picturing concretely rather than describing in the abstract. Monday morning, the request queue has whatever came in over the weekend: a vendor onboarding form from procurement, an expense query flagged by finance, a facilities ask forwarded from someone's inbox. Each becomes a card before anyone touches it. The weekly task column, capped at five, already has the standing items: payroll reconciliation, the supply reorder, a compliance check that runs every Monday regardless. Requests from the queue only enter that column once something in it closes. The cap holds even during a busy week, which is precisely the week it matters most. The vendor column sits apart, with the AMC renewal sitting there for its third week because the vendor hasn't replied: visible, not silently dropped. By Friday, closed-this-cycle shows what actually got done, and next Monday the standing items reappear in the weekly column on their own, because they always do.

How to use it

1. 01Route every request through the queue. No side channel, if a request comes in over chat, the first step is turning it into a card, not answering it directly.
2. 02Size the weekly column to real capacity, and cap it. Count what the team can actually carry in a normal week, not what it managed during a quiet one.
3. 03Keep vendor follow-ups in their own column. They move at a different pace than internal requests and get missed when mixed in with everything else.
4. 04Write the SOP into the wiki the first time you do a task, not after the third time someone asks how it works.
5. 05Review closed-this-cycle weekly. It's the fastest way to see which tasks are truly recurring and which have become dead weight on the board.
6. 06Re-check the weekly cap monthly. Recurring load changes as the business does, a cap set correctly six months ago is worth revisiting rather than assumed still right.

None of this is specific to ShipSprint. A single queue, a capped weekly column and a separate vendor lane will work in any tool that supports them. It's written down here because the single-queue rule is the one operations boards drop first, usually within the first busy week, right when it would have mattered most.