Guide · Client delivery

How to send a client a link to an AI-generated deliverable

Your agent just built the report, the dashboard, the analysis — and now you have to hand it over. Attaching a file to an email feels amateur, clutters the client's inbox, and tells you nothing about whether they ever opened it. There's a cleaner way to deliver.

When you publish a document with freo.cloud, you hand your client a clean, shareable link instead of an email attachment — no download, no hosting on your side. You choose who can open it, it renders as a branded page under your handle rather than a raw file, and every open is recorded. It's the professional way to send an AI-generated report: one link you control, locked to the right person, that looks like your work.

On a chat app like Claude.ai or ChatGPT instead of a coding agent? Connect the MCP server with one-click OAuth (no token) — then the same "just ask it to publish" flow applies.

Why not just email the file

An attachment is the path of least resistance, and it quietly costs you: once the file leaves your outbox you can't tell if the right person opened it, take it back, or fix a typo without sending "v2 final (updated)." A link sidesteps all of it — one address, always current, that you decide who can reach. It keeps the client's inbox clean and keeps copies of your work from scattering across email chains you can never fully claw back.

Lock it to the client

A client report usually isn't meant for the whole internet, so you set an access level to match — public, an unguessable unique link, email-verified, or a named allowlist for the tightest cases. Because access is a setting on the document, you can change or revoke it instantly without touching the link; the full menu is in the guide on access control for AI files.

Make it look professional

freo renders your report, dashboard, or HTML in a clean branded viewer — with a table of contents, in-page search and syntax-highlighted code — served from your space and shown under your handle, so the client clicks the link and is reading a considered page — nothing to install, no download step. That first impression is the difference between "here's an attachment" and "here's the work," and it comes with the link at no extra effort. When the deliverable was assembled by an agent, the viewer is what makes it look unmistakably like yours.

Know when they've read it

Every published document keeps its own view record, so you can tell whether the client opened the link before you follow up or invoice — a unique link shows opens, while an email-verified or allowlist document shows which named person opened it. See how to tell if someone opened your shared link for the detail.

Revise without resending

Deliverables change — a client asks for a tweak, a number gets updated, a section gets rewritten. With a link you update the document in place and the URL stays exactly the same. The client refreshes and sees the current version; there's no "v3 final" chain, no re-sending, no risk of them reading the wrong copy. The one link you gave them is always the live one.

Retire it when the engagement ends

A client link shouldn't live forever, so you can set a deliverable to auto-expire — once the project wraps the link stops working and no orphaned copies linger after the invoice is paid, while you keep the document in your space. See auto-expiring share links for how to set it.

A worked example

You don't touch a dashboard to do any of this — you ask your agent in plain language, in the same session where it built the deliverable. Once you've connected your space, the whole flow is a sentence, and the agent handles publishing, access, and the link for you:

• →"Publish this proposal and share it with angela@acme.com." — the agent publishes the document, sets it to that named viewer, and hands you back the link.
• →"Update the shared proposal with these revised numbers." — same link, new content, no resend.
• →"Expire the client report at the end of the month." — the link retires itself when the engagement closes.

Questions