“Increase the budget on the good campaign” contains several unresolved decisions. Which account? Which campaign? What amount? For how long? What evidence made it good? Has someone already changed it?
A change request turns that conversation into an executable proposal. It should be understandable to a buyer, approver, or AI operator without requiring them to infer missing values from chat history. The template below is a working process, not a requirement imposed by an advertising platform.
State the decision before the implementation
Open with the business reason and intended effect. For example: “Test whether the acquisition campaign can absorb additional spend while maintaining the agreed contribution target.” This tells the reviewer why the edit exists.
Then identify the evidence and its limits. Include the reporting window, conversion maturity, customer mix, and any important operational constraint. If the proposal depends on stock arriving tomorrow, name the inventory owner and the confirmation required.
Keep the hypothesis distinct from the command. A plausible reason for more spend is not a precise instruction to raise a budget, and a precise budget edit is not proof that the hypothesis is correct.
Use a request with explicit fields
| Field | What to write |
|---|---|
| Request ID and owner | Stable reference and responsible operator |
| Target | Platform, account ID, campaign or object IDs |
| Observed state | Current values and time checked |
| Proposed state | Exact replacement values, units, currency, and schedule |
| Reason | Business question and supporting evidence |
| Dependencies | Conditions that must be true before execution |
| Authority | Standing permission or named approval for this version |
| Verification | Resulting state to inspect and exception handling |
| Follow-up | When and how the business outcome will be reviewed |
An illustrative request might propose changing an average daily budget from $200 to $230 for one identified campaign, subject to the client's approved spending framework. The number is an example, not a recommended increase or a promise about daily charges.
For several objects, attach one row per change. A phrase such as “apply to all similar campaigns” can expand scope beyond what the reviewer intended.
Check whether the request is still current
Read the live state immediately before execution. If the current budget is already $250 rather than the recorded $200, stop and reconcile the difference. Applying the old proposed value could now reduce spend instead of increasing it.
Use Google Ads change history or the corresponding platform record to investigate relevant edits. The request should not compete silently with another buyer, a platform recommendation, or an automation rule.
Define an expiration or revalidation condition for consequential requests. Approval given before a promotion ends or before a tracking outage may no longer support the same decision. Refresh the evidence and return material changes to the appropriate approver.
Keep approval attached to the exact version
An approval should identify the request version, target objects, and values. If the agency changes the proposal after approval, use the agreed revision process. Do not retain the approval as though it covered every subsequent edit.
For AI operators, the distinction between a proposal and an authorized action should be visible in the workflow. OWASP's AI agent security guidance discusses scoped permissions and controls around consequential tool use. In this process, that means the operator should execute only the action actually authorized within the client's scope.
Avoid making approval depend on vague sentiment. “Let's push harder this month” may establish a strategic preference while leaving the exact campaign edit unresolved.
Separate a rollback from a reversal of consequences
Record how to restore a setting when that is technically possible, along with the prior value and owner. But do not imply that restoring a budget refunds spend or that pausing an ad removes impressions already served.
Some changes have dependencies that make restoration more complex. A conversion-goal edit, deleted asset, or changed destination may require additional repair and verification. Describe those conditions before execution if they materially affect the decision.
Use a bounded recovery plan: which objects to inspect, what state to restore, and what evidence shows the account is stable. Avoid an account-wide reset as the default answer to a local issue.
Record what happened, including partial results
After execution, compare each requested change with the resulting platform state. Mark completed, failed, skipped, or unresolved items separately. Include provider responses only to the extent they help explain the result without exposing unnecessary sensitive data.
If an operation times out, inspect current state before retrying. An uncertain response is not proof that nothing happened. Repeating a launch can create duplicate ads or tasks if the integration does not prevent it.
Link the execution receipt to the change log. The request explains the intended action; the receipt establishes what was observed afterward.
Close with the decision review
Immediate verification should confirm settings and status. A later review should evaluate the business hypothesis using an appropriate data window. Record external changes that make the result hard to interpret.
If the test is inconclusive, state why and choose the next useful observation. Do not mark a request successful simply because the edit was accepted by the platform.
A strong change request can be read backward from outcome to action to approval to evidence. That trace makes delegation easier and prevents a series of reasonable-sounding messages from becoming an ambiguous operating instruction.