Kord logoKord

Blog

Forty-seven comments and one Excel file

A customer review comes back as dozens of comments spread across marked-up PDFs and a spreadsheet log. Checking a comment off in the log while the file never gets the fix is easy, and so is missing a markup entirely. The hard part isn't fixing forty-seven comments. It's proving every fix made it into the revision you shipped.

Kord vs Bluebeam

Transmittal 2 comes back with forty-seven comments. Twelve on the P&IDs, most of them on the narrative spec, three that just say 'see previous submittal' with no page number. The PM assigns disciplines and sets a return date. Mechanical clears their sheet in a week. Document control opens the comment log in Excel, because the comment log is always Excel.

Three weeks later you resubmit. The log shows all forty-seven closed. The customer opens Transmittal 3 and finds comment 31 still open: it got checked off in the spreadsheet, but the fix never made it into the datasheet that shipped. Comment 19 never got answered at all, because the markup was sitting on a PDF nobody reopened.

Comment rounds fail quietly

It isn't laziness. The comment and the file live in two different places. You close the comment in the Excel log; the fix never gets made in the source file, or it gets made and never re-exported. The log says closed and the released file still has the original wording. One open item is enough to hold up commercial acceptance, and you find out on Transmittal 4.

  • The comment log is in one spreadsheet, the markups are in Bluebeam, and the real status is in email.
  • Nothing ties a comment to the file revision that fixed it, the person who checked it, and the export that actually went out.
  • 'Closed' means three different things: fixed, won't-fix, or fixed in the native file and never re-exported.
  • A markup on a PDF nobody reopened never gets a reply, and nobody notices until the customer does.
Forty-seven comments is a week of work. Losing track of which ones actually made it into the files is how that week becomes three.

What closing a round actually takes

Before you call a round done, someone has to be able to answer, per comment: which file revision fixed it, who verified, and what else changed in that same export batch. With folders and email that's a tedious afternoon. With a review session where every response links to a versioned file and the release won't close over open items, it's just how the tool works.

How Kord closes the round

  • Every comment is pinned to the thing it's about (the line, the cell, the region on the P&ID or datasheet) so a markup can't sit on a PDF nobody reopens. Comment 19 lives on the drawing, not in a separate Bluebeam file.
  • Each comment links to the file version that resolves it, so 'closed' means the fix is in a released revision, not a checked box in a row the source file never heard about.
  • The review session is the log: comment ID, source file, location, owner, status, resolving revision, in one place instead of split across a spreadsheet, Bluebeam, and a mail thread.
  • Checklist templates can require a second reviewer on the critical specs, so no discipline quietly closes its own items.
  • The release won't complete with open comments, and it exports a manifest of the approved versions, so the resolved set ships with the transmittal instead of trailing it by three days.

Iterative submittals are just how EPC and modular equipment work gets done. The tooling should move at that rhythm (grouped reviews, a visual diff on resubmit, a trail from the moment a comment opens to the moment it's released) instead of pushing every round through a fresh Bluebeam session and another hunt through SharePoint. That's the gap between a markup tool and document-set review. It's the difference between Transmittal 3 closing the job and Transmittal 5 finally doing it.

Let's get started

Book a demoor