Communications and reminders

The basic idea

A running program needs to keep people informed and moving — someone gets invited, a match is made, a session is coming up, a form is overdue. Rather than a program admin manually chasing each participant, the platform sends these messages automatically at the right moment. This automatic messaging has two parts that work together:

Communications — the actual messages: what gets said, in what wording, sent as an email and/or an in-app notification.
Reminders — the time-based nudges that repeat or escalate around a specific event (a session, a form, an evaluation) until it’s handled.

Both are orchestrated by the platform itself. A program admin configures what’s active and how it looks; the platform decides when to actually send, based on the state of the program (who was invited, what’s overdue, what’s coming up).

Communications: the messages

Every program has a catalog of possible messages it can send, organized into everyday categories such as onboarding/lifecycle moments (invited, welcomed, program wrapping up), sessions, packages of work, forms, matching, and goals. Each entry in this catalog is a distinct “moment” the platform can message someone about.

For each of these moments, a program admin can influence, at a high level:

Whether it’s active — a message type can be turned on or off for the program. If it’s off, that moment simply stays quiet.
Who receives it — messaging can be scoped to specific participant roles (for example, the person being supported, the person giving support, their manager, or an HR partner), so not everyone has to get every message.
Wording and branding — the subject and body text can be customized per language, and a message can carry a distinct visual template/branding so it matches the program’s look and feel.
Sender identity — a program can override the “from” name and address shown to recipients, rather than using the platform-wide default.

Message wording is written and stored per language, so the same moment can read naturally to participants in different locales rather than being a single fixed piece of text.

Configuration follows a layered pattern: sensible defaults exist out of the box, and a program can override them for its own participants without affecting other programs. Nothing needs to be built from scratch — an admin adjusts only what needs to differ for their program.

Notifications: how messages get delivered

“Communications” describes what is said; delivery of a message to a person happens through one or more channels — most commonly an email and/or an in-app notification (the kind a user sees inside the platform itself, e.g. via a notification bell). Which channels are used can vary by message type. This delivery layer is what “notifications” refers to: it is the platform’s job of actually getting a composed message in front of the right person, and it is a distinct piece of plumbing from the communications content itself, even though the two are tightly linked in the everyday experience of “the program sent me a message.”

Reminders: time-based nudges

Reminders are the more concrete, day-to-day mechanic admins interact with. A reminder is a scheduled nudge tied to something that’s expected to happen or be completed — and programs commonly schedule a series of reminders around the same thing rather than a single one-off message. Typical areas reminders cover:

Sessions — nudges as an upcoming session approaches (for example, at multiple points in the days before it), plus a nudge afterward to complete a session evaluation.
Matching — reminders while a match/handshake is pending confirmation.
Evaluations and forms — reminders to complete an assigned form or evaluation, escalating if it becomes overdue.
Completion/progress — nudges tied to a participant’s overall progress or inactivity, and general “program wrapping up” reminders as a program nears its end.

For each reminder, an admin can typically control:

Whether it’s turned on for the program.
Which roles receive it.
The timing pattern it follows, where the program exposes that control (for example, reminding at set points before a due date, or after a period of inactivity).
The wording used, following the same per-language, per-role customization as other communications.

Reminders follow the same per-language wording, branding, and role-scoping approach as other communications — a reminder is, in effect, a communication that is triggered on a schedule or by an overdue condition, rather than by a single one-time event.

Why this separation is useful for admins

Thinking of this area as two questions keeps configuration simple:

“Should this program mention this moment at all, and how should it sound?” — that’s communications: enable/disable, wording, branding, sender identity, audience by role.
“How often, and on what timeline, should we keep nudging about it?” — that’s reminders: cadence around sessions, matching, evaluations, and completion.

Both ultimately reach a participant the same way — an email and/or an in-app notification — so from the recipient’s side it just feels like “the program keeps me informed.” The admin-facing distinction is about which lever to pull: content and audience, versus timing and cadence.