Client Portal Notifications Clients Act On

A client portal holds the answers, but clients will not check it every day just in case something has changed. Notifications close that gap. A short email when a document is ready, an alert when an approval is waiting, a live status change on the screen a client is already looking at: these bring clients back at the right moment and stop them chasing your team for updates. Badly designed notifications do the opposite, flooding inboxes until clients filter them out. This guide explains how to design client portal notifications: which events deserve them, which channels to use, how to deliver real-time updates in the browser, how to let clients control what they receive and how to build the plumbing reliably, with a worked notification matrix.

Which events deserve client portal notifications

Notify clients when something needs their action or materially changes their situation. Good candidates include:

• An approval, signature or document is requested from the client
• A deliverable, report or invoice is ready
• A status changes in a way the client cares about, such as a shipment delayed or a project milestone reached
• A message arrives from your team
• Something is overdue, such as an unpaid invoice or an outstanding request

Overdue reminders deserve care: a polite first reminder and a firmer second one are usually enough before a person follows up. Do not notify for every internal update. A project moving from "internal review" to "quality check" may matter to your team but not to the client. Each notification should pass a simple test: would the client want to be interrupted for this?

Choosing channels

ChannelStrengthsBest forEmailReaches clients wherever they are; leaves a recordAction requests, documents ready, invoices, digestsIn-portal notificationsNo inbox noise; visible on next sign-inLower-priority updates, history of changesLive updates in the browserInstant feedback while the client is using the portalStatus changes, new messages, upload processingSMS or mobile pushHard to missUrgent, time-sensitive events only, with consent

Most portals use email for anything needing action, in-portal notifications for everything else, and live updates to keep open screens current.

Real-time updates in the browser

When a client has the portal open, changes should appear without a page refresh. Two common techniques are WebSockets, which allow two-way communication, and server-sent events, a simpler one-way stream from server to browser that suits notifications well. With server-sent events, the browser opens a connection and the server pushes small messages as events happen. In a front end, it can look like this simplified, untested illustration:

const source = new EventSource("/api/portal/events");

source.addEventListener("status", (e) => {
  const update = JSON.parse(e.data);
  updateStatusBadge(update.recordId, update.status);
});

source.addEventListener("chat", (e) => {
  showToast("New message from your account team");
});

The server sends only events for the signed-in user's organisation, checked on the server, and the browser reconnects automatically if the connection drops. The updateStatusBadge and showToast functions stand in for the portal's own interface code.

Letting clients control notifications

Different people in the same client organisation want different things. A finance contact wants invoice notices; a project manager wants milestone updates. Offer preferences by category and channel, such as "Invoices: email" or "Project updates: in-portal only", with sensible defaults. Let users choose an instant or daily digest for non-urgent categories. Never let preferences switch off notices that are contractually or legally required, and make those clear.

Writing notifications people act on

• Say what happened and what to do in the subject or first line, such as "Approval needed: change request 14 for the Leeds site"
• Link directly to the relevant page in the portal, not the home screen
• Keep sensitive details out of email bodies; link to the portal instead, where the client signs in
• Use a recognisable sender name and address, and set up email authentication so messages are delivered reliably

Building the plumbing

Notifications are triggered by events in back-office systems: a status changes in the project tool, an invoice is created in accounting, a message is added in the CRM. A reliable design receives those events, decides who should be notified according to rules and preferences, and sends through each channel, with each step decoupled by a queue. That way a slow email provider does not delay live updates, and a burst of events does not overwhelm anything. Record every notification sent, with its recipient, channel and delivery status, so your team can answer "did the client get told?" with evidence. Our guide to the webhook queue explains the queue-based processing behind this.

Guard against duplicates and storms. If an import updates 500 records at once, clients should not receive 500 emails. Group related events within a short window into one notification, and add rate limits per user.

Worked example: notification matrix for an architecture practice

Suppose an architecture practice runs a portal for clients on building projects. Its notification matrix:

EventWhoDefault channelCan opt out?Drawing issued for client approvalClient project leadEmail plus in-portalNoApproval overdue by three working daysClient project lead and their adminEmailNoMilestone reachedAll client project membersIn-portal; optional weekly digestYesInvoice issuedClient finance contactEmailNoNew message from practiceAddressed usersEmail plus live updateEmail can be switched to digestUpload processed or rejectedUploaderLive update plus in-portalYes

Events from the practice's project system flow into a queue, a rules service applies the matrix and each user's preferences, and senders deliver email and live updates separately. Bulk changes within five minutes for the same project are combined into one message. The events, defaults and window are this practice's choices, shown to illustrate the method.

Measuring notification quality

Track how quickly clients act after action notifications, how often they open the linked page, and opt-out rates by category. Rising opt-outs for a category suggest it is too frequent or not useful. Ask client-facing staff whether chasing calls have fallen for the events you notify about.

Common mistakes

• Notifying for every internal change
• Links that land on the home screen instead of the relevant item
• Sensitive details in email bodies
• No preferences, or preferences that allow switching off required notices
• Bulk updates triggering floods of messages
• No record of what was sent

For the portal as a whole, see our guide to client portal development.

Frequently Asked Questions

What notifications should a client portal send?

Notifications for actions the client must take, deliverables or invoices that are ready, important status changes, messages from your team and overdue items.

How do portals show real-time updates?

Typically with server-sent events or WebSockets, which push changes to the open browser so status and messages update without a page refresh.

Should clients be able to turn off portal notifications?

Yes for optional categories, by channel and with digest options, but not for notices that are contractually or legally required.

How do we avoid flooding clients with notifications?

Notify only for meaningful events, group related events within a short window, rate-limit per user and offer digests for non-urgent updates.

Keep your clients informed

We build client portals with reliable, well-judged notifications driven by your CRM and back-office systems. See our custom app development services, or talk to us about your portal.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.