Requirement
The submittal item or review requirement from the project manual, named by its type.
A submittal log is the list of everything the spec book makes you submit, who owes it, when it's due, what's been reviewed and what's still waiting on somebody. A lot of late material orders go back to a row that never made it onto the log.
The submittal item or review requirement from the project manual, named by its type.
Something like Section 09 51 00 Acoustical Ceilings, page 212. That's what tells you why the row is there.
Who owes it, whether it's gone out yet and what came back from the architect.
When procurement needs the stamp back, and what got decided along the way.
Before any product ships, the project manual spells out what has to be submitted and reviewed, and those requirements are spread across dozens of sections. The log pulls them together into one list the whole team can see.
A log that's just a list of names doesn't help much. A useful row keeps its section, its type, who owns it and whether it still needs a decision, and that's what lets a reviewer trust the list without reading the manual again. If two people on the team use a word differently, the glossary can settle it.
The first draft matters most. It sets what gets reviewed, who's responsible and what gets bought, and a row missed there shows up months later as material sitting on a dock with no stamp behind it. If you want to start one now, the free Excel template has the same columns described here, with dropdowns and a filled in example.
Manufacturer data for the acoustical panels, logged under 09 51 00 with the page it came from.
Product data for the grid and hangers. It gets its own row so the reviewer can confirm each part.
A samples row flagged as an architect or owner selection, so the choice doesn't get lost in the list.
The required test report, with a status on it so somebody chases it before install.
It's the list on a project that tracks every required submittal, like product data, shop drawings, samples and test reports, along with who's responsible, the review status, due dates and notes. It takes requirements that are scattered all over the project manual and puts them in one place you can track.
A good row has the requirement, its section, the submittal type, who's responsible, the source page, the review status and a due date or a note. The source page is how a reviewer confirms the row belongs there.
Usually yes. Most people use both words for the same list, one row for every submittal the project manual calls for, and SubPro does too. SubPro also drafts a section register, which is a summary of which sections call for submittals and how many each one has.
Usually a project engineer, a submittal coordinator or whoever runs document control. SubPro drafts the first version from the project manual, so that person starts with real rows that show their pages.
How SubPro reads the spec book and drafts the log for you.
Keeping the log in software you can edit and export, with the pages cited.
How a team reviews a drafted log and keeps the pages behind it.
Book a fit call and send one project manual. You get back the drafted log, a register and a flagged rows report.