Skip to main content

​
Build an end-to-end FNOL and claims lifecycle program

You run policyholder communications for an insurer or a third-party administrator. A policyholder who just cracked a windshield or took water in the kitchen expects to report the loss in two messages and watch the claim move without phoning anyone. This guide composes the pieces Devotel Orbit ships for that program — keyword-driven FNOL intake, two-way WhatsApp document requests, a voice triage IVR, segment-triggered claim-status journeys, RCS claim cards with SMS fallback, capped renewal reminders, cross-channel opt-out, and delivery evidence — into one reference, in the order you should build them. Each part has its own deep guide. This page is the program-level order of work; if you only need one lane, start from that lane’s guide.
This guide describes Devotel Orbit platform controls. It is not legal advice. The consent classes per line of business, which flows are urgent claims traffic, and the evidence your regulator or claims-handling rules expect belong to your counsel and your compliance officer. Every control below is tenant-owned: you choose the classes, you operate the gates, and you own the retention decision.
The consent class of a message is a tenant-owned decision, set per line of business. Orbit provides the controls and enforces them at send time; it does not impose one posture on every tenant. Make four decisions before you build any flow: Write these into the workspace before the first flow goes live, because every lane below inherits them.

​
2. FNOL intake across three lanes

Run FNOL intake as three lanes that write to one policyholder record and one inbox queue, so a claim started by voice is not lost when the policyholder follows up by text:

​
SMS keyword lane

Create a single keyword such as CLAIM on your claims sender, following the match types and precedence in the keyword auto-reply worked examples. The auto-reply confirms receipt, sets the next-step expectation, and carries your intake link and opt-out language. Then make the inbound message actionable: order your inbound rules so the FNOL keyword lands ahead of general support traffic per Route inbound SMS with priority-ordered rules, and open a ticket for every FNOL so the queue gets an SLA the way a support queue does, per Operate the Inbox Tickets queue. Keep the keyword set to one word. Every extra keyword is a misspelling you will support at 11 p.m. when a policyholder meant to start a claim.

​
WhatsApp lane

WhatsApp carries the two-way FNOL: the policyholder describes the loss in free form inside the session window, your agent or team asks the structured follow-ups, and the document request follows — photos of the damage, the police or incident report, receipts. The discipline for those attachments, what you accept and how large it may be, is the same discipline documented for email in Email attachments: file size, MIME types, and encoding. Connect the WABA per WhatsApp WABA setup and operate the day-to-day conversation per the WhatsApp workspace walkthrough; use approved templates for any business-initiated follow-up outside the session window.

​
Voice triage lane

Build the FNOL IVR per Build and ship your first IVR flow: greet, classify the loss type in one menu, then collect the details that matter for triage (date of loss, type of loss, whether anyone is injured or the property is still at risk) with slot-filling per Collect structured intake in an IVR with slot-filling. Route on the captured slots: an active risk gets a warm transfer to your emergency claims queue; everything else gets a captured FNOL plus an outbound SMS with the intake link, so the policyholder has the claim reference in writing. Offer a callback slot for policyholders who would rather talk to a person. Schedule callbacks inside the federal calling window; the platform blocks outbound voice outside it regardless of tenant settings. Inbound FNOL calls are caller-initiated and are not subject to it.

​
3. Claim-status updates: segment-triggered, RCS-first

When your claims system emits a status change, enroll the policyholder in a journey keyed to the claim per Segment-triggered journeys: enroll segments into multi-step flows. Emit one event per status change with a stable claim_id, and key every journey condition on that id so an event on a closed claim can never touch a newer one. Deliver the update rich-first: build the claim-status card (status, next action, adjuster contact, upload-document action) in Build rich RCS cards in the visual builder and upgrade eligible recipients per Upgrade SMS traffic to RCS per recipient. Recipients without RCS get the SMS status line through your fallback chain:
A fallback send is still a send: it must pass the same consent and suppression checks as the primary. Because status updates sit in the urgent claims class you declared in section 1, quiet hours do not hold them.

​
4. Renewal reminders in their own lane

Renewals are a service lane with marketing-adjacent discipline, and they must not share configuration with the claims lane. Build the reminder sequence (a workable default is T-30, T-14, and T-3) with Build, simulate, and launch a campaign journey. Apply the renewal lane’s quiet hours and a rolling cap, for example three renewal touches per policyholder per 30 days, with frequency caps, and let message suppression absorb opt-outs, renewed policies, and manual exclusions. End the sequence on a renewed event keyed to the policy id, so a policyholder who renewed by phone never gets the T-3 nudge. The separation cuts both ways: the urgent claims lane does not inherit renewal caps, and a policyholder who opted out of marketing still receives the claim-status updates your consent classes declare transactional.

​
5. Cross-channel opt-out propagation, worked example

A policyholder replies STOP to an SMS renewal reminder. The sequence your configuration produces:
  1. The keyword write lands the SMS destination in your opt-out list, and one confirmation reply goes out stating what they will no longer receive and which classes (for example transactional claim notices) still arrive.
  2. Message suppression blocks later renewal sends to that destination across every campaign, not just the one that took the opt-out.
  3. Your cross-channel scope decides the radius: configured cross-channel, the same policyholder’s WhatsApp, voice, and email renewal sends are suppressed too; scoped per channel, the WhatsApp renewal lane still sends, and that is a decision your consent record should be able to explain.
  4. A claim-status update two days later is affected or not exactly as the consent classes you declared in section 1 say.
Test this matrix in sandbox before go-live: opt-out on each channel, against each class you declared. The semantics, custom keywords, and re-opt-in behavior live in Custom Opt-Out Keyword Lists.

​
6. Day-two monitoring and the evidence file

Assemble evidence on a cadence, not on demand. A weekly export is a workable default for an active claims workspace:
  • Per-message delivery outcomes from the Delivery log for the claim-status and FNOL-acknowledgement lanes.
  • Your own DLR record, written by a consumer per Build a DLR-only webhook consumer, keyed on claim_id so delivery sits inside the claim file instead of a vendor console.
  • Consent and opt-out changes, send-gate refusals, and quiet-hour holds, pulled through Audit Log Export. That export is the policyholder-record evidence your regulator or claims-handling rules expect.
A refusal row is not a defect by itself: it means a class and a send disagreed, or compliance work is pending, and the row tells you which.

​
7. Rollout checklist

​
Troubleshooting

​
See also