See Viola on your workflow.

Three steps. First, a 30-minute discovery call about your lines, states, and current stack. Then a live demo on a workflow like yours: quote-to-bind, an AI-triaged claim, or a rating change. Then a tailored rollout plan, with timeline, pricing, and a phased migration sketch. Each step is meant to remove a different unknown. The discovery call establishes whether the fit is real before anyone spends time on a demo. The demo is run against a workflow you recognise rather than a scripted happy path, so what you see is transferable to your own book. The rollout plan puts a shape on sequence and cost, including which desk to start with, so the decision to proceed is made against something concrete.

The lines you write, and the states you operate in or want to expand into. A rough picture of your current stack helps too: policy administration, rating, claims, billing, and any BPO or vendor dependencies. That is enough to run the demo against a workflow that looks like yours, rather than a generic script. None of it needs to be formal. A list of lines and states written from memory is more useful than a document assembled over two weeks, and the vendor dependencies are usually the most informative part: they say where the current cost and the current delay actually sit. If a specific frustration prompted the enquiry, naming it is the fastest way to make the demo relevant.

Real workflows, not slides. A submission going from data capture to a bound, paid, documented policy in minutes. A claim read, triaged, and routed by AI the moment it lands. A rating change moving through draft, review, and approval as an effective-dated version. The rating change is the one worth watching closely, because it is where legacy platforms usually reveal their constraints. Seeing a version move through approval and get scheduled with an effective date, rather than being applied in place, is the difference between rates as governed assets and rates as settings. The claim walkthrough is the same argument from the other end: OCR reading the report, extraction pulling parties and damages, rules assigning the adjuster with a reserve recommendation attached.

Viola is API-first. Every capability is exposed through clean APIs and real-time channels. It connects to CRMs, carrier portals, payment rails, and data providers. You can deploy it module by module instead of as a rip-and-replace. Carriers commonly start with one desk and expand from there. API-first is a statement about sequence rather than a feature list: the interfaces were not retrofitted onto screens built first, so anything the platform does internally is available to a system you keep. That is what makes a partial deployment viable. A desk running on Viola alongside a legacy core still reads and writes through the same record, so the integration does not become the new source of re-keying.

Yes. Email connect@regeninsurtech.com with a question about your operation, an integration you are weighing, or a request for a custom consultation. The contact form on this page reaches the same team. A question does not need to be a buying question. Teams weighing an integration, sizing a migration, or trying to work out whether their situation is a configuration problem or a platform problem are worth a conversation on their own terms, and the answer is sometimes that Viola is not the right fit yet.

MGAs, program administrators, carriers, and digital insurers. Typically these are teams replacing a policy administration system, planning multi-state expansion, or automating underwriting, claims, or billing without adding headcount. Personal auto is supported today, with commercial lines next. The common thread across those teams is a change they cannot make at the pace they want: a program that should be live this quarter, a state that should take a week, a claims queue that should not need another hire to absorb volume. If the constraint is the software rather than the strategy, the conversation is likely to be useful. If the strategy is still being settled, it usually is not, and the discovery call is the cheapest place to find that out.

In phases, not as a rip-and-replace. Viola is API-first, so it can be deployed one module at a time and run alongside what you have. Carriers commonly start with a single desk, prove it, then expand. The rollout plan you get after the demo includes a phased migration sketch for your stack, rather than a single cutover date. Phasing matters most for the risk it removes. A single cutover concentrates every unknown into one weekend, which is why legacy migrations acquire their reputation. Running a desk on Viola beside the existing core means the first phase is reversible: if something does not hold, the fallback is the system still running, not a rollback under pressure. Expansion then happens on evidence rather than on the original plan.

That depends on scope, and the rollout plan after your demo carries the timeline. What is fixed is the pace once you are running. A new state is configuration, not a project. A state launch takes five working days. Rate tables import on day 1, factors and rules on day 2, actuarial review on day 3, approval on day 4, first bind on day 5. The distinction worth drawing is between the initial deployment and everything after it. The first phase depends on your stack, your data, and how many desks you are moving, so it is scoped rather than quoted from a template. The five-day figure describes the steady state: once you are running, opening a state is configuration work with an approval trail, not a project with a business case.

Pricing is quoted per operation rather than published, because it follows your lines, states, volumes, and which modules you deploy. It is covered in the tailored rollout plan alongside the timeline and the migration sketch. For context on the economics, Viola targets a 30–45% cut in total cost of ownership against legacy platforms, largely from reduced BPO and vendor overhead. That is a benchmark target, not a per-customer guarantee. Pricing per operation rather than per seat follows from how the platform is used. A high-volume auto book with two desks live and a multi-line carrier running the full lifecycle are different commitments, and a published list price would have to assume one of them. The rollout plan is where the figure becomes specific, alongside the sequence it depends on.