BFCM pricing changes touch products, collections, marketing, feeds, and customer support at the same time. The goal is not to make a catalog change instantly. The goal is to make the change understandable, reversible, and observable.
Before the campaign
- Freeze unrelated catalog edits while the promotion is being prepared.
- Export original prices, compare-at prices, variant IDs, and SKUs.
- Confirm which collections and variants are included and excluded.
- Test discount rules on a small set of products.
- Review the planned changes before scheduling.
- Confirm the store timezone and exact start and end times.
- Assign an owner for launch monitoring and rollback decisions.
During launch
Watch the first batch instead of assuming the entire catalog changed correctly. Check a product page, collection page, cart, mobile storefront, and any important sales channel. Keep the export and snapshot accessible to the person on call.
Bulk updates on a large catalog may roll out over time. Make the expected timing visible to the team and avoid starting another price job while the first one is still running.
After the campaign
- Verify restored prices across every included collection.
- Check a sample of excluded products for accidental changes.
- Compare the final state with the original export or snapshot.
- Save an incident note for every manual correction.
- Do not uninstall the sale tool until recovery is complete and the backup is stored.
During the BFCM freeze
Avoid shipping unrelated code changes during the peak campaign window. Keep a rollback decision tree, support contact, and a copy of the restore file ready. A short, boring runbook is more useful than a last-minute improvisation.
SaleGuard is intended for stores that want the backup and restore plan ready before BFCM pricing changes go live. It combines an original-price snapshot, a dry-run preview, scheduled changes, automatic restore, and rollback controls in one workflow.
Boundary
SaleGuard cannot edit prices after its Shopify access is revoked by uninstall. The merchant-owned CSV backup remains the fallback and should be stored independently.