Show clients what changed in a weekly project update

Start with the change your client cares about

“The booking flow is progressing” leaves your client guessing. A short recording can show something specific: a customer choosing a new appointment time and seeing it on the review screen.

Choose one useful interaction before you open the recorder. Start where the change begins and stop at its result. If another change needs a different explanation, give it a separate clip.

Describe the change in your client’s language. “Customers can choose another appointment time before confirming” gives them more to work with than a list of components or commits. Keep technical detail nearby when it affects their decision.

Record a small demonstration in Rill

Use a test account and data you can share. Close unrelated tabs, hide notifications and check the visible page for names, email addresses and payment details. Choose a tab or window when your browser offers it and that keeps the recording focused.

Sign in to Rill and choose Record my screen. Add microphone narration if it helps explain what to look for. Show the interaction, stop, then preview the clip before you save it. Create a share link once you are ready for someone else to watch.

Rill records the private information you leave visible. Anyone with an active share link can view the recording and included comments, so check the clip before sharing it. See the capture and sharing guide for the current workflow.

Write down what the clip establishes

Name the environment in the message: “staging with sample appointments” or “available on the live site.” Your client should be able to find that detail without inspecting a browser tab.

Describe the result you can see: “The selected time changes to 2 pm, and the review screen shows the same time.” If you stop before saving the change or sending a confirmation email, include that limit in the update.

Keep any test results separate from the demonstration. A clip of the review screen cannot establish that a booking persists after confirmation. A manual screen recording also does not automatically include console or network diagnostics. Share verified results when you have them, and leave unchecked steps open.

An example: a booking change that is still in progress

Cedar Studio is a fictional appointment-booking project. The scenario and message below illustrate an update you could make; they are not a real recording, customer response or verified app result.

The developer has built a way to propose a new time before confirming an appointment change. The client still needs to choose how late customers may reschedule.

Start on staging with a sample appointment at 10 am. Open Change time, choose 2 pm and return to the review screen. Pause so the client can see the new time, then stop before confirming or taking a payment.

After reviewing the clip, attach its share link to a message like this:

Here’s this week’s booking update. The attached recording uses sample appointments on staging.

The clip shows a customer proposing a change from 10 am to 2 pm, with the new time visible on the review screen. Saving the confirmed change, confirmation emails and payment are still outside this demonstration.

Should customers be able to reschedule until 24 hours before the appointment, or would you like a different cutoff? Please reply with the rule you want. Next, we’ll implement that rule and check the complete rescheduling flow.

Add the actual reviewed share link when you use the template. The message gives the client one visible change to inspect and one business decision to make.

Ask for a reply you can act on

Give your client a specific question. “Does the review screen need to show the original time as well as the new one?” is easier to answer than “Any thoughts?” When feedback concerns one moment, ask them to include its time in the recording and describe what they expected.

Keep the answer in your project’s written record. If a client says “looks good,” clarify whether they mean the interaction looks right or they have chosen the rescheduling rule. Viewing a recording alone does not approve scope, policy or a release.

A suggestion may introduce new work. Record the request, then agree whether it belongs in the current scope before treating it as a commitment.

Reuse the structure next week

Keep a small template: the visible change, the environment, the unfinished or unchecked steps, and the next decision. Link the previous update when a comparison will help your client see progress.

When a test fails during preparation, describe the blocker or show the current behavior with its limits. For an update with no visible interaction, a few lines of text may carry everything your client needs.

For the next change worth showing, record one interaction in Rill and review it before sharing. Give your client a clear place to look and a clear way to respond.