Client Report Multichannel Delivery Automation: The Client Actually Gets It, on Three Channels

A report that exists inside a tool is invisible to the person it was written for until it actually reaches them — by an email they open, a notification they see, or a link they can hand to someone else internally. A delivery step that only changes an internal status to "sent" without genuinely sending anything leaves the client exactly where they started: unaware anything was produced for them at all, and left to log in and go looking on their own.

Genuinely delivering a report to an external recipient means resolving who that recipient actually is before doing anything else — a client's contact information changes, gets added, or was never entered as a dedicated recipient at all, so a delivery mechanism that assumes a fixed address will eventually send nothing to nobody or something to the wrong person. It also means treating the channels as independently fallible: an email provider can reject a message for reasons that have nothing to do with whether the report itself is fine, and a delivery mechanism that cannot tell the difference between "the report failed" and "the email bounced" will hide real problems behind a reassuring green status.

Before anything is sent, delivery resolves the actual recipient list: a dedicated list of report recipients takes precedence, and when none exists it falls back to the client's own registered contacts, with every recipient tagged by which source it came from so a team can see who is about to receive the report before it goes out. The report's PDF is then built — and only once recipients are resolved and the PDF exists does any channel actually fire, so a failure at either step blocks the whole delivery rather than sending half of it.

Email goes out through a dedicated service that authenticates with a timing-safe check, downloads the PDF to attach it as a genuine file (not just a link the recipient has to trust), and degrades gracefully — sending a link-only email and logging the reason — if the PDF download itself fails. A portal notification is inserted for the client whenever they have an actual login on file, so the report also surfaces where the client already looks. A public, token-based read-only link is generated on demand and can be included in the email or shared directly, without requiring a login. If the email specifically fails after the portal and status updates already succeeded, that failure is recorded and returned honestly — the whole delivery is not rolled back or reported as a false success, and a separate internal notification tells the team the same thing.

A team sends a ready report to a client with two recipients on the dedicated list and a portal login on file. Recipients are resolved, the PDF is built, and the email goes out with the PDF attached to both addresses — but the email provider rejects the send because of a temporary issue on their end. The portal notification still goes through, the report's status still updates correctly, and the team sees an internal alert naming the exact failure instead of a falsely reassuring "delivered." The client can still open the report from their portal in the meantime, and the team can retry the email once the provider issue clears.

A report being marked "sent" starts meaning something concrete and checkable — a specific set of resolved recipients, an attached PDF, and a record of exactly which channels actually succeeded. A partial failure on one channel is visible and actionable instead of hidden behind an internal status that cannot tell the difference between a genuine delivery and one that quietly failed.

A team that wants to choose per-send which of the three channels fire, beyond the built-in email/portal toggle, will find the channel set fixed to what is described here — there is no fourth channel (SMS, WhatsApp) built into this specific delivery path today. A client with neither a dedicated recipient list nor any registered contact email cannot receive the email channel at all — a valid address has to exist somewhere before delivery can resolve one.

Marking a report "sent" without actually delivering anything leaves the client no better informed than before, and a delivery mechanism that cannot separate "report failed" from "email bounced" hides exactly the problems a team most needs to see. Centriu Atlas instead resolves real recipients before sending, builds and attaches the actual PDF, fires three independent channels, and reports each one's outcome honestly — so "sent" means the client genuinely has a way to see the report, not just that a database column changed.