From submission to settlement. Every desk.

Under one week. Viola treats a new state as configuration, not an IT project. A Georgia expansion runs five working days. Day 1: rate tables imported. Day 2: state factors and rules configured. Day 3: actuarial review. Day 4: rate version approved and scheduled. Day 5: first Georgia policy bound. The platform enforces compliance guardrails throughout. Each of those days is work someone was always going to do; what changes is that none of it waits on a vendor release window. Rate tables are imported in bulk from the spreadsheets actuaries already maintain, rather than re-keyed into a vendor form. The version that results is effective-dated and approval-gated like any other, so a fast launch and a defensible audit trail are the same artifact.

Minutes, not days. A guided flow captures applicant, drivers, vehicles, and coverages. AI risk assessment applies your underwriting rules. Versioned, effective-dated rating prices the risk. One click binds the policy, with premium re-checked on the server. Underwriting time drops from days to minutes, with better consistency and pricing integrity. The consistency gain comes from the rules being applied by the platform on every submission rather than remembered by whoever picks the file up. The pricing-integrity gain comes from the server re-check: the premium presented at bind is recomputed against the governed rate version, so it cannot drift from what the approved rates actually produce. Payment is collected in the same flow, so a bound policy is a paid policy.

Viola targets a 40%+ lift in team productivity through end-to-end automation. It also targets a 30–45% cut in total cost of ownership against legacy platforms. Most of that comes from reducing BPO dependency and vendor overhead. These are benchmark targets the platform is built toward. They are not per-customer guarantees. The productivity figure assumes the automation actually removes steps rather than relocating them, which is why the platform is organised around whole desks rather than individual features: intake, extraction, routing, and the routine cases are handled end to end. The cost figure is dominated by two line items most insurers can name precisely, outsourced processing and vendor change requests, both of which shrink when products, rates, and rules become configuration.

A loss can be reported through any channel: customer portal, admin desk, or an email inbox. AI handles intake, triage, and routing the moment it arrives. OCR reads police reports, and AI extracts parties and damages. Rules auto-assign the claim to an adjuster, with a reserve recommendation attached. Duplicate detection, phase tracking, and acknowledgements run on their own. Adjusters get the cases that need them. FNOL is first notice of loss, the moment a claim enters the system, and it sets the cost of everything that follows: a claim that sits unrouted for two days is more expensive to settle than the same claim triaged on arrival. Handling it unattended is where most of the loss-adjustment-expense reduction comes from.

Four: Underwriting and Rating, Claims and FNOL, Policy Administration, and Billing and Payments. Together they cover 16 named capabilities. All four run on the same AI-native core. Work moves between them without a re-key, a ticket, or a handoff lost between systems. The desks are the unit deliberately, because that is how the work is actually organised and where the handoffs go wrong. Adoption does not have to arrive all at once: deploy the desk where the pain is, keep the rest, and expand when it has earned it. Because all four read the same record, a partial deployment does not create the very integration seam it was meant to remove. The 16 capabilities are named rather than counted loosely so that a deployment can be scoped against them. It is the difference between agreeing to modernise claims and agreeing to which parts of claims move first. Each desk also carries its own measurable outcome, so a deployment can be judged on its own terms rather than on a platform-wide business case. Underwriting is measured in quote-to-bind time, claims in loss-adjustment expense, policy administration in mid-term changes handled without rework, billing in premium collected at bind.

Yes. Products, rates, and rules are configured in the platform. Mid-term endorsements re-rate on their own. Renewals apply the correct rate version. Policy documents, ID cards, and state filings, including SR-22, are generated without a vendor ticket or a release window. The stated outcome is launching and changing products in days, not months. The dependency this removes is the one that sets the pace of most insurance roadmaps: when a rule change requires a vendor release, the release calendar becomes the product calendar. Configuration does not mean ungoverned, though. A change still moves through draft, review, and approve and carries an effective date, so removing the vendor from the path does not remove the control.

The policy is continued for a further term, priced against the rate version in force for that term. Viola applies the correct version on its own, so a renewal is never quoted off rates that were superseded months earlier. Premium is re-checked on the server. Payment runs through the same billing setup as the original bind, including installments and auto-pay. Applying the right version automatically is the part that is easy to underrate: on a legacy stack it is a common source of leakage, because a renewal quoted from stale rates is wrong in a way nobody notices until an audit. Effective dating makes the correct version a property of the term rather than a step someone has to remember.

By taking the manual handling out of a claim’s first hours. Loss-adjustment expense is what it costs to investigate and settle a claim, apart from the payment itself. OCR and extraction remove re-keying. Triage scores severity, coverage match, and completeness on arrival. Rules auto-assign the claim and attach a reserve recommendation. Duplicate detection, phase tracking, and acknowledgements run unattended, so adjuster time goes to the files that need it. The first hours dominate because that is when a claim is either routed correctly or not. A misrouted file accrues cost through every day it sits with the wrong desk, and the acknowledgement that was never sent becomes a complaint later. Automating arrival is cheaper than correcting it afterwards. The reserve recommendation attached at assignment matters for the same reason. A reserve set late, or set from an incomplete file, distorts the picture the whole book is managed against, and correcting it later is a second piece of work on top of the first.

Every rate version is effective-dated and frozen. It carries the base rates, factors, and rules for one product in one state, and it only prices policies after passing draft, review, and approve. Months later you can still show which version priced which policy, and who approved it. Privileged actions are logged, so the approval trail stands up alongside the rates themselves. The difference from a spreadsheet-driven process is that the evidence is produced as a by-product of pricing rather than reconstructed afterwards. There is no step where someone has to remember to archive the rates that were in force, because the version that priced the policy is the record, and it cannot be edited after approval. The same holds for the approval itself. Who signed off, and when, is captured as part of the privileged-action log rather than in an email thread alongside the system, so the two halves of the evidence stay together.