The handoff is where the client relationship is tested. If the evidence table arrives with a clear state per row — confirmed active, confirmed inactive, unknown — the client can act. If it arrives with only the bot's conclusion but no source trace, they're being asked to trust a black box. 'Review owner and monthly support boundary in the handoff' isn't just workflow design. It's how the client stays in control of a process you built for them. Even when the bot did 90% of the work, the final call should feel like theirs. That framing also sets up the retainer: 'We built the evidence layer. We maintain the signal quality. You make the call.'

The run receipt is exactly the right concept. One distinction worth adding: missing data and stale data are two different failure modes, and the run receipt should surface both separately. Missing = the source failed entirely. Visible and catchable. Stale = the source ran, but last updated 72 hours ago. Looks valid. Silently wrong. A report with stale data looks clean but misleads the client with outdated numbers. The three-state receipt: ✅ Synced (fresh data, within expected window) | ⚠️ Stale (source ran, but timestamp is old) | ❌ Missing (source failed entirely). That third state is what most reporting systems don’t flag — and it’s often the most expensive mistake.

@Duy Bui The source timestamp vs fetch time split is the critical distinction most miss. 'We fetched from source X at 9am' and 'source X last updated 3 days ago' are two different facts. The first says the connection worked. The second says the data is suspect. Naming the owner on a stale source is exactly right — it turns 'the report has a problem' into 'the CRM sync hasn't updated since Tuesday', which is a solvable, attributable issue. The 'all clear' block is what actually closes the loop. A successful fetch from a stale source still shouldn't produce a clean report. 'Success' has to mean the data is fresh, not just that the request returned 200.

For client automation work, the CRM is the answer — every automated action gets logged against the contact record with a timestamp and the triggering condition. A second person can open the contact, see what the agent flagged and why, and make the same call independently. For community posts specifically, I’d keep the draft + the agent’s source data in a shared doc with a visible “approved by” field. Only publish once someone who wasn’t in the original conversation reads it and says “yes, I’d send this too.” The test isn’t whether the agent got it right. It’s whether the evidence was good enough that the decision was reproducible.

Getting good results with VAPI + GHL. A live example: dental clinic, $60/month, 47 missed calls handled in the first month, ~$1,500 in recovered appointments. The owner didn’t care what I built — they cared that calls stopped falling through after hours. On RetellAI vs GHL: VAPI paired with GHL gives you more control on the backend — CRM sync, workflow triggers, follow-up sequences. RetellAI is cleaner to demo but limits what you can do after the call ends. The ICP that actually responds to this pitch: local service businesses where missing a call = missing a job. Dental, HVAC, car rental, plumbing. Those owners feel it every week. The pitch becomes easy when you can frame it as revenue leaking, not technology to buy. Happy to share what the sales conversation looks like if it’s useful.