Capture the terms at the moment you agree them
The highest-value habit in the whole system, and it takes about ninety seconds. When the deal is agreed, write down the deliverable count and format, the number of included revision rounds, the delivery date, and the licence term — before you shoot anything.
Reconstructing these later from an email thread is not merely slower; it is unreliable in a predictable direction. Under time pressure you will resolve ambiguity in the brand's favour, because arguing feels disproportionate to the amount at stake. Written down in advance, there is nothing to resolve.
Attach deliverables to the deal, not to a list
A flat task list across all your work loses the thing that matters: which brand, at which rate, under which terms. 'Edit video 2' as a standalone task tells you nothing about whether that edit is included or billable.
Every deliverable should carry its parent deal, so the terms travel with the task. This is the structural reason a general to-do app underperforms here — it models tasks, and your problem is obligations under an agreement.
Count revision rounds explicitly
Unpaid revision creep is the most common way a fairly priced UGC deal becomes an underpaid one, and it happens gradually enough that nobody notices. Each individual request is small and reasonable, which is exactly why the total goes uncounted.
Record rounds used against rounds included, on the deliverable itself, and update it as they happen rather than at the end. When a request arrives that exceeds the allowance, the message writes itself: this is round three and two were included, here is the price for a further round. That is a straightforward conversation when you have the count and an uncomfortable one when you do not.
The sentence that prevents most of it
In your delivery email: 'This includes two rounds of revisions — just send consolidated notes and I'll turn them around within 48 hours.' Naming the allowance at handover, before any feedback exists, makes the limit a stated fact rather than a later objection.
Work from one cross-deal view
The question you actually ask on a Monday morning is 'what is due this week', across everything. If your system can only show you one deal at a time, it does not answer the question you have — which is why per-brand folders and per-brand threads feel organised while still letting deadlines pass.
Sort by due date across all deals, not by client. Client grouping is useful for finding something specific and useless for planning a week.
Let the brand see status
Roughly half of deliverable admin is answering 'where is it?' A shared view showing in progress, delivered, and approved removes that category of email entirely, and it reads as organised rather than as exposure.
It has a second benefit that matters later: it creates a dated shared record of when something was delivered. That settles most payment-timing disagreements before they become disagreements, because both sides are looking at the same timestamp.
Close the deal properly
A deal is not finished when the files are sent. It is finished when the invoice is paid — and the licence obligation continues past that, which is the part most tracking systems get wrong by archiving the record at delivery.
Keep three states after delivery: delivered, invoiced, paid. Then keep the record findable for the length of the licence, because you will need the terms when the expiry approaches and the renewal conversation is worth having.
- Delivered — Files handed over in the agreed formats. Revision allowance state recorded.
- Invoiced — Invoice sent to the right recipient with a due date. This is where deals stall most often.
- Paid — Money received and reconciled. Only now is the production side closed.
- Licence running — Not a closed state. Track the expiry date — this is where renewal income comes from.