# Give buyers a build schedule they can read correctly

A buyer-facing build schedule shows sequence, current phase, upcoming decisions and known changes without presenting every target date as a guarantee. The field schedule stays the operating source. You translate it into a reviewed update that explains what moved, why it moved, what happens next and what the buyer has to decide.

## What does the buyer want from the schedule?

Not to manage trades. They want to know where the house stands, which decisions are coming, what changed and when to prepare for closing or a move. A bar chart full of internal activity names looks precise and answers none of those questions.

The superintendent needs task-level sequence and trade coordination. The office needs approvals, selections, draw and document status. The buyer needs a stable view of the build with enough detail to follow cause and effect. All three views come from one current operating record, not three disconnected calendars.

Say at the start that a schedule is a working plan built on current information. Then show how changes get recorded. That is more credible than hiding every target date, and more honest than publishing a date the field cannot hold.

### Should the schedule show a completion date?

Only the date language your current project documents and approved practice support. Keep a target, a forecast, a confirmed appointment and a contractual date distinct. Do not let formatting erase the difference. A bold date in a portal creates an expectation even when the label says "estimated."

## Which details belong in a buyer update?

Translate the field plan into buyer questions. What was completed? What is active? What comes next? Which inspection, selection, material or approval gates that next work? What changed since the last update?

| Schedule item | Internal view | Buyer-facing view |
| --- | --- | --- |
| Current phase | Task sequence and trade assignments | Plain description of active work and verified progress |
| Next phase | Planned start and dependencies | What has to happen before the next visible milestone |
| Decision need | Approval or selection status | What the buyer decides, by when and why |
| Material status | Order, delivery and inspection record | Only the status that changes upcoming work |
| Schedule change | Revised task dates and reason code | What changed, the known cause and the next review point |
| Completion outlook | Current forecast and open risks | Approved date language with the uncertainty stated plainly |

Photos support the update. They do not replace status. A framed room looks finished to a buyer while rough inspections, corrections or concealed work stay open. Caption each image with the work it documents. Do not call a phase complete before the responsible field role verifies it.

## How do you assemble a weekly schedule update?

With a repeatable review path. The update cannot depend on one person remembering everything at the end of a long site day.

1. **Read the current field record.** Active tasks, completed checks, open corrections and the latest approved plan set.

2. **Compare the prior update.** Each promised next step: did it happen, move or change scope?

3. **Check dependencies.** Selections, materials, inspections, permits and trade handoffs that gate upcoming work.

4. **Record schedule changes.** Known reason, affected phase and next review point. No blame.

5. **List buyer actions.** Only decisions that need attention, each with a deadline and a source link.

6. **Review the draft.** The responsible project role confirms the facts and the date language before it goes out.

Our Claude and Codex agent fleet gathers approved status fields, compares the prior message with the new field record, drafts plain language and checks that links work. People confirm job-site facts, choose the date language and approve the message. The agent is a drafting and checking layer, not the scheduler.

## How do you explain a schedule change without sounding evasive?

Cause and effect. What changed, what evidence confirms it, which work is affected, what the team is doing now and when the schedule gets reviewed again. If the effect is not yet known, say so.

"Exterior work moved" is weak. Name the affected activity, the condition blocking it, any work continuing elsewhere and the next decision point. You are not defending the builder. You are giving the buyer an accurate operating picture.

Keep specialized notices connected. A [weather delay update](/articles/process-and-documents/weather-delay-communication/) documents site conditions and affected work. A [permit delay update](/articles/process-and-documents/permit-delay-communication/) separates submission, review, correction and release. The main schedule summarizes those records and links to them.

### When do you call instead of sending an update?

When a change needs a decision, touches a major expectation or is too uncertain for a one-way message. Follow the call with a written record of facts, decisions, owners and next steps. The call carries context. The record prevents competing memories later.

## How do you keep the schedule from becoming a second contract?

Use labels the same way every time and point to the controlling documents. Never add an obligation through a dashboard, a photo caption or a casual text. When a buyer asks how a schedule change affects a contractual term, route the question through the approved review path.

Archive prior schedule snapshots instead of overwriting them. A revision log shows when the forecast changed, why and who approved the communication. That history answers later questions without reconstructing months of messages.

Build the communication standard into the [documented build process](/articles/process-and-documents/documenting-your-build-process/). The [Operating profile stage](/process/operating-profile/) names the owners and records behind each update. Your [operating profile](/glossary/operating-profile/) holds that cadence in writing. The [build process guide](/guides/writing-down-your-build-process/) shows how to keep those handoffs current. The [process and documents library](/articles/process-and-documents/) covers the adjacent buyer records.

## Which schedule update questions come up most?

### How often should buyers receive a schedule update?

At a cadence your team can hold and has approved. Send an extra notice when a material change or decision cannot wait for the next one.

### Should buyers see the full field schedule?

Usually not. Buyers get a translated view. Review trade assignments, internal notes and tentative sequencing before any part of the field schedule goes out.

### Can a portal replace a written update?

Only if it preserves facts, explanations, revision history and review controls. Dates alone explain neither dependencies nor changes.

### What if the schedule effect is still unknown?

State the verified condition, the question under review, the responsible role and the next update point.