Landing Page Approval Process — Process Failure & Resolution

Overview

In January 2026, Blue Point client Wade discovered live landing pages he claimed had never been approved. Investigation revealed this was a process failure, not a policy violation — the team incorrectly assumed that a single edit request on one page constituted implicit approval for all pages in the batch. The incident was compounded by typos and content errors on the live pages.

See also: ^[1]

What Happened

Timeline:

1. September — Melissa sent a set of landing pages to Wade for review.
2. Wade responded with one edit request: a change to the PMAX page.
3. The team made the requested edit and assumed silence on the remaining pages meant approval.
4. October — All pages were pushed live without explicit sign-off.
5. January (call) — Wade discovered the live pages while Googling a keyword, and raised the issue at the end of an otherwise positive call.

Compounding factor: The live pages contained typos and content errors, which gave Wade legitimate grounds for frustration beyond the approval process question alone.

Root Cause

"The breakdown is he didn't explicitly say, 'these are all ready to go.'"
— Karly Oykhman

The team operated on an implicit assumption: one edit request acknowledged = all other pages approved. This assumption was never validated with the client. The policy (no work goes live without client approval) was correct; the execution failed to enforce it.

This was not a rogue publish or a policy bypass — it was a gap in how approval was interpreted and tracked across a multi-page batch.

Resolution

• Immediate: Karly took the pages offline and emailed Wade a full timeline explaining what happened.
• Communication framing: The email acknowledged the process gap without being defensive — it documented the September send, the single edit received, and the October launch, and confirmed pages were now offline pending review.
• Policy reinforcement: Going forward, explicit written approval is required before any landing page goes live. A single edit response on one asset does not constitute approval for a batch.

Wade had not responded to the follow-up email at the time of this sync. The broader client relationship remained positive — the call prior to the discovery had gone well, and the New York campaign work was being well received.

Key Decisions

• Pages taken offline immediately upon discovery of the dispute.
• Explicit written approval required for all future launches — no implicit approval from partial feedback.
• Karly to manage the client relationship directly; Melissa (who owned the account originally) is accountable for the original process gap.

Action Items

• [x] Karly emailed Wade the timeline and confirmed pages are offline (completed prior to sync)
• [ ] Wade to review the pages and provide explicit approval or revision requests before relaunch

Lessons & Process Changes

This incident surfaces a recurring risk when managing multi-asset review cycles with clients:

• Partial feedback ≠ full approval. When a client responds to one item in a batch, the remaining items remain in an unresolved state.
• Approval must be explicit and documented. A written "these are approved" or equivalent is required before launch — not inferred from silence.
• QA before client send. Typos on client-facing pages should be caught internally. Pages with errors should not reach the client review stage, let alone go live.

See also: ^[2] for the updated approval policy.