You send the same scan-to-BIM scope to three firms. The quotes come back at wildly different numbers. One is a third of another.
The usual conclusion is that somebody is overpriced. The usual reality is that the three firms read your scope differently and quoted three different jobs — and you have no way to tell which one, because the scope didn't say enough to constrain the answer.
That's not a vendor problem. It's a specification problem, and it's fixable in about half a page.
“Scan the plant and give us a Revit model” contains at least eight unstated decisions. Every bidder has to guess at all of them, and every bidder guesses in the direction of the job they're set up to do.
The low bidder usually isn't cutting corners on purpose. They read “give us a model” and priced a reasonable model. The high bidder read the same words and priced fabrication-grade capture with tight control across the whole facility. Both are quoting in good faith. Neither is quoting your project, because your project was never described.
The fix isn't a longer RFP. Long RFPs full of boilerplate make this worse, because the specific items get buried. The fix is being precise about eight things and deliberately silent about the rest.
The most valuable sentence in the whole document, and the one most often missing. Not “as-built model” — “model will be used for clash detection against a new air handler and for fabrication of four piping tie-ins.”
That one sentence lets a competent vendor derive most of the other requirements, and it lets you tell immediately whether a bidder understood the job. If the proposal doesn't reflect your stated use, they didn't read it.
Use a real framework rather than an adjective. The USIBD Level of Accuracy specification gives you defined tolerance tiers, and it is designed to be applied per element rather than per project. So name the tight elements separately: “LOA20 for general facility and clash detection; LOA40 at the four tie-in interfaces identified on the attached markup.”
Also state whether the requirement applies to the captured data, the delivered model, or both. If your deliverable is a model, it needs to apply to the model.
LOD and accuracy are different dials. LOD describes what's in the model; accuracy describes how close it is to reality. Specify LOD by system, because you almost never want the same detail everywhere: piping above a certain diameter at one level, structural steel at another, architectural shell at a third, and a stated cutoff below which things aren't modeled at all.
That cutoff is a significant cost lever. “All piping” and “all piping 2 inches and larger” are very different jobs.
Attach a marked-up plan. Say where the scan starts and stops, floor to floor and wall to wall. Then say by system what's in and what's out: process piping in, electrical conduit out, insulation modeled to outside face, and so on.
Ambiguity here is a reliable source of change orders on scan-to-BIM work, and it's completely avoidable with a markup and a list.
Name them. Revit version, whether you want the registered point cloud and in what format, whether you need 2D drawings extracted, whether you need a federated coordination model or discrete discipline models. Say what coordinate system and datum the deliverable lands in, and who establishes control.
Version mismatches are a small problem that becomes a real one at the worst time — when the model shows up and won't open in your environment.
This is where bids diverge most and where scopes are most optimistic. Say what's true:
A bidder who is told “operating plant, two 6-hour night windows, escort required, elevated work in the boiler house” prices something real. A bidder told “industrial facility” prices a warehouse and then submits a change order. Understating access conditions never saves money; it defers the cost to the point where you have the least leverage.
Mobilization window, and delivery deadline, and what the deadline is tied to. “Model needed by October 15 because fabrication release is October 20” is far more useful than a bare date. It tells the vendor which parts of the deliverable are on the critical path and lets them propose a phased handover — tie-in areas first, general model after — which is often the difference between a schedule that works and one that doesn't.
Two clauses that almost nobody includes and everybody needs.
Verification: ask what control and verification approach they'll use and what documentation comes with the deliverable. A stated tolerance with nothing behind it is a marketing number.
Reality divergence: on any brownfield project, the field will disagree with the drawings you handed over. That isn't an exception, it's the normal case. Say up front how it gets handled: who gets notified, how it's documented, and whose call it is to resolve. Without that clause, discovering that the drawings were wrong turns into a commercial dispute instead of a two-hour conversation.
Being specific about the eight items above earns you the right to be quiet about everything else. Deliberately don't specify:
Scanner make and model. Specify the outcome — tolerance, coverage, deliverable — and let the vendor choose the instrument. Naming hardware either eliminates good bidders for no reason or, worse, gets you a job done with the wrong tool because the RFP demanded it. The one exception is a genuine site constraint: if a device can't come into an area for safety or clearance reasons, say that as a constraint, not as a hardware spec.
Number of scan positions or setups. That's a means, not an end, and it's the vendor's problem to solve. Specifying it caps quality and invites gaming.
Method. Terrestrial, mobile, SLAM, or a mix — the right answer depends on geometry, accuracy, and access, and a good vendor will propose a mix and explain the trade-offs. Asking for a method rationale in the proposal is smart. Dictating the method is not.
Their internal QA process. Ask what verification documentation you'll receive. Don't try to write their procedure.
The pattern: specify outcomes and constraints, not techniques. Techniques are what you're buying expertise in.
Everything above fits on one page:
Eight headings. Once they're filled in, three bids become genuinely comparable — and any bid that ignores them tells you something useful about the bidder.
A well-specified scope gets you comparable numbers, which is worth the effort on its own. But the bigger return comes later.
Expensive surprises on a scan-to-BIM project tend to trace back to a scope question that never got asked: the model wasn't accurate enough for the fabrication somebody planned, or it didn't cover the area somebody needed, or it didn't open in the software somebody had. Those are all resolvable in half a page, before anyone mobilizes. After mobilization they're resolvable too — just at a very different price.
Write the eight items. It's about the cheapest risk reduction available on the whole project.
Want a second set of eyes on your scope before it goes out? Send it over — we'd rather help you specify it correctly than win a job that was scoped wrong. Get in touch →
Related reading: Pre-turnaround laser scanning checklist · Everything you need to know about BIM coordination
Sources: USIBD Level of Accuracy Specification, current release Version 3.1; BIMForum Level of Development Specification.
Each project represents our commitment to accuracy and technical excellence
Talk with our team about your facility, scope, and objectives to determine the right capture, modeling, and analysis approach.
