Launch checklist template

A launch checklist is one row per check. Each row says what is being confirmed, why it matters, who does it, when it is due, whether the launch may proceed without it, how it is verified and what evidence is kept.

The last three columns are the ones that make it a checklist rather than a list. A check with no verification method is a reminder; a check with no evidence cannot be relied on a month later; and a list where everything blocks is a list that will be overridden the first time somebody is in a hurry.

Use it before every campaign that involves more than one person or more than one system. The value is not in the obvious rows — somebody would have checked the budget anyway — it is in the three or four rows that only one person knows about and that person is on leave.

Use it again afterwards, to add the checks you wished you had had.

Most launch checklists are written as though the risk were forgetfulness about obvious things. It is not. Nobody forgets to set a budget.

What actually goes wrong is specific and local: a tracking parameter that only works on one of three landing pages, a payment method that expires next week, an ad account that loses access when somebody's contract ends, a page that does not exist yet in one market, an approval that takes three days and was requested yesterday. Every one of those is known to exactly one person, and the point of the document is to get those facts out of that person's head and into a row before they take leave.

That reframes what a good checklist looks like. The obvious rows are there for completeness; the rows that earn the document are the ones somebody added the morning after something went wrong.

The check column has to be written as something a person can do, and then answer.

Tracking works is not a check. Complete a real conversion end to end and confirm it appears in the reporting within an hour with the right campaign attached is a check. The first can be ticked by anybody who believes it is fine; the second cannot be ticked without doing it.

The how-to-verify column carries the specific action, which matters because two people will otherwise check the same row in different ways. It also makes the list usable by somebody new, which is most of its value at three in the afternoon on a launch day when the person who normally does it is unavailable.

The blocking column is where most checklists quietly fail, by marking everything as blocking.

That feels safe and is the opposite. The first time a launch has to happen despite an incomplete row — and it will, because a deadline is real — the entire list is overridden at once, and the three rows that genuinely should have stopped it are overridden with everything else. After that the list has no authority at all.

So keep the blocking set small and defensible. Broken measurement usually blocks, because the spend produces nothing usable. Missing approvals usually block. A landing page that does not exist blocks. A second creative size that is not ready usually does not: start without it and note the gap.

Each row carries a due date relative to the start, not an absolute one, so the list can be reused.

The ordering matters more than it looks. Checks that depend on somebody else — an approval, an access request, a page deployment, a payment method — belong a week out, because they have queues in front of them. Checks that only need you belong closer. And a handful belong on the morning of, because they can change: the budget is actually in the account, the creative is actually approved by the platform, the page is actually live.

A list sorted by due date is a schedule, and a schedule is something a person can work through. A list sorted by topic is a document somebody reads once.

The evidence column is what makes the checklist useful after the launch rather than during it.

A tick records that somebody believed something. A screenshot with a timestamp, a reference number, a link to a message, a copy of the approval — those record what was actually true. The question you eventually have is not whether the box was ticked; it is whether the check was done properly or done at speed while three other things were happening.

It also protects the person who did the work. A campaign that goes wrong for a reason outside the checklist is much easier to diagnose when the rows that were checked have evidence behind them.

The verified-on column exists because launches move.

A check completed three weeks before a delayed launch is a check worth doing again: access changes, pages get redeployed, budgets get spent elsewhere, approvals lapse. With a date on every row, the stale ones are visible in a glance; without one, a delayed launch inherits a list of green ticks that describe a world three weeks ago.

A simple rule works: any blocking row verified more than a week before the new start date is reset.

The last column is the notes, and it is where the next version of the list comes from.

After every launch, spend ten minutes adding the rows you wished you had had and deleting the ones nobody used. A checklist that is never edited is one that describes the launches of two years ago; one that is edited each time converges on the things that actually go wrong in your systems, with your people, on your platforms.

That accumulated list is the asset. Any team can copy a generic checklist; only yours knows which three rows matter most in your account.

Seven checks on the checklist itself. Every row has an owner by name and a due date relative to the start. Every row says how it is verified. The blocking rows are few enough that blocking still means something. Every completed row has evidence attached. Rows that do not apply have been deleted rather than marked. No blocking row was verified so long ago that it might no longer be true. And the list was updated after the last launch with what was missing.