# Feedback and approvals

> Collect notes in one place, then turn them into changes without the chaos.

Feedback is useful when it is specific and useless when it is a list of feelings. A little structure gets you from comments to changes quickly.

## Asking for the right feedback

Give reviewers one job at a time. "Walk through booking a session and tell me where you get stuck" produces far better notes than "what do you think?".

Ask for:

- The screen they were on
- What they expected
- What happened instead

## Collecting it

Keep every note in one place, such as a shared document or your team's usual tracker, so nothing gets lost between messages.

## Turning notes into changes

Group the notes, then send one message per group:

1. Fix anything that blocks the main task.
2. Fix anything that looks broken.
3. Then discuss preferences.

Do not negotiate taste before the flow works.

## Approvals before publishing

For client work and regulated teams, a simple rule works well: one named approver per project, and publishing only after they say yes. For changes to sensitive areas, [Guardrails](/build/guardrails) can require human review and record it in the audit trail.

> [!tip] Ask the approver to sign off on what will actually ship, not on an earlier preview. "It changed after you approved it" is a conversation worth avoiding.

Next: [Conductor](/collaborate/conductor).