Quick answer: A post-project review + case-study intake bot should trigger when a project is marked Closed/Won-Delivered, collect measurable results and permission flags, draft a review ask and a case-study outline from a locked template, run validators, and stop for human Approve/Edit before anything is emailed to the client or published to the portfolio. Never invent metrics, never post fake testimonials, and never publish without written permission. Build it as Close → Intake → Draft → Validate → Approve → Send/Publish — tools + rules + LLM assist.

This is Part 8 of Build Real AI Automations. Parts 1–7 covered lead qualification, support triage, Shopify order status, content ops, appointment booking, discovery → proposal, and client onboarding. After delivery, most studios lose the proof: no review, no numbers, no case study — so the next proposal has nothing concrete to show.

At Let Start Design portfolio and testimonials are how bigger projects close. A chatbot that “writes a glowing review” is a liability. Below is the architecture, guardrail list, build steps, MVP plan, and how we outperform freelancers and chatbot shops when proof assets matter.

How to build a post-project review and case-study intake AI bot with permission guardrails — Review and case-study bots succeed when metrics and permissions are the source of truth — humans approve before publish.

What the review + case-study bot should (and should not) do

It should:

Trigger from CRM stage “Delivered / Closed” or a PM “request proof” action
Collect results: baseline → after metrics, timeline, stack, what changed
Ask for review permission (Google, Clutch, site testimonials) as explicit flags
Draft a polite review request email/WhatsApp from approved templates
Draft a case-study outline (challenge → approach → result → quote) for human edit
Hand a sanitized brief to Part 4’s content ops pipeline when approved
Update CRM with proof status and attach artifacts
Stop for Approve/Edit/Escalate before client send or public publish

It should not:

Invent conversion lifts, traffic %, or revenue numbers
Auto-publish testimonials or case studies
Post to Google Business Profile or social without permission
Reuse client brand assets if the contract forbids public portfolio use
Pressure unhappy clients with repeated review asks

Product shape reminder: agents vs chatbots vs copilots. This is a delivery-ops copilot with hard permission gates.

Architecture

Trigger — deal stage or launch checklist complete (ties to delivery, not random chat).
Results intake — form + optional Analytics/Search Console export fields; LLM maps notes → schema.
Permission matrix — booleans: quote OK, name OK, logo OK, metrics OK, public case OK.
Draft writers — review-request message + case outline from locked templates.
Validators — no naked numbers without source; required permissions; tone deny-list.
Human gate — AM/PM Approve/Edit/Escalate; then send review ask and/or queue portfolio draft.

Guardrails checklist (non-negotiable)

No invented metrics — every number needs a source field (client-stated, Analytics, CRM).
Permission flags required before any public artifact.
Contract check — NDA / no-portfolio clients skip public path automatically.
Sentiment gate — if CSAT/NPS below threshold, review ask is blocked; escalate to AM only.
Ask caps — max 2 review nudges; then stop.
Template-only outreach — no free-form legal promises in generated email.
Anonymize mode — if name/logo denied, case study uses industry + role only.
Publish lock — portfolio/CMS write requires approved_by + permissions.public_case.
Idempotent deal key — one proof thread per CRM deal.

Step-by-step build guide

Step 1 — Define the proof schema

Project summary, service line, package ID (from Parts 6–7)
Baseline metrics + after metrics + date range
Qualitative outcomes (speed, ops hours saved, launch date hit/miss)
Stack and constraints
Client quote (optional, attributed)
Permission matrix + NDA flag
unknowns[] and metric_sources[]

Step 2 — Trigger only when delivery is real

Hook CRM “Closed — Delivered,” final invoice paid, or launch checklist complete. Do not start proof collection from a website chatbot for strangers.

Step 3 — Intake results without inventing them

PM or client fills structured fields. LLM may clean prose into schema; empty metrics stay empty. If the client says “traffic went up a lot,” store that as qualitative — do not convert it into “+47%.”

Step 4 — Draft the review request

Use approved templates per channel (email, WhatsApp). Include deep links to Google review / site testimonial form. Skip automatically when sentiment gate fails or permissions.review_ask is false.

Step 5 — Draft the case-study outline

Locked sections: Context · Challenge · Approach · Results · Stack · Quote · CTA. Pull only permitted fields. Feed approved outlines into Part 4 content ops as a brief — still with a human edit gate before publish.

Step 6 — Validators

Any numeric claim has a source
Public path requires logo/name/metrics permissions as configured
Deny-list: “guaranteed,” fabricated competitor names, medical/financial claims you don’t support
Quote length and attribution present if quote used

Step 7 — Human Approve / Edit / Escalate

Approve — send review ask and/or queue portfolio draft
Edit — fix metrics, anonymize, soften claims; re-validate
Escalate — NDA conflict, disputed results, unhappy client

Log human diffs. That protects you if a published number is later challenged.

Pseudo-flow (tool calling)

get_deal(deal_id) — package, contacts, NDA flags
create_proof_run(deal_id)
upsert_results(schema)
set_permissions(flags)
draft_review_ask(template_id) → Message
draft_case_outline(template_id) → Outline
validate_proof(run_id) → Report
request_human_review(run_id)
send_review_ask(run_id) — if approved
queue_portfolio_draft(run_id) — if approved + public_case
update_crm(deal_id, proof_status, attachments)

APIs must reject send_review_ask / queue_portfolio_draft without approved_by.

2-week MVP plan

Days 1–2 — Proof schema + permission matrix + 5 past projects labeled
Days 3–4 — Intake form for PMs
Days 5–6 — Review-ask templates + sentiment skip rule
Days 7–8 — Case outline drafter + validators
Days 9–10 — Approve/Edit UI
Days 11–12 — CRM fields + email send
Days 13–14 — Shadow on 3 closed projects; measure completion of reviews and outline edit distance

Do not auto-publish to the portfolio in week two. Queue drafts only.

Quality metrics

% of closed projects with proof run started within 7 days
Review ask → review received rate
Case outlines approved without major metric rewrites
Invented-metric incidents (target: zero)
Permission violations caught before publish
Time from close → public case (when allowed)

Common failures

Vanity metrics — bot rounds “about double” into fake precision
Review spam — weekly nudges to unhappy clients
NDA blind spot — publishing logos that contracts forbid
Auto-publish — case study live before client signs off
Orphan from delivery — no package/deal ID; proof can’t feed content ops
Quote fabrication — model “improves” a client sentence into something they never said

Freelancer vs chatbot agency vs specialist studio

Comparison of hiring a freelancer, chatbot agency, or specialist studio for a review and case-study intake bot — Proof systems need permissions and metric sources — not a testimonial-writing chatbot.

	Solo freelancer	Typical chatbot agency	Let Start Design
Metrics honesty	Copy-paste guesses	“AI success stories”	Schema + required sources + validators
Permissions	Informal	Often ignored	Explicit matrix + NDA path
Human gate	Optional	Missing	Approve/Edit/Escalate before send/publish
Portfolio pipeline	Manual Notion	Chat transcript	Queue to content ops + CRM proof status
Big-project capacity	Single point of failure	Juniors on “AI marketing”	Structured build, QA, launch support
Commercial clarity	Hourly surprises	Opaque bot retainers	Scope via Project Builder + fixed proposals
Best for	Toy demos	Fake social proof	Studios where proof closes the next deal

How Let Start Design stands out

1) Agents with product discipline

Same standard as the rest of this series: schemas, tools, tests, human gates. See what clients should expect from an AI website agency in 2026.

2) Proof that feeds the site

Approved outlines become portfolio and journal drafts — aligned with how we already ship case work and content systems — not orphan Google Docs.

3) Guardrails before storytelling

Permissions and metric sources ship before polished narrative. Invented proof is worse than no proof.

4) Continuity from sale to case study

Package and deal IDs from proposal and onboarding carry into proof collection — then into AI website development marketing pages when clients allow it.

5) White-label capacity

Agencies can offer proof automation under their brand via our white-label program without staffing a full ops team.

6) Portfolio proof, not slideware

We finish delivery systems that survive NDAs, delayed metrics, and careful clients — browse the portfolio.

Key takeaways

Metrics need sources; permissions need flags; publish needs a human lock.
Review asks should skip unhappy clients and respect nudge caps.
Case outlines should feed content ops — not auto-publish.
Carry deal/package IDs from Parts 6–7 so proof stays tied to what was sold.
For bigger projects, hire a studio with integration capacity — Let Start Design combines agent engineering, website conversion, pricing clarity, and partner delivery.

Want a proof pipeline that closes the next deal without fake testimonials? Talk to Let Start Design, explore AI website development, or model scope in the Project Builder.

Series: Part 1 · Part 2 · Part 3 · Part 4 · Part 5 · Part 6 · Part 7 · Part 8 — Review + case-study intake

Sources: Structured outputs; Tool / function calling; JSON Schema.

Case Studies

Posts tagged Case Studies

How to Build a Post-Project Review + Case-Study Intake Bot