The contractor has revision C. Our register says B.
A site query comes in about a beam size. The contractor is working from revision C of a general arrangement drawing. Your register shows revision B as the latest issue. Someone digs through sent emails and finds that revision C did go out, attached to a reply to the architect, and never made it into the register or onto a transmittal.
In a small practice this happens because the register is an Excel workbook that one person maintains when they remember. In a larger one it happens because drawings are issued through a common data environment for some projects, by email for others, and by a shared link for the odd contractor who cannot get into the CDE. Every route needs the register updated by hand.
Where the register goes wrong
The register is treated as a record written after the fact, not as part of issuing. That single design choice is behind most of the drift.
- Revisions and suitability codes are typed in title blocks, file names and the register separately.
- Urgent issues go straight from an engineer's inbox, bypassing whoever keeps the register.
- Transmittals are made from a template and nobody checks them against the files attached.
- Superseded drawings stay in the same folder as current ones, so it is easy to attach the wrong one.
- Each project uses a slightly different register layout, so nothing can be checked across projects.
What a drifting register exposes you to
| Symptom | Consequence |
|---|---|
| Register behind the issue | No reliable record of what the contractor received and when |
| Wrong revision attached | Work proceeds on superseded information |
| Missing transmittals | Hard to answer a later question about what was issued |
| Inconsistent status codes | Drawings for comment treated as for construction |
Then there is the time. Rebuilding a register at project close, or when a dispute or query arrives, can take a technician days of searching old emails. And it is the kind of job nobody wants, so it gets done badly.
How we connect issuing to the register
- We agree one naming and revision convention with you, based on the one your team already uses or the ISO 19650 style if your clients require it.
- Drawings for issue are placed in an issue folder, or selected in your CDE, and an issue form asks only for recipients, purpose and status.
- The tool reads the file name and title block data, checks the revision is later than the last issued one, and stops if it is not.
- The register updates automatically with revision, status, date and recipients.
- A transmittal PDF is generated from the same data, so it cannot disagree with what was sent.
- The issue goes out by email or is logged against the CDE upload, depending on the project.
- Superseded files are moved to a superseded folder so they cannot be attached by mistake.
- A register report per project, or across all projects, is available at any time.
Where a project lives in a CDE such as Viewpoint for Projects, Aconex or Autodesk Construction Cloud, we read issue events from its API where it offers one, so the register still reflects issues made there.
After the change
An engineer issuing an urgent revision does it through the same short form, which takes less effort than writing the email by hand. The register is always current, so a site query about revisions is answered in seconds rather than by searching an inbox.
At project close there is nothing to rebuild. The register and transmittals already exist.
Signs your register needs this
- Someone updates the register from sent emails after the event.
- You have found a contractor on a revision your register does not show.
- Transmittals are typed separately from the drawings they list.
- Superseded and current drawings share a folder.
- Each project team keeps its register in its own format.