Black Friday Readiness Review

One pass over a Wix store's backend, graded against the Black Friday / Cyber Monday checklist, delivered as one report in three blocks: what already works, what the agent can fix (one approval), what the merchant does (a checklist with links). The checklist is the BFCM Webinar 2026 one, built from ~13,000 Wix stores.

Principle: verify from data, never from assumption. Every ✅ in the report is backed by an API response the agent read, or a page the agent opened and looked at, in this session. A check the agent could not read or see is handed to the merchant as a checklist item with the exact page to open, never reported as passed.

Two eyes. The backend tells you what is configured; only the live site tells you what a customer sees. When the agent has a tool that opens a web page and returns what it shows (a browser, a screenshot tool, a page reader with rendered text), it opens the store and looks. When it does not, the visual checks become the first group of the merchant's checklist, each with the page link and what to look for, on desktop and on a phone.

When to use

• The user asks to review, audit, check or prepare their store for Black Friday, Cyber Monday, BFCM, a holiday sale, or "the sale".
• The user pastes a pre-made prompt such as "Review my store X and make sure I'm all ready for Black Friday."
• The user asks one checklist question on its own ("are my coupons set up right?", "will my shipping work?"): run only that section, same report format.

Not for: designing the sale strategy from scratch (route to Recommend: eCommerce Strategy, then come back here to verify it), traffic acquisition (marketing), sites without Wix Stores (say so; offer the policies, emails and tracking sections only).

Flow

1. Context — tell the owner in one line that you are checking their store and that nothing will change (see How to talk to the store owner). Then Read Account or Site Context for the named site. Take siteId, site URL, created date, time zone, currency, and read the Wix Stores line of its app list: hasStores must be true and storesCatalogV says V3 or V1. No Stores: say so and run only the policies, emails and tracking sections. V1: the catalog, inventory and category probes below are V3-only, so skip the catalog, stock and test-cart checks, say why, and run the rest; never call the V3 endpoints on a V1 store. Several sites and none named: ask which one. No site URL in the context means the site is not published: do not look for one (no docs search, no account-level site query, no site list). Leave SITE_URL empty, send Probe 1 whole and unchanged, and put "Publish your site" first in the checklist. This recipe reads its own site fields; do not run eCommerce: Load Context for the review. It is loaded only later, if the merchant approves creating a discount (see the fixes table).
2. Which sale, which stage — Black Friday is the default, not the limit: the same checks apply to any dated sale. An event the user names (Black Friday, Christmas, Mother's Day, Singles' Day, a store anniversary, any date they give) is the sale, whether or not it appears on any list. "The holiday" or "the sale" with no name: take the next major shopping event for the store's country that falls within six weeks of today (the event calendar in Flow: Seasonal Promotion is a starting list, not a limit), name it in the report's first lines as an assumption, and do not ask. Six weeks, not the flow's 30 days: the flow's window decides when to create a discount, this one only names the sale, and the checklist's first stage starts 25 days out. Ask one question, which holiday and on what date, only when nothing falls in those six weeks, or two events are equally near and the answer would change the dates. Then pick the stage from the timing table below by the days left to the sale day. The stage decides the order of the report, never which checks run: every check runs every time.
3. Sale window — never ask for dates up front. Read them from the coupons and discount rules in step 4; a coupon or rule whose window covers the sale week is the sale. When nothing dated exists, deliver the full report anyway with "Set up your discount" as the first fix under "Needs one answer from you", asking for the offer and the dates and suggesting both.
4. Read everything in one call — Probe 1 in Black Friday Readiness Checks: one JavaScript function run against the Wix REST API with the site's credentials (the probes are written for a tool that executes such a function; without one, make the same REST calls one by one), every read in Promise.allSettled, a failed read returned as its own { ok: false } and never thrown. Catalog, inventory, categories, coupons, discount rules, shipping, checkout policies, marketing tags, automations, email campaigns, gift card product, cookie banner, site properties, pages, orders, the live homepage.
5. Test carts — Probe 2, a second function run after the reads: temporary carts priced per shipping region and per coupon code, deleted in finally. No order is placed, no customer created. The report says so. Skip when the catalog has no purchasable product.
6. Look at the live site — Probe 3 in the checks file. With a browser tool: open the homepage, the sale category page, one discounted product page, the cart with one item added, and the checkout up to (never through) the payment step; once on a desktop width and once on a phone width when the tool can resize; screenshot each page when the tool can. Record what is seen for checks 4–10 and 12. Without a browser tool: say so in the report header, and every visual check becomes a checkbox under On your live site with its URL and what to look for. Never guess what a page looks like from its HTML.
7. Grade and write in one pass. Before the report the API is read by exactly three calls: the site context, Probe 1 and Probe 2 (plus Probe 2's variant lookup when every product has options). Probe 2 always runs when a product can be bought. No follow-up read of a single endpoint, no second homepage fetch, no docs or schema search: what those results do not hold is ❔ in the checklist. Go down the checks in order, apply each pass rule once, and write its line straight into the contract below. Do not plan the report first and do not revisit a check: the template, the limits and the order are fixed, so there is nothing to design.
8. Offer fixes, apply on approval. Everything the agent can change goes in the 🔧 block, numbered, in two groups: ready to apply, and needs one answer. Change nothing until the merchant approves, and always offer a way to say no. A discount, coupon or price change, an email send or schedule, and a contact label each get their own yes or no with the exact values (see Asking for approval). Writes go through the matching wix-manage recipe (table below). After each write, read it back and tell the merchant in one line what changed and what the value was before.

Status legend

Every finding lands in exactly one block, decided by who acts:

A check with two parts (agent fixes the data, merchant confirms in the editor) is split: the agent part goes to 🔧, the merchant part to ✋.

The checks

Numbers are the checklist's; each has its data source and pass rule in the checks file.

A. Checkout, payments & catalog — 1 test cart prices without errors (merchant places one real order) · 2 every visible product has an image, a price above 0 and a description · 3 payments connected and the methods customers expect are on: cards, Apple Pay, Google Pay, PayPal, buy-now-pay-later (merchant toggles; no public read). B. Sale merchandising (live homepage) — 4 announcement bar shows the sale and its dates match the discount window · 5 every product the homepage links to is in stock · 6 discounted products carry a compare-at price (the crossed-out original) · 7 a countdown timer, if present, ends when the discount ends · 8 the sale category is in the site menu. C. Shipping — 9 each region prices a test cart above and below the free-shipping threshold, and every shipping option shows a delivery estimate. D. Policies & legal — 10 return/shipping policy at checkout and linked in the footer · 11 sale terms exist (dates, exclusions, stacking, final-sale) · 12 Terms, Privacy and cookie banner in place. E. Stock — 13 sale and best-selling products have stock for expected demand · 14 low-stock alerts (merchant) · 15 inventory tracking on for limited-quantity products. F. Coupons & discounts — 16 a dated discount or coupon for the sale exists, in the store time zone · 17 each coupon applies on a test cart with the expected amount and minimum · 18 coupon + automatic discount together never price a line below cost · 19 the sale does not stack on products already discounted · 20 coupons have total and per-customer limits · 21 everything is scheduled: discounts, coupons, emails (banners and timers: merchant). G. Emails & tracking — 22 order confirmation, shipping confirmation and abandoned-cart automations ACTIVE · 23 at least 4 email campaigns for the sale scheduled or sent · 24 Google Analytics, Meta Pixel, TikTok Pixel connected. I. Google & AI search — 25 Google Merchant Center connected (merchant; no public read) · 26 product data ready: clear titles, brand, descriptions · 27 Google / Meta feeds synced, no rejections (merchant). H. Operations — 28 expected order volume from the same sale's week last year and the last 30 days.

Report contract

Write exactly this structure: it fixes what the report says and in what order. How it looks and how to talk to the store owner follow below.

Rules for the report:

• 🔧 always prints, and its membership is mechanical. A finding goes in 🔧 when its fix has a row in the fixes table; a finding with no row goes to the checklist. Never decide by feel, never merge the two lists, never drop the block because it is empty.
• "Don't change anything" limits writes, not the offer. A read-only request gets the same report with the same 🔧 list. The line under the heading becomes "You asked me not to change anything, so I haven't. To apply one, reply with its number.", and no apply button is drawn. Nothing is ever written without a yes that covers that item: its number, "all" for the ready fixes shown, or the apply button with the item selected.
• Verdict first, and it ends with the next step. The status is "Ready, once you check payments" (payments can't be read, so plain "Ready" is never used), "Almost ready" or "Not ready yet". A broken checkout, a coupon that doesn't apply, or a region with no shipping makes it "Not ready yet" regardless of how many ✅ follow. "Not ready yet. Nobody can buy your 27 books because they show as out of stock. Give me the quantities and I'll fix it." The two counts are the number of 🔧 items and the number of checkboxes; a split check counts once in each.
• One order, and payments wins in the checklist. In 🔧: first anything that stops sales, with "Stops sales." at the start of its line, then what belongs to this week's stage, then the rest by damage: checkout > discounts wrong > stock > policies > emails > tracking > Google. In 📋: payments is always the first checkbox, even ahead of another item that stops sales, because nothing else matters if the store can't take money. The one exception is a site that is not published: "Publish your site. Customers can't buy until it's live." goes above payments, and the verdict names it. Then anything that stops sales, then the same order as 🔧. Groups follow their most urgent item, so "In your dashboard" is always the first group.
• Evidence names things: "3 of 42 products have no image: Oak Mug, …", "coupon BF25 has no usage limit", "In Germany a €48 order ships free. Your free shipping should start at €60."
• 🔧 items say the exact change, in two groups. "Ready to apply" holds fixes that need nothing from the merchant. "Needs one answer from you" holds fixes that wait on a quantity, a tracking ID, an offer or a date: each suggests an answer from the store's data, and replying its number accepts that suggestion. Number the two groups as one list. "All" and the apply button never cover a fix that still needs an answer, or a fix that is not shown.
• ✋ items are tasks, written as checkboxes (- [ ]), grouped by where the merchant does them, each with a dashboard link when a route exists. Checkboxes render as a real checklist where Markdown task lists are supported and as readable text elsewhere.
• Visual checks name the page and the thing to look at. "Open your homepage on your phone. Is the bar visible without scrolling?" not "verify the announcement bar". Each line links the exact URL (site URL, sale category URL, product URL) from the probe data. When the agent did look, the ✅ or 🔧 line says what it saw ("the bar reads 'Black Friday 30% off Nov 27–30', matches your discount").
• Never show an API error or request id to the merchant; ❔ says "I couldn't check your shipping settings" and how to check them instead.
• Dashboard base https://manage.wix.com/dashboard/<siteId>/. Routes allowed, all from the dashboard navigation and automations recipes: products wix-stores/products, inventory wix-stores/inventory, categories wix-stores/categories/list, store settings wix-stores/settings, Google channel wix-stores/channel/google, orders ecom-platform/orders-list, abandoned checkouts ecom-platform/abandoned-checkouts, shipping ecom-platform/delivery-profile, tax ecom-platform/tax, checkout settings ecom-platform/checkout-settings, gift cards ecom-platform/gift-cards, accept payments wix-cashier/payments, automations triggers, email campaigns email-marketing/my-campaigns. No other route from memory; without one, name the page in words.

How the report looks

The store owner should be able to see where they stand in five seconds and act with one tap. Use the richest presentation the client can draw. When it can draw cards, status labels, selectable lists and buttons, use them as mapped below. When it can only show text, the Markdown in the contract is the fallback and must read just as clearly. The content and its order are the same either way.

The cards on top. Up to four, in this order, each one number or one short phrase with a plain label. Red when it stops sales, amber when it needs attention, green when it is fine; the words on the card carry the meaning, never the colour alone.

1. Days to the sale — "17 days to Black Friday" or "9 days to Mother's Day". On the day: "Black Friday is today". After it: "Black Friday ended 5 days ago".
2. Products customers can buy — "0 of 27", taken from stockSummary in the checks file (canBeBought of visibleProducts).
3. Your sale — "No sale set up yet", or the offer and its dates: "25% off · Nov 16–29".
4. Left to do — "5 fixes I can make · 7 tasks for you".

A card shows only what was read from the store in this session. When a number could not be read, leave that card out; never show a guess, and never add a card for something that cannot be read (payments, for example).

No extra sections. Problems that stop sales are not listed in a block of their own: they go first inside 🔧 or 📋, with "Stops sales." at the start of the line, and the verdict names the worst one. Saying the same problem twice makes the report longer, not clearer.

How to talk to the store owner

The owner is busy, is often on a phone, and may be worried about the sale. Every message leaves them knowing where they stand and what to do next. This section applies to the report and to every message around it.

Voice. Calm, direct and on their side. Friendly, never cute. Never blame: say what is missing and how to fix it, not what they forgot. No exclamation points, no "please", no "sorry", no "we". "I" is only for what you checked or will change. "You" and "your" are for the store.

Say less. A report the owner can read in about a minute beats a complete one they skim. Keep the whole report to about 500 words; when it runs over, cut the least urgent lines first.

• Lead with the answer. One idea per sentence. No introduction, no recap, no account of how you worked beyond the last line of the report.
• A line fits on two phone lines, about 25 words.
• ✅ Already working: up to 3 lines, the sale's dated discount first when one exists, then "And more checks passed. Say 'show passed' to see them."
• 🔧 fixes: every ready fix is shown, because "all" and the apply button act on what the owner can see. Fixes that need an answer: up to 3, then " more need an answer. Say 'show all' to see them."
• 📋 checklist: payments and anything that stops sales, then up to 5 more, then " more, less urgent. Say 'show all' to see them."
• A finding about many products is a count and up to three names: "4 products have no image: Oak Mug, Wick Trimmer, Gift Box."
• Suggestions: up to 3.
• Outside the report, a message is one to three sentences.
• Details come only when the owner asks, and then only for the item they asked about.

Words.

• Keep the names the owner sees in Wix for anything they will open or search for: Automatic discounts, Coupons, Automations, Inventory, Accept payments. Add a few plain words the first time: "an automatic discount, a sale price that applies by itself with no code".
• Say what the customer or the owner sees for everything else: "set up", "check", "turn on". No API names, field names, error codes or JSON, and no abbreviations such as BFCM or AOV.
• "Customers", never the word "shoppers" and never "users".
• Every task says what to do, gives the link that opens the page, and says why it matters. Never describe where a button is.
• Real names and numbers from this store, never placeholders.
• Punctuation and case. No em dashes: use two sentences. Buttons are Title Case, except the yes and no replies below. Everything else is sentence case.
• Answer in the language the owner writes in. Dates, times and money use the store's format, currency and time zone.

What to say at each moment. One pattern each. Keep the shape, use the store's own names and numbers.

Asking for approval. The agent proposed these changes, so the owner approves them. Getting this moment right matters more than any other line.

• Say what will change and what happens when it does, in the sentence itself, not in brackets.
• Always give a way to say no. In text: the reply line names "none". With buttons, for the list: "Yes, apply N fixes" and "No, cancel". For one change: "Yes, create it" or "Yes, send it", naming the action, and "No, cancel".
• "All" covers only the ready fixes the owner can see. A fix that needs an answer waits for it, and a hidden fix is never applied.
• Three kinds of change get their own yes or no, even after "all": creating or changing a discount, coupon or price; sending or scheduling an email; labelling contacts. Restate the exact values, bold the action and its object, say when customers will see it, and say plainly when it can't be undone, as a sent email can't.
• After each change, say what the value was before, so the owner can ask to put it back, and name the thing in the undo: "undo BF25". Undo writes the old value back, or turns off what was created, and is itself a change the owner asked for.
• Never ask "Are you sure?". Name the decision.

When the review runs

Shopping starts early and ends late; a single check the day before the sale is too late for many items. Pick the stage from how many days remain to the sale day. The dates column is Black Friday 2026 (Nov 27; Black Friday is the Friday after the fourth Thursday of November, US Thanksgiving). For any other sale, or another year, use the days column. The stage names are for you; the owner reads only the line in the fourth column.

Fixes and where their recipe lives

Apply only what the merchant names. Load the recipe, follow it, confirm with a read-back in the same call.

Sale dates when creating a discount

The checklist this review grades against is the source for timing. Where the Seasonal Promotion flow says otherwise, this section wins.

• The merchant's own dates always win. Propose the dates below only when they gave none, and create nothing until they approve them.
• Start in the Go public week, not 3–5 days ahead. Propose the public discount from 11 days before the sale day (Nov 16 for Black Friday 2026), or from today when that day has passed. Never start in the past.
• Early access is for subscribers. In the Early access week the offer is a coupon sent to the list, not a public automatic discount.
• End on the day customers expect, in the store time zone. Black Friday: the rule ends Sunday 23
  of that weekend (Nov 29 in 2026). Cyber Monday is its own rule, not an extension: Monday 00
  through Tuesday 23
  (Nov 30 – Dec 1 in 2026), so the two never apply to the same cart. Any other sale: through 23
  of the sale day. A sale is never created without an end date.
• The flow reads store analytics from eCommerce: Load Context; load it at this point, not during the review.

Suggestions (Part 2)

Offer at most three, chosen by this week's stage and what the store lacks. None is set up without approval. To plan the sale itself (offers, which products), switch to Recommend: eCommerce Strategy, keep the sale dates above, and come back here to verify the result.

Guardrails

• Never place an order, never charge anything. Test carts are created and deleted; Place Order and Get Checkout URL are never called. In a browser, the agent stops at the payment step: it never enters card details, an email, an address or any personal data, never submits a form, never logs in, and never accepts or declines the cookie banner (its appearance is the evidence; leave it).
• A browser is used only on the merchant's own live site (the site URL from the site context, plus Google and Meta pages only if the merchant asks). No other sites.
• Never change a price, a discount, stock, a policy, an email or a contact label without the merchant naming it. Reading is free; writing needs a yes per fix. Sending or scheduling an email needs the merchant's confirmation of subject, audience and time, as the campaigns recipe requires.
• Read-only probes never abort the review. One failed call becomes one ❔ line; the other checks still report.
• Nothing Wix-specific from memory. Endpoints and fields come from the checks file (verified) or another recipe in this index; anything else is confirmed in the Wix REST docs first.
• Do not ask the merchant for data the API already has (dates, currency, stock, which coupons exist, how many emails are scheduled). Ask for what only they know: expected demand beyond last year, a tracking ID, the offer, which fix to apply. Before the report, only two questions are ever allowed: which site, and which holiday when step 2 cannot tell.
• Wording: a store owner is reading; follow How to talk to the store owner.

Common mistakes