The columns that earn their keep
A working log needs, per line item:
- Submittal number (spec-section convention: 23 34 00-001) and current revision
- Spec section and description
- Type: product data, shop drawings, samples, calcs, closeout
- Responsible subcontractor / supplier
- Required-by date, driven backward from lead time and the construction schedule
- Date received from sub, date sent to A/E, date returned — for every revision
- Action received (Approved, Approved as Noted, R&R, Rejected)
- Ball-in-court: who holds it right now
- Notes: deviations, partial releases, AHJ legs
Build it from the specs on day one
The log's value depends on being exhaustive before the first package arrives. Walk every spec section's Part 1 submittal article and create a line for each required item — including the easy-to-forget informational ones: test reports, warranties, certifications, closeout documents. On a mid-size commercial job this is several hundred lines across dozens of sections, and it is tedious, which is why it gets skipped, which is why closeout takes three months. A register built from the specs also becomes your completeness defense: when the architect asks where the mock-up submittal is, the log shows it was never in the spec — or shows you owe it.
The dates that actually manage the job
Logs fail when they only record history. The management power is in the forward dates: for each line, the date material must be on site, minus lead time, minus review cycles (plan two for complex scopes), minus preparation time — giving the date the sub must submit. Sort the register by that date and you have the project's real priority list, which almost never matches the order subs naturally submit in. Review the aging report weekly: everything in the A/E's court past the contractual window gets a dated follow-up; everything in a sub's court past its need date gets a phone call.
Keeping it honest through the project
A log is only as good as its worst week. The failure pattern is universal: the register is immaculate through month two, then a schedule crisis eats the updates, and by month four the log says 'submitted' on items that came back rejected weeks ago. Whatever tool you use, the fix is making updates a side effect of the work rather than a separate task — log the return the moment the stamped package arrives, in the same sitting, before it gets filed. A log that is 95% current is a management tool; a log that is 70% current is a liability, because people make procurement decisions from it.
A log that maintains itself
In Submittal.App the register is generated from your project's spec sections and updated by the workflow itself — dates stamp automatically when packages are sent, opened, and returned; revisions increment; ball-in-court is always current. The spreadsheet that consumed a project engineer's Friday afternoons becomes a report you read instead of a document you maintain.