How we build client AI visibility dashboards

Weekly reporting has a way of growing until it fills a person's whole Thursday. Someone exports charts, pastes them into a deck, rewrites the same caveats, and sends it to a client who reads the first page. We have done it that way, and we stopped. The fix was not a prettier deck. It was deciding what each dashboard is for, then building only that.

This post describes how we set up client dashboards now, and where the tooling saves the most time.

Start with the client's question, not the metric list

A dashboard that tries to show everything answers nothing. Before we touch a chart, we write down the single question each dashboard serves. In practice a client program needs about three:

• Are we being named against competitors? This one is for the marketing lead. It needs visibility, share of voice, and a competitor comparison, split by engine.
• Where are the gaps? This one is for the content team. It needs topics where competitors appear and the client does not, with the prompts behind them.
• What is being cited? This one is for whoever owns the site. It needs cited domains and pages, so they see which sources AI engines rely on.

Each question has a different reader, a different cadence, and a different level of detail. Mixing them on one page is the main reason client dashboards go unread.

The manual version

If you have no tooling, you can still run this. Keep a spreadsheet with one tab per question. Pull the same prompt set on the same day each week. Record the numbers, write two sentences on what changed, and attach the three or four example answers that explain the change. It is slow, but the discipline transfers: one tab, one question, one reader.

Two habits keep the manual version honest. Always list the scope (engines, markets, prompt count, competitor set) at the top of each tab, and always log any setup change that breaks comparison, such as adding a prompt or a competitor midway through the period. We described that scope block in our note on what agencies should report to clients.

Templates get you 80 percent of the way

The slowest part of any dashboard is the blank page. According to the Promptwatch changelog, custom dashboards arrived on September 22, 2026, and on October 14 they gained four templates: competitor comparison, topic gaps, AI model breakdown, and citations. Each template sets up its widgets and their settings.

Those four map almost exactly onto our three questions, with the model breakdown as a useful extra for clients who ask "is it only ChatGPT, or everywhere?" We start every new client from a template, then trim. Removing a widget that does not serve the question is faster than inventing the layout.

Trimming matters. A template is a starting point, not a deliverable. We delete widgets the client will not act on, rename the dashboard after its question, and pin the date range we will use every week so the comparison stays like for like.

Let the agent build the first draft

The same October 14 changelog entry says Agent Chat and the MCP server can create and edit dashboards from widgets, saved filters, and widget settings, or start from a template. Dashboards made in chat are personal by default.

That detail shapes our workflow. When we onboard a client, someone on our team describes the dashboard in plain language ("competitor comparison for the UK market, last 30 days, ChatGPT and Google AI Overviews"), reviews what the agent built, fixes anything off, and only then shares it. Personal by default is a feature here: a half-finished draft does not leak into a client workspace. We treat the agent's output as a junior analyst's first pass. It saves the setup time. It does not replace the check that the filters match the scope we promised.

Schedule the PDF and stop assembling decks

Reporting only becomes cheap when delivery is automatic. The changelog lists scheduled PDF reports for custom dashboards, added on October 2. The report contains the widgets on the dashboard, in the same order, and carries the dashboard's name as its title. A schedule follows its dashboard, so if you change the widgets or rename it, the next report picks that up.

For our programs this means the dashboard is the report. We do not maintain a second copy in a slide deck. A client who wants to see the live data opens the dashboard, and one who prefers email receives the PDF on schedule. Our analyst time goes into the commentary: a short note on what moved, what we shipped in the period, and what happens next.

The changelog also notes that white-label organisations can export and schedule PDF reports with their own branding. It does not say which plan that sits on, so check with Promptwatch before you promise it to a client on a specific tier.

Where Promptwatch fits

Promptwatch is the platform we run client programs on, and the pieces above (custom dashboards, the four templates, chat-built dashboards, scheduled PDFs) are why reporting no longer eats the week. The agency plans list custom reports and the Looker Studio connector among their included features, and the brand plans from Professional upward include custom reports too, so the decision about which plan to buy is mostly about response volume and seats, not reporting access. Check the current plan list for exact limits before you scope a client.

We use it as the measurement base and keep two things outside it on purpose. Business outcomes such as leads and revenue stay in the client's own analytics and CRM. And the written interpretation stays ours, because a chart cannot say that a drop came from a model update, not from the page we edited.

The dashboard checklist we use

1. Write the question and the reader at the top of the dashboard description.
2. Start from the closest template and delete anything that does not serve the question.
3. Fix the date range and comparison period so every week reads like the last.
4. State the scope: engines, markets, prompt set, competitors.
5. Schedule the PDF to the people who actually read it.
6. Add a short human note on what changed and what we did.
7. Review the dashboard monthly and retire widgets nobody mentions.

None of this is clever. It is a set of small decisions made once, so the weekly work shrinks to the part that needs a person. If your own reporting still takes most of a day, the first thing to cut is the second copy of the data.