Communicate a phased feature rollout clearly

Use one row per meaningful eligibility group, not one row per marketing segment. Each row needs a rule, current state, evidence date, allowed claim and next action. Keep an empty date visibly unconfirmed in the working packet; do not convert it into “soon” as if that supplied useful timing.

Avoid describing every user as part of an early wave. If eligibility is determined by an account setting or administrator action, the announcement should explain that condition rather than imply a waitlist order.

• Eligibility: the verified condition that determines access.
• State: available, pending, paused or not included.
• Evidence: owner and time of the latest confirmation.
• Timing: confirmed date or no announced date.
• Action: open the feature, request activation, wait for notice or read the scope.

Imagine a fictional reporting feature initially enabled for selected test workspaces. The following matrix is illustrative, not an actual rollout schedule.

• Selected test workspace: available after an administrator enables the setting; copy, “Test workspaces can enable the new report in Settings.”
• Other workspace: not yet available; no expansion date approved; copy, “The report is currently limited to selected test workspaces. Broader availability has not been announced.”
• Unsupported role inside a test workspace: cannot enable the setting; copy, “Ask your workspace administrator to check eligibility.”
• Paused test workspace: follow the verified status notice; do not reuse the available-access CTA.

For the eligible group, lead with the task and show the activation prerequisite before the report. For the wider audience, introduce the capability as a limited rollout and explain the current boundary. The same product demonstration can support both, but the opening and ending must not promise access to viewers who lack it.

An evergreen alternative is a single status-led explanation with a clearly named status destination. That reduces the number of edits, but the video still needs an accurate statement of the current limitation. A link cannot repair a misleading “available to everyone” headline.

Keep availability copy in a replaceable scene and record which matrix row it represents. When access expands, update that row and every asset derived from it. A later release may remove one boundary while preserving another, so replacing “selected” with “all” is not a safe mechanical edit.

Check the published asset's title, description and thumbnail copy too. If rollout pauses, identify whether the existing asset still explains the feature accurately or now directs people toward an unavailable action.