“Improve the campaign before Friday” is a request for an outcome, not an instruction an operator can safely execute. It leaves the actual changes, their boundaries and the meaning of completion unresolved. A reviewable change request turns that intention into a concrete proposal for the ChatGPT campaign.
The document does not need to be long. It needs enough detail for the approver to understand the tradeoff and for the operator to implement the same change that was reviewed. Those are two different readers, so the request should connect the business reason with the exact proposed configuration.
State the problem without promising the result
Open with the observed problem or new business requirement. Identify the evidence and its limits. “The destination offer has changed” establishes a different reason for editing than “we suspect the current message attracts the wrong enquiries.” The second is a hypothesis and should remain one.
Describe the expected benefit as a rationale, not a guaranteed outcome. Replacing ambiguous copy may make the offer clearer, but the request should not promise a specific conversion increase without appropriate evidence. Approval of the change is not confirmation that its expected effect will occur.
If the request is urgent, explain the actual deadline. An offer expiry, a scheduled client review and a preference to finish this week are different constraints. The approver can make a better decision when urgency is tied to a real dependency instead of the word “ASAP.”
Show the exact difference
Name the account and affected resource identifiers. Add familiar names for readability, but do not rely on names alone to distinguish similar campaigns. Specify whether the change applies to a campaign, ad group, ad or destination managed outside the advertising account.
Show the current observed value and the proposed value for each affected field. For a text change, include the full proposed wording rather than a vague instruction to make it more direct. For a list replacement, make the intended complete list clear. The operator should not have to reconstruct the proposal from several comments.
Use a boundary statement: which objects and fields are included, and which related work requires a separate request? This prevents a small approved edit from becoming an opportunity to make several unreviewed improvements. It also makes the later verification manageable.
| Part of the request | A concrete answer |
|---|---|
| Affected resource | Account and object identifiers |
| Present state | Observed value with observation time |
| Proposed state | Complete intended value or configuration |
| Reason | Evidence or business requirement behind the change |
| Completion check | Read-back or review that confirms the intended difference |
If the current value has not been checked, mark that gap. A proposal based on an old export can become invalid when another colleague has already made a related correction. Reconfirm the current state before executing the approved request.
From wish to reviewable proposal
- Too vague
Improve the ad and make the offer clearer before Friday.
Reconsider - Reviewable
An identified ad, exact replacement copy and the reason for changing it.
Checkpoint - Verifiable completion
Read back the resulting state and compare it with the approved revision.
Checkpoint
Expose the dependencies before the decision
List the conditions that must be true for implementation. An advertised price may depend on the destination being updated. A new image may need approval from its owner. A measurement change may need a verified event implementation. Include only dependencies relevant to this proposal.
Assign an owner to each unresolved condition and state whether it blocks the change. “Website team informed” is weaker than a confirmed destination and an agreed readiness check. The request should make it possible to tell whether implementation can start now.
Consider the recovery boundary too. If the change must be reversed, what earlier values are available and which later edits need protection? Link to a rollback record where the change warrants one. Do not imply that every platform action has an automatic undo function.
Check the applicable operation in OpenAI campaign management before treating the proposal as technically implementable. The internal request format here is not a platform approval mechanism. It records the agency or advertiser’s decision around the operation.
Make approval refer to a fixed proposal
Give the request a revision identity. The approver should confirm the specific text and configuration they reviewed. If the operator later changes the proposal materially, the earlier approval should not be stretched to cover the new meaning.
Keep discussion separate from the final decision. Comments may contain alternatives that were rejected or assumptions that were later corrected. A short final state and the associated approval evidence help the implementer distinguish the agreed proposal from the surrounding conversation.
Record who can authorize the change under the working arrangement. A colleague’s useful feedback is not necessarily permission to change a client’s offer or spending plan. The request should route the decision to the appropriate owner without creating unnecessary approval steps for already authorized routine work.
Close with observed implementation
After execution, record the implementation time and check the resulting state against the approved difference. Separate a successful submission from verification of the intended outcome. Note partial completion or any additional action that remains necessary.
If a campaign change freeze applies, record the relevant exception or postpone the change according to the agreed procedure. Keep the completed request with its evidence so the next operator can answer what changed and why. A good change record is a concise connection between intention, authorization and observed result, not a pile of messages that someone must reinterpret later.
Sources and scope
Describe the exact scope, intended resulting state and verification of a proposed campaign change before its implementation is approved.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.