Treat a submittal as a controlled project decision, with an identifiable package, a review owner, and a visible disposition—not simply a collection of PDFs.
Begin with the project’s requirements
Read the applicable specifications, equipment schedule, purchase requirements, and agreed submittal procedure before assembling the package. Identify the equipment tags covered, the documents requested, the responsible reviewers, and the required submission dates. A package for a hydronic circulation equipment may differ substantially from one for another application. Avoid copying a previous project’s index without checking its relevance.
Build an index the reviewer can follow
Depending on the project, the package may include product data, selection information and performance curves, dimensional or arrangement drawings, motor and control details, and the requested supporting documents. Identify the proposed model and configuration rather than leaving the reviewer to choose among catalog options. List each included document with its number, title, revision, and related equipment tag. Explicitly identify outstanding information and departures for review.
Check consistency before issuing
Use an internal review to compare equipment tags, model references, duty information, dimensions, and electrical details across the package. Route technical questions to the responsible engineer or manufacturer. The coordinator’s role is to make discrepancies visible and confirm that the right people have reviewed them, not to substitute document completeness for engineering approval. Give the issued package a revision identifier and retain the exact version transmitted.
Track comments through to resolution
Keep reviewer comments with the package they refer to. For each comment, record the response owner, proposed resolution, affected document, and current status. A resubmission should make changes easy to locate and explain how each comment was addressed. Use the project’s actual disposition terms rather than assuming that “reviewed,” “approved,” and “approved as noted” authorize the same next step.
Connect review status to the project schedule
Work backward from the required procurement or delivery milestone and allow time for internal checking, external review, and potential resubmission. Track the next action and the party holding it. Before purchasing, fabrication, or another release step, confirm the applicable authorization with the project owner. A returned package may still contain conditions or unresolved items that affect the planned action.
Carry the accepted record into handover
Keep superseded revisions available for traceability while clearly identifying the revision relevant to the current work. Connect the final project record to equipment identity, subsequent changes, and the documents required for handover. Distinguish the submitted selection from what was ultimately supplied or installed. The service team should inherit a usable equipment record, not an undifferentiated archive of every project email.
A simple coordination example
For a fictional two-asset project, the register might show an arrangement drawing awaiting a dimensional clarification and product data already returned with comments. The coordinator assigns the drawing response, records the due date, and identifies the downstream release that remains dependent on it. The value is a clear next action and a traceable decision; the register itself does not approve the equipment.
A practical equipment submittal register template
For a service company coordinating a replacement equipment or customer upgrade, a complete folder is only the starting point. The coordinator needs to know who is answering each comment and what the next person is authorized to do. Use three linked records: a package register, a document index and a comment log.
UFGS 01 33 00, dated August 2026, offers an example of a formal procedure: its register provisions distinguish transmittals, review actions and dates. Adapt the structure to your actual project procedure rather than importing its action codes into every customer job.
Open these in your spreadsheet tool. Each file contains column headings only. Add your own project records, due dates and agreed review terms.
1. Package register: who owns the next action?
Keep the package identifier stable through resubmissions. Retain the history of each issue instead of overwriting earlier review events. Record both the original due date and any revised date, with a reason for the change.
| Field group | What to record |
|---|---|
| Identity | Project, package ID, description, equipment tags and requirement reference |
| Responsibility | Coordinator, technical response owner and review recipient |
| Issue and timing | Package issue, transmittal, sent date, due dates and required release date |
| Review | Returned date, exact disposition, conditions and return-record link |
| Next action | Action, named owner, due date and blocker |
| Release | Authorized scope, authorizing person, date and supporting evidence |
Keep review disposition and release authorization separate. A returned package can still contain conditions. For a service contractor, the relevant release might be an equipment order, approved installation scope or repair center action; the project’s actual process determines the authority.
2. Document index: which files were actually issued?
A package issue and a document revision are different identifiers. Package issue 03 can contain an unchanged data sheet at revision 01 and an updated drawing at revision 04. Link each row to the exact file transmitted, and archive the index with that issue.
| Document | Title | Equipment tags | Revision |
|---|---|---|---|
| PD-101 | Selected equipment product data | P-101, P-102 | 01 |
| GA-101 | General arrangement drawing | P-101, P-102 | 04 |
| CR-101 | Comment-response schedule | P-101, P-102 | 02 |
3. Comment log: an answer is not yet confirmed closure
Give every comment an ID. Record its reviewer, original wording, source document and revision, page or drawing location, response owner and due date. Link the response to the revised document and outgoing transmittal. Keep a separate closure-evidence field.
- AssignedOwner and due date recorded
- Preparing responseTechnical question with the appropriate reviewer
- Response issuedAnswer and revised reference transmitted
- Closure confirmedEvidence required by the review procedure retained
These are suggested internal working statuses, not substitutes for the project’s official review codes. “Response issued” means your team has answered. Confirm closure only when the agreed process supports it.
An illustrative comment, followed through
In a fictional project, comment C-007 requests a dimension clarification on GA-101 revision 03. The coordinator assigns the response to the appropriate manufacturer representative. When revision 04 and a response arrive, the coordinator updates the index, records the outgoing transmittal and marks the response as issued. The subsequent review record supplies any required closure evidence. The updated drawing alone does not authorize dependent work.
Use the register in the service-project meeting
Review overdue responses, missing information and decisions affecting upcoming work. Ask: what document or decision does the next person need, and who will provide it? At closeout, connect the current project record to the equipment actually supplied and the customer’s service requirements.
Continue with the equipment project-to-service handover checklist, or explore customer equipment history and service work-order records.
A working checklist
- Project requirements, equipment tags and required reviewers identified
- Every returned comment has an identifier, response owner and due date
- Technical questions routed to the appropriate qualified reviewer
- Responses identify the affected document, revision and location
- Related documents checked for effects of the proposed changes
- Document index matches the exact files being transmitted
- Outgoing package, changes and unresolved items retained together
- Response issued distinguished from confirmed comment closure
- Returned disposition, conditions and exclusions preserved
- Dependent work has the required release authorization and evidence
- Current record linked to the customer equipment and service handover
Further reading: UFGS 01 33 00 — Submittal Procedures, August 2026. Sections 1.9.4–1.9.6 provide one example of register fields and review action codes. This guide specification requires project-specific tailoring. The actual contract and agreed review procedure govern your project. The templates below are original coordination aids, not engineering approval.
An operational planning perspective. Equipment-specific decisions and service procedures remain with qualified personnel and the customer’s approved process.