The $90 sale ended. Its promise kept traveling from search ad to support desk.

At 9:03 on Monday, someone forwards a screenshot: “Your ad said $90. Checkout says $120.” The weekend sale ended at midnight. Everyone on the team can explain, truthfully, what they switched off.

Here is a constructed case of one brewer and one offer. The point is the route the promise takes, not a claim that any particular account served this combination.

The paid-search manager scheduled the promotion asset to end on Sunday. That is a real clock: Google Ads lets an asset be eligible only within selected dates. The little red price tag is less obedient. It also exists elsewhere. Google Ads explains promotion-asset scheduling.

“We ended the promotion asset” answers a question about the asset. It does not answer the customer's question about the ad. The $90 headline was written into an evergreen responsive search ad. Ending an attached promotion does not edit that headline. If the team changes ad text, the new version goes through review; a time-sensitive claim needs a planned replacement or a pause while it is corrected. Google Ads describes editing and review of ad text.

The product feed holds another copy of the $90 claim.

The feed owner has a receipt for the morning upload. In the submitted product data, though, sale_price remains $90 and sale_price_effective_date is blank. Google says that without that date range, the sale price applies for as long as it is submitted. A received file is evidence of delivery, not evidence that its price agrees with the site. If the page has returned to $120, that disagreement can trigger a price-mismatch issue; it is not a dependable retirement plan. Merchant Center's product-data specification and price-mismatch guidance make the distinction explicit.

The web team restored the product price. The page banner was a separate content block. Both statements are now visible in the same browser, which is a particularly efficient way to make a customer doubt both. At checkout the brewer costs $120. The stale banner still invites the $90 expectation.

The support agent did not create the headline, the feed, or the banner. The agent receives the contradiction. The old macro has not been sent in this exchange, but it still says the $90 offer is live. Simply replying “The offer expired” would also miss what this person saw today. A useful reply acknowledges the screenshot and takes the case to whoever can decide the remedy. Retire the macro before the next agent picks it.

Every owner finished a task. Nobody owned the claim across its copies.

Retire the promise, then prove it stayed retired

The customer still needs an answer while the team retires each remaining $90 claim.

For this offer, one owner would keep a short claim record: which brewer, $90 instead of $120, which customers qualify, the exact close time and time zone, every place the price appears, and who handles a customer who saw it after the close. The owner need not personally edit every surface. They do need an answer from each surface owner.

At close, the check is concrete:

A green upload receipt, a scheduled end date, or an edited page proves only its own narrow fact. Look at the live customer path and the processed platform state, record when each was checked, and repeat a check that was still pending review or update. If one $90 promise remains, stop sending people into the discrepancy while its owner fixes it.

The offer did not become stale because it was forgotten by everyone. It became stale because it was remembered in pieces.