“Looks good” appears in a client conversation. Is that approval of the image, the full ad, the landing page or the proposed spending plan? If several versions were discussed, the phrase alone may not tell the campaign operator what can be implemented.
Approval evidence is the connection between a decision and the specific proposal it concerns. For ChatGPT campaign work, that connection should remain understandable after the conversation has moved on and the person who coordinated it is unavailable. The aim is operational clarity, not a larger archive of every message anyone sent.
Example one: the correct words beside the wrong version
Imagine a fictional review with two ad drafts. Version one describes a general consultation. Version two introduces a more specific service and a different call to action. The client replies positively to an earlier screenshot, while the operator assumes the latest file is approved.
The failure is not necessarily a missing positive response. It is a missing link between the response and the revision. Preserve an identifier for the exact proposal: a versioned document, a stable review item or another reference the team can retrieve. Keep the approved text and relevant visual together when they were reviewed as one message.
Do not depend on a filename such as final-final. A filename can change, and two people can have different local copies. The record should let the operator compare the proposed implementation with the actual reviewed material. Where the workflow provides a revision identifier, preserve it; otherwise use a clear internal revision convention.
If the connection is ambiguous, resolve it before making the consequential change. A short clarification tied to the exact proposal is more useful than interpreting the client’s enthusiasm as permission for every nearby item. The change request guide explains how to prepare a proposal that is concrete enough to approve.
Example two: approval with an unfinished condition
A fictional client says that the new ad is approved once the destination shows the agreed delivery information. That is not the same operational state as approval for immediate implementation. The record needs the condition, its owner and the evidence that it has been met.
Separate the decision from the readiness check. The client may have approved the message, while a website owner still needs to confirm the destination. Store both facts without rewriting the conditional statement into an unconditional one. The operator should be able to see whether the condition remains open.
Also distinguish a preference from a decision. “I prefer the second image” may resolve one creative choice without approving the offer or timing. A request for feedback on several independent elements should not be closed by a response that only addresses one of them.
Use a compact record that makes the distinction visible:
| Evidence field | What it establishes |
|---|---|
| Decision-maker | Who gave the relevant decision under the working arrangement |
| Proposal reference | Which revision and objects the decision concerns |
| Scope | Which parts were approved and which remain undecided |
| Conditions | What must be true before implementation |
| Confirmation time | When the decision was recorded |
| Readiness evidence | How any blocking condition was resolved |
Keep the record proportionate. A routine, already authorized adjustment should not acquire a new approval ceremony merely because a table exists. The point is to preserve decisions that the workflow actually requires, with enough context to apply them correctly.
What does the client's response mean?
- Looks good
The relevant component and revision may be unclear.
Reconsider - Choose image two
The image choice is addressed. Other parts may remain open.
- After the page is corrected
A condition needs verification before implementation.
Reconsider - The identified revision
The decision can be matched to the right content and scope.
Checkpoint
Example three: the approved message changes afterwards
An operator may make a small edit while implementing approved copy. Some edits are typographic; others change meaning. Replacing “request an appointment” with “book immediately” can alter the promise even though the sentence remains short. The important question is whether the reviewed decision still covers the resulting message.
Compare the final version with the approved one before submission. If the meaning, offer, relevant conditions or agreed scope changes, route the revised proposal through the appropriate decision process. Do not quietly extend an earlier approval to a materially different version.
Record the resulting implementation separately. Client approval does not establish that the campaign was successfully updated or that the platform accepted the creative. The operational chain needs both the decision and the later evidence of what was submitted and observed. Use current OpenAI campaign management for the platform steps; this approval record is the team’s own coordination method.
Make the evidence accessible to the people who need it, while avoiding unnecessary distribution of private client conversations. A concise decision summary with a controlled link to its source can be more useful than copying an entire thread into every project document. Include approval records in a suitable access review when they sit alongside campaign reports.
During an operator handover, point out any conditional or partial approvals that are still open. The incoming operator should be able to identify the approved revision, explain its limits and find the remaining owner. That is the practical test of useful evidence: another person can act on it without guessing what the original conversation meant.
Sources and scope
Connect a client decision to the correct revision, scope and conditions so operators can distinguish approved campaign changes from comments and provisional feedback.
Working methods and examples are editorial suggestions. Check current platform requirements and available features before implementation.