Track Retainer Clients in Notion (Without Losing the Plot on Hours)

Project-based clients and retainer clients need different tracking, and treating them the same is how a retainer quietly goes sideways. A project has a start, an end, and a fixed scope — you can watch it move through a pipeline. A retainer just continues, month after month, with no natural checkpoint forcing anyone to ask "are we still delivering what they're paying for." That question needs to be asked on a schedule, or it doesn't get asked at all.

Why a deal pipeline doesn't fit a retainer

Most freelance CRMs — including a plain Lead → Proposal → Negotiation → Won pipeline — are built around a deal closing once. A retainer client closes once and then needs tracking every month after that, which a one-time pipeline stage was never designed to hold. If you're running retainer clients through the same board as new-business deals, they either sit forever in "Won" doing nothing useful, or you're duplicating the client every month just to have somewhere to put this month's status.

The fix is a small addition, not a different tool: a lightweight Retainer Log, one row per client per month, sitting next to your existing client and project data.

The properties that matter

• Client — relation to your clients database, or text if you're not running a full CRM
• Month — e.g. "March 2026," title field
• Hours Included — number, from the contract
• Hours Used — number, updated as work happens
• Hours Remaining — formula: prop("Hours Included") - prop("Hours Used")
• Renewal Date — date
• Status — On Track, Over Hours, Needs Check-in

The one formula that prevents scope creep

Retainer Flag:
if(prop("Hours Remaining") < 0, "🔴 Over hours",
   if(prop("Hours Remaining") < prop("Hours Included") * 0.15, "🟠 Running low", "🟢 On track"))

This is the entire value of the system. Without it, "did we go over on the Meridian Studio retainer this month" is a question you answer by manually adding up time entries, which means you answer it rarely — usually only after the client asks first, which is the worst time to find out. With a flag that computes itself, going over is visible the day it happens, not the day the client mentions it.

Renewal dates deserve their own view

Retainers don't renew themselves, and a contract that auto-continues silently is exactly how a rate that should have gone up two years ago never does. Add a view sorted by Renewal Date ascending, filtered to the next 60 days. That's your list of conversations to have — about scope, about rate, about whether the relationship is still working for both sides — before the renewal happens by default instead of by decision.

Where this sits relative to a full CRM

If you're running Freelance CRM Pro, the Retainer Log relates naturally to the same Clients database — a client can have deal history, active projects, and a running retainer log, all visible from one page. If you're using the simpler Client Tracker Lite, the log works fine on its own with a plain text client field; you just lose the automatic cross-reference to project and deal history.

Invoicing a retainer is the same pattern as any other invoice — see the invoice-tracking system for the overdue-flag approach — except the invoice line item references the retainer month instead of a one-off project.

The habit, not just the database

Once a month, for each active retainer:

1. Log hours used for the month that just ended.
2. Check the flag. If it's amber or red, that's the conversation to have before the next invoice goes out, not after.
3. Glance at the renewal view. Anything inside 60 days gets a note on your calendar to actually talk about it.

None of this is complicated. The value is entirely in it happening on a schedule instead of only when something's already gone wrong — the same principle that makes an overdue-invoice flag useful, applied to the slower-moving problem of a retainer that's drifted from what it was originally scoped to be.