Quick answer: A first notice of loss is a multi-channel notification problem, not a portal form. The policyholder reports the loss on the channel they are holding, expects a receipt in seconds, and then watches the claim move over messages they never had to chase. Devotel Orbit ships that sequence today: FNOL intake over a voice AI agent and two-way WhatsApp, a claims-status SMS cadence with link-outs driven by your claims system's events, RCS claim cards where the handset supports them with SMS as the floor, and a shared inbox that hands the thread to an adjuster with the full channel history attached. This post walks the shipped sequence in order and names the tenant-owned controls — consent classes, quiet hours, opt-out scope, verification — that decide how it runs in your market.
1) The FNOL moment arrives on whatever channel the policyholder is holding
The loss happens away from any portal: a cracked windshield at the roadside, water in the kitchen, a bag that never arrived at the carousel. A portal login is where first notices go to die, and a claims line that rings into a queue is where the policyholder learns the claim has a hold time before it has a number.
The intake that works meets the policyholder on the channel in their hand and moves the claim into one queue regardless of where it started. That is the shape Devotel Orbit ships for insurance: three intake lanes that write to one policyholder record and one tickets queue, so a claim started by voice is not lost when the policyholder follows up by text.
2) The shipped sequence: intake, status cadence, handoff
The FNOL and claims lifecycle walkthrough builds the program in the order it should be built. The sequence that matters for notifications is three moves.
First-notice intake. The voice lane answers the claims line with an AI agent that classifies the loss in one menu and captures what triage needs — date of loss, type of loss, whether anyone is injured or the property is still at risk — through slot-filling. An active risk gets a warm transfer to your emergency claims queue; everything else gets a captured FNOL plus an outbound SMS carrying the intake link, so the claim reference exists in writing. The WhatsApp lane carries the two-way FNOL: the policyholder describes the loss in free form inside the session window, your team or agent asks the structured follow-ups, and the document request follows — photos of the damage, the police or incident report, receipts. An SMS keyword such as CLAIM on the claims sender returns the receipt reply with the intake link and opt-out language for policyholders who start by text.
Claims-status SMS cadence with link-outs. When your claims system emits a status change, a segment-triggered journey keyed to the claim sends the next message in the cadence: an SMS status line with a link-out to the claim's status page or document upload. Handsets that support RCS get the claim-status card first — status, next action, adjuster contact, an upload action — and the fallback chain delivers the SMS status line when the card cannot. Emitting one event per status change with a stable claim id, and keying every journey condition on it, means an event on a closed claim can never touch a newer one.
Adjuster handoff via inbox. A policyholder reply on any channel — "when is the adjuster coming?" — opens or reopens a ticket on the claim in the shared inbox, with the SMS, WhatsApp, and voice history attached. The adjuster picks up the thread and answers in-thread, so the conversation the policyholder started by text does not restart on a phone call.
3) Consent and quiet hours are tenant-owned controls
Orbit provides the controls and enforces them at send time; it does not impose one posture on every tenant. The consent class of a message is your decision per line of business: which flows are urgent claims traffic that sends at any time — FNOL acknowledgements, a status update a policyholder is waiting on — and which lanes observe quiet hours, like renewals and cross-sell. A status update should not sit overnight behind a renewal lane's window, and the classification that prevents it is a setting you own.
The same posture applies when a policyholder replies STOP. Your cross-channel opt-out scope decides whether a stop taken on SMS also suppresses WhatsApp, voice, and email for that policyholder, and which classes survive it; the confirmation reply states what they will no longer receive and what still arrives. Frequency caps sit per lane, set apart from the urgent claims lane so a cap never silences a claim.
Which consent classes apply per line of business, and which flows count as urgent claims traffic, are decisions for your counsel and your compliance officer. The platform records the posture you set, enforces it at send time, and produces the exportable artifacts — consent and opt-out changes, send-gate refusals, quiet-hour holds — that go into your file. The consent and suppression surfaces are documented in consent management, quiet hours configuration, and opt-out lists.
4) The channel-mix math: SMS for status, WhatsApp for documents, email for the record
The three channels earn their place on different economics:
- SMS for status. It reaches any handset with no app installed, at a low cost per segment, which makes it the right carrier for the status cadence. The trade-off is plain text: the status line must read complete on its own, and the link-out carries the detail.
- WhatsApp for document upload. Media, delivered and read receipts, and a session window that makes the two-way follow-up cheap. The document request — photos, reports, receipts — belongs on the channel built for conversation-sized media.
- Email for formal notices. The record copy: formal notices and policy documents that need attachments and a durable thread, with the attachment size and type discipline that applies to the channel.
The ordering and the degradation between them is the fallback chain you configure once at the organization level; the router applies it to every send path. The per-channel failure taxonomy — which failures a chain can retry and which are terminal recipient states — is worked in full in the channel fallback matrix.
5) The fraud angle: verify the number before the claim details move
Claims traffic is a fraud target, and the phone number on file is the identity anchor the whole sequence relies on. The Verify API confirms the policyholder controls that number before claim details move, and the SIM-swap and related signals it checks ship with a cooldown window and an action on hit that you set: block the send, challenge further, or pass with the signal attached for your own risk engine. On claims-adjacent traffic that is a configurable posture, not a platform guarantee — your risk program names the policy, and every verification event carries the signal it passed or blocked on so your SIEM consumes the same decision surface the operator sees. The signal loop is covered in depth in the Verify API OTP and fraud-monitoring explainer.
6) Where to start
Start from the FNOL and claims lifecycle walkthrough: it carries the build order, the consent-class decisions to make before the first flow goes live, and the rollout checklist with the sandbox sign-off paths. The vertical surface lives at Devotel Orbit for insurance, and the wider buyer picture — renewals, premium collection by pay-by-link, wallet passes for policy cards, E911 on registered voice numbers — is in the insurance buyer explainer. Everything in this post is the shipped platform sequence, configured per tenant; the consent classes and the urgent-lane decisions are yours to set.