Practical checklist
What this article covers
A delivery-package manifest with editable-source expectations, references, versions and known issues; no duplicated issue-readiness article.
A useful transmittal identifies the exact files sent, their purpose, the recipient and the exceptions they need to understand. It is a delivery record, not evidence that the recipient has accepted the design.
Use this proposed checklist for a bounded production handoff. Adapt its fields to the project's document-control and access arrangements.
Build a manifest before packaging
Name the package and intended use. List the required native files, PDFs, references, review notes and other agreed outputs individually. Keep excluded material separate from missing required material.
Autodesk explains that Revit eTransmit uses saved host and linked-file versions. Confirm the intended saved baseline and packaging options; do not assume the utility captures unsaved changes or every supporting document.
Give the recipient a usable delivery record
| Manifest field | What to record |
|---|---|
| Package identifier | Stable reference for this exact delivery |
| File identity | Filename, format and relevant revision |
| Purpose | What the recipient is being asked to do |
| Dependency arrangement | Included reference or agreed accessible location |
| Software context | Agreed version and relevant receiving requirements |
| Exceptions | Missing items, unresolved questions and use limits |
| Recipient and access | Intended recipient and approved transfer route |
| Receipt result | What was received, opened or still needs correction |
Do not place credentials in the manifest. Confirm transfer access through the agreed secure channel and avoid widening access merely to make a delivery easier.
Compare the manifest with the package itself
Open the staged package through the agreed receiving workflow where practical. Check filenames and revisions, required references, PDF page identities and the presence of issue notes. Record what was actually tested.
Autodesk's sheet-list documentation describes the index role within a drawing set. Use the sheet-index checklist when the manifest and drawing index cover different subsets.
For CAD content, ask for the project's required dependencies and plotting references instead of applying Revit-specific assumptions to a DWG package.
Hypothetical example: the manifest and PDF revisions disagree
In this fictional handoff, the manifest lists Review-PDF-R4, but the staged folder contains Review-PDF-R3. The model file is correctly identified as the current saved baseline.
Do not relabel the old PDF to match the manifest. Ask the production owner to supply the intended output, then repeat the relevant package check. If the lead elects to send the older PDF for a limited purpose, record that decision and describe the actual revision honestly.
Retain the earlier delivery record if a package was already sent. A replacement should identify what changed rather than silently overwriting the recipient's reference.
Separate delivery, receipt and acceptance
“Sent,” “received,” “opened successfully” and “accepted for the stated use” describe different events. Record them separately and identify the person responsible for each remaining decision.
Use the drawing issue checklist before release. Nest's outsourcing quality-control guide and construction documentation support provide context for agreeing deliverables and review responsibilities.
Related guides and services
Keep the production handoff connected to the wider workflow:
Need help with current production work?
Tell us which drawings, models, visualizations, or review packages need attention. We can review the assignment, confirm availability, and explain whether a project package or dedicated monthly support fits.
Book a project callSend a project brief