First: read the whole markup, then triage
Comments live in three places: the action stamp, cover-letter comments, and page-level markups — read all three before reacting, because a benign stamp can carry an expensive page note. Then sort every comment into three buckets: (1) accept and incorporate — most of them; (2) accept but it changes cost or time — price it and route a change request before buying; (3) disagree — the note conflicts with the spec, the drawings, or physics. Bucket 3 gets a professional response, not silent compliance and not silent omission.
The comment-response log
For any resubmittal with more than a couple of comments, lead the package with a response log: each reviewer comment quoted, numbered, and answered — 'Incorporated, see page 12,' or 'Not incorporated: specified 480V, see one-line E-601; request confirmation.' This does three things: it proves you addressed everything (the fastest path to approval on round two), it surfaces disagreements as questions instead of surprises, and it builds the record that protects you if a comment was wrong. Reviewers approve resubmittals with response logs measurably faster because they review the deltas, not the whole package again.
Pushing back without burning the relationship
Reviewers make mistakes — a comment citing a superseded addendum, a correction that contradicts another discipline's drawings. The move is always the same: respond with the document. 'Comment 4 requests 90°C conductor; spec section 26 05 19 ¶2.1.B specifies 75°C — please confirm which governs' wins where 'the reviewer is wrong' loses. Route genuine document conflicts as an RFI rather than resolving them silently inside a resubmittal, because a submittal is not the instrument that changes contract documents. And concede gracefully where the comment is right; credibility is the currency that gets your next borderline package approved.
Resubmit clean, resubmit fast
The resubmittal carries the same number with an incremented revision (R1, R2), the response log up front, and changes visibly identified — clouds or a change summary. Resubmit only what changed if the spec allows partial resubmittals; otherwise the full corrected package. And move: the calendar cost of a resubmittal is the review window all over again, so a package turned around in two days instead of two weeks buys real schedule. Submittal.App keeps every version, comment, and response on one record, and reassembling a corrected package from the indexed library takes minutes — which is the difference between resubmitting Friday and resubmitting month-end. Track your own resubmittal rate too: if a third of your packages bounce, the fix is in your preparation step, and it is cheaper to fix than to keep paying for in review cycles.