Section 3.8: Deliverables — Review & Approval

A deliverable is a single piece of work someone owes the project — a document, a cut, a design file, or a link to work stored elsewhere. This guide walks through the full lifecycle: creating a deliverable, assigning it, submitting work against it, and moving it through feedback to approval.

1. Creating a Deliverable

Add a deliverable by giving it a name. From there, you can optionally connect it to other deliverables in the project using two relationship types:

• Blocks: This deliverable must be finished before the linked one can move forward.
• Relates To: A looser connection for deliverables that are related but not strictly dependent on each other.

These relationships feed the dependency view described below, so it's worth setting them up if your deliverables have a natural order.

2. Assigning Work

A deliverable isn't limited to a single owner — you can add multiple assignees to the same deliverable, and each one gets their own allocated hours. This is useful when a deliverable is a shared effort rather than one person's task.

To help you pick the right people, ABRAM can suggest recommended assignees, each shown with a confidence indicator so you can gauge how strong a fit the suggestion is before you commit to it.

Every change to who's assigned is kept in an assignment history, so you can look back and see who was added or removed from a deliverable and when.

3. Submitting Work

Once assigned, a contributor submits their work directly on the deliverable. Two submission types are supported:

• File upload: Upload a PDF or Word document.
• Reference links: Attach one or more links pointing to work hosted elsewhere (for example, a cut stored in Frame.io).

Every time a new submission comes in, it's saved as a new version — a revision counter increases with each round, so nothing overwrites the previous attempt and everyone can see how the work has evolved.

4. Feedback & Approval

Reviewers respond to a submission with a typed feedback entry. Each entry is one of three types:

• Approve: The submission is accepted.
• Request Revision: The submission needs changes before it can be approved.
• Reject: The submission is turned down.

Feedback entries can optionally be time-coded, which is useful for pointing to a specific moment in a video or audio submission rather than describing it in words.

Alongside formal feedback, every deliverable has a comment thread that supports @mentions to pull in specific teammates. Comments are clearly separated into client comments and internal comments, so your team's internal back-and-forth stays distinct from anything a client has said.

5. Organizing & Tracking Deliverables

A few tools help keep larger deliverables — or a large batch of them — manageable:

• Checklist sub-tasks: Break a deliverable down into smaller checklist items to track partial progress.
• Dependency view: See how deliverables connect to each other based on the Blocks and Relates To relationships you set when creating them.
• Portal visibility toggle: Control whether a specific deliverable is shown or hidden in a connected Client Portal.
• Activity feed: See a running history of what's happened on the deliverable.
• Bulk actions: Select several deliverables at once to assign them, set dependencies, update their status, or link them to a milestone in one step.

6. What Your Client Sees

If a deliverable's portal visibility toggle is turned on and it belongs to a project shared with a Client Portal, your client can open it, review the submission, and leave comments of their own. Their comments show up in the same thread, tagged separately from your team's internal comments.

For a full walkthrough of setting up and managing client access, see Section 6.4: Client Portal.

7. Related Guides

• Section 3.2: Work Packages & Milestones — how deliverables fit into the larger project structure
• Section 3.4: Task Lists & Tracking — tracking deliverables alongside milestones and work orders
• Section 6.4: Client Portal — sharing deliverables with clients for review