Inside the signage approval process: how software cuts sign-off from months to days

The signage approval process is how every sign in a building gets from a drawing to a decision: each panel's wording, languages, size, material, fixing and position is drafted, reviewed by the people who have to live with it, changed, and formally signed off before anything is cut. On a mid-sized building that comes to several hundred separate decisions, almost none of them individually hard. What makes signage feel slow is the machinery used to collect the decisions. Moving that machinery out of PDFs and email and into our own software cut our sign-off times from months to days.

The industry-standard method makes that expensive. A re-signing programme runs on one PDF of every sign type issued to the client, comments returned by email, a revised PDF issued, comments returned again. Three stakeholders send mark-ups in three formats on three different days: estates, the design team, and a head of department who was copied in late. One set is written against a version that has already been superseded. A meeting room gets renamed twice. The panel that reaches the factory carries the first name. It is made, delivered, installed, and then made again.

Nothing in that story is a design failure. It's a coordination failure with four reliable causes, and none of them are solved by working harder on the drawings. A slow signage package almost always gets blamed on the factory when it belongs to a Wednesday afternoon in an estates office.

• Everything is bundled. A PDF is a single unit of approval, so four hundred signs wait on the last unresolved comment about one door. The slowest decision in the building sets the pace for all of it.
• The reviewer cannot see the sign. A schedule row reading “Type C · 400 × 150 · Seomra Cruinnithe / Meeting Room” is not something a head of department can picture, so they approve it, then object when the real thing appears on the wall.
• Comments detach from the things they describe. Mark-ups arrive as annotated PDFs, emails, a phone call and a photograph of a printout, and somebody has to transcribe all of it back onto a schedule without losing one.
• Nobody is certain which version is live. Every re-issue makes another copy, and the copies travel further than the corrections do.

Once you see the problem that way, the fix stops being about faster reviewers and starts being about a smaller unit of approval. A building isn't one decision but several hundred, most of them independent of each other and held by different people who care about different things: estates about the numbering, the design team about the finish, a department head about the four words on their own door. Bundling them into one document forces a serial process onto a set of problems that is naturally parallel. A single directory panel makes the arithmetic plain. The one we delivered for Trinity Business School carries forty-odd destinations across seven levels, in two languages, each with a room number that has to agree with the door it sends you to.

Approve a building one sign at a time, not one PDF at a time.

So we built our own platform, and every project we deliver now runs through it. We don't sell it. It's how we work, and it does five things a document cannot.

• Live sign previews. Every item in the destination schedule renders as the actual sign: real typeface, real proportions, real bilingual line breaks, braille and tactile text where they belong, the pictogram at the size it will be made. Approvers see the sign.
• Approval per sign, not per drawing. Each item carries its own state: drafted, issued, commented, approved. When 380 of 400 signs are approved, 380 signs go into production and the argument continues over twenty.
• Comments that live on the item. A remark about the wording of Level 2's lift lobby is attached to Level 2's lift lobby, visible to everyone, and closed when it's answered. Nothing gets retyped out of an email thread.
• Versioned changes. Amend a name and the item gets a new version; the previous one is kept, with who changed it and when. The artwork the factory receives is generated from the approved version, so the sign that is made and the sign that was approved are the same object.
• Stakeholders without software. Reviewers get a link, a view of their own signs, and two buttons. Nobody installs anything, and nobody is excluded because they do not have the drawing package.

The comparison is our own: elapsed time from first issue to full sign-off, on comparable projects before and after we moved off documents. Worth being precise about where it comes from, because none of it is clever.

• Review runs in parallel. Six stakeholders look at their own signs at the same time instead of queueing behind one marked-up file.
• Production starts on the approved majority. The signs nobody disputes are in the factory while the four contested ones are still being discussed, which on its own recovers a fortnight on most jobs.
• Wording changes stop being drawing work. A preview is generated from the schedule, so amending a name is a data edit and a re-render, not an afternoon in artwork and a re-issue.
• Chasing is automatic and impersonal. The system knows who has eleven signs outstanding; nobody has to compose the email that says so.
• There is one version, and everybody is standing in it. The single largest saving is the rework that never happens.

What it doesn't do is compress the part of the programme that belongs to the client. If a hospital hasn't decided what to call a department, no software will approve the door sign. Where nobody on the client side has the authority to close an item, the platform does one thing: it makes the delay visible, and attributable, a great deal earlier than a PDF would.

Speed is the visible benefit. The one that lasts is that an approval history doubles as evidence. Signage carries statutory duties, and at handover somebody has to be able to say who approved which wording, against which standard, on what date. Technical Guidance Document M asks for signage that is clear and concise, discourages text set entirely in capitals, and looks for tactile and braille information at key locations; BS 8300 carries the practice behind it, including the 30 or more points of light reflectance value that should separate a sign face from its background. Escape-route and fire-equipment signage belongs to the fire strategy under TGD B, with symbols to I.S. EN ISO 7010. And where the client is a public body in Ireland, the signage regulations made under the Official Languages Act require the Irish text to appear first and to be no less prominent, and no smaller, than the English, which is a layout constraint before it is a translation task.

Because those rules are applied to the item itself, the record assembles itself: the approved version of every sign, the person who approved it, the date, and the compliance attributes it was made to. Everything we supply is made to Part M and BS 8300 by default, and we certify on completion, and the certificate is only as good as the paper trail behind it. Ours is a database. That matters most two years later, when a department moves and somebody has to find out what the sign used to say.

Two things, mainly. The first is naming. If the appointment letter, the room-booking system, the website and the door disagree about what a place is called, a faster approval process just ratifies the disagreement at speed. Which is why the room naming work has to be finished before the sign schedule is issued, not during it. The second is authority. An approval platform needs somebody empowered to approve; where a client has never decided who that is, the tool will show you a wall of amber items and a clear, unarguable account of why the programme is slipping. Useful information, but not a decision.

Used properly, the effect is less dramatic than it sounds. Nobody in a project meeting ever says the signage approval process is going well; they just stop talking about it, and manufacture starts earlier than anyone expected. If you're specifying a signage package and want to see how we run approvals, or you're three weeks into a PDF that is already on revision four, talk to us and we'll show you the working version.