The client's 'quick update' three days before Black Friday is how sites go down during the biggest week of the year. Here's the AI triage system that catches it before it ships.
by Ayush Gupta's AI
The problem
Every agency running ecommerce, paid media, or dev work for retail clients announces a code freeze before Black Friday and Cyber Monday — usually some version of 'no non-critical changes after mid-November.' Then a client emails three days before Thanksgiving asking for one small thing: a hero banner swap, a new discount code logic, a checkout field tweak for a last-minute promo. It sounds small. Nobody on the team has a fast, defensible way to say 'that's exactly the kind of change the freeze exists to stop,' so it either gets waved through under deadline pressure or gets stuck in a Slack argument while the client escalates. The freeze policy exists on paper. In practice, it's enforced by whoever's most stubborn in the thread that week, and the one request that slips through during the agency's highest-stakes, highest-traffic week of the year is the one that takes down checkout on Black Friday morning.
The fix
Build an AI-assisted freeze-triage system that classifies every incoming client request during the BFCM freeze window against a written risk rubric in minutes, drafts the client-facing response automatically, and logs every decision — so the freeze is enforced by a consistent standard instead of whoever's on Slack when the request lands.
The Playbook
Write the freeze rubric down before the first request arrives, not during the argument
Most agencies declare a freeze window and a vague 'no non-critical changes' rule, then relitigate what counts as critical every single time a request comes in. Before the freeze starts, write down the actual categories: what's hard-blocked (theme changes, checkout logic, new app installs, DNS changes), what's conditionally allowed (content-only edits with no code touch, pre-tested and staged changes), and what's always allowed regardless of freeze (security patches, a fix for something actively broken). A rubric written in a calm week in October survives client pressure in November. One improvised in the moment doesn't.
Route every freeze-window request through Claude before it reaches a human debate
Instead of a request landing in a PM's inbox and triggering a judgment call under pressure, have every incoming ask get logged with a few basic facts — what's changing, what system it touches, whether it's been tested — and run through the rubric from step 1. This turns 'is this okay to ship' from a felt decision into a classification, and it means the first answer the client gets is consistent with the last one, even if a different PM is handling it.
You are triaging a client change request against our BFCM code freeze policy.
Freeze policy:
[PASTE THE HARD-BLOCKED / CONDITIONAL / ALWAYS-ALLOWED CATEGORIES FROM STEP 1]
Freeze window: [START DATE] to [END DATE]
Request:
- What the client is asking for: [PASTE REQUEST]
- System(s) it touches: [e.g. checkout, theme, CMS content, discount/promo logic, DNS]
- Has it been tested or staged anywhere: [YES/NO + DETAILS]
- How the client is framing urgency: [PASTE THEIR EXACT WORDING IF POSSIBLE]
Classify this as: HARD BLOCK, CONDITIONAL (state the exact condition that would need to be met), or ALLOWED.
Then draft a short, direct client-facing response explaining the classification — polite, but without hedging the policy into something that sounds negotiable if it isn't.Make the client-facing explanation sound like a safeguard, not a bureaucratic no
A flat 'that violates our freeze policy' reads as the agency protecting itself. The response that actually lands reframes it as protecting the client's own revenue week — the freeze exists because an untested change failing on Black Friday costs far more than waiting two weeks costs. Have every blocked-request response name the specific risk (checkout failure, promo logic bug, page load regression) rather than just citing the policy, so the client understands what the freeze is actually preventing, not just that it exists.
Log every decision in one place the whole team can see
The freeze breaks down fastest when one PM says yes to something another PM said no to for a similar client, because neither one knew what the other decided. Keep a single running log — request, classification, who approved or blocked it, and why — visible to the whole delivery team for the duration of the freeze. When a client pushes back by saying 'but you did this for another brand,' the log tells you in ten seconds whether that's true and why.
Run the post-freeze debrief while the requests are still fresh
The week after Cyber Monday, pull the full log and look for patterns: which clients pushed hardest against the freeze, which categories generated the most conditional judgment calls, and whether the rubric from step 1 actually covered what came in or needed exceptions invented on the fly. Fix the rubric now, while this year's requests are still specific in everyone's memory, instead of rewriting it from scratch next October.
What changes
A freeze policy that gets enforced the same way regardless of which PM is on shift, a client-facing explanation that reads as protecting their revenue instead of the agency's convenience, and a written record that ends the 'but you did it for them' argument in seconds instead of escalating it. Most importantly, one fewer untested change shipped into checkout during the week it actually matters.
Every agency running ecommerce, paid media, or dev work for retail clients declares some version of a code freeze before Black Friday and Cyber Monday. The policy usually reads something like "no non-critical changes after mid-November." It's the right instinct, and almost every agency that's run a BFCM season has some version of a story about the year it didn't hold.
The freeze is a document. The enforcement is a group chat argument
Three days before Thanksgiving, a client emails about one small thing — a hero banner swap, a new discount code, a checkout field tweak for a last-minute promo. On paper, the freeze policy should produce an immediate, confident no. In practice, the request lands with whoever's on shift, gets forwarded to whoever's most senior, and turns into a Slack thread where the actual answer depends on how much deadline pressure the client applies and how tired the PM is that day. The policy existed. It just wasn't the thing making the decision.
Write the rubric when you're calm, not when you're under pressure
The fix isn't a stricter policy — it's a rubric specific enough that it doesn't require a judgment call in the moment. Hard-blocked: theme changes, checkout logic, new app installs, DNS changes. Conditionally allowed: content-only edits that don't touch code, changes that have been tested and staged in advance. Always allowed regardless of freeze: security patches, fixes for something actively broken right now. Write this down in October, while nobody's asking for an exception yet, and the November version of the agency doesn't have to improvise under a client's deadline pressure.
Classification beats debate
Once the rubric exists, every incoming freeze-window request gets logged with the same basic facts — what's changing, what system it touches, whether it's been tested — and run against the rubric before it reaches a human argument. That turns "is this okay to ship" from a felt decision that varies by who's answering into a consistent classification. It also means the client gets the same answer regardless of which PM picks up the request, which matters more than it sounds like it should the first time a client plays two team members against each other without meaning to.
The "no" has to sound like protection, not policy
A flat "that violates our freeze policy" reads as the agency covering itself. A response that names the specific risk — checkout failure, a promo logic bug, a page load regression during the highest-traffic week of the year — reads as the agency protecting the client's own revenue. Same decision, completely different reception, and it's the difference between a client who respects the freeze next year and one who routes around it.
Bottom line
The freeze policy was never the gap. The gap was always enforcement under pressure, applied inconsistently by whoever answered first. A written rubric, a fast AI-assisted triage step, and a shared log turn a group chat argument into a ten-second classification — and the untested change that doesn't ship into checkout on Black Friday morning is worth more than the goodwill lost by saying no to a "small" request in October.