client-dashboard

Files (5)

• NOTES.md
• README.md
• SKILL.md
• dashboard-template.html · templates/
• results.example.json · templates/

SKILL.md (first lines)

# 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 climbing and
pages shipping with your logo on it, and re-signs without a meeting. That's the offense —
it's a retention and referral engine. "Read-only, standalone, can't crash their site" is the
enabler that lets you ship it in an afternoon and never think about it again — never the
headline.

---

## Say this to your agent

> "Set up a client dashboard for <client>. At the end of each run, write a `results.json` of
> what you did — work shipped, ranking/traffic changes, what's in progress, what's next — then
> regenerate a branded, self-contained HTML page from it and save it so I can host it as a
> static link. Never wire anything into the client's site. Keep costs, prompts, tool names, and
> raw logs OUT of it — client-facing only. Stamp it with the date it covers."

That one line is the whole ask. Everything below is the pattern behind it and the rules that
keep it safe.

---

## The pattern (four steps, one direction)

Data flows one way — from your agent's run, out to a page the client reads. Nothing flows back.

1. **Agent run does the work.** Your normal run against the client's account — pulling rankings
   from your SEO platform's MCP, shipping content, running an audit. Same work you already do.
2. **It writes a structured results file** (`results.json`). This is the single source of truth
   for the dashboard: *what happened this period*, as data. Separating "what happened" from "how
   it looks" is what makes the whole thing regenerable and boring-in-a-good-way — the agent only
   ever has to produce clean data, never fiddle with HTML.
3. **A branded HTML page is regenerated from that file.** One self-contained file — inline CSS
   and JS, no dependencies, your brand colors and logo. The agent swaps the run's data into one
   clearly-marked block and leaves everything else untouched. Same layout every run; only the
   numbers change.
4. **You host it as a static page.** Drop the file on any static host — a Netlify/Vercel drag-and-
   drop, an S3 bucket, GitHub Pages, your own web host, even sent as an email attachment. The
   client gets a link (or the file) and opens it. That's it.

Because the output is *just an HTML file on a static host*, the client has **no login into your
stack and no way to change anything** — read-only isn't a permission you set, it's the shape of
the thing. And because nothing is installed on their site, your automation can never take their
site down.

---

## What goes ON the dashboard vs. what stays INTERNAL

This is the line that makes a dashboard client-safe. When in doubt, leave it out.

| Put it ON the client dashboard | Keep it INTERNAL — never on the client page |
|---|---|
| Work shipped this period (plain-English outcomes) | Your costs, hours, margin, or credit usage |
| Rankings / traffic / conversions and their deltas | The prompts, skills, or agent instructions you used |
| What's in progress and what's blocked on the client | Raw agent logs, tool call traces, error stacktraces |
| What's next, with owners and rough timing | **Which specific tools/MCPs/vendors** power the work |
| A one-line headline of the period's win | Credentials, API keys, internal notes, TODOs |
| The date the data covers | Any other client's data (never mix accounts) |

Two rules inside that table matter most. **Never expose the machinery** — the client bought an
outcome, not a tour of your tool stack; naming your vendors just hands them a shopping list to
cut you out. And **never leak cost or margin** onto a page a client reads — it reframes your value
as your bill. Say *"published the emergency-care landing page and it's now ranking #4,"* never
*"ran 3 content-gen calls at $X."*

---

## Refresh cadence

Match the rhythm the client already expects to hear from you.

- **Weekly is the sweet spot** for most retainers — it lines up with how agencies already report,
  and it's frequent enough that the client feels progress without you staffing a daily update.
  Regenerate the page at the end of your weekly run and the link updates itself.
- **Per-run** is fine when your agent runs on a schedule anyway — just let the last step of every
  run rewrite the page. The client's bookmark always shows the latest.
- **Avoid real-time.** A number that ticks live invites anxiety and "why did it dip at 2am?"
  questions; a dashboard is a *report*, not a monitor. And **avoid monthly-only** — a month of
  silence makes even great work feel like nothing happened.
- **Always stamp the coverage date on the page** ("Data through July 7"). A client who can't tell
  whether they're looking at this week or last month stops trusting the page — and a stale-looking
  dashboard is worse than none.

---

## First dashboard in an afternoon

You do not need a build pipeline. You need four moves:

1. **Copy the starter template.** Take `templates/dashboard-template.html` — it already renders a
   full demo dashboard when you double-click it, so you can see the shape before you change a thing.
2. **Brand it once.** Open the template and swap the two brand colors in the `:root` block and the
   logo mark for the client's. (You can also set colors per-run from the data file — see `brand.*`
   in `results.example.json`.) This is a one-time edit.
3. **Wire your run to produce the data + regenerate the page.** At the end of your agent run, have
   it write a `results.json` in the shape of `templates/results.example.json` (its keys map 1:1 to
   the page), then replace the JSON between the `DASHBOARD_DATA:START` / `DASHBOARD_DATA:END`

From search-atlas-group/amm-founding-circle, MIT.

More from search-atlas-group/amm-founding-circle