A roofing project can be moving forward while the customer still feels unsure about its status. An update that says “making progress” may be accurate, but it leaves the reader to work out what changed, what comes next and whether anyone needs a decision.
Before sending the next in-progress update, answer four questions. Use the answers to build a short message that fits the reader and the situation. This is a suggested communication practice you can adapt to your team’s responsibilities and customer agreements.
1. What changed since the last update?
Start with the information the recipient needs most. Identify the property or project and the date of the update, then describe the progress you can actually confirm. A customer managing several buildings should not need to search an old email to discover which job you mean.
Be specific about the stage of work. “The site visit took place” and “the office is reviewing the visit notes” describe different events. Neither statement automatically means that the whole project is complete. If something remains unconfirmed, name that uncertainty rather than folding it into a broad statement that everything is on track.
Keep technical detail proportional to the reader’s needs. A field supervisor and a property manager may need different explanations of the same activity. Digital.gov’s guidance on organizing information recommends putting the most important information first. For a customer update, that means leading with the useful change rather than a long account of internal conversations.
2. What happens next?
Give the reader a clear picture of the next planned step. Identify who is coordinating it and explain any dependency that affects the plan. If a date is still being arranged, say that directly. A proposed date and a confirmed appointment should not look identical in the message.
Separate an observation from a forecast. Your team may know that today’s scheduled visit happened while still checking the timing of the next activity. Report the confirmed event, then explain how and when the remaining timing will be clarified. Do not turn an internal target into a customer commitment without checking it with the responsible person.
A short explanation is usually more useful than a string of internal status labels. If a phrase only makes sense to your office, replace it with language the customer can use. Digital.gov’s clear-writing guidance recommends focusing each sentence on one idea. That is a useful editing check when a single sentence contains progress, a possible date, an exception and a request.
3. Does the reader need to decide or provide anything?
If the next step needs customer input, make the request easy to find. Explain what information or decision is needed, who should respond and any timing that has genuinely been agreed. Keep separate requests separate, especially when different people are responsible for them.
A status message can report that a decision is pending without implying that additional work has been authorized. Use the approval process that applies to the job. If the recipient only needs information, say that no action is needed from them at this stage.
Before asking again, check the current correspondence and ask the existing coordinator whether a reply has already arrived. A useful update should reflect what the team currently knows. It should not send the customer back through a decision they have already made or leave two people requesting the same answer in separate threads.
4. When will the next update arrive?
Set an update expectation that the responsible person can support. That may be a particular day, after a scheduled review, or when a named dependency is confirmed. Choose a practical checkpoint rather than promising a response time the team has not agreed to meet.
If there is no material change, the next update can say so and identify what remains pending. There is no need to invent progress to fill a message. Make sure someone owns the follow-through, including the handoff if that person will be unavailable.
The communication channel matters too. Use the customer’s agreed route and the existing project thread where appropriate. Check the recipient list before sharing project information, and keep internal discussion, access credentials and unrelated contact details out of the customer-facing message.
A hypothetical update using the four questions
The following example is fictional and illustrates message structure. Its dates and activities do not describe a real customer or establish a recommended roofing method.
Subject: Building B project update — Tuesday
Today’s planned site visit took place. Our office is reviewing the visit notes before confirming the next activity.
Jordan, our project coordinator, will confirm the proposed timing with your facilities contact. The next visit is still being arranged; no new appointment is confirmed in this message.
Please tell Jordan who should receive the proposed dates. No decision on additional work is being requested here.
Jordan will send another update by Wednesday afternoon, including any timing that is still unresolved.
For a real message, replace every detail with information the responsible people have verified. Use the team’s actual names, timing and approval arrangements. The example’s promised update time belongs only to the fictional scenario.
Read it once as the customer
Can the recipient identify the project, understand the change, see the next step and find any requested action? Are confirmed facts and tentative plans clearly separated? Digital.gov’s heading guidance supports using the questions readers actually have to organize information. You can use these four questions as an internal check even when the finished email needs no headings.
This guide covers communication while work is in progress. For the later handoff after a repair, read the service-ticket closeout checklist. For broader listening and follow-through habits, see seven keys to good communication.
Bring one example of your current customer-update workflow to a Centerpoint Connect demo. Ask questions about the workflow you want to review rather than assuming how any particular feature works.