Fictional example: A crew sends the office a photo and a question about an area of Building C. The project coordinator opens a scope review. The estimator sees the message, but the field lead still has yesterday’s instructions, purchasing has the original material list, and the customer-contact owner has not seen the question.
Before anyone treats the new message as a direction to proceed, map what it could affect. Which records need review? Who owns each decision? Which version should each person use? A small change record can organize those questions without turning a field observation into an approved scope change.
The following is a proposed coordination practice for roofing teams. Use it alongside your existing project responsibilities and approval arrangements. It does not determine technical suitability, contractual authority or permission to perform additional work.
Record the difference before rewriting the instructions
Start with the job reference, building or roof area, observation date and person who raised the question. Link the relevant photo, marked-up drawing or message. Describe what was observed separately from what someone proposes doing about it. If the location or meaning of a photo is uncertain, give that question a reviewer instead of filling in an answer.
Keep one short description that the next person can understand without reading an entire chat history. For example: “Building C, west roof area: field photo attached for scope review; proposed response not yet decided.” That is enough to begin a review. It does not claim that a defect has been diagnosed or that a particular repair is appropriate.
For a source-specific example of this record structure, Autodesk’s issue-report documentation brings together a description, assignee, location, photos and references. The practical point for your own log is to keep the question, supporting evidence and responsible reviewer connected.
Make an affected-record list
Do not assume that every scope question changes every document. Ask the responsible people which records actually need review, then give each affected record its own owner and state. A compact list could look like this:
| Record to review | Question for its owner | State to record |
|---|---|---|
| Work order or field instructions | Does the current instruction still describe the intended work? | Current reference; review owner; decision pending or revision identified |
| Material plan | Does the question affect an item, quantity or need date? | Purchasing review needed, or no change confirmed by its owner |
| Schedule | Does an unresolved dependency affect the planned sequence? | Dependency and person responsible for the next scheduling decision |
| Customer-facing scope document | Does the customer-contact owner need to prepare an explanation or request a decision? | Draft, awaiting the relevant decision, or current version identified |
| Photos and supporting references | Can the reviewer identify the location and the evidence being discussed? | Reference attached, clarification requested, or corrected reference identified |
Use the actual document names your team recognizes. If one person maintains both the work order and material plan, record that person against both rows. If a record is unaffected, note who confirmed that conclusion. An empty box should not quietly become “no change needed.”
Match each update to its recipient
A complete recipient list is not necessarily the largest list. Give the field reviewer the context needed to assess the question, purchasing the information needed for its review, and the customer-contact owner the material needed to explain the next step. Keep internal discussion separate from the version intended for a customer or subcontractor.
Procore’s change-event email instructions provide recipient fields, a message and attachments, with visibility affected by permissions. That is a source-specific example, not a statement about Centerpoint functionality. In your own process, check the actual audience and accessible attachments before treating an update as communicated.
Assign one coordinator to follow the open questions. The coordinator can ask for missing decisions and keep the record current without taking over the technical, purchasing or customer-approval roles.
Check the version people can actually see
Record a document reference and revision or date beside each affected row. Preserve a clear distinction between proposed wording and the version authorized through your existing process. When a revision is ready, identify which previous reference it replaces and which people need the update. Do not assume that changing one file updates every copy already in circulation.
Visibility deserves its own check. JobNimbus’s work-order documentation, for example, distinguishes recipient-visible special instructions from internal notes. Before sharing your own update, inspect the recipient-facing document: can that person see the necessary instruction and evidence, and have internal notes or access details been kept in their proper place?
Walk the fictional handoff through its next step
Return to Building C. The field lead supplies a clearer location reference. The existing project reviewer records the question to resolve. Purchasing marks its material-plan review as waiting on that decision. The coordinator records the current schedule dependency. The customer-contact owner prepares a draft explanation, leaving the requested decision visibly pending.
As decisions arrive, each owner updates the relevant row. The coordinator then identifies the revised references and asks the affected recipients to confirm which version they will use. A sent message, a revised document, an acknowledged update and completed work remain separate states. None should be substituted for another.
Close the communication loop
At the next project check-in, ask someone who did not prepare the change record to explain what changed, which references are current and what remains unresolved. If the answer depends on memory or an unlinked message, add the missing reference or owner. Keep unanswered items open rather than marking the entire handoff complete.
For the customer-facing side of this process, read the four questions behind a useful roofing status update. To discuss your team’s current coordination process, book a Centerpoint Connect demo.