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

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.

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

1. Trigger — deal stage or launch checklist complete (ties to delivery, not random chat).
2. Results intake — form + optional Analytics/Search Console export fields; LLM maps notes → schema.
3. Permission matrix — booleans: quote OK, name OK, logo OK, metrics OK, public case OK.
4. Draft writers — review-request message + case outline from locked templates.
5. Validators — no naked numbers without source; required permissions; tone deny-list.
6. 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)

1. get_deal(deal_id) — package, contacts, NDA flags
2. create_proof_run(deal_id)
3. upsert_results(schema)
4. set_permissions(flags)
5. draft_review_ask(template_id) → Message
6. draft_case_outline(template_id) → Outline
7. validate_proof(run_id) → Report
8. request_human_review(run_id)
9. send_review_ask(run_id) — if approved
10. queue_portfolio_draft(run_id) — if approved + public_case
11. 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

	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

Related: Agents vs chatbots vs copilots · White label in the age of AI · Testimonials

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