Creative project tracking: how to spot stalled and at-risk work without opening every board

Creative project tracking is the layer above your board: a small set of filtered views and rules that answer which deliverables are on track, which have stalled, and which will miss a date — without opening each board and reading every card. The board stores the truth. Tracking is how you read it in a few minutes.

Most teams try to do both at once, and get neither. They add more columns, more labels, more cards, and still cannot say on a Tuesday morning whether a client project has moved since Friday.

Tracking is the reading layer, not the board

Setting up a production board is a different job from running it. Stages, routing rules, handoff conventions and who owns which stage are setup work, covered in content production workflow: board, routing and handoffs. This article assumes that structure already exists and answers the question that comes after it: how do you know, from outside the board, that work has stopped moving?

Two failure patterns appear when tracking is missing. The first is silent drift: a card sits in Review for six days and nobody notices because nothing is on fire yet. The second is theatre: the board looks busy because it is full of cards, and busyness hides that four deliverables have been waiting on the same client since last week. Both are solved by the same three things — named states with exit conditions, saved filtered views, and one aging rule.

The five states worth tracking, and what moves each one

Five states cover almost every creative deliverable. The point of the table is not the names; it is that each state has a defined exit and an owner. A state with no exit condition is a place work goes to be forgotten.

The distinction that matters most is between in review and blocked. Review has a version, a reviewer and usually a date. Blocked has none of those, which is why blocked work ages faster and needs chasing more aggressively. If your board uses one column for both, split it.

For the field conventions that make these states filterable, the freelance project tracker setup covers the minimum record each deliverable needs — client, deliverable, stage, due date, and whose court the ball is in.

Three filtered views replace opening every board

You do not need a dashboard product. You need three saved views that you look at in the same order every day.

1. Due this week. Filter: due date within the next seven days, stage is not Done. This is your commitment list. It should be short enough to scan in a minute; if it is not, your due dates are decorative.
2. Waiting on someone else. Filter: stage is Review or Blocked. This is where the schedule quietly dies, because waiting work produces no activity and triggers no alarm.
3. Aging past threshold. Filter: days in current stage above your threshold for that stage. See the next section for setting it.

The second view only works if the next action has an owner. The convention that holds up: put the next action on a task, with an assignee, attached to the card. "Client approves v2" assigned to the reviewer, with a due date. A card in Review with an unassigned task is a card nobody owns, and it will sit there.

If a client is the reviewer and you have given them access, note that a guest without the view-all permission sees only the cards they are assigned to — which is exactly the behaviour you want for review access, but it also means an unassigned card is invisible to them. Assignment is not paperwork; it is visibility.

Aging: the number that separates late from busy

Aging is how long a card has been in its current stage. Any tool that records stage entry time can show it. The threshold is a convention you set, not a benchmark anyone else can give you: a common starting point is two business days for a review round you control, and five for an edit stage. Adjust once, then leave it alone and let it fire.

Aging tells you something has been idle. It does not tell you whether the job can still land. For that, do one piece of arithmetic per at-risk deliverable.

Assume a deliverable is due in 10 days (counting from today), still needs 4 days of editing, and has 2 review rounds left with a 2-day turnaround each. That is 10 − (4 + 4) = 2 days of slack. Narrow, but survivable. Now change one input: if the edit actually needs 7 days, slack is −1 — the date is already gone before anything goes wrong, and the helpful move is to say so today rather than on the morning it is due.

Delivery slack estimator

Decide whether a deliverable can still land on its due date, or whether the date needs to move now.

Slack equals the days left before the due date minus the editing days still needed and the total review turnaround (rounds multiplied by days per round). Zero or negative slack means the date is already at risk or missed.

Assumptions: Illustrative planning inputs from your own estimates, not measured benchmarks. Assumes review turnaround per round is roughly consistent and that no extra rounds are added; slow or bundled client feedback will change the answer.

Worked example: Days until the due date: 10 days; Editing days still required: 4 days; Review rounds remaining: 2 rounds; Turnaround per review round: 2 days. Slack days before the due date: 2 days.

Where aging and slack disagree, trust slack. Aging says "this has been in review four days". Slack says "you still have two days". Both are true and useful, but slack decides whether you make the phone call.

Automations that tell you when work stops moving

Three automations remove most of the manual checking. Board automations run as "when X happens, do Y" and are opened from a board's menu; a stage that has them shows a bolt and a count on its header, so you can see at a glance where they sit.

• On entering Review, create a task for the reviewer with a due date. This is the single highest-value rule you can add, because it converts an anonymous waiting card into assigned work. If nobody gets assigned, the rule has exposed a gap rather than created one.
• When a card becomes overdue, notify its assignees. This trigger fires once per due date. It is deliberately conservative: one message, not a daily nag that everyone learns to ignore.
• A scheduled Monday summary. The ready-made template for this is a weekday standup card; the weekly review template drafts a report into Drive. Either gives you a starting point for the sweep below instead of a blank page.

Automation steps that use AI drafting spend AI credits like any other generation, so keep the scheduled one narrow — a list of overdue and aging cards, not a full narrative report. If a run fails or is rejected, the Runs tab says why in plain words and offers Retry on the same event. Full detail is on the automations overview.

A Monday sweep across 26 deliverables

Say a four-client studio has 26 open deliverables on Monday morning: 11 on track, 6 in review, 4 blocked, 3 at risk and 2 finished last week. Here is a 20-minute pass, done in this order.

1. Minutes 0–5: the review list. For each of the 6 cards in review, answer one question — is a named person working on this today? If yes, leave it. If no, assign the task now or move the card to blocked.
2. Minutes 5–10: the blocked list. For each of the 4 blocked cards, send one message to the person holding it, and record the promised date on the card. Do not send a second chase on a card where a chase already went out this week; that is how you become noise.
3. Minutes 10–14: the at-risk list. Run the slack arithmetic on the 3 at-risk cards. For any negative number, decide now: move the date, cut the scope, or add a person. Decide out loud, in writing, on the card.
4. Minutes 14–20: update the due dates and the client lines. Where a date moved, change it in the workspace and write the client-facing sentence you will send this afternoon. Not tomorrow — today, while the context is fresh.

The outcome you want is a short list of decisions, not a longer list of cards. If the sweep ends with 26 cards and no decisions, you have read your board, not tracked your projects.

What clients see, and how to say it

Internal states are diagnostic labels. Exporting them to a client is a separate translation job, and doing it badly makes small problems look like chaos. The rule is: report the change, the impact, and the one thing you need.

For clients who want more detail than a message, a dated milestone view works better than a status feed; the structure is described in building a client-facing project timeline. Whatever you share, share it from the same record you run internally, so the version you send is never a hand-written guess.

To start this week, do not rebuild anything. Take your three most likely-late deliverables, run the slack arithmetic on each, and open one conversation per negative number while there is still room to change the outcome. The tracking system can come after — the decisions cannot wait for it.