Nothing reaches Amazon without your approval

MerchPPC can change your Amazon account. It never does so on its own.

Every change — a bid, a budget, a negative keyword, a new campaign, a price — is staged rather than applied. It lands in the Publish queue, where it sits until you read it and approve it.

What staging looks like

A staged change shows you three things: what the value is now, what it would become, and that it has not happened yet.

TARGET              SPEND    ACOS    BE-ACOS    BID
"funny cat shirt"   $18.40   61.4%     41.3%    $0.62 → $0.41   [Queued]

The [Queued] is the important part. Nothing in that row has reached Amazon. Wherever you staged it from — a product page, the console, a Lookout — the word is the same, and it means Pending.

Approving

The Publish tab has four groups: Pending, Approved, Done and Failed.

• You approve rows individually or in bulk. Approving moves a row to Approved.
• Pressing Publish all applies the approved rows to Amazon, and they move to Done. Nothing schedules that run: it happens when you press the button and at no other time.
• Anything Amazon refuses moves to Failed, with the reason, and stays there. It is not retried silently.

Two transient labels turn up inside those groups. Publishing is an approved row currently being sent; Skipped is a row the run passed over, and it sits with the failures because it needs the same second look.

The two kinds of change apply differently, and the difference is visible:

• Advertising changes — bids, budgets, negatives, campaigns — go straight through Amazon's API.
• Merch changes — prices and new products — run through an automation tab that opens in front of you, one design at a time. Closing that tab returns the rest of the run to the queue rather than losing it.

You can delete a pending row and nothing happens. That is the point of the queue existing at all.

Why it works this way

Two reasons, and the second is the one that matters more.

The obvious one is safety: an automatic tool that gets a rule slightly wrong spends your money before you find out.

The less obvious one is that you are the one who knows things the data does not. A product with terrible ACoS might be a design you are about to relaunch. A keyword that looks wasteful might be one you are deliberately buying to hold. No amount of data reaches those facts, and a queue is how the tool asks rather than assumes.

What this means for Lookouts, and for AI

A Lookout — a rule that watches part of your advertising — proposes. It never applies. Every proposal it makes lands in the same queue as a change you made by hand, and waits the same way.

The same is true of anything Claude or ChatGPT stages through a connector, and those rows are held to a stricter rule still: an assistant's row waits for your approval on its own row, and Publish all will not send it. An assistant also never authors a number — it can point at an action the extension already computed, and there is no way for it to hand over a bid, a budget or a keyword of its own.

That is why the next page is about writing a Lookout.