Sending a deliverable to a client
The work is done and it's an HTML file — an analysis, an audit, a performance review, a scan. Now comes the part that costs you a day: the delivery.
The three usual routes, and what each costs
Email the file. Attachments over ~20 MB bounce, and HTML attachments in particular get quarantined by mail filtering because a self-contained HTML file with embedded script is exactly the shape of a phishing page — see emailing an HTML report. If it does arrive, the client can't open it on a phone.
Export to PDF. The interactive parts die: the sortable table becomes a screenshot of its first sort, the chart tooltips are gone, a 40-column table gets cropped at the page margin. You also lose every link.
Put it in the portal. Now the client needs an account, an invite, a password reset, and a support conversation before they see any of your work. Half of them never make it and ask you to just email it.
Publish it once instead
Drag the file — or the whole output directory, or a zip — into Comma. You get a URL:
- Renders faithfully, including scripts, inside a sandboxed iframe. The filters and charts still work — interactive HTML reports.
- Opens on a laptop and a phone, in one click, with no account.
- The client never pays and never signs up. Pricing is per publisher; viewers and commenters are free and unlimited.
Set the access to match the engagement
Per report, not per account:
| Situation | Setting |
|---|---|
| Draft, internal review only | private, invite the two people who need it |
| Sent to a named client contact | public visibility, link permission comment |
| Read-only final, no more feedback | public visibility, link permission view |
| Client is on your identity provider | domain visibility (Enterprise) |
| Engagement is ending | password + expiry on the link (Enterprise) |
Full model — five visibility levels, four link permissions, per-person roles that override the link — in sharing & access control.
Feedback that stays attached to the work
Comment permission means the client selects the paragraph or the number and replies there. The thread stays anchored across revisions, so when you re-publish, "this is the wrong baseline" is still sitting on the baseline. Compare that with the alternative, which is an email saying "see attached, comments in the third chart" — commenting on HTML and stop screenshotting reports.
You can answer in the thread. So can an agent, if you've wired one up — let an agent respond to comments.
Revisions, so "what changed" has an answer
Publish v2 to the same report id and the URL is unchanged — the client's bookmark, the link in your invoice email and the one in their Slack all still resolve. The old version stays as a revision you can diff. This is also how a monthly deliverable stops being a folder of near-identical files:
curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
-H "Authorization: Bearer $COMMA_API_TOKEN" \
-H "Content-Type: application/json" \
-d "$(jq -n --rawfile html report.html \
--arg title "Q3 review — Acme" '{title: $title, html: $html}')"
Or put it on a schedule and let the refresh happen without you — scheduled HTML reports.
Before you send anything client-facing
- Check the visibility is what you meant.
publicmeans anyone with the link; that's usually right for a client and never right for a draft. - If the report embeds credentials, internal hostnames or another client's data in a tooltip, that ships with it. A link is easier to revoke than an attachment, but it isn't a redaction step.
Try it
Comma is free — unlimited reports, unlimited commenters, unlimited revision history.
Publish a client deliverable →