Landing Page Approval Process — Best Practices

Core Rule

Never launch a landing page without explicit written approval from the client. Silence, partial feedback, or a single edit request on one page does not constitute approval for all pages in a batch.

The Failure Pattern to Avoid

The Blue Point incident illustrates a common and costly process failure:

1. Multiple landing pages were sent to the client for review
2. The client responded with one edit request on a single page (the PMAX page)
3. The team made that edit and interpreted the lack of further feedback as implicit approval for all pages
4. Pages launched with unreviewed content — including typos and copy errors
5. The client discovered the live pages by accident and escalated

The root cause was assumed approval, not a deliberate policy violation. The fix is procedural: approval must be explicit, not inferred.

Required Approval Workflow

Before Launch

• [ ] Send all pages to the client with a clear request for written sign-off
• [ ] Specify that each page requires approval, not just the batch as a whole
• [ ] Do not interpret an edit request on one page as approval for others
• [ ] Do not interpret silence as approval — follow up if no response is received
• [ ] Obtain explicit written confirmation (email is sufficient) before any page goes live

Confirmation Language

When following up, use clear language such as:

"Please confirm you've reviewed all pages and are happy for us to proceed with publishing. We won't go live until we hear back from you."

After Approval

• Document the approval (email thread, timestamp) in the client's project record
• Reference the approval if any dispute arises post-launch

Quality Gate Before Sending for Review

Before pages are sent to the client for approval, the team is responsible for:

• Proofreading all copy for typos and grammatical errors
• Verifying content accuracy against the brief
• Checking that all images are correct and non-duplicated
• Confirming that social proof, testimonials, and other required sections are present

Sending pages with errors to a client for review undermines trust and creates unnecessary friction — even if the client was already going to review the content.

Communicating a Process Failure to a Client

When a page goes live without proper approval, the recommended response is:

1. Acknowledge the timeline honestly — show the client what was sent and when
2. Own the process gap — explain that the team assumed approval from partial feedback, and that this was an error in process, not intent
3. Take immediate corrective action — take the pages offline while review is completed
4. Restate the policy — confirm in writing that no future pages will go live without explicit written approval

Example language used in the Blue Point resolution: "We sent the pages in September, received feedback on one item which we completed, and received no additional edit requests, so we launched in October. Moving forward, per our policy, we won't move anything live without explicit written permission."

Related Incidents

• ^[1] — Blue Point landing page dispute (January 2026): pages launched in October after team assumed approval from a single PMAX edit request. Pages contained typos. Client discovered them live via a Google search.

See Also

• ^[1]
• ^[2]