# Plan a release message around verified availability

Illustrative planning brief; no automatic product import.

Illustrative change: a feature passes local validation but has not been rolled out to the intended customer cohort.

## Decision

Hold the availability claim until deployment and access conditions are verified.

## Owned work

- Define the actual change
  - Owner role: Product owner
  - Acceptance evidence: The message states the resulting user behavior without unsupported extras.
- Verify availability
  - Owner role: Release owner
  - Acceptance evidence: Rollout and applicable access conditions are confirmed.
- Check the user action
  - Owner role: Content reviewer
  - Acceptance evidence: The destination reaches the actual supported next step.

## Workflow

1. Describe the concrete before/after behavior.
2. Verify deployment and audience conditions.
3. Review the final message and destination before the authorized announcement.

## Judgment

A build, source branch or local landing page does not prove that customers can use the announced feature.


## Illustrative delivery brief

Change: the verified resulting behavior.
Availability: deployment and access cohort confirmed separately.
Next action: the current supported destination.
Review: remove claims that exceed the rollout evidence.


## Workflow questions

### Can we announce a source-only capability as available?

No. Use accurate preview or planned wording until the deployment/access evidence exists.

### What should the next-action link do?

Reach the real supported journey, with wording matching its current behavior.

## Product connection

Prepare an accurate availability update alongside the team’s delivery records; a local test does not establish a live TeamBoostAI feature.

Confirm account availability before adopting this manual outline.