The hardest walk to run is not the one with the difficult condition. It is the one with four people on it.
Owner in one window, architect in another, sub's foreman standing next to you on the deck, owner's rep dialing in late from a car. Everyone has a different question. Everyone assumes their question is the reason for the call. Twenty minutes in you have covered one wall and somebody has said "sorry, can you go back." That is a multi party site walkthrough going badly, and it is the default outcome when nobody is chairing it.
It is worth running anyway, because the alternative is three sequential walks and a game of telephone between them. But it needs a chair, and the chair is you.
Why a multi party site walkthrough beats three calls
The value is not efficiency, though the efficiency is real. The value is that everyone hears the same answer at the same time.
Run the architect's walk on Tuesday and the sub's walk on Thursday and you have created a two-day window where the sub is working from a version of the answer that the architect did not give. That is where the expensive rework comes from. Not from disagreement, from sequencing.
Put both of them on the same feed and the disagreement surfaces immediately, in front of the person paying, which is the only place it can actually be settled. A multi party site walkthrough turns a two-week email chain into an eight-minute exchange with a decision at the end.
It also protects you. When the owner hears the architect say "yes, that is acceptable" on a recording, you are not relaying it. You do not have to be believed, because nobody is depending on your account of what someone else said.
Set the frame before anyone joins
Three things go out with the invite, and they are not optional.
What this walk covers, in one line. "Level 2 mechanical rough-in and the two open ceiling height conditions." If the scope is not stated, everyone assumes their item is on the list.
Who is on it and why. Naming the participants in advance stops the "wait, who else is on this" that eats the first three minutes and makes people cagey.
What decisions you need out of it. Two, maybe three, listed explicitly. A walk with no decision request is a tour, and tours drift.
Then the practical part: everyone needs to be able to join without a fight. The architect is on a firm laptop with locked-down software. The owner is on a phone. The sub's foreman is on a truck's data plan. If joining requires an install or an account, one of those three fails, and it will be the one whose answer you needed. Sending a link that opens in a browser is the whole reason a multi party site walkthrough is schedulable at all. The viewer flow is worth checking against your own architect's IT before the first one.
Run it like a chair, not a guide
The camera is the floor. Whatever is in frame is what gets discussed. That is your only real lever, so use it deliberately.
State the agenda in the first thirty seconds and say how long each part gets. People behave differently when they know a clock exists.
Take questions by name. "Architect, anything on this before I move?" Then move. An open floor on a four-party call means the loudest participant sets the agenda, and the loudest participant is usually the one with the smallest stake.
Say the location out loud constantly. Level, column line, orientation, room number. Four people are looking at the same feed with four different mental models of the building. The narration is what keeps them synchronized.
Repeat back every decision before you leave the spot. "So: ceiling comes down to nine-six in 214, architect confirms, sub prices the change by Thursday." Then move. If you cannot get a decision, say who owns it and when it is due, and move anyway.
Park anything that turns into a commercial conversation. Cost, responsibility, and who eats the delay are not camera work. Note it, name the owner, keep walking. A multi party walk that turns into a change order negotiation stops being useful to the two people who were only there to look at the condition.
The specific problem of the sub on the call
The sub's foreman being on the walk is the highest-value and highest-risk part of the whole thing.
High value because he is the only person who knows why it was built that way, and the answer to about a third of the questions is a two-sentence explanation that no amount of email would have produced.
High risk because he is being observed by the two parties who can cost him money, live, with no time to think. If you treat that carelessly you get a defensive foreman and you will not get straight answers again.
So handle it. Tell him beforehand exactly which items will come up. Do not spring conditions on him on camera. And when something is genuinely his error, do not run a trial about it on the call. "That is not right, we will sort the fix offline" is enough, and it keeps him useful for the remaining fifteen minutes.
Afterward
Send the recording and five lines of decisions within the hour, while everyone still agrees on what was said. Not a transcript. Decisions, owners, dates.
The recording matters more on multi party walks than on any other kind, because these are the walks where instructions get given. Six months later the question is never "what did the wall look like." It is "who told the sub to do that, and when." A dated recording with the exchange in it answers that without anyone having to defend their memory.
Keep the same recordings where the whole team can reach them, not in one PM's phone. The point of getting four parties on one feed is a shared record, and a shared record stored privately is just your record.
The mechanics of running the walk itself, signal, light, narration, phone handling, are covered in the remote construction walkthrough guide. The multi party version is the same walk with a stricter chair.
Try it on one open item that has been bouncing between an architect and a sub for two weeks. Fifteen minutes, all three parties, one decision. The plans and limits are here, and a trial is enough to see whether your architect can actually join before you build a process around it.
InspectStream records what an inspector observed. It is not a public adjusting service and does not prepare, negotiate, or advise on insurance claims.