The two questions that cause most delivery arguments are boringly factual: which version are we talking about, and what round are we on.
Email cannot answer either. A Delivery Room is a per-booking workspace whose main job is that it can.
Who can see it
A room is party-gated: the brand who owns the booking, and the creator who was booked. Nobody else, on either side.
That's worth knowing because it changes what you can put in it. It isn't a public share link. It's a private workspace, so working versions, internal notes on constraints, and the invoice can all live there without a second thought.
Versions, not files
You submit deliverables as versions. v1, v2, v3, each preserved.
Three things follow from that, and they're the whole value:
A note stays attached to the version it was written against. When the brand says "at 1:12 the pause is too long", that note lives on v2. When v3 arrives, the note doesn't float free and become ambiguous.
"Which one were you looking at?" stops being a question. The single most common source of wasted review rounds.
Nothing is overwritten. When someone says "actually the previous one was better" (and they will), it's still there.
Submitting is creator-only and capped. You control what enters the room as a deliverable, and the cap is a guard against a runaway loop, not a limit you'll meet in normal work.
Comments, pinned to a timecode
Either side can comment, and a comment can pin a leading timecode.
This is the mechanical fix for the worst category of feedback. "The bit near the end where the music changes" costs you ten minutes of scrubbing and a coin flip on which bit they meant. "At 1:12" costs nothing and is unambiguous.
You don't need frame accuracy for review: 1:12 is plenty. What matters is that a time is attached at all. Timecode feedback covers the conventions, and it's worth sending to a client who's giving you vague notes; most people have simply never been told how.
The verdict is one-shot
The brand's verdict is brand-only and guarded by a one-shot machine: it can be given once, per the round.
That constraint is doing something specific for you. It makes "we're on round two" a fact in the system rather than a claim in an email thread, which is exactly the fact most likely to be disputed at the point it costs money.
If your agreement says two rounds, the room is the record of whether you've used them. That's your protection as much as theirs.
What this changes about your process
You still have to run the project. What the room removes is a specific class of friction:
- No "can you resend the link"
- No "I thought we'd already changed that"
- No reconstructing which version was approved, from memory, months later
- No notes scattered across three inboxes and a WhatsApp thread
What it doesn't remove: the client still has to give good notes, consolidated, from one voice. A tool can hold the record; it can't stop seven people commenting independently. That's a conversation you have at kick-off. See managing expectations.
The invoice lives here too
Room invoices attach to the same booking. Moving one from draft to sent emails the brand owner with a print link.
Worth being precise about what that is and isn't: Acumin records the invoice, it does not process the payment. Marking it paid is a bookkeeping acknowledgement: a note that money arrived by whatever means you actually use. Invoicing through Acumin covers the details.
Then you get rated
When the work is delivered and paid, the brand rates it: on quality, communication and timeliness.
That rating is the only thing that moves your Acumin Score, and it can only exist because a real booking completed. Which is why running a job through the room rather than around it compounds: the same work builds proof you couldn't otherwise get.
Two of those three dimensions are about how you ran the project, not how you shot it. The room helps with both.
The honest limits
It's not a review tool for internal edits. It's a delivery workspace between two parties. Your own edit process lives wherever it already does.
It doesn't move money. Connect-only doctrine: Acumin records numbers and never handles payment.
Fail-soft on newer features. Some of the room's newer comment fields land in later migrations; a deployment missing one reads that field as empty rather than breaking. You may occasionally see a capability the docs mention and your instance doesn't have yet.
How to use this tomorrow
On your next delivery, submit as a version with a short note saying what stage it is: "rough cut, no grade, temp music, looking for structural notes."
That one sentence prevents the most expensive review round there is: the one where a client panics at an unfinished cut and gives you colour notes on work that hasn't happened.
Related: Delivering files covers formats and naming, which still matter. Invoicing through Acumin is the last step.