How to Track Creative Projects, Revisions, and Client Approvals

A logo project quoted at 18 hours took 47. The client loved round one, picked direction B, then sent a Loom three weeks after sign-off asking to "just try it in green, and maybe see what it looks like with the icon on the right." You did it. You ate the time. You told yourself the next project would be different.

This is the math of creative project management. Deliverables are visual and subjective. Approval is opinion, not transaction. Revision counts drift open-ended unless someone caps them in writing. And the tools most studios use — a mix of Figma comments, Loom links, email threads, Dropbox folders, and a Notion page someone forgot to share — let scope creep happen silently until you reconcile the time sheet at month-end and discover you billed 60% of what you worked.

This post is the operational playbook for tracking creative work end-to-end: the lifecycle from brief to archive, the file-versioning structure that prevents "wait, which one was final?", the contract language that protects margin, the client approval workflow that holds up, and the KPIs that tell you whether the studio is actually profitable. Written for 1-15 person creative operations — solo freelancers, small studios, in-house creative teams — doing brand, web, packaging, motion, or content work.

Generic project management software was built for transactional work. Engineers ship a feature, salespeople close a deal, support reps close a ticket. Each one has a clear definition of done. The card moves to the right column and the work is complete.

Creative work does not behave that way. "Done" is what the client says is done, and the client gets to change their mind. A logo that you spent 20 hours refining can be sent back with the comment "can we see it more energetic?" — which is not a brief, not a spec, and not a thing your project management tool has a status for. The work item is not closed; it is reopened on subjective grounds you cannot fully anticipate.

Three things make creative project management structurally different from general PM:

Approval is opinion-based, not criteria-based. There is no test suite that runs green. There is a client looking at a JPG and deciding whether they like it. The same deliverable can pass on Tuesday and fail on Thursday because the client showed it to their spouse over the weekend.

Revisions are open-ended unless capped contractually. Without a scope clause that says "three rounds of revisions included, additional rounds at $X/hour," the revision count drifts. The client does not see revisions the way you do. To them, a small color tweak is a comment, not a round.

Deliverable artifacts proliferate. A single logo project ends up with source files in Illustrator, working files in versioned folders, exported PDFs for client presentations, PNGs for the website, SVGs for the dev team, brand guidelines as a separate doc, and font licensing receipts as a third attachment. Tracking the canonical version of each is its own job.

The upshot: a creative project management system has to track the deliverable, the version, the revision count, the approval status, the hours spent, and the contractual scope simultaneously — because the moment any one of them drifts, margin disappears.

Every project — brand, web, packaging, motion, content — moves through roughly the same six phases. The names vary by studio. The shape does not.

Brief intake, mood boards, competitive audit, stakeholder interviews. The deliverable is alignment, not artwork. The hidden time-sink: every studio underestimates discovery, because it does not produce a visible artifact. A 4-hour kickoff call generates 8-12 hours of synthesis, mood-boarding, and brief writing before any creative work starts.

What to track: time logged against discovery, mood board artifacts, signed-off brief document.

Three to five directions presented to the client. This is the highest-risk phase for scope creep, because the client has the most agency here — they can ask for more directions, hybrid directions, or a do-over.

What to track: each direction as a versioned artifact (Concept A, B, C), time logged per direction, presentation file (PDF or share link) sent to client.

Client picks one direction. This should be a single decision documented in writing — not a Slack message, not a Loom reaction, a formal sign-off that names the chosen direction and acknowledges that the other directions are no longer in scope.

What to track: written approval of selected direction, archived non-selected directions.

Revisions on the chosen direction. This is where the contractual revision cap matters. A reasonable industry default is 2-3 rounds of revisions included in the original quote. Each round is a single bundled set of feedback applied at once, not an open thread of individual tweaks.

What to track: revision round number (Round 1, Round 2, Round 3), feedback document for each round, time logged per round, versioned deliverable file per round (v2_round1, v3_round2).

Production files in the requested formats. For a brand project, this is typically a kit: PDF brand guidelines, vector logo files (AI, EPS, SVG, PDF), raster exports (PNG at multiple sizes, JPG), color specs (HEX, RGB, CMYK, Pantone), and font licensing documentation. For a web project, source design files plus a dev hand-off document. For packaging, dieline files and print-ready PDFs.

What to track: final delivery package (organized folder structure with naming conventions), client receipt confirmation, archived source files.

Project closes. Source files archived with version history. Final invoice sent. Project moved out of active board.

What to track: project archived (read-only access for client if applicable), invoice paid, retrospective notes (estimated vs actual hours, revision count vs scope).

Revision creep is the single biggest margin killer in unscoped creative work. The pattern is almost identical across studios:

You quote a project at 18 hours. Round 1 of revisions takes 3 hours and is contractually included. Round 2 takes another 3 hours, also included. Then comes the email three days after final delivery: "Hey, one small thing — can we just try a different shade of blue?" You spend 40 minutes on it. The next day: "Actually, can we also see it with a slightly thicker outline?" Another 30 minutes.

None of these requests felt large enough to push back on individually. By the time you reconcile the time sheet, you have eaten 6-8 hours of unbilled work. The project came in at 47 hours instead of 18, and your effective hourly rate dropped from $125 to about $48.

In unscoped freelance creative work, hour overruns on projects happen roughly 60% of the time. The fix is not better willpower. It is contractual language plus a tracking system that surfaces the overrun in real time, not at month-end.

The clause does three things: caps revision rounds, defines what counts as a round, and prices overage at a clear rate.

Sample scope clause language:

"This project includes three (3) rounds of revisions on the selected concept direction. A revision round is defined as a single, consolidated set of written feedback delivered within 5 business days of the most recent deliverable. Additional revision rounds beyond the three included, or feedback received after final delivery, will be invoiced at $125/hour in 15-minute increments, with an estimate provided before work begins.

A new project scope (new direction not previously presented, new deliverable type, or new use case) will be quoted separately as a change order."

Typical revision-overage rates as of 2026: $75-150 per hour for freelance, $125-200 per hour for studio work. The rate matters less than having the rate.

The clause does not exist to milk clients. It exists to give you a clear, non-awkward path to charge for work the client genuinely needs done but did not include in the original scope. "Happy to make that change. Per our agreement, this is a Round 4 revision at $125/hour — I estimate about 90 minutes. Want me to proceed?" is a calm sentence. Eating the time and resenting the client is not.

Most studios discover their file naming convention after the third time a client says "can you send me the final one again?" and they have to scan six PDFs to figure out which is current.

A workable convention has four parts: project code, deliverable type, version, status.

Format: `{project}_{deliverable}_v{n}_{status}.{ext}`

Examples:

- `acme_logo_v1_concepts.pdf` (Round 1 presentation, three directions) - `acme_logo_v2_selected.ai` (After concept selection, single direction) - `acme_logo_v3_round1.pdf` (After Round 1 revisions) - `acme_logo_v4_round2.pdf` (After Round 2 revisions) - `acme_logo_v5_final.pdf` (Approved final, presentation file) - `acme_logo_v5_final.ai` (Approved final, source file) - `acme_brand_guidelines_v1_final.pdf` (Separate deliverable)

The status field is the operative part. `concepts` / `selected` / `round1` / `round2` / `final` makes it unambiguous which file matches which phase. The version number is monotonically increasing across the project; never reset to v1 mid-project.

The folder structure mirrors the phases:

``` /Clients /Acme Co /01_Brief /02_Concepts /03_Selected /04_Refinement /05_Final Delivery /06_Archive ```

This matters because every studio eventually faces the "three years later, client emails asking for the source file" question. A consistent structure means you can find the file in 30 seconds instead of an hour.

Approval is where most studios bleed time. The pattern goes wrong in three places.

Place one: where feedback gets collected. A client sends comments via email, Slack, a Loom recording, a PDF annotation, and a phone call — all on the same deliverable. Now you have feedback scattered across five surfaces, and consolidating it into a single actionable list is its own 30-minute task.

Place two: who counts as the approver. A small business owner approves a concept, then their business partner sees it the next week and hates it. The studio assumed the owner had authority. They did. But the partner did not know about the project and now wants changes. The studio eats the time.

Place three: what "approved" actually means. A client says "looks great, ship it!" Two days later they ask for one more tweak. Was the "looks great" an approval or a checkpoint? Without a formal sign-off, the answer is whatever the client wants it to be.

The approval workflow that holds up:

1. Single feedback channel per deliverable. Whether it is a Figma comment thread, a customer portal review page, or a structured form, all feedback for a deliverable goes through one channel. "If you want it changed, put it here." No exceptions — if a client sends a Loom, you copy the actionable points into the canonical channel and reply there.

2. Named approver, named in the contract. The scope agreement names a single person on the client side with sign-off authority. Other stakeholders can review and comment, but the named approver is the one whose written approval ends the round. If the client wants to add an approver mid-project, that is a change order.

3. Formal sign-off, written and dated. Approval is a sentence: "I approve the v5_final logo as the final deliverable. The project is complete." Not a thumbs-up emoji, not a verbal yes on a call. A line of text in the canonical channel with a timestamp. This is the artifact that ends the project and starts the clock on the post-delivery revision-rate window.

Different studios cobble together different stacks. The honest picture as of 2026:

- Figma comments for in-design feedback on web/app/UI work. Strong for collaborative review, weaker for non-Figma deliverables. - InVision historically used for approval workflows; usage has declined as Figma absorbed most of the use case. - Notion for project tracking and docs. Flexible, but rarely the place where files live. - Asana, ClickUp, Trello for general project management. Built for task tracking, not creative deliverables — no native revision count or approval state. - Dropbox, Google Drive for file storage. Universal, but version control is manual. - Loom, email, Slack as the de facto feedback channels. Easy to use, terrible for consolidation. - Specialized review tools (ReviewBoard, Filestage, ProofHub) designed for creative approval workflows. Best-in-class for the approval step; another subscription on the stack.

Most 1-5 person creative operations end up with five or six of these in active use. The integration tax is real — the same project has files in Drive, comments in Figma, tasks in Notion, hours in a spreadsheet, and an invoice in QuickBooks. Reconciling them at month-end is its own meaningful chunk of time.

Deelo is not specifically a creative tool. It is a small-business operating system where every app shares one customer record. For creative teams, that translates to running the full project lifecycle on one platform without the integration tax.

Here is how a 5-person studio runs a brand project end-to-end on Deelo:

Projects. Project record per client engagement, with deliverables as sub-items (logo, brand guidelines, business card design, website mockup). Each deliverable has a status (Discovery / Concept / Selection / Refinement / Final / Archived). Revision round is a numeric field on the deliverable.

Docs. Source files, working files, and versioned exports stored with version history. Naming convention enforced via folder template. Client-facing files in a separate share with read-only access.

Forms. Revision request form embedded in the customer portal. Required fields: deliverable, revision round, feedback (consolidated), priority. Submission creates a task on the deliverable and increments the revision count.

Customer Portal. Client logs in and sees their project status, deliverables awaiting their review, comment threads on each deliverable, and a sign-off button that creates a written, timestamped approval record.

Time. Hours logged per deliverable, per phase, per revision round. Real-time visibility into estimated vs actual hours; alerts when a project crosses 80% of its budget.

Invoicing. Invoice generated from the project with line items for the original scope plus any revision overages (auto-calculated from time logged in revision rounds beyond the scope cap). Client pays via the same portal where they approved the work.

The value is not that any one of these apps is the best-in-class version of itself. The value is that they share a customer record, so an update on the deliverable in Projects shows up in the Customer Portal, the time logged in Time flows into Invoicing, and the approval in the portal closes the deliverable in Projects. No Zaps to maintain. No reconciliation at month-end. One system of record.

Putting it together, here is the full operational sequence that protects margin on creative work:

Step 1: Scope it in the proposal.

Proposal includes scope clause with revision cap (typically 3 rounds), revision definition (single consolidated set of feedback), overage rate ($75-150/hr freelance, $125-200/hr studio), and named approver. Client signs proposal before work starts.

Step 2: Log every revision request.

Every feedback round gets logged as a revision round on the deliverable. Round number visible to both you and the client. No revision happens off-the-books — if a client sends a Loom with "just a small tweak," you copy the points into the canonical channel and log it as Round N before applying.

Step 3: Track time per round in real time.

Hours logged against each round, not pooled across the project. This lets you see when you are approaching the budget for a given round and gives you the data to bill confidently if overage occurs.

Step 4: Surface scope-creep early, not at invoice time.

When the client requests changes that fall outside scope (Round 4+, new deliverable, new direction), you flag it the moment you see it, not after you have already done the work. "Quick heads up — this would be Round 4, which is overage at $125/hr. I estimate about 2 hours. Want me to proceed?" Said calmly, in the moment, this is rarely a fight. Said three weeks later at invoice time, it is awkward and often results in a discount.

Step 5: Charge for the overage, confidently.

Invoice includes a clear revision-overage line item with hours logged. Not buried, not apologetic, not absorbed silently. The contract said this is what happens. The system has the data. The line item is the natural consequence of the agreed scope.

The studios who run this consistently report two things. Margin per project rises by 20-40% within the first quarter (because previously-eaten revision time is now billed). And client relationships actually improve — clients prefer knowing what changes cost in advance to discovering at final invoice that you have been quietly absorbing their requests.

A small creative team does not need a dashboard. It needs four numbers, reviewed monthly:

Gross hourly realized is the single most important number. Compute it monthly: total revenue invoiced divided by total hours logged across all projects. If you quote at $125/hr and your realized rate is $60/hr, you are running a 50% margin leak somewhere — almost always in revision creep or scope drift.

The other three KPIs exist to tell you where the leak is. High repeat-client rate plus low gross hourly means clients love you but your pricing is too low. Low repeat-client rate plus high gross hourly means scope enforcement is too rigid. The pattern in the data is the diagnosis.

Creative work will always have a subjective edge that pure transactional PM tools do not handle well. The studios that stay profitable are not the ones with the most rigid scope policies — they are the ones with the clearest system. Scope is set in writing, revisions are logged as they happen, time is tracked per round, and approvals are formal artifacts rather than vibes. The system does the discipline so the designer can do the work. That is the difference between a studio that ships 47 hours of work and bills 18, and one that ships 47 hours of work and bills 47.