Production launch checklist

A customer can see exactly what must be connected before launch.

Used by internal operators and client stakeholders to verify production readiness.

Included in: Professional

What the customer uses

A usable piece inside a launched package.

Database, queues, billing, live sends, domain, auth, and monitoring checklist.

How it is produced

What powers it in the deployed product.

Reads the same production readiness facts surfaced by /api/production-readiness.

Done when

This is how you know the deliverable is complete.

Every launch dependency is visible.
Current configured/not-configured state is not hidden.
The customer knows the next action.

Implementation guide

Production launch checklist is a working building block inside a complete Lead OS solution. It exists so the business buyer can understand exactly what was created, how it is used, and how completion is verified.

Start here

Read the buyer outcome first.
Confirm whether the block is B2B internal or B2B2C customer-facing.
Review the delivered artifact and backend reality before using the example.
Run or inspect the live example on this page.

Implementation steps

Use the block inside a package workspace, not as a disconnected asset.
Match the block to the client success metric before presenting it as value.
If the block touches downstream customers, verify the copy, consent, routing, and escalation expectations.
If the block depends on live account access, use safe sample or managed-handoff mode until approved access exists.
Document the next operator action in the client delivery hub.

Operating workflow

Capture or inspect the input.
Produce the visible artifact.
Route the result to the correct business or customer-facing next step.
Measure the result against the acceptance criteria.
Improve the package workflow if the artifact does not advance the promised outcome.

If unclear or blocked

If the artifact looks like a sample, treat it as a demo until connected package data is present.
If the next action requires a client-owned account, do not represent it as live until approved access exists.
If the block does not map to the selected package outcome, return to the package delivery hub.
If the customer cannot tell what to do next, use the implementation steps and acceptance checklist before handoff.

Next milestones

Today: confirm the block exists and the acceptance criteria are visible.
This week: connect it to a package workspace or run a sample scenario.
This month: use reporting evidence to decide whether the surrounding package should be optimized, expanded, or bundled.

Dependency	Current state	Launch action

This checklist is generated from the same public production readiness truth.

Loading…

Implementation steps

Use the block inside a package workspace, not as a disconnected asset.

Match the block to the client success metric before presenting it as value.

If the block touches downstream customers, verify the copy, consent, routing, and escalation expectations.

If the block depends on live account access, use safe sample or managed-handoff mode until approved access exists.

Document the next operator action in the client delivery hub.

If unclear or blocked

If the artifact looks like a sample, treat it as a demo until connected package data is present.

If the next action requires a client-owned account, do not represent it as live until approved access exists.

If the block does not map to the selected package outcome, return to the package delivery hub.

If the customer cannot tell what to do next, use the implementation steps and acceptance checklist before handoff.