Build full client lifecycle document

This commit is contained in:
2026-07-24 06:06:00 +00:00
parent 2aa61c4b5a
commit a7484be219
+307 -113
View File
@@ -1,52 +1,192 @@
# Client Lifecycle
## Overview
## Purpose
The client lifecycle defines the end-to-end journey from first contact through ongoing engagement, renewal, and offboarding. Every stage preserves the reconnaissance-versus-execution rule and evidence-tier discipline.
This document defines how a local business moves through the Digital Operations Partner service from first contact through assessment, proof-of-concept, retainer conversion, ongoing monitoring, renewal, expansion, or offboarding.
**Reconnaissance-versus-Execution Rule:** Agents may detect and draft. Humans approve before publish. This rule applies at every stage where an agent proposes a client-facing change.
The lifecycle exists to connect the business mission, value creation model, evidence model, go-to-market strategy, and operating rules.
**Evidence-Tier Rule:** Verified Evidence (concrete, timestamped, observable) may be presented as confirmed issues. Indicative Evidence (sampled, directional, probabilistic) must be presented as directional risk or opportunity, not confirmed customer loss. Ambiguous findings default to Indicative Evidence unless upgraded by human review. Rejected Verified Evidence classifications default to Indicative Evidence unless the reviewer discards the finding or requests additional evidence.
The service is designed around a proof-of-concept-first motion: demonstrate concrete value, then offer ongoing monitoring and optimization.
---
## Stage 1: Prospect
## Lifecycle Overview
Initial identification of a potential client. No engagement yet. May come from referral, inbound, outbound, or partner channel.
The standard client lifecycle is:
**Activities:**
- Fit assessment against ideal client profile
- Preliminary digital presence scan (public signals only)
- Decision: qualify or disqualify
**Output:** Qualified prospect record or disqualification note.
1. Prospect
2. Qualification
3. Initial Assessment
4. Evidence Classification
5. Proof-of-Concept Fix
6. Before/After Report
7. Retainer Offer
8. Ongoing Monitoring
9. Monthly / Periodic Reporting
10. Renewal / Expansion
11. Cancellation / Offboarding
---
## Stage 2: Initial Assessment
## 1. Prospect
Structured diagnostic of the prospect's digital pathways affecting discovery, trust, and customer action.
A prospect is a local service business that may be silently losing customers because of digital visibility, trust, representation, or engagement issues.
**Activities:**
- AI visibility assessment (search + AI-assisted discovery)
- Customer Path Integrity review (GBP, website, booking, contact, citations)
- Local entity consistency check
- Competitor baseline snapshot
- Evidence collection following evidence-tier rules
Prospects may come from:
**Output:** Initial Assessment Report — findings categorized by evidence tier, prioritized by impact and fixability.
- Warm referrals
- Local business relationships
- Direct outreach
- Existing owner networks
- Case studies
- Before/after proof from previous clients
**Gate:** Human review of assessment before any client-facing delivery.
The preferred go-to-market motion is geographically concentrated and relationship-driven rather than broad, cold, price-based competition.
The company does not initially compete by being the cheapest provider. It competes by demonstrating specific, local, provable before/after value.
---
## Stage 3: Proof-of-Concept Fix
## 2. Qualification
Qualification determines whether the prospect is a good fit for Version 1.
A good V1 prospect is typically:
- A local service business
- Owner-operated or small-team operated
- Dependent on local discovery, calls, appointments, bookings, visits, or consultations
- Likely to have meaningful customer lifetime value
- Likely to suffer from silent customer loss if digital pathways break or degrade
- Not in a heavily regulated advertising category unless vertical-specific guardrails exist
Version 1 priority categories include:
- Home services
- Auto repair
- Salon / spa without medical claims
- Boutique fitness / gym
- Other local service businesses with clear customer action pathways
Categories requiring later guardrails include:
- Dental
- Veterinary
- Med spa / aesthetics
Attorney / legal services are excluded for the foreseeable future due to materially heavier advertising and testimonial compliance constraints.
---
## 3. Initial Assessment
The Initial Assessment identifies potential Silent Customer Loss across the business's digital presence.
The assessment may examine:
- Google Business Profile
- Business name, address, and phone consistency
- Business hours
- Booking or contact pathways
- Website discoverability
- Service clarity
- Local citations
- Reviews and reputation signals
- AI Visibility Integrity / AEO signals
- Local Competitive Awareness signals
The goal is not to create a long generic audit.
The goal is to identify the most important issues that may prevent customers, search engines, or AI systems from finding, understanding, trusting, accurately representing, or engaging the business.
---
## 4. Evidence Classification
Findings from the Initial Assessment must be classified before they are used in client-facing materials.
The evidence model contains two tiers:
### Tier 1: Verified Evidence
Verified Evidence is concrete, observable, timestamped, current, or instrument-backed.
Verified Evidence may be presented as a confirmed issue.
Examples:
- Wrong phone number
- Incorrect business hours
- Broken booking link
- Failed contact form
- Incorrect listing data
- Indexing issue
- Metadata issue
- Canonical tag issue
- Missing or incorrect Google Business Profile information
### Tier 2: Indicative Evidence
Indicative Evidence is sampled, directional, probabilistic, or risk-based.
Indicative Evidence may be presented as directional risk or opportunity, but not as confirmed customer loss.
Examples:
- AI answer absence
- AI misrepresentation
- Weak entity clarity
- Inconsistent service descriptions
- Thin FAQ coverage
- Missing structured data
- Competitors appearing more consistently in AI answer samples
- Weak local discovery signals
Agents may propose an evidence tier, but humans approve final evidence tiers before client-facing use during Version 1.
Ambiguous findings default to Indicative Evidence unless upgraded by human review.
Rejected Verified Evidence classifications default to Indicative Evidence unless the reviewer discards the finding or requests additional evidence.
---
## 5. Proof-of-Concept Fix
The Proof-of-Concept Fix is the first value demonstration.
It is designed to show the prospect that silent customer loss can be identified, explained, and reduced.
The fix should be:
- Low-risk
- Clearly scoped
- Evidence-backed
- Understandable to the business owner
- Suitable for before/after comparison
- Within Version 1 contract boundaries
Examples may include:
- Correcting a wrong Google Business Profile field
- Fixing a broken booking or contact pathway
- Correcting inconsistent listing information
- Improving service clarity
- Improving metadata or discoverability signals
- Recommending structured data or entity-clarity improvements
- Identifying AI representation problems as directional risk
The Proof-of-Concept Fix must not become an open-ended implementation project.
---
## Proof-of-Concept Fix Approval Gate
During the proof-of-concept stage, agents may detect issues, gather evidence, and draft proposed fixes.
**Reconnaissance-versus-Execution Rule:** Agents may detect and draft. Humans approve before publish. This rule applies to every proposed client-facing change.
Any fix that publishes to a client-facing surface requires human approval before it goes live.
This includes, but is not limited to:
**Proof-of-Concept Fix Approval Gate:** Any fix that publishes to a client-facing surface requires human approval before it goes live. This includes, but is not limited to:
- Google Business Profile edits
- Review responses
- Q&A answers
@@ -58,137 +198,191 @@ During the proof-of-concept stage, agents may detect issues, gather evidence, an
- Website changes
- Directory or citation updates
**N≥100 Zero-Error Graduation Threshold:** For any specific task type (e.g., GBP description edits, review responses, Q&A answers), the agent must demonstrate ≥100 successful executions with zero errors before that task type is eligible for reduced-review or auto-approval workflows. The threshold is task-type-specific, not aggregate.
The lifecycle must preserve the reconnaissance-versus-execution rule:
**Evidence Collection:** Each proposed fix must cite its evidence tier. Verified Evidence fixes (wrong phone, broken link, incorrect hours) proceed with clear confirmation. Indicative Evidence fixes (AI answer absence, weak entity signals) are labeled as directional.
**Output:** Approved fixes applied; Before/After evidence captured.
Agents may detect and draft.
Humans approve before publish.
---
## Stage 4: Before/After Report
## 6. Before/After Report
Documentation of what was found, what was fixed, what remains, and the evidence tier for each item.
The Before/After Report is the receipt for the proof-of-concept engagement.
**Structure:**
- Verified Evidence fixes — confirmed before/after with artifacts
- Indicative Evidence improvements — directional comparison, labeled as sampled
- Remaining risks — categorized by evidence tier
- Recommended next steps
The report should show:
**Gate:** Human review and approval of report before client delivery.
- What was reviewed
- What was found
- Whether each finding was Verified Evidence or Indicative Evidence
- What was fixed or recommended
- What changed after the fix
- What risk remains
- What should be monitored going forward
The report must distinguish between confirmed issues and directional risks.
Verified Evidence may support stronger before/after proof.
Indicative Evidence may support directional comparison, but must be labeled as sampled, directional, or probabilistic when appropriate.
The report is not the product.
The product is continuous digital oversight and approved low-risk optimization.
The report exists to document value, support trust, and create the bridge to ongoing service.
---
## Stage 5: Retainer Offer
## 7. Retainer Offer
Formal proposal for ongoing engagement based on proven value from the proof-of-concept.
After the proof-of-concept engagement, the client may be offered an ongoing retainer.
**Components:**
- Scope definition (monitoring domains, cadence, deliverables)
- Evidence-tier reporting standards
- Approval-gate framework for ongoing optimizations
- Pricing tied to recoverable LTV (2030% ceiling per policy)
- Term and renewal terms
The retainer should be positioned as ongoing protection against silent customer loss.
**Gate:** Human approval of offer terms before presentation.
The sales argument is:
- Problems can exist without the business owner noticing.
- Search engines and AI systems can misrepresent or fail to surface the business.
- Competitors and platforms change over time.
- Digital pathways break silently.
- The business owner should not have to monitor all of this manually.
The retainer should not be positioned as generic marketing.
It should be positioned as ongoing digital operations oversight.
The client should understand that ongoing service includes monitoring, diagnosis, prioritization, reporting, and approved low-risk optimization within the contract scope.
---
## Stage 6: Ongoing Monitoring
## 8. Ongoing Monitoring
Continuous digital oversight per the agreed scope.
Ongoing Monitoring is the recurring service layer.
**Reconnaissance-versus-Execution Rule (restated for Ongoing Monitoring):** Agents may detect and draft. Humans approve before publish. No agent-initiated client-facing publishes without human approval.
It may include:
**Monitoring Domains (per scope):**
- AI visibility (search + AI-assisted discovery sampling)
- Customer Path Integrity (GBP, website, booking, contact, citations)
- Local entity consistency
- Competitor signal tracking
- Review signal monitoring
- Structured data / schema health
- Customer Path Integrity checks
- AI Visibility Integrity / AEO checks
- Local Competitive Awareness checks
- Reputation signal monitoring
- Listing and citation monitoring
- Booking or contact pathway checks
- Website discoverability checks
- Service clarity checks
- Detection of new risks or changes
**Approval-Gate Framework:**
- Verified Evidence findings → proposed fix drafted → human approval → publish
- Indicative Evidence findings → risk/opportunity noted → human review → optional fix drafted → human approval → publish
- N≥100 zero-error graduation threshold applies per task type before any reduced-review pathway
Monitoring depth may vary by tier.
**Cadence:** Continuous monitoring with periodic human review checkpoints (minimum weekly).
Local Competitive Awareness is a built-in capability for every client, but the depth and frequency may scale by package.
**Output:** Monitoring alerts, drafted fixes pending approval, periodic summary.
AI Visibility Integrity is core to the service, but the company does not guarantee placement, ranking, citation, or recommendation by any AI system.
### Ongoing Monitoring Approval Gate
During ongoing monitoring, agents may detect issues, gather evidence, compare changes, draft recommendations, and draft proposed low-risk optimizations.
Any action that publishes to a client-facing surface requires human approval before it goes live.
This includes the same client-facing surfaces listed in the Proof-of-Concept Fix Approval Gate, including Google Business Profile, review responses, Q&A answers, business descriptions, service descriptions, hours, phone numbers, booking links, website changes, and directory or citation updates.
The ongoing monitoring phase must preserve the same reconnaissance-versus-execution rule:
Agents may detect and draft.
Humans approve before publish.
### Approval Gate Graduation Threshold
During Version 1, the approval gate remains in place by default.
A specific task type may only bypass the human approval gate after a documented reliability run of at least 100 completed tasks with zero errors for that exact task type.
The threshold applies to the exact task type only.
Reliability for one task type does not transfer to another task type.
Until the threshold is met and documented, human approval remains required before publishing to any client-facing surface.
---
## Stage 7: Monthly/Periodic Reporting
## 9. Monthly / Periodic Reporting
Structured delivery of monitoring outcomes, actions taken, and forward look.
Ongoing clients receive periodic reports.
**Report Contents:**
- Verified Evidence fixes applied (confirmed before/after)
- Indicative Evidence risks/opportunities identified (directional, labeled)
- Monitoring alerts generated and dispositioned
- Competitor signal changes
- Evidence-tier compliance summary
- Recommended next actions with priority
Reports should be concise and decision-oriented.
**Gate:** Human review and approval of report before client delivery.
Reports should answer:
- What did we watch?
- What changed?
- What did we find?
- What did we fix or recommend?
- What remains at risk?
- What should happen next?
Reports must preserve evidence-tier discipline.
Verified Evidence and Indicative Evidence must not be blended.
The client should not be forced to interpret raw findings or prioritize work alone.
The service reduces decision burden.
---
## Stage 8: Renewal/Expansion
## 10. Renewal / Expansion
Evaluation and negotiation of continued or expanded engagement.
Renewal occurs when the client continues the ongoing service.
**Activities:**
- Value delivered review (verified fixes, risk reduction, visibility gains)
- Scope adjustment (add/remove monitoring domains, change cadence)
- Pricing re-evaluation against recoverable LTV
- Term extension or expansion agreement
Expansion may occur when the client asks for additional coverage, faster monitoring, more locations, deeper AI visibility checks, deeper competitive analysis, or additional approved optimization work.
**Gate:** Human approval of renewal/expansion terms.
Expansion must not erase contract boundaries.
Work outside the defined recurring service areas should be quoted separately unless explicitly included in the package.
Examples of separate project work may include:
- Website redesign
- Branding projects
- Social media production
- Paid advertising
- Full SEO campaigns
- CRM or email marketing
- Large-scale content production
---
## Stage 9: Offboarding
## 11. Cancellation / Offboarding
Formal and complete disengagement when the relationship ends.
If a client cancels, offboarding should be clean and documented.
**Required Actions:**
- Final report delivery (status of all monitored pathways, remaining risks)
- Revocation of all agent credentials for client systems
- Removal of delegate access (GBP, social, directories, analytics, etc.)
- Revocation of API tokens, webhook subscriptions, integration keys where applicable
- Removal of client from monitoring systems, alerting, and data pipelines
- Confirmation that no automated agents retain access to client-facing surfaces
- Data retention / deletion per agreement and policy
Offboarding may include:
**Gate:** Human confirmation that all access is revoked and client is fully removed from operational systems.
- Final status summary
- List of completed fixes
- List of known remaining risks
- Export or handoff of relevant documentation
- Removal of user access where appropriate
- Revocation of any agent credential tied to the client's accounts
- Revocation of delegate access
- Revocation of API tokens where applicable
- Removal from ongoing monitoring systems
- Confirmation that no further monitoring will occur
**Output:** Offboarding completion certificate signed by human operator.
The company should not retain unnecessary access to client accounts after cancellation.
---
## Lifecycle Summary
## 12. Lifecycle Principles
| Stage | Name | Key Gate |
|-------|------|----------|
| 1 | Prospect | Fit qualification |
| 2 | Initial Assessment | Human review of assessment |
| 3 | Proof-of-Concept Fix | Human approval per fix (N≥100 threshold for task-type graduation) |
| 4 | Before/After Report | Human review of report |
| 5 | Retainer Offer | Human approval of terms |
| 6 | Ongoing Monitoring | Human approval per publish (reconnaissance-vs-execution) |
| 7 | Monthly/Periodic Reporting | Human review of report |
| 8 | Renewal/Expansion | Human approval of terms |
| 9 | Offboarding | Human confirmation of full access revocation |
The lifecycle is governed by the following principles:
---
## Core Principles (Restated)
1. **Reconnaissance-versus-Execution:** Agents detect and draft. Humans approve before publish. No exceptions.
2. **Evidence-Tier Discipline:** Verified Evidence = confirmed issues. Indicative Evidence = directional risk. Ambiguous = Indicative by default. Rejected Verified = Indicative unless discarded or re-evidenced.
3. **N≥100 Zero-Error Graduation:** Per task type, ≥100 successful executions with zero errors before reduced-review eligibility.
4. **Human-in-the-Loop:** Every client-facing publish, every client-facing report, every scope/pricing decision requires human approval.
5. **Complete Offboarding:** All access revoked, all tokens removed, all monitoring stopped, confirmed by human.
1. Proof before retainer.
2. Broad mission, narrow contract scope.
3. Agents may detect and draft; humans approve before publish.
4. Verified Evidence and Indicative Evidence must be separated.
5. Ambiguous findings default to Indicative Evidence.
6. Reports are receipts, not the product.
7. The company improves digital pathways, not every marketing function.
8. AI Visibility is core, but AI placement is not guaranteed.
9. The client should receive clarity, not more homework.
10. Scope expansion must be earned, explicit, and separately priced when outside the package.
11. Approval-gate relaxation requires task-type-specific reliability evidence.