One clash found in the field can cost $5,000 to $50,000. BidLight pins each issue to the geometry, tracks it across model commits, and will not close it without proof.

Every Unresolved Clash Is a Bet Against Your Own Margin

The $50,000 You Already Agreed to Pay

You are one unverified clash away from a $50,000 field repair. That is not a scare number. That is a duct main that lands in a steel beam on level three, found by the foreman at 7:20 in the morning with a crew standing around and a crane on hourly. The fix is not the duct. The fix is the sequence. You cut the beam, you re-engineer the penetration, you wait on a signed detail, and you eat days of idle labour plus the GC's schedule claim. Nobody planned for that. Nobody could, because nobody saw it.

So think about what a clash actually is. It is a decision you have not made yet. Two disciplines ran their own logic, both are internally correct, and the intersection is a question. Every question in a model is a cost with a date attached. Answer it in the model and it costs about $50. Answer it in the field and it costs $5,000 to $50,000 out of your own pocket, because the contract says coordination was your job and the schedule does not care whose fault it was.

Isometric model view of a white duct crossing through a blue steel beam, with the overlap flagged by an orange question-mark pin and a card showing a cost and a

Here is the trap. Most firms track clashes in a report that lives outside the model. Someone exports a Navisworks clash list to a spreadsheet, assigns names, holds a meeting, and the spreadsheet goes stale the moment the architect moves a wall. That spreadsheet is a photograph of a problem, not the problem itself. The real problem is still sitting in the geometry, waiting.

BidLight takes a different stance. Every issue gets pinned to the geometry it belongs to, so it travels with the element when the model changes. If the duct moves, the issue is still on the duct. If the beam gets resized, the comparison shows it against the issue. Nothing gets resolved by accident because the report was out of date.

That single habit is the difference between a coordination process and a rumour. You do not judge a problem by one snapshot. You watch it across revisions and weeks, and you track how it moves. Clashes deserve the identical treatment. One snapshot tells you nothing about whether the problem is getting better or worse.

A Clash Is a Cost Event, Not a Drawing Note

Once you start treating clashes as cost events, the whole coordination meeting changes. You stop asking whether a clash is open or closed and start asking what it will cost if it ships. A sprinkler line through a cable tray is a quick conversation in the model and a shutdown of the ceiling grid in construction. A column through a corridor is a design discussion today and a sawcut tomorrow. The same clash has two very different costs depending on when you catch it.

Isometric model view of a sprinkler pipe cutting through a cable tray with a red clash marker, beside a cost card showing $18,400 and a rising bar chart.

That is why timing matters more than most people admit. The moment your versions ride on the model, every model change is also visible as a change, and every visible change is a chance to catch the knock-on effect. When a clash drives a reroute, the pipe gets longer, the hangers multiply, other trades' space shrinks, and the people affected should hear about it that day. If your clash list lives in a spreadsheet you made last Tuesday, nobody hears anything, and you find out at the end.

Compare the two paths. The traditional path is: model gets issued, someone checks it by hand or from a PDF, someone types the findings into a log, someone emails the trade, and by the time the answer comes back the model has already moved. The BIM path is supposed to fix that, but only if the record actually rides on the model. A model that feeds a static report is just a prettier version of the same problem.

BidLight keeps the exports, the comparison, and the issues in the same live record. Every publish is a versioned snapshot with its own files, author, and milestone. Any two revisions compare element by element, by category: structural, MEP, envelope, interior. That is why a finding you raise in a meeting still holds when you check it a week later.

So when a clash forces a reroute, you are not re-doing a report. You are watching the change appear in the comparison. The reroute costs what it costs, and you can see it before anyone commits to it in the field. That is the whole point. A clash you caught in the model is an item you can close. A clash you caught in the field is a repair order you get to argue about.

Side-by-side model views of a duct run, one clashing with a column and one rerouted over it with the change in orange, above a card showing the reroute's cost.

Track the Issue Across Commits, Not Just Its State

There is a real mental model here. A single pull never tells you what is going on. You set a baseline, you watch the trend, and you flag anomalies when something moves. You are looking for change, not for a snapshot. That is exactly how an issue list should behave.

A good coordination review does not read one issue and declare the project healthy. It reads the whole set, groups it by category and owner, and surfaces what changed this week versus last. Change is the signal. You only care about the item that moved, not the item that sat flat. Apply that to a model and the signal is the same: which issues appeared since the last revision, which ones moved discipline, which ones quietly resolved themselves because the design changed under them.

BidLight tracks every issue across revisions, which means you can see the trend, not just the state. An issue that has been open for six weeks and migrated from a ceiling void into a corridor is telling you something. It is telling you the design is drifting and the cost of the fix is drifting with it. An issue that appeared yesterday and resolved today is noise. You want to spend your coordination meeting on the first one.

Two section views of the same clash, a duct-and-pipe conflict in a ceiling void in week 1 and a marker in a corridor in week 6, linked by a dotted trail above a

This is where most firms lose control. They run a clash report, they clear 400 items, they feel good, and then the next model issue brings 350 of them back because the filtering was cosmetic. Nothing was pinned. Nothing was tracked. The numbers reset and the trend is invisible, so the same fight happens next week with the same people in the same room.

Running a clash test on a Revit model does not fix that on its own. Finding conflicts is the easy part. Anyone can run a test and hand you ten thousand rows. The hard part is keeping each row anchored to the geometry, tracking it revision to revision, and refusing to mark it closed until the model agrees. That refusal is the service. It is also what protects the $50,000 you would otherwise spend on a repair you never saw coming.

A clash that sits for 47 days can burn $28,000 in idle field labour. And an unresolved one behind a crew can cost $15K to $50K a week. Seen from that angle, the open issue list is not paperwork. It is a list of bets against your own margin, each with a date on it.

One Live Record and a Stubborn Closing Rule

BidLight keeps one live record of the project inside Revit and Navisworks. That sentence is the whole architecture. There is no export step that goes stale, no spreadsheet that forks from the model, no separate truth that someone has to reconcile by hand. Publish your model and you get a versioned snapshot in minutes. Change the design, publish again, and the comparison shows what moved, because the issues are riding on the same model the changes are.

Isometric illustration of a building model panel and a clash-detection view panel both wired into one central stacked data record, with orange clash markers on

That is what lets you answer a design question while the conversation is still open. A client asks what a layout change touches. In the old workflow you go away, dig, and come back in two days with an answer nobody trusts. In this workflow you answer in about 15 minutes instead of a 90-minute meeting, with the elements and owners named. You are not selling software output. You are showing the consequences of a decision while the decision is still open.

The closing rule is simple and it is deliberately stubborn. An issue stays open until it proves itself against the model. Not until someone says it is handled. Not until a sub confirms in an email. Closing takes a screenshot, a tagged user, and the model commit that fixed it. If the duct still hits the beam, the issue is open, and it will show up in the next comparison whether or not anyone remembered to mention it. The median issue closes in about 7 days.

The 6am digest keeps that honest without chasing. Every owner gets the issues they own at the start of the day, and the project view shows who is behind while there is still schedule to move work. You stop walking into the GC meeting three weeks after a slip started.

Plans run from Basics at $260 per licence per year to Max at $590, with custom Enterprise terms, and every plan includes unlimited projects. BidLight does done-for-you BIM work as well: execution plans, 4D sequencing, and fabrication detailing and spooling. So you can carry the record yourself or hand the coordination load to a team that already lives inside the model.

Three ascending pricing cards at $260, $590 and custom Enterprise, each holding project folders, above a 3D building model with a highlighted duct clash, a 4D s

The pitch is plain. Stop chasing scattered updates. Catch the clash in the model for about $50 instead of finding it in the field for $5,000 to $50,000. Close issues with proof so they do not come back on site. Watch a clash that used to be a $50,000 field repair become a two-minute item in design. One live record of the project inside Revit, with every export versioned and every issue pinned to the geometry. If you remember one thing, remember that.

Related Lessons

Support

Responses