PDF is Not Dead with Shanoc Halliday

Most firms deploying digital tools spend all their energy on the software and almost none on the process around it. The result is predictable: a few teams using the tool brilliantly, everyone else doing the minimum to get by.

Shanoc Halliday, Senior Enterprise Customer Success Manager at Bluebeam, sees this pattern across global engineering and construction enterprises every day. His role is not to teach people which buttons to press. It is to understand what a business is actually trying to achieve, and build a plan that connects the software to those outcomes. The conversation that follows is one of the clearest accounts I have heard of why digital adoption really fails, and what actually fixes it.

The Pockets of Excellence Problem

Almost every organisation has a team that is using their tools really well. Structured markups, custom tool sets, data extracted and put to work downstream. The problem is that it stays there.

It does not spread because no one gave it a mandate to spread. There is no standard, no deployment, no expectation. The rest of the business keeps doing whatever feels natural, which usually means the bare minimum.

This is not negligence. It is what happens when software is treated as simple enough not to need a process. Bluebeam, in particular, suffers from this. It is easy to use, which leads organisations to assume it does not need the same investment in setup and standardisation that a BIM tool would.

That assumption is expensive.

The Real Starting Point Is Not the Software

Before any conversation about features or workflows, the most valuable work is a discovery conversation at every level of the business.

What is the executive trying to achieve over the next twelve months? What is the project manager's daily friction? What does the person doing the markup actually need to get home on time? These are different questions with different answers, and the disconnect between levels is usually where adoption breaks down.

What tends to work is building a customer success plan from those answers, then prioritising ruthlessly. Not every problem at once. One workflow, done consistently, across the whole organisation, before adding anything on top.

The companies that close the gap between their best teams and their average teams treat their software setup the way they treat a CAD standard: documented, deployed, and expected of everyone.

Consistency Over Perfection

Here is something that sounds obvious but rarely gets applied: it does not matter which standard you choose, as long as everyone uses the same one.

During a cross-office debate about how to represent a structural element in drawings, the argument that ended it was simple. Pick one approach. Any approach. Then stick to it. A standard you disagree with can be refined over time. Chaos cannot.

The same principle applies directly to tool sets in Bluebeam. Build them, deploy them, and let them evolve. When someone creates a new connection detail or a better markup symbol, share it. Standards should be living documents that get better because people are actually using them, not locked files that gather dust on a shared drive.

The organisations that improve fastest are the ones where the standard is a starting point, not a constraint.

Bluebeam Is Not a Construction Phase Tool

There is a persistent misconception that Bluebeam belongs at the end of a project: RFIs, as-builts, close-out. That is where many firms start using it, and where most stop.

The better-performing clients have moved it upstream. Engineers are now using it at tender stage for constructability markups, capturing intent quickly in a format that goes directly to modelling staff if the project is won. Through design development and QA, it becomes the checking layer. At handover, it has been used to verify as-built packages and link to payment approvals on major infrastructure projects.

The firms doing this well have recognised something important: the PDF is not just an output. It is a data container that carries information forward through a project. The question is whether that information is structured and usable, or just a flat image of something someone once drew.

Clean Data Today Is AI Infrastructure Tomorrow

Every AI conversation eventually lands in the same place. What you get out depends entirely on what you put in.

Bluebeam has recently released Max, integrating AI through MCP with Claude, and has acquired Firmus, a tool focused on drawing review and compliance checking. The direction is clear: AI will be able to interrogate drawings, cross-reference specifications and standards, and flag inconsistencies before construction begins. It will reduce risk on projects where things being built wrong is still a costly and common problem.

But that future is only available to firms whose markup data is structured and consistent today. Teams running ad-hoc, unstandardised workflows will struggle to extract value from AI tools that depend on clean inputs.

The firms best positioned for what is coming are not necessarily the most advanced right now. They are the ones building good foundations today.

Key Takeaways

• Pockets of excellence are not a strategy. Consistency across the organisation requires a standard, a deployment, and an expectation that everyone follows it.
• Treat Bluebeam like a CAD tool: build libraries, profiles, and tool sets rather than letting each user configure their own setup from scratch.
• Introduce Bluebeam at tender and concept design stage, not just in construction. The markup created early can carry forward directly to the modelling team.
• Your Customer Success Manager is a strategic resource, not a support contact. Bring them into your business challenges and ask for a structured plan.
• Audit how structured your current PDF markup data is. If AI cannot read it cleanly, it will have limited value in the tools arriving in the next two to three years.
• Standardisation matters more than which standard you choose. A consistent process you can improve is worth more than a perfect process nobody follows.