The Friday Afternoon Package You Sent Against Last Week's Model

The Package Was Fine. The Model It Was Built On Was Just Old.

Think about the last coordination package you sent out on a Friday. You probably felt okay about it. The clash notes were in, the trades had answered, the issue list looked tidy. So you hit send and went home.

Now think about when the model behind that package was actually exported. For a lot of firms, it happened on a Tuesday two weeks earlier, in a room with a coffee and a set of drawings that got revised six times since. Nobody lied to anyone. The package was honest. It was just old.

That is the quiet failure mode of the export-to-coordination workflow most firms run today. The model lives in one place and gets updated. The coordination notes live in another place and do not. Every revision that lands between the export and the handoff creates a gap. The gap is small at first. Then it is not.

An architect issues a revision set on Thursday. A door swings the other way, a corridor shifts a few inches, a mechanical room gets rearranged. Your field team has not started yet, so nobody flags it. Your coordinator is buried in two other packages and does not see it. Friday comes. Your package goes out with notes that match a drawing that no longer exists.

The trades build against it and you never find out why the ducts do not fit. The package looked complete. It was just built on a design that had already moved.

Why Two-Week-Old Exports Are Normal and Still Costly

Nobody sets out to send stale data. The workflow just makes it almost impossible to avoid. The export gets done when the coordinator has time. The notes get built from the export. The issue list gets refreshed from emails that arrive on their own schedule. Each of those steps is a snapshot, and snapshots age.

If your model and your issue list live in separate streams, you will always be reconciling them at the worst possible moment, which is the day you have to send.

This is where version control from the Revit model gets interesting. When every publish is a versioned snapshot, and the snapshot comes straight from the file the design team is editing, then the package is never more than one publish away from current. You are not chasing a spreadsheet. You are comparing against the model the architect just changed.

That sounds simple until you try it with the tools most firms have. Then you find out the hard way that a Revit file can contain the same room twice, that a family can be nested three levels deep, and that the door count in your schedule depends on which view you exported. The version problem is not arithmetic. It is geometry and metadata, and getting it right is the whole game.

Once the versions are live, the issues can be live too. Issues pin to the elements they concern and carry the sheet and revision that raised them. Change a wall and the issues on that wall are flagged. Add a fixture and it shows up in the comparison. The coordinator stops being the person who copies notes between files and starts being the person who reads a short change list and decides what needs a call.

What Live Looks Like on a Thursday Night

Here is the concrete version. It is Thursday at 6 PM. The architect drops a revised model into the shared folder. The design moved a chase wall six inches, added four doors on the second floor, and swapped a rooftop unit for a slightly larger one.

You publish from Revit, and the snapshot lands with its own files, author, and milestone. The comparison against the last revision lists exactly what changed, grouped by category: structural, MEP, envelope, interior. The chase wall is under envelope and interior. The rooftop unit is under MEP. Not Tuesday. Thursday, right after the revision lands. The coordinator opens it Friday morning and sees exactly what changed and who owns it.

Now the Friday decision is a real decision. You can hold the package and call the mechanical lead, or send it with a note that two issues moved, or decide the change is big enough to call a short meeting. All three of those are good outcomes. None of them happen if the package you sent was built against a design that got replaced two weeks ago.

The reason this works is that two revisions compare element by element. Every added, removed, or modified element is listed against its category, and every open issue pinned to one of those elements is flagged for its owner. BidLight does not run automated clash detection. It tracks what moved between revisions and the clashes and issues raised against them, so a human still looks, which is exactly where you want the line. And at 6am the owners get a digest of what they own, so the Thursday change is in front of them before the Friday handoff.

This is what a live record means in practice. It is not a black box that hands you a verdict. It is a record that hands you a running change list you can interrogate element by element, with the model as the source of truth for what moved and the issue log as the source of truth for who owns it.

The Win Is Not Speed. The Win Is Not Re-Doing the Reconciliation.

Speed gets all the attention. A comparison in about 15 minutes instead of a 90-minute meeting. That is real and it is nice. But the bigger win is that you stop re-doing the reconciliation every time the design moves, because the history is never a separate artifact to begin with.

Ask any coordinator what they hate about the job and it is rarely the clash itself. It is the re-checking. The second pass. The third pass. The version where somebody emails a new set and you have to figure out what actually changed versus what just renumbered. That is the grind that burns people out and makes good coordinators leave. Many lose about 11 hours a week to exactly this.

When the record rides on the model, the diff is the change. You do not have to hunt for it. A wall moved, the system knows a wall moved, and the issues on that wall come with it. Your job shifts from archaeology to judgment, which is the part you are actually paid for.

The pattern shows up in the cost of the job too. A clash that is caught in the model costs about $50. The same clash found in the field costs $5,000 to $50,000. Teams working from current information catch more of them in the first place, because the information is current.

There is a second win underneath that one. When reviews stop being a two-week event and start being a running record, early design reviews become something you can offer as a service. Clients pay for answers. If your firm can tell a client what a move touches in the meeting, on the spot, that is a service, not a favour.

And the record stays auditable, which matters downstream. Claims, change orders, closeout. All of it gets easier when there is one live record of the project inside Revit and Navisworks, and every issue closed with proof.

What Packages You Defend Look Like

You know the meeting. A client or a GC pushes back on a handoff and asks you to explain it. If your answer is a spreadsheet somebody built two weeks ago, you are defending a guess. If your answer is the model, with the revision and the issue history attached, you are defending a record.

That distinction is the whole pitch. You hold the line with records you can defend. Not because you argue better, but because the record traces back to something the other side can see. A wall in the model. A revision in the history. A fix with a commit behind it.

The same live record answers questions you would otherwise answer from memory. How did you get that door count. Why did that duct move. Which revision set was the package built against. If the answer is already sitting in the model and the issue log, you stop guessing and start pointing.

This is also where closing rules become less abstract. An issue closes only with a screenshot, a tagged user, and the model commit that fixed it. That is a system that insists on proof and routes the open items to a person, which is the only kind of record anybody should sign.

Plans run from Basics at $260 per licence per year to Max at $590, with custom Enterprise terms when a firm needs more. Every plan includes unlimited projects. Beyond the software, the team does done-for-you BIM work: execution plans, 4D sequencing, fabrication detailing and spooling. So if you would rather someone else set the workflow up the first time, that is an option.

The point is not that the software is clever. The point is that the Friday package you send is built from a model that is current, and you can stand behind every line of it when somebody asks.

What to Change Before Next Friday

You probably cannot rebuild your coordination workflow in a week. You can change one thing. Stop letting the export be a separate step that happens once. Whatever tool you run, find a way to keep the record tied to the model so it updates when the model updates.

Then start asking a simple question before every package goes out. What revision is this built against, and is it the current one. If the answer is anything other than yes, you have a gap, and the gap has a cost attached. Usually one you do not want to defend.

The firms that win on this do not win because they are faster typists. They win because the record is never more than one publish behind the design. When the architect moves the wall on Thursday, the issues move with it. Friday is boring. Boring is the goal.

Start with one project. Watch how many times the design changes between your first export and your handoff. That number is the amount of rework you have been doing for free. For most firms it is larger than they expect.

BidLight exists to make Friday boring. One live record of the project inside Revit and Navisworks. Every export versioned and every change diffed. A 6am digest so nobody is surprised. That is the whole idea, and it is the one thing worth remembering.