Building the dashboard is no longer the hard part. You describe what you want, the assistant writes a self-contained HTML page with charts and filters, and it works. The hard part is the last hundred metres: getting it to a client so it opens, works, and looks like something you meant to send.
This guide covers the delivery problem specifically, for people whose clients are not developers.
What makes AI-generated dashboards awkward to deliver
They are usually one HTML file with everything inlined — styles, scripts, data, chart code, all in a single document. That is a genuinely good format. It also happens to be the format every business tool handles worst.
- Email treats it as a suspicious attachment.
- Slack shows a paperclip, not a preview.
- The client's IT policy may strip the scripts, which is the entire dashboard.
- The chat link to the conversation you built it in drops them into your message history.
So the file that works perfectly on your screen is the file least likely to survive the trip.
The delivery options, honestly assessed
Screenshot it
Fast, universal, and it throws away every interactive element. If the dashboard has filters or hover detail, a screenshot is a picture of a dashboard rather than a dashboard. Reasonable for a Slack message that says "look at this trend". Not reasonable as a deliverable.
Send the .html file
Works when your client is technical and expecting it. Otherwise see why HTML files open as blank pages — the failure modes are numerous and none of them are your fault, which does not help when the client is confused.
Use the assistant's own share link
Claude and ChatGPT can both produce a share link without any setup, which makes this the path of least resistance. The trade-offs are worth knowing before you send one to a paying client:
- The page is hosted on the vendor's domain, not yours.
- Access can depend on the recipient having an account, which varies by product and plan.
- The link is tied to the conversation, so housekeeping on your side can break it.
- You get no view data and no ability to revoke it later.
For an internal look-at-this, fine. For client delivery, you are putting your work on someone else's infrastructure with no controls.
We compare these directly in Pagepost vs Claude's built-in publish and Pagepost vs ChatGPT canvas sharing.
Deploy it to a static host
Netlify, Vercel, Cloudflare Pages — all free, all real hosting. The right answer if you are shipping a site. Heavier than needed for one file going to one client, and you end up managing deploys for what is really a document. See Pagepost vs Netlify Drop.
Publish it as a link
Upload the file, get a URL, send it. The client clicks and sees the working dashboard — scripts running, charts live, on any device. It unfurls properly in Slack with a title and preview. You can revoke it when the engagement ends, set it to expire, and see whether anyone actually opened it.
What clients notice
Three things, in our experience, and none of them are the chart library:
It opens on their phone. Clients check things on phones. A downloaded .html attachment on a phone is close to unusable. A URL is not.
It has a real preview in Slack. A bare link with a title and description reads as a considered deliverable. A file attachment reads as homework.
It still works next month. Links that die between the engagement and the follow-up call are the ones people remember.
A practical workflow
- Build the dashboard in your assistant of choice.
- Check it renders the way you expect — paste it into the HTML viewer if you want to confirm before publishing.
- Publish it to a URL. If you have set up the connector, you can skip the download entirely and just say "publish it".
- Send the link, not the file.
- When the client asks for a change, revise and republish to the same URL. They keep the link they already have.
That last step is the one that changes how the work feels. The normal cycle — export, re-upload, send a new link, apologise for the new link — disappears. There is one URL for the dashboard, and it is always current.
When not to bother
If the dashboard is a throwaway you built to answer one question in a meeting, screenshot it. Not everything needs to be a deliverable, and the fastest good-enough answer is often the right one.
The moment it goes to someone outside your organisation, though, treat it as a deliverable, and deliver it as a URL.