Most of them trace back to one thing: last year's support SOP quietly drifted. Here is each mistake, why it keeps happening, and the fix.
Black Friday and Cyber Monday compress a month of customer service into four days. Ticket volume runs 3 to 8 times normal, and every gap in your process gets found at once. The brands that come through with their reputation intact are not the ones with the most agents. They are the ones whose support playbook still matches how the team actually works.
Here is the pattern almost nobody names. The mistakes that wreck BFCM support are the same ones, year after year, at brand after brand. They repeat because the SOP you wrote for last year's BFCM quietly went out of date. The refund macro points at a tool you have since replaced. The staffing math is built on last year's order volume. The escalation tiers describe a team that has since changed. That gap between the documented process and the real one is SOP drift, and BFCM is where it gets expensive.
You do not need a longer BFCM playbook. You need last year's playbook to still be true. Every mistake below is a place where the documented process drifted away from reality, and the fix is to close that gap before peak, not during it.
Below are the seven that do the most damage, why each one happens, and the specific fix. Each links to the SOP that prevents it.
A BFCM support SOP is written once, usually in a hurry, right before or right after a peak. Then the year happens. You switch helpdesks or payment processors. You change your returns window. Two agents leave and three contractors join. The promo calendar looks different. None of that updates the doc, because updating documentation is the one task that never has a deadline. By the next November, the plan on paper and the way the team works have drifted apart, and the drift is invisible until volume forces it into the open.
So read the seven below as seven places to check for drift, not seven new tactics to add. If your SOP already covers them and still matches reality, you are ahead of most brands your size.
The most common way BFCM support falls over is simple: you staff to a number that felt right, or to last year's raw ticket count, and you are buried by 2pm on Black Friday. The number drifted. Your order volume grew, your tickets-per-order moved with new products or a new returns policy, and the staffing plan never caught up.
The fix is to forecast, not guess. Take last year's BFCM ticket count, multiply by your revenue growth rate, and add a 30 percent buffer for the unexpected. That number is your staffing baseline, and you need it by October 1, because everything downstream (hiring, training, scheduling) depends on it.
The full prep playbook: the forecast step, escalation tiers, and monitoring, as a template you can copy or download and adapt to your store.
An agent fires the refund-request macro and it walks through Stripe, but you moved to Shopify Payments in March. The shipping-status macro links to a tracking page that changed. During peak, agents send these hundreds of times a day, so a single broken macro is a broken experience at scale. The macro did not break on its own. The tools and policies around it changed, and nobody re-read the copy.
Audit every high-volume macro by November 1. The five that carry the most weight: shipping status, refund request, address change, item missing, and sizing question. Read the copy, test every action, and fix anything that points at a tool or policy you no longer use.
A step-by-step audit that catches the macros pointing at tools you have since replaced, before your busiest week sends them a thousand times.
Run the whole period with no way to separate BFCM tickets from your normal trend, and your December reporting becomes guesswork. Worse, next year's forecast starts from a bad number, which is how the staffing mistake in point one repeats. Tagging conventions get set once and forgotten, usually when the person who owned reporting moves on.
Create a dedicated tag, something like bfcm-2026, and apply it to every ticket in the period. It costs nothing and it is the difference between forecasting next year from data and forecasting from a feeling.
Your SOP says Tier 2 handles refunds and Tier 3 is the manager. But the manager left in the spring, and two of your Tier 2 people are new contractors who have never seen a chargeback. During a spike, unclear escalation means every hard ticket lands on the one person who still knows the answer, and that person becomes the bottleneck for the whole team.
Rewrite the tiers against the actual current team before peak. Tier 1 contractors handle standard tickets. Tier 2 in-house handles refunds, complaints, and edge cases. Tier 3 handles VIPs and anything heading for social. Name the people at each tier, not just the tier.
How to structure escalation tiers so hard tickets route to the right person instead of piling on one overloaded lead.
You hire help for BFCM and start onboarding them the week of Black Friday, so your extra hands spend the busiest days of the year learning your helpdesk instead of clearing tickets. The hiring timeline slipped, and 'we will train them when they start' quietly became 'we will train them during the fire.'
Hire by October 15 and have contractors trained in your helpdesk before Halloween. Most support agencies need a four-week ramp to be useful on your macros and policies. Training during peak is training too late.
A repeatable onboarding path so a new agent or contractor is productive in days, not the day of your biggest sale.
A delayed-shipment complaint lands on your Instagram or X during peak. By the time someone drafts a reply and chases an approval, it has been quote-tweeted. Public complaints move faster than your internal process, and the templates that would have saved you, if they ever existed, were written for a different tone, a different team, or a crisis you already handled and forgot.
Pre-write responses for the three that hit in public every BFCM: shipping delay, item not as described, and the customer who says they have been ignored. Attach a fast approval path so a reply goes out in 30 minutes, not three hours. Speed is the whole game once a complaint is public.
A customer orders on December 20 expecting delivery by the 24th, it does not arrive, and now it is a support ticket, a refund, and a one-star review, all of it avoidable. Last year's cutoff dates were in a doc nobody updated, and the carrier deadlines moved.
Publish the current carrier cutoff dates where customers actually see them: on the product and cart pages, in your email flows, and in a support macro, before December. Expectations set up front are tickets that never get created.
Where and when to publish carrier cutoff dates so late-December orders do not turn into refunds and reviews.
Every mistake above is the same failure in a different place. A process was documented once, reality moved, and the doc did not. You can patch all seven by November and still be right back here next October, because the patching is manual and the drift is constant.
The durable fix is to treat your BFCM SOP as a living document. Record the process the way it actually runs this year, so next year's plan starts from what you did rather than what you meant to do. Better still, use something that flags when the real process has drifted from the doc, so you find the broken macro and the stale staffing math in October, not on Black Friday.
The mechanism behind all seven mistakes: how documentation goes stale within 90 days, and how to catch it before it costs you a customer.
Forecast volume and start hiring by October 1, and finish contractor training by Halloween. Audit macros and rewrite escalation tiers by November 1. Preparing in November is too late, because contractors need roughly a four-week ramp to be useful during peak.
For most DTC brands, ticket volume runs 3 to 8 times normal over roughly 96 hours, depending on category, promo aggressiveness, and shipping performance. Forecast from your own last-year numbers rather than a rule of thumb.
Forecasting volume early enough to hire and train contractors before peak. Every other fix assumes you already have enough trained people at the desk.
Probably not a full one. Your normal team can usually absorb the spike. Above roughly $5M ARR, lock the SOP down by October, because at that scale a single bad peak experience gets posted publicly and follows the brand.
SOP drift is the gap between what your documentation says and what your team actually does. It is why the same BFCM mistakes repeat every year: the playbook was written once, then tools, policies, and the team changed, and the doc did not keep up.
I built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed July 24, 2026
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
Macros silently break. Customers notice before you do. Here's the audit that catches broken macros before CSAT slides.
A new agent's first month sets their ceiling. A documented onboarding is how you raise it.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.