Escalation & Stop-Work Policy

QCK SOP

Escalation & Stop-Work Policy

QCK WordPress Infrastructure & Dev Governance Framework

Version
Version 1.0
Owner
Dev Lead + Operations
Focus
Escalation, risk controls, and controlled execution

1️⃣ Purpose

This policy defines when technical risk requires escalation or controlled pause before work proceeds.

Escalation does not mean refusal. It means:

  • Risk documented
  • Leadership informed
  • Stabilization path proposed
  • Timeline adjusted appropriately
This policy protects QCK from preventable instability and inherited infrastructure liability.

2️⃣ Red Risk Triggers

Immediate escalation is required if any of the following are present:

  • Master Risk Score = Red (13+)
  • No staging environment for structural changes
  • Unsupported or abandoned critical plugin
  • Headless architecture without repository access
  • Rewrite rule uncertainty affecting indexed URLs
  • No confirmed backup prior to deployment
  • Multiple caching layers with no visibility
  • Design Lock not confirmed before development begins
  • Permalink changes affecting high-traffic ranking URLs
If any trigger is present, Dev must notify the AM before proceeding.

3️⃣ Headless Escalation Protocol

If the site uses headless architecture:

  • Repository access confirmed
  • Deployment workflow documented
  • Build pipeline understood
  • Hosting environment identified
  • Rollback plan confirmed

If repository access or deployment clarity is missing:

  • Dev does not modify live structure
  • Escalate to leadership
  • Recommend stabilization phase
  • Require documentation before proceeding
Headless environments cannot be treated like traditional WordPress themes.

4️⃣ Unsupported Plugin Escalation

If a plugin is classified as 🔴 Red, escalation is required.

Typical Triggers

  • No updates in 12+ months
  • Marked incompatible with current WordPress
  • Custom undocumented code
  • Security vulnerabilities
  • Critical WooCommerce override conflicts

Required Action

  • Document plugin risk
  • Notify AM
  • Present options to the client

Option A

Replace plugin

Option B

Controlled refactor in staging

Option C

Proceed under Limited Infrastructure Scope

Dev must not modify unsupported plugin logic in production.

5️⃣ No Staging Policy

Structural changes include:

  • Permalink changes
  • CPT creation
  • Template overrides
  • WooCommerce checkout modifications
  • Major CRO experiments

If no staging environment exists, the following options should be considered:

Option A

Client provides staging

Option B

Temporary staging created

Option C

Controlled deployment window defined

Option D

Proceed under Limited Infrastructure Scope

If none of the above are possible and risk is high, Dev may recommend stop-work until the environment is stabilized. No structural change should be blindly introduced into production.

6️⃣ Limited Infrastructure Scope Rules

Limited Infrastructure Scope applies when:

  • Hosting access denied
  • CDN visibility denied
  • Server configuration unknown
  • No staging available
  • Backup system not confirmed

Under Limited Scope:

  • Dev operates only at application layer
  • No server-level guarantees
  • Redirect behavior depends on unknown configuration
  • Cache performance cannot be guaranteed
  • Rollback depends on client infrastructure
AM must document Limited Scope acknowledgment. This protects QCK from assuming server-level liability.

7️⃣ Stop-Work Authority

Stop-Work may be recommended if:

  • Structural risk is extreme
  • Deployment safety cannot be confirmed
  • Rewrite logic is unclear
  • Backup is not verified
  • Client declines all stabilization options
  • Red Risk Score with no mitigation

Stop-Work means:

  • Pause structural changes
  • Document risk
  • Align leadership
  • Propose stabilization phase
Stop-Work does not mean project termination. It means controlled execution.

8️⃣ Escalation Communication Template (Internal)

Subject: Escalation — Infrastructure Risk Identified

Client: __________________

Project: __________________

Trigger Identified: __________________

Risk Summary:

__________________

Recommended Action:

__________________

Timeline Impact:

__________________

9️⃣ Escalation Communication Template (Client)

Hi [Client Name],

During our technical review, we identified infrastructure constraints that increase implementation risk.

Before proceeding with structural changes, we recommend addressing the following:

  • __________________
  • __________________

Our goal is to protect stability, SEO integrity, and long-term performance.

We will proceed carefully and align on next steps.

Tone: Measured. Protective. Non-alarmist. Professional.

🔟 Governance Philosophy

Escalation exists to:

  • Protect rankings
  • Protect revenue
  • Protect conversions
  • Protect timelines
  • Protect team morale
Unchecked risk compounds as QCK scales. Disciplined escalation enables sustainable growth.

1️⃣1️⃣ Final Rule

Responsibility is shared, but clearly defined:

Dev

Responsible for identifying structural risk

AM

Responsible for expectation alignment

Leadership

Responsible for final go/no-go decision when Red triggers exist

Clarity prevents chaos.