Intake to Delivery: Why a Creative Ops DAM Runs the Workflow

Editor's note: This is a working argument, not a neutral survey. I run creative ops thinking into how we build YetOnePro, so I have a horse in this race — we build a Creative Ops DAM. Where I cite outside numbers I link the source. Where I give a number from operating a team, I say so and you should treat it as a working estimate, not a law.

One of the most expensive minutes in a creative project is the minute a finished, approved asset sits in someone’s downloads folder while a colleague re-uploads it into the place it was supposed to live all along. I have watched that exact handoff happen more times than I can count: the review tool says “approved,” the brand lead exhales, and then a coordinator drags the file out of one app and drops it into another, renames it, and hopes the rights and the version number survived the trip. They usually don’t.

That re-upload is a symptom. Underneath it, most teams run creative work across two or three systems that don’t share a source of truth: the project management tool owns the brief and the deadlines, the review tool owns the comments, and the DAM owns the final files. Each is good at its job. The trouble lives in the seams between them, and almost every guide to creative project management end to end assumes those seams are free. Monotype’s 2025 Scaling Creative Operations report(opens in new tab), a survey of 1,008 creative professionals in the US, UK and Germany, found 57% of creative teams spending more than a quarter of their time on non-creative work — asset management, compliance checks, workflow bottlenecks. That is what a seam costs.

The Creative Line, End to End#

Strip away the jargon and almost every comprehensive piece on creative work describes the same line. A request comes in. Someone decides who does it and by when. The work gets made, reviewed, and approved. The approved thing gets delivered to wherever it needs to go. Then it gets reused or retired. Five stages, in plain terms:

• Intake. A structured request lands. Not “hey can you make a thing” in a channel, but a brief with the outcome, the audience, the deadline, and the constraints captured up front.
• Routing and assignment. The request goes to the right person with the right capacity. This is the stage most teams improvise, and the one that quietly determines whether the project ships on time.
• Review and approval. Drafts circulate, stakeholders comment, versions stack up, and someone with authority says yes, in writing and on the record.
• Delivery and distribution. The approved asset goes out: to a client portal, a channel, a partner, a CMS. This is the stage the “creative project management” guides treat as a handoff and the DAM guides treat as the whole point.
• Reuse and archive. The asset gets found again, repurposed, or sunset when its rights expire. The part nobody plans for and everybody needs.

That is the creative project lifecycle, and it is not controversial. What is controversial is who should own it. The conventional answer is: split it. Let a project management tool own the first half and a DAM own the second. My answer is that the split is the problem, because the moment of approval is both the end of review and the beginning of delivery, and you cannot put that single moment in two systems at once without something falling through the crack.

DAM, PM, and Creative Operations Are Not the Same Thing#

These three terms get used interchangeably, and they shouldn’t be. A digital asset management system is about the files: where they live, how they are tagged, who can use them, which version is current. Project management software tracks something else entirely, the work itself, with its tasks and owners and deadlines. Creative operations is neither. It is the discipline that connects them, the practice of running creative work as a repeatable system rather than a series of heroic rescues.

For years the assumption was that you need a separate tool for each. Buy a DAM for the assets, buy project management software for the schedule, wire them together with an integration, and call it a stack. The problem with traditional project management applied to creative work is that it was built for tasks with clean acceptance criteria: ship the feature, close the ticket. Creative work doesn’t close that cleanly. A logo is “done” in a way a sprint never is, and the “ticket” for a logo is a file that will outlive the project by years.

A Creative Ops DAM collapses those layers into one system of record. It is a DAM that also understands work (intake, assignment, review, approval), so the asset and the workflow around it never live in different places. We built YetOnePro this way on purpose. If you want the longer taxonomy of how these categories differ, we wrote a whole piece comparing DAM vs MAM vs PAM, and a companion on what a creative operations manager actually does. The short version: the manager owns the line, and the tooling should let one person see all of it.

Intake Is Where Routing Starts#

The DAM guides describe intake as a lightweight brief form, and the creative project management guides call it a creative brief. Both descriptions are too modest. Done properly, intake is the routing engine for the entire creative team: the place where unstructured demand becomes structured, assignable work.

A good intake form does three jobs at once. It captures the project goals and constraints: the audience, the deadline, the budget, the channel, the brand it belongs to. Nobody designs in the dark. It enforces completeness, so a request can’t enter the queue missing the one field that will stall it in week two. And it feeds assignment: a request that knows it is a 30-second video for a launch can be routed to the editor who owns video, with their current capacity already visible. That last job is the one a creative brief living in a document can never do, because a document doesn’t know who is free on Thursday.

This is where the two-tool stack starts leaking. When intake lives in a request tool that is separate from where the work and the files live, the request becomes a copy. Someone reads the brief, opens the project tool, and re-types it as a task. The brief and the task drift apart immediately. The deadline changes in one and not the other, and three weeks later nobody can say which document is canonical. We go deeper on getting the upstream right in our creative brief template; the point here is that intake should not be a document you transcribe. It should be the first state of the work itself.

Approval Is an Asset State, Not a Message#

Here is the hinge of the whole argument. In a split stack, approval is a message: a comment, an email, a Slack thumbs-up that says “ship it.” The asset itself doesn’t change. It is the same file it was an hour ago; only a human now believes it is final. That belief lives in a notification, and notifications get lost, contradicted, and forgotten.

In a system where the workflow and the asset are one, approving something changes the asset itself. The file moves from “in review” to “approved.” That state carries the version that was approved, the person who approved it, the timestamp, and the rights that travel with it. The next person down the line doesn’t hunt through a thread to find out whether the file in front of them is the blessed one; the asset tells them. Orange Logic makes a version of this argument(opens in new tab): a standalone approval tool gives fast feedback but loses its value the moment it is disconnected from the final asset state.

If approval only ever existed as a message, then six months later, when someone asks which version the client actually signed off, the honest answer is whatever the thread remembers.

This is also why version confusion is endemic in split stacks. Review happens on a copy, approval happens on that copy, and then someone has to get it back into the DAM as the canonical version. Every one of those steps is a chance for v3-final to win over v3-final-ACTUAL. It is not a rare tax: in a Santa Cruz Software survey of more than 500 design professionals, nearly three-quarters reported spending at least three hours a week managing versions(opens in new tab), and 15% spent over six. It is a vendor-run survey, so read it as directional rather than definitive. Run version control inside the same system that runs review and the problem largely goes away. There is only one asset, and it has one current state. We cover the mechanics of that in our guide to version control for designers.

What Breaks in the Handoff to Delivery#

Follow the approved asset one more step. In the conventional setup, delivery is a fresh act: download the approved file, log into the portal or the CMS, upload it again, set the permissions again, and hope the metadata and the consent travel along. That metadata rarely survives the round trip. Rights and consent captured at intake live in the project tool, the delivered file came out of the DAM, and the two were never formally joined, so an asset can go out the door without the usage terms it was approved under.

I want to be careful here, because I can point to this failure in teams we have worked with but I cannot put a number on how widespread it is, and I have not found research that does. Treat it as a mechanism worth checking in your own stack rather than an established statistic: if your license expiry dates live in a different system from the files they govern, nothing is watching the gap.

When intake, approval, and distribution are states of one asset, nothing gets uploaded a second time. The same governed asset, in its approved state, is shared from the place it already lives. The rights ride along because they were attached to the asset, not to a separate record. The client gets the file through a branded portal that reads from the live library, so when a newer approved version exists, the link reflects it. This is the seam the “creative project management” literature skips and the DAM literature owns, and it is the entire reason to keep the line in one system. If the consent and license details matter to your work, we go deep on image rights management and on watermark protection for assets that go out the door.

Distribution to clients is its own discipline once the file is governed. A portal that pulls from the same library means there is no “final files” folder to assemble by hand and email as a zip. The thing the client sees is the thing the team approved. We wrote separately about client file management and about keeping client contacts inside the DAM so the people and the permissions don’t live in a spreadsheet on someone’s laptop.

Reporting Only Works When One System Owns the Line#

The payoff of running the whole creative process in one system is that you can measure it. Cycle time from intake to delivery. Revision counts per project. On-time delivery rate. Asset reuse. Every one of those metrics spans the seam between “the work” and “the files,” which means in a split stack you cannot compute them without exporting two datasets and joining them by hand. In my experience that join is the first thing to get dropped when a quarter gets busy, which is why a lot of teams cannot answer these questions on demand.

When intake, review, approval, and delivery are states of the same asset, the timestamps are already in one place. Cycle time is the gap between two states on one record. Revision count is the number of versions before the approved one. On-time delivery is the approved-state timestamp against the deadline captured at intake. None of these is a report you have to build. They are byproducts of the line living in one place, which is the difference between managing creative projects by anecdote and managing them by something you can see. For the broader case on why teams consolidate at all, our guide on how to choose a DAM and the foundational what is digital asset management both come at it from the asset side.

When Two Tools Is Actually the Right Call#

I should be honest about the limits of my own argument, because I have one. Consolidating the whole line into a Creative Ops DAM is the right move for teams whose center of gravity is the asset: in-house creative teams, brand teams, studios, and agencies whose deliverable is the file. There are three situations where I would tell you to keep two tools, and mean it.

Creative is a minority of the work. If the design team is eight people inside a two-hundred-person operation already running on a heavyweight project management platform, the seam you would fix is small and the migration you would force is enormous. Forcing a hundred non-creative people off their tool to gain a cleaner creative handoff is a bad trade. Keep the PM tool as the system of record for the program and let the DAM own the library.

Engineering owns the media pipeline. If assets are transformed and served programmatically, say a product catalog rendering thousands of variants through an API, then the thing you need is a media pipeline with SDKs, not a workflow surface. Creative ops sits beside that, and the consolidation argument does not apply to the automated half at all.

You are mid-contract on a platform the org has standardized on. Consolidation is a two-year payoff. If you are eighteen months into a three-year enterprise agreement and the compliance team has already built its audit reporting against that platform, the right answer is to fix the seam with an integration and revisit at renewal. I would rather say that than pretend the timing is always right.

The other honest caveat is migration cost. Moving the line into one system means moving the assets, and that is real work. We wrote a whole field guide to moving from Google Drive to a DAM precisely because it is the step teams underestimate. A good creative asset audit before you migrate, and a clear metadata taxonomy to land on, are what separate a migration that pays off from one that just relocates the mess. The consolidation argument is strong, but it is not free, and any vendor who tells you otherwise — including me, on a bad day — is selling.

The teams that benefit most are the ones where one person is already trying to hold the whole line in their head. A creative ops manager toggling between a request tool, a review tool, and a DAM is doing integration work by hand all day. Give that person a single system of record and the toggling stops being their job. The pitch is narrower than a new category to buy. You already use all three; they should share one truth. If the seams in your current stack are where your projects keep slipping, that is the signal worth acting on. And if brand consistency is the thing that keeps breaking in the handoff, our piece on brand management picks up that thread.

Viacheslav Shuranov

Co-Founder at YetOnePro

Entrepreneur and software engineer with 20+ years building products that matter. From payment systems to telemedicine to media encoding, Viacheslav has led technical teams as CTO and Tech Lead across multiple startups. He co-founded YetOnePro to solve the creative workflow problems he encountered firsthand.

Contact author

If you want to leave feedback, suggest an addition, or report something outdated — reach out.