# Proof Capture Operating System

Install a repeatable way to gather real proof assets so the business stops depending on weak marketing copy and starts building evidence that can actually be shown, cited, and trusted.

## Why Proof Capture Breaks

Most businesses do good work but fail to capture evidence of it. The team is busy, the trigger moment passes, and the only thing left is generic copy written later.

That creates three problems:

- the website stays thin
- reviews and case studies grow slowly
- the brand looks less credible than the work really is

## Capture Triggers

Define the exact moments when proof should be collected.

Common triggers:

- successful emergency response
- completed repair or install
- positive consult outcome
- resolved complaint
- high-NPS or strong verbal praise moment
- visible before/after transformation
- repeat-customer milestone

Each trigger should tell the team:

- what to capture
- who captures it
- where it gets stored
- what approval is required

## Asset Types

Do not rely on one proof format.

Capture a mix of:

- review requests
- short testimonial quotes
- before/after photos
- job-story notes
- FAQ-worthy scenarios
- staff observations
- quantified outcomes where appropriate

## Approval Workflow

Use a simple approval path so proof is usable without creating chaos.

1. Capture the raw material
2. Save it to the right folder or form
3. Mark consent or usage status
4. Assign an editor or owner
5. Publish to the right surface

Required tracking fields:

- customer name or ID
- date
- service line
- location
- consent status
- proof type
- owner
- publish status

## Review-to-Proof Pipeline

Turn reviews into more than a star rating.

When a strong review arrives:

- tag the service type
- extract the core concern it resolved
- decide whether it belongs on a service page, FAQ, city page, or case strip
- pair it with a photo or process note if available

This creates reusable evidence instead of letting every review live in one silo.

## Case-Study Compression

Long case studies are not always necessary. Use a compressed format that still sounds real.

Recommended structure:

- `Situation`: what the customer was dealing with
- `Response`: what the business did
- `Outcome`: what changed
- `Why it matters`: what this proves about the business

This can live on:

- service pages
- resource pages
- estimate follow-up emails
- review response training

## Team Roles

Assign proof responsibilities clearly:

- technician or provider: capture field notes and photos
- office lead: collect reviews and consent
- operator or marketer: shape assets for publication
- owner: review sensitive or flagship proof pieces

Without ownership, proof capture becomes everybody’s job and nobody’s job.

## Publishing Destinations

Route proof to the right place:

- website proof strips
- FAQ answers
- city pages
- Google Business Profile posts
- resource guides
- sales follow-up sequences
- internal training

The same raw asset can fuel several surfaces if it is tagged well.

## Quality Controls

Do not publish:

- fake testimonials
- edited quotes that change meaning
- photos with unclear consent
- vague “great service” snippets without context
- proof that contradicts the actual workflow

Do publish:

- specific quotes
- real timing or process detail
- honest outcomes
- clean visuals
- evidence matched to the correct page or question

## Monthly Review

Every month, review:

- number of proof assets captured
- number approved and published
- gaps by service line or location
- stale proof on top pages
- strongest new stories worth deeper use

## 30-Day Installation Plan

### Week 1

- define triggers
- choose storage method
- assign owners

### Week 2

- train the team on what to capture
- create the approval workflow
- test the first 5 captures

### Week 3

- publish to service pages, FAQ pages, and local profiles
- connect reviews to proof strips

### Week 4

- review output quality
- remove weak examples
- tighten the workflow for the next month