103 lines
3.9 KiB
Markdown
103 lines
3.9 KiB
Markdown
---
|
|
artifact: B
|
|
name: Strategy and Remediation Brief
|
|
layer: 3+
|
|
client: ""
|
|
date: ""
|
|
linked_artifact_a: ""
|
|
status: draft | qa | approved
|
|
---
|
|
|
|
# Artifact B — Strategy and Remediation Brief
|
|
|
|
Purpose: Translates threat-register-v1.md findings into capacity/ticket-weighted priority, revenue scenarios, package recommendation, and measurement windows. Prescriptive by design — this is the one place solution/recommendation language belongs. Does not restate requirements-v1.md or workflows-v1.md content — see §4 Feed-Forward.
|
|
|
|
---
|
|
|
|
## 1. Diagnostic Inputs
|
|
|
|
- Linked Artifact A:
|
|
- Audit ID:
|
|
- Audit date:
|
|
- Prompt library version:
|
|
- Engine set version:
|
|
- Competitor set version:
|
|
|
|
---
|
|
|
|
## 2. Capacity and Economics
|
|
|
|
- Capacity state:
|
|
- Capacity details:
|
|
- Average ticket size:
|
|
- High-ticket services:
|
|
- Desired lead type:
|
|
- Revenue-at-risk language approved by:
|
|
- Revenue-at-risk approval date:
|
|
|
|
Revenue-at-risk language rules: never "you are losing $X/month," "this defect costs you N customers," or "will guarantee more bookings." Use scenario framing only: *"If a business receives N additional qualified calls per month and average ticket size is $X, that represents $Y in potential monthly revenue. This is a scenario for discussion, not a forecast."* Human review required before any figure ships.
|
|
|
|
---
|
|
|
|
## 3. Opportunity Matrix
|
|
|
|
| Evidence ID | Finding | Severity (from threat-register-v1.md) | Capacity fit | Ticket impact | Priority | Feeds into |
|
|
|---|---|---|---|---|---|---|
|
|
| | | | | | | |
|
|
|
|
Priority values: Fix Now / Fix Soon / Monitor. This is a remediation-planning property (how urgent is the fix, weighted by capacity and ticket size) — distinct from Severity (how bad is the problem, lives in threat-register-v1.md). "Feeds into" references the corresponding entry ID in requirements-v1.md or workflows-v1.md — this matrix is the capacity/ticket-size economic weighting layer, not a duplicate action list.
|
|
|
|
---
|
|
|
|
## 4. Feed-Forward
|
|
|
|
Actions themselves — trigger, step sequence, owner, effort, approval gate — are not restated here. They live in:
|
|
|
|
- `docs/clients/<client>/requirements-v1.md` (Layer 4) — outcome-statement requirements, linked to Threat ID, band-ceilinged.
|
|
- `docs/clients/<client>/workflows-v1.md` (Layer 5) — trigger, step sequence, data dependencies, failure path, cadence.
|
|
|
|
This file's Opportunity Matrix (§3) is the bridge: it takes threat-register findings and weights them by capacity and ticket size before they become a requirement or workflow. It does not itself define the fix.
|
|
|
|
---
|
|
|
|
## 5. Revenue-at-Risk Scenario
|
|
|
|
- Assumption set:
|
|
- Scenario calculation:
|
|
- Conservative interpretation:
|
|
- What this is not:
|
|
|
|
---
|
|
|
|
## 6. Package Recommendation
|
|
|
|
- Recommended package (Get Found / Stay Found / Custom):
|
|
- Reason (must tie to evidence, not general pitch):
|
|
- Included workstreams:
|
|
- Excluded workstreams:
|
|
- Assumptions:
|
|
- Client decision required:
|
|
|
|
Example acceptable framing: *"Because the audit shows multiple verified entity defects and competitive visibility gaps across high-intent prompts, the recommended path is Get Found followed by Stay Found monitoring after the remediation sprint."* Avoid copy that implies guaranteed lift (e.g. "Get Found gets you found" vs. "Get Found addresses verified entity defects").
|
|
|
|
---
|
|
|
|
## 7. Measurement Window
|
|
|
|
- Baseline artifact:
|
|
- First re-measurement window (default 30 days — early signal):
|
|
- Second re-measurement window (default 60 days — first meaningful comparison):
|
|
- Third re-measurement window (default 90 days — reliable trend):
|
|
- What will be measured:
|
|
- What will not be promised: *"We do not promise exact improvement dates. AI engines and directories update at different speeds. We will measure at defined intervals and report what changed."*
|
|
|
|
---
|
|
|
|
## 8. Approval Gates
|
|
|
|
- Human owner approval:
|
|
- Client approval:
|
|
- Data-sharing permission confirmed:
|
|
- Live-change permission confirmed:
|
|
- Brand voice constraints confirmed:
|