Friday afternoon, twenty drawings to issue
The technical design package is ready to go to the contractor and the structural engineer. The architectural technician exports twenty PDFs from Revit or ArchiCAD, checks the title blocks, and opens the issue sheet spreadsheet. They type in the drawing numbers, titles, revisions, the date, the recipients and the purpose of issue: for construction, for information, for comment. They attach the PDFs to an email, or upload them to a file share, and send.
Two weeks later the contractor builds from a revision B that had been superseded. The issue sheet says revision C was sent, but only to the engineer. Somebody forgot to tick the contractor column.
Why the register and reality drift
The drawing's number, title and revision are in the title block, set in the design software. The issue itself happens in email or on a shared platform. The register is a spreadsheet updated by hand in between. Every transfer is a chance for a typo, a missed recipient or a forgotten issue. Common data environments solve much of this on larger projects, but many practices do smaller work where setting one up feels heavy, and still issue by email.
- Drawing details are retyped from title blocks into a spreadsheet.
- Recipients are ticked by hand for each issue.
- Some issues happen by email and never reach the register.
- Nobody can say quickly which revision each party holds.
- Purpose of issue is not always recorded.
What register errors cost
Work built from a superseded drawing leads to rework on site, disputes about who pays, and the uncomfortable question of what the register shows. Even without errors, technicians spend time on admin at the end of a package, when deadlines are tightest. And when a contractor asks 'what is the latest on the kitchen elevation?', someone has to go and look.
An issue step that reads the drawings
- The technician drops the PDFs to be issued into an issue folder or web page.
- Drawing number, title, revision, scale and status are read from each title block, and checked against the project's drawing list and naming convention. Anything that does not match is flagged.
- The technician selects the recipients from the project's distribution list and the purpose of issue for each.
- The drawings are sent by email with a transmittal, or uploaded to the shared platform, from the same step, so the issue and the record cannot diverge.
- The issue sheet is produced in your format and filed, and the register updates automatically.
- The register shows, for every drawing, the latest revision and which revision each recipient last received.
- Where a recipient holds a superseded revision of a drawing issued for construction, it is highlighted.
Where the project already uses a common data environment, we work with it rather than beside it, reading its records for the register.
The register view
| Drawing | Latest revision | Contractor holds | Engineer holds |
|---|---|---|---|
| Ground floor plan | C | C | C |
| Kitchen elevation | C | B | C |
| Roof plan | B | B | B |
In this illustration, the kitchen elevation would be flagged: the contractor has not received the latest revision.
Issuing without the spreadsheet
Technicians issue drawings in one step and the paperwork takes care of itself. Anyone in the practice can see who has what, instantly. And if there is ever a question about which drawing a contractor worked from, the register and the email trail agree, because they come from the same action.
Is this your issue process?
- Issue sheets are typed into Excel.
- Drawings are sometimes emailed without the register being updated.
- Someone has built from a superseded revision.
- You cannot quickly say which revision each consultant holds.