Use cases
Use cases start from a concrete insurance operations problem and show which Bevaya pattern solves it — the template to start from, the nodes that do the work, the integrations involved, how a person stays in the loop, and how to track the work once it's running.
Every use case follows the same shape under the hood. A flow is triggered, documents are read and prepared, an AI step classifies and extracts what matters, the flow matches or routes the result, a person reviews exceptions, and the work item is finalized — and, where it applies, data is written back to your system of record. The building blocks are the same across use cases; what changes is how they're composed and configured. See Platform concepts for the underlying model and Build AI Agents for how flows are built.
How to choose a starting pattern
Pick a use case by matching four things to your situation:
- The operational problem — what work are you trying to take off a person's plate?
- The source documents — what arrives, and in what shape?
- The system of record — does the flow need to look something up or write something back, and to which system?
- The review needs — how much human confirmation does the work require before it's trusted?
The patterns documented today are below. Each links to its full guide; start there for the template details, the released nodes it uses, the integrations to configure, the review model, and how to track runs.
Underwriting automation
Submission Intake — A new-business submission arrives as a packet of mixed documents (ACORD forms, SOVs, loss runs, supplementals, census, correspondence). The flow classifies each document, extracts the fields that matter per type, and produces a one-page underwriting briefing. No system match — it organizes the submission and hands a trusted data set to the underwriting process. Review fires on exceptions; underwriters verify and decide.
Claims automation
Claim-to-Policy Comparison — A new loss is reported as an FNOL package. The flow sets up the claim end to end (creates the claim, sets a reserve, assigns an adjuster, attaches documents) and assembles an AI coverage comparison against the policy in force. Matches to the policy in your carrier system and writes the claim back. The adjuster approves before anything is finalized — the comparison is decision support, not a determination.
Claim Indexing — Inbound claim mail (medical bills, legal correspondence, reports, photos) needs to be filed against the right existing claim. The flow classifies each document, matches the package to an existing claim (by claim number, or by claimant name and date of loss), and attaches the documents with the right tags. Unmatched or mixed packages route to a person. It never creates claims or touches reserves.
Claim File Summarization — Someone needs to come up to speed on a claim quickly — an adjuster handoff, a supervisor review, an exposure audit. The flow reads the whole claim file and produces a one-page briefing (loss event, investigation, financials, coverage, open actions). No system match; the summary lives on the work item and can optionally be written back. A reviewer confirms it.
At a glance
| Use case | Source documents | System of record | Writes back? | Review model |
|---|---|---|---|---|
| Submission Intake | Submission packet (ACORD, SOV, loss runs, supplemental, census) | None | No (optional) | Exceptions routed to review |
| Claim-to-Policy Comparison | FNOL package + policy declarations | Policy in force | Yes — creates claim, reserve, assignment, docs | Adjuster approves every claim |
| Claim Indexing | Inbound claim correspondence | Existing claim | Yes — attaches documents only | Reviewer confirms; no-match routed |
| Claim File Summarization | A full claim file | None | No (optional) | Reviewer confirms each summary |
This catalog grows as more templates are documented. If a workflow you need isn't listed here yet, you can still build it from scratch — see Create an AI Agent.
What's common to every use case
- Triggers. Each template ships with Manual File Upload for testing; production intake uses the Outlook Trigger, and runs can be started programmatically through the Bevaya API. See Configure triggers.
- Nodes. Classification and extraction use InsurGPT nodes; routing and looping use Control nodes; file prep, validation, API calls, and human review use Utility nodes; carrier connections use App integration nodes; and the work item is closed with an Action node. The Node catalog is the full map.
- Human in the loop. Exceptions and approvals route to a person via Flag for Human Review; reviewers work the Insights and Review tabs on the work item. See Human review.
- Tracking. Watch runs in Run history and counts by status in Item status reporting.
- Roles. Building flows requires the Admin or Partner role, with AI intelligence available to Admin; reviewers work items but don't build. See Users and access.
Reading this section by audience
- Executives — read the problem and "At a glance" sections to see which operational problems Bevaya addresses and where a human stays accountable.
- Implementation teams — read each guide's template, configuration, integration, and rollout sections to scope and deliver a deployment.
- Operations teams — read the review model and run-status sections to understand the day-to-day reviewer experience and how to monitor the work.
Where to go next
- Build AI Agents — how flows are built, tested, published, and run.
- Create an AI Agent — start from a template or build from scratch.
- Monitor and Review — run history, human review, and item status.
- Bevaya API — drive any of these workflows programmatically.
- Platform hierarchy and Users and access — set up your organization before you build.