Name the decision owner early
An agency may receive comments from marketing, sales and a founder. Those perspectives can improve a deliverable, but they do not automatically form a coherent instruction. Ask the client to identify who can resolve disagreements and approve the final version. Record the answer in the brief. This is not an invitation to ignore stakeholders; it prevents the producer from becoming an accidental arbitrator of the client’s internal priorities.
Separate contributors from approvers
A person who can view or comment on work is not necessarily authorized to approve spend, scope or publication. Review the platform’s actual permission options, then supplement them with clear process notes where needed. Avoid implying that a software role proves commercial authority. A client may use the same interface account for several activities while still needing a separate internal approval for a particular claim, budget or brand decision.
Resolve conflicts in one summary
For an illustrative example, one reviewer wants a shorter headline while another wants three additional claims. Present the conflict plainly and ask for a consolidated choice. Keep both original comments rather than deleting the inconvenient one. The agreed summary should identify the version and the intended outcome. Starting two opposite edits in parallel wastes time and makes it harder to determine whether the eventual output matches anyone’s actual instruction.
Make final approval specific
Ask the authorized reviewer to approve the named version for the agreed use, not a vague category such as “the latest design.” If another stakeholder introduces a change afterward, follow the revision or scope process rather than treating the prior approval as meaningless. Keep the history visible. A dependable approval path is particularly valuable when staff change or a campaign is revisited months later and nobody remembers which comments were merely suggestions.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- ManyRequests admin, client and team permissions — Merchant documentation · help.manyrequests.com · Merchant-controlled · checked 2026-09-19
- ManyRequests project management and proofing — Merchant documentation · manyrequests.com · Merchant-controlled · checked 2026-09-19