Sell Funnel Audit

Audit a live sales funnel end to end using rendered browser evidence.

This skill exists to prevent a specific failure mode: making high-severity claims from DOM trees, affordance listings, or raw HTML that do not match what users actually see after render.

When to Use

• A user asks for a sales funnel audit, booking funnel critique, or conversion-path review.
• A prior audit or external review needs verification against the live site.
• SELL-08 activation readiness needs current funnel evidence before paid spend.
• A business has changed booking UX, pricing presentation, room cards, deal routing, or Octorate handoff behavior.

Relationship to Other Skills

• meta-user-test: broad site QA and crawl coverage. Use it for full-site health audits.
• lp-sell-funnel-audit: narrow conversion-path audit focused on revenue-critical routes and handoffs.
• tools-ui-breakpoint-sweep: responsive defect sweep for selected routes. Use it when layout breakage is the main concern.
• startup-loop: consumes this audit as SELL-08 activation evidence.

Inputs

Default viewport scope for this skill is:

• mobile: iPhone-class width with touch enabled
• fullscreen: desktop viewport around 1440x900

Do not add tablet or intermediate breakpoints unless the user requests them.

Non-Negotiable Rendered Evidence Gate

Before recording any finding above Low, complete all of the following:

1. Capture rendered screenshots for each audited surface in both required viewports.
2. Exercise the flow with real navigation and clicks/taps where possible.
3. Confirm that the rendered state matches the claimed issue.

Rules:

• DOM text, affordance trees, HTML source, and network payloads are supporting evidence only.
• If a claim is based only on DOM/HTML and not on rendered state, label it Hypothesis - needs rendered verification.
• Do not call something Critical or High until the rendered state is confirmed.
• If rendered evidence contradicts an earlier claim, the rendered evidence wins.
• Wait for the rendered state to settle after hydration, redirects, and primary image/content load before judging the screen.
• Claims about visible prices, sticky CTAs, above-the-fold actions, rate-plan clarity, deal carry-through, or booking-engine summaries always require rendered confirmation.

Required Audit Scope

Unless the user narrows scope, audit these surfaces:

1. Homepage primary booking entry points
2. Deals or promo page CTA path
3. Dated booking page with room cards and rate-plan controls
4. Booking engine handoff page (for example Octorate)

For each surface, verify:

• visible price state
• CTA labeling and hierarchy
• trust signals
• date/guest persistence
• mobile above-the-fold behavior
• handoff clarity and brand continuity

Workflow

0) Write QA Inventory

Before opening the browser, list:

• the user questions to answer,
• the conversion claims you expect to make,
• the concrete surfaces and actions to verify,
• at least 2 off-happy-path checks.

Minimum off-happy-path checks:

• direct load of a dated booking URL
• click-through from deals/promo path to booking path

1) Capture Rendered Evidence First

Open the live site in both required viewports and capture:

• homepage top state
• booking-surface top state
• at least one room-card state
• booking-engine handoff top state

If a prior review is being critiqued, do this step before judging any of its claims.

2) Map The Live Funnel

Build the current funnel map from observed behavior:

Ingress -> intermediate route(s) -> dated booking state -> room/rate selection -> handoff

Use exact URLs where relevant.

3) Validate Or Reject Prior Claims

If a prior review exists, classify each major claim as one of:

• Validated
• Partially valid
• Invalid on live site
• Stale / superseded
• Unverified

Do not just summarize. Record the specific mismatch between the old claim and the current rendered evidence.

4) Write Current Findings

Focus on present-tense issues only.

Use this severity model:

• Critical: trust or transaction integrity failure on the core booking path
• High: likely conversion blocker or strong trust break with workaround
• Medium: material friction or clarity issue
• Low: polish or minor messaging issue

5) Decide SELL-08 Activation Readiness

The audit must end with one explicit activation decision:

• Pass
• Blocked

Blocked if any unresolved Critical or High finding exists on the core path in either required viewport.

6) Persist The Artifact Into The Sales Loop

Write the audit to:

docs/business-os/strategy/<BIZ>/sales/YYYY-MM-DD-<business-lower>-sales-funnel-rendered-audit.user.md

Persist screenshots to:

docs/business-os/strategy/<BIZ>/sales/artifacts/YYYY-MM-DD-<business-lower>-sales-funnel-rendered-audit/

If the business already has a standing-registry sales funnel artifact entry, update its path to the new audit so the latest evidence is discoverable by the sales loop.

Output Contract

Frontmatter (required)

---
Type: Sales-Funnel-Audit
Status: Active
Business: <BIZ>
Date: <YYYY-MM-DD>
Viewport-Scope: mobile, fullscreen
Rendered-Evidence: required
Primary-URL: <https://...>
Activation-Decision: Pass | Blocked
Activation-Blockers-High: <int>
Activation-Blockers-Critical: <int>
Review-trigger: Before SELL-08 paid activation or after any booking funnel / booking-engine change.
---

Body Sections (required order)

1. # <Title>
2. ## Scope and evidence
3. ## Executive verdict
4. ## Live funnel map
5. ## Prior review validation
6. ## Current findings
7. ## Activation readiness decision
8. ## Evidence log
9. ## Next actions

Quality Bar

• Every High or Critical finding has at least one screenshot link.
• Mobile and fullscreen are both covered.
• The audit distinguishes stale claims from current issues.
• The activation decision is explicit and backed by current evidence.
• The artifact is written into the business sales namespace, not left in chat only.