Build full client lifecycle document
This commit is contained in:
@@ -1,5 +1,184 @@
|
||||
# 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
|
||||
|
||||
During the proof-of-concept stage, agents may detect issues, gather evidence, and draft proposed fixes.
|
||||
@@ -22,4 +201,188 @@ This includes, but is not limited to:
|
||||
The lifecycle must preserve the reconnaissance-versus-execution rule:
|
||||
|
||||
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