> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

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

> A program-level walkthrough for insurers and TPAs: FNOL intake over SMS, WhatsApp, and voice, claim-status journeys with RCS-first delivery, renewal reminders in their own lane, and the delivery evidence your claims file needs.

# 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.

> [!WARNING]
>
> 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.

## 1. Set consent classes per line of business first

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:

| Decision | What it controls | Where you set it |
| - | - | - |
| **Consent class per line of business** | Whether auto, property, life, or group messages are transactional claims traffic, service messages, or marketing. The class decides which sends need documented consent and what an opt-out silences. | [Consent management](https://docs.orbit.devotel.io/compliance/consent-management.md), [Send gates](https://docs.orbit.devotel.io/compliance/send-gates.md) |
| **Urgent vs. non-urgent lanes** | Which flows send at any time (FNOL acknowledgements, claim-status changes) and which observe quiet hours (renewals, cross-sell). A status update a policyholder is waiting on should not sit overnight behind a renewal lane's window. | [Quiet hours configuration](https://docs.orbit.devotel.io/guides/quiet-hours-configuration.md) |
| **Frequency caps per lane** | How many renewal or service touches one policyholder receives in a rolling window, set apart from the urgent claims lane so a cap never silences a claim. | [Frequency caps](https://docs.orbit.devotel.io/guides/frequency-caps.md) |
| **Cross-channel opt-out scope** | Whether a `STOP` taken on SMS also suppresses WhatsApp, voice, and email for that policyholder, and which classes survive it. | [Opt-out lists](https://docs.orbit.devotel.io/guides/opt-out-lists.md), [Message suppression](https://docs.orbit.devotel.io/guides/message-suppression.md) |

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:

```text theme={null}
FNOL intake
├─ SMS      keyword CLAIM → receipt reply + intake link → inbox ticket
├─ WhatsApp two-way description → structured details → document request
└─ Voice    triage IVR with slot-filling → capture, transfer, or callback
All lanes ────────────────┴→ one policyholder record, one tickets queue
```

### 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](https://docs.orbit.devotel.io/guides/keyword-rules-recipes.md). 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](https://docs.orbit.devotel.io/guides/inbound-sms-routing.md), 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](https://docs.orbit.devotel.io/guides/inbox-tickets-workflow.md).

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](https://docs.orbit.devotel.io/guides/email-attachments.md). Connect the WABA per [WhatsApp WABA setup](https://docs.orbit.devotel.io/guides/whatsapp-setup-first-waba.md) and operate the day-to-day conversation per the [WhatsApp workspace walkthrough](https://docs.orbit.devotel.io/guides/whatsapp-workspace-walkthrough.md); 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](https://docs.orbit.devotel.io/guides/build-ivr-flow.md): 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](https://docs.orbit.devotel.io/guides/ivr-slot-filling-intake.md). 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](https://docs.orbit.devotel.io/guides/segment-triggered-journeys.md). 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](https://docs.orbit.devotel.io/guides/rcs-rich-card-builder.md) and upgrade eligible recipients per [Upgrade SMS traffic to RCS per recipient](https://docs.orbit.devotel.io/guides/sms-to-rcs-upgrade.md). Recipients without RCS get the SMS status line through your [fallback chain](https://docs.orbit.devotel.io/guides/fallback-chains.md):

```text theme={null}
claim.status_changed (claim_id) → journey keyed on claim_id
  ├─ RCS eligible  → RCS claim-status card
  │     └─ undelivered → SMS status line
  └─ not eligible  → SMS status line
  Policyholder reply on any channel → ticket on the claim
```

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](https://docs.orbit.devotel.io/guides/campaign-journey-builder.md). Apply the renewal lane's quiet hours and a rolling cap, for example three renewal touches per policyholder per 30 days, with [frequency caps](https://docs.orbit.devotel.io/guides/frequency-caps.md), and let [message suppression](https://docs.orbit.devotel.io/guides/message-suppression.md) 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](https://docs.orbit.devotel.io/guides/message-suppression.md) 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](https://docs.orbit.devotel.io/guides/opt-out-lists.md).

## 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](https://docs.orbit.devotel.io/guides/delivery-log.md) for the claim-status and FNOL-acknowledgement lanes.
* Your own DLR record, written by a consumer per [Build a DLR-only webhook consumer](https://docs.orbit.devotel.io/guides/dlr-webhook-consumer.md), 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](https://docs.orbit.devotel.io/guides/audit-log-export.md). 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

| Go-live area | Insurance addition |
| - | - |
| Sandbox sign-off | Run the keyword FNOL, WhatsApp document request, IVR slot-filling, and RCS-to-SMS fallback paths against sandbox numbers, including the no-reply and fallback branches. |
| Number and sender readiness | Claims senders registered for the classes your counsel approved; WhatsApp templates approved for FNOL acknowledgement and document request. |
| Webhooks | Claim-status events signed, idempotent, and deduplicated on `claim_id`. |
| Sending guardrails | Renewal-lane quiet hours set, renewal frequency caps set, suppression lists loaded, urgent claims lane declared as its own class. |
| Access | Keyword, journey, and suppression-scope writes limited to `owner`/`admin`; consent-class decisions kept with the compliance officer. |
| Ops | Evidence export scheduled weekly; refusal rows reviewed as an incident queue. |

## Troubleshooting

| Symptom | Check |
| - | - |
| FNOL keyword gets no auto-reply | Verify the keyword is bound to the claims sender and sits ahead of the general support rule in [inbound rule precedence](https://docs.orbit.devotel.io/guides/inbound-sms-routing.md); check the match type against the [keyword worked examples](https://docs.orbit.devotel.io/guides/keyword-rules-recipes.md). |
| Policyholder got SMS although you built an RCS card | The device or carrier is not RCS-capable, or the card went undelivered and the fallback chain worked as designed. Confirm eligibility and the card's DLR in the [Delivery log](https://docs.orbit.devotel.io/guides/delivery-log.md). |
| Claim-status update held until morning | The update was classified into a lane that observes quiet hours. Fix the classification so claims traffic sits in the urgent lane; do not widen the renewal window instead. |
| Opted-out policyholder still gets renewals on WhatsApp | Your opt-out scope is channel-local. Widen the cross-channel scope in [message suppression](https://docs.orbit.devotel.io/guides/message-suppression.md), or record the per-channel decision in your consent model. |
| IVR intake returns with empty slots | Review the retry count, timeout, and DTMF-versus-speech capture settings in [slot-filling intake](https://docs.orbit.devotel.io/guides/ivr-slot-filling-intake.md). |
| WhatsApp document request never delivers | Business-initiated messages outside the session window need an approved template; check the template's category and approval state before the request flow. |

## See also

* [Industry landing pages: the buyer surface for each vertical](https://docs.orbit.devotel.io/guides/industries-overview.md) (the Insurance row)
* [Insurance buyer explainer](https://docs.orbit.devotel.io/blog/insurance-buyer-explainer-2026)
* [Devotel Orbit for insurance](https://orbit.devotel.io/en/insurance)
* [Build and ship your first IVR flow](https://docs.orbit.devotel.io/guides/build-ivr-flow.md)
* [Segment-triggered journeys: enroll segments into multi-step flows](https://docs.orbit.devotel.io/guides/segment-triggered-journeys.md)
* [Custom Opt-Out Keyword Lists](https://docs.orbit.devotel.io/guides/opt-out-lists.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.