client-dashboardlisted

# client-dashboard **The problem this solves:** your agents are doing real work on a client's account — shipping pages, moving rankings, fixing audits — and the client can't see any of it. So they ask for "a dashboard," and the tempting move is to wire your agent stack *into their site*: install a plugin, drop a widget, connect a live feed into their CMS. Don't. One member did exactly that and a single plugin conflict took down **four client sites at once**. The moment your automation has a write path into a client's live property, a bad write, a version bump, or a plugin clash is no longer a bug — it's an outage on a site you don't own, in front of the client who pays you. The fix is a different shape entirely, and it's the whole skill: > **Don't put your agents inside the client's house. Publish a standalone view of what > they did.** Each agent run writes a small results file. A self-contained, branded HTML > page is regenerated from that file and hosted as a plain static page the client opens in > a browser. They see the work; they never touch your tools, never log into your stack, and > there is no write path into their site. It is read-only *because of how it's built*, not > because you remembered to lock it. Why an owner should care, in money terms: **the work your agents do is invisible until the client can see it — and invisible work doesn't renew.** A clean, branded dashboard turns silent throughput into visible ROI: the client opens a link, sees rankings climbi