---
title: Landing Page Approval Process — Process Failure & Resolution
type: article
created: '2026-04-05'
updated: '2026-04-05'
source_docs:
- raw/2026-01-22-impromptu-zoom-meeting-116338672.md
tags:
- client-blue-point
- landing-pages
- approval-workflow
- process
layer: 2
client_source: BluepointATM
industry_context: b2b-services
transferable: false
---

# 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: [[wiki/clients/current/bluepoint/_index]]

---

## 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: [[wiki/processes/client-approval-workflow]] for the updated approval policy.