Build full client lifecycle document
This commit is contained in:
@@ -1,5 +1,184 @@
|
|||||||
# Client Lifecycle
|
# Client Lifecycle
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
The lifecycle exists to connect the business mission, value creation model, evidence model, go-to-market strategy, and operating rules.
|
||||||
|
|
||||||
|
The service is designed around a proof-of-concept-first motion: demonstrate concrete value, then offer ongoing monitoring and optimization.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Lifecycle Overview
|
||||||
|
|
||||||
|
The standard client lifecycle is:
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Prospect
|
||||||
|
|
||||||
|
A prospect is a local service business that may be silently losing customers because of digital visibility, trust, representation, or engagement issues.
|
||||||
|
|
||||||
|
Prospects may come from:
|
||||||
|
|
||||||
|
- Warm referrals
|
||||||
|
- Local business relationships
|
||||||
|
- Direct outreach
|
||||||
|
- Existing owner networks
|
||||||
|
- Case studies
|
||||||
|
- Before/after proof from previous clients
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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
|
## Proof-of-Concept Fix Approval Gate
|
||||||
|
|
||||||
During the proof-of-concept stage, agents may detect issues, gather evidence, and draft proposed fixes.
|
During the proof-of-concept stage, agents may detect issues, gather evidence, and draft proposed fixes.
|
||||||
@@ -23,3 +202,187 @@ The lifecycle must preserve the reconnaissance-versus-execution rule:
|
|||||||
|
|
||||||
Agents may detect and draft.
|
Agents may detect and draft.
|
||||||
Humans approve before publish.
|
Humans approve before publish.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Before/After Report
|
||||||
|
|
||||||
|
The Before/After Report is the receipt for the proof-of-concept engagement.
|
||||||
|
|
||||||
|
The report should show:
|
||||||
|
|
||||||
|
- 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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Retainer Offer
|
||||||
|
|
||||||
|
After the proof-of-concept engagement, the client may be offered an ongoing retainer.
|
||||||
|
|
||||||
|
The retainer should be positioned as ongoing protection against silent customer loss.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 8. Ongoing Monitoring
|
||||||
|
|
||||||
|
Ongoing Monitoring is the recurring service layer.
|
||||||
|
|
||||||
|
It may include:
|
||||||
|
|
||||||
|
- 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
|
||||||
|
|
||||||
|
Monitoring depth may vary by tier.
|
||||||
|
|
||||||
|
Local Competitive Awareness is a built-in capability for every client, but the depth and frequency may scale by package.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 9. Monthly / Periodic Reporting
|
||||||
|
|
||||||
|
Ongoing clients receive periodic reports.
|
||||||
|
|
||||||
|
Reports should be concise and decision-oriented.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 10. Renewal / Expansion
|
||||||
|
|
||||||
|
Renewal occurs when the client continues the ongoing service.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 11. Cancellation / Offboarding
|
||||||
|
|
||||||
|
If a client cancels, offboarding should be clean and documented.
|
||||||
|
|
||||||
|
Offboarding may include:
|
||||||
|
|
||||||
|
- 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
|
||||||
|
|
||||||
|
The company should not retain unnecessary access to client accounts after cancellation.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 12. Lifecycle Principles
|
||||||
|
|
||||||
|
The lifecycle is governed by the following principles:
|
||||||
|
|
||||||
|
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.
|
||||||
Reference in New Issue
Block a user