Why most launch checklists fail
Not because they are missing items. Because nobody owns the items. A checklist with twelve unassigned tasks is a list of things everyone assumes someone else is doing, and on launch morning you discover the overlap was smaller than you thought.
Every item below has a role attached. Change the roles to real names before you use it.
Seven days out
- Confirm the actual stock number: Ops. Not the Shopify number: the number after you subtract damaged units, pre-orders, and anything committed to a wholesale order.
- Set the stock floor and who can breach it: Founder. A number, and one name. Write it down where the team can see it.
- Agree the dispatch promise with the warehouse: Ops and Warehouse together. Support cannot invent this on the day.
- Write the support macro using that promise: Support. Exact wording, approved in advance.
Two days out
- Staff the warehouse for the window: Warehouse lead. Including the two hours after the sale ends, which is when the picking actually happens.
- Check the ad creative points at the right SKUs: Paid media. Surprisingly often it does not.
- Set the pause trigger and permission it: Paid media and Ops. Whoever watches stock must be able to pause spend without asking.
- Lower your alert thresholds for launch products: Ops. A threshold of 10 is useless when you sell 14 an hour.
Launch morning
- Open the room and pin the two decisions: Founder. Stock floor and support promise, at the top, visible.
- Assign the four watchers: Ops. Stock, spend, queue depth, and the floor. Four numbers, four names.
- Confirm everyone can actually see the counter: Ops. Someone always cannot, and it is always the person watching stock.
- Set a hard time for the post-launch reconcile: Founder. One hour after sell-out, before anyone leaves.
Number 12. The reconcile is where you catch oversells while they are still cheap to fix. Skip it and you find them on Thursday, in a customer email, after the parcel has shipped.
After the launch
Write the recap the same day. Not a retro. A recap. What sold, what ran out first, what the queue peaked at, and which of these twelve items you skipped and got away with. The next launch is a copy of this document with the wrong assumptions corrected.
We wrote more about the day itself in how to run a flash sale without losing your team.
Why launch checklists fail
Almost every store has rebuilt this list from memory at least once, which is the tell. The list existed, it was not findable, so somebody made a new one under time pressure and left things out.
Three failure modes account for most of it.
The list has no owners. Twelve items and one implied person, usually whoever wrote it. Under pressure that person becomes the bottleneck for all twelve.
The list is aspirational. It contains what a well-run launch would include rather than what your store actually does. Items nobody has ever completed get skipped, and skipping trains people to treat the whole list as optional.
It lives somewhere nobody opens. A document in a drive, findable only by someone who remembers it exists. If it is not where the launch conversation is happening, it does not exist on launch day.
Assigning the items properly
Every item needs a name and a time, and the time should be relative rather than absolute: "the day before" survives a date change, "Thursday" does not.
Where two people could plausibly own something, decide now. Launch day is the worst possible moment to discover that both of you assumed the other had checked the discount codes.
The items most often left unowned are the boring ones: confirming stock depth on the hero product, checking the discount code scope, making sure whoever answers customers knows what is launching. None are difficult and all are expensive when missed.
The rehearsal
An hour, a few days out, spent placing a real order end to end. Use a real card, apply the discount, let it flow through to fulfilment, then refund it.
This catches the category of problem no checklist finds, because it tests the interaction between things rather than each thing separately. A discount that works, and a shipping rule that works, can still combine into an order that ships free when it should not.
It also gives whoever handles customer messages a concrete picture of what buyers will see, which is worth more than any briefing.
After the launch
Update the list the same week, while you still remember what was missing. This is the step that turns a checklist into an asset rather than something rebuilt from scratch every time.
Two questions: what did we do that was not on the list, and what was on the list that turned out not to matter? Add the first, cut the second. A list that only grows becomes one nobody finishes.
The twelve, and why each one is there
Rather than reproducing a generic list, here is the reasoning that decides whether an item belongs on yours.
Stock and variants. Depth checked at variant level, not product level, on everything featured. This single item prevents the most common launch failure.
Discount scope. What the code applies to, what it stacks with, and when it expires. Code errors are silent and expensive, and they are only visible after money has moved.
Shipping rules. Particularly any free-shipping threshold interacting with the discount. The two together produce outcomes neither produces alone.
The purchase test. A real order, end to end, refunded afterwards.
Customer-facing briefing. Whoever answers messages knows what is launching, what it costs, and what to say when it sells out.
Fulfilment capacity. Someone has confirmed the volume can actually be picked and collected on the day.
The rest are store-specific. The test for adding one is whether it has ever gone wrong for you, not whether it appears on somebody else's list.
Deciding what happens when it sells out
The decision nobody makes in advance and everybody makes under pressure.
Before launch, agree what the product page does when stock runs out, who pauses the ads, and what customers are told about restocking. Write the three answers down with names against them.
This costs ten minutes beforehand and saves an hour of confused messages during the launch, which is exactly when the hour is least available.
The day itself
A checklist covers preparation. Launch day needs a different, much shorter thing: who is watching what, and when.
Name one person watching stock, one watching customer messages, and one able to change the site. On a small team that may be two people wearing three hats, which is fine as long as it is stated rather than assumed.
Agree three checkpoints rather than continuous monitoring. An hour in, mid-afternoon, and end of day. Continuous watching sounds diligent and produces people refreshing dashboards instead of working.
Agree in advance what triggers a change: at what stock level something comes out of the email, at what point ads pause, who makes the call. Decisions made calmly beforehand are better than decisions made at eight in the evening.
The week after
Thirty minutes, and it is the difference between a checklist that improves and one that gets rebuilt annually from memory.
Three questions. What did we do that was not on the list? What was on the list that did not matter? What did we find out too late?
The third is the valuable one. Something that was true all along and reached you at four in the afternoon is usually a monitoring gap rather than a preparation gap, and it points at what to watch next time rather than what to add to the list.
Update the document the same week. Anything left for later gets written from a version of the launch that memory has already tidied up.
Common questions
How far ahead should a pre-launch checklist start?
Most items sit in the final week, with stock decisions earlier because they have a lead time. Anything requiring an order from a supplier has to be resolved before the rest of the list is useful.
Who should own the checklist?
One person owns the list; individual items have their own owners. A list owned by everybody gets partially completed by several people who each assume the rest is covered.
Should we test the full purchase flow before launch?
Yes. Place a real order with a real card, apply the discount, follow it to fulfilment, then refund it. This catches interaction problems that checking each element separately never will.
What gets forgotten most often?
Discount code scope, stock depth at variant level, and telling whoever answers customers what is launching. All three are unglamorous and all three cost real money.
How do we stop rebuilding the list every time?
Update it in the week after launch, while the gaps are fresh, and keep it where the launch conversation happens rather than in a folder someone has to remember.