Built on real submissions, not a demo dataset
RM Assistant automates submission intake for MGAs, program administrators and wholesale brokers. It was built inside a working commercial trucking program, against the documents brokers actually send.
Why this exists
Commercial insurance submissions arrive as email. Attached to that email is some combination of ACORD forms, loss runs from several carriers in several formats, vehicle schedules as spreadsheets or PDFs, MVRs, and supplementals that vary by program. Before anyone can price the risk, a person has to open all of it and re-key the contents into a policy administration system.
That step takes somewhere between 45 and 90 minutes per submission, and it is done by the most qualified and most expensive people in the building. It is not a technology gap that nobody noticed. It is a cost that the industry has absorbed for decades because the documents are genuinely messy and the tolerance for error is genuinely low.
The interesting part is not reading text off a page — that problem has been largely solved for years. The hard part is everything after: knowing that this page is an ACORD 127 and that one is a loss run, that a loss run has claim rows that must be itemised and merged across carriers, that a VIN decodes to a specific vehicle that should reconcile against the count on the application, and that the resulting record has to satisfy the schema of the system it is going into. That insurance-specific layer between raw text and a postable record is the actual product.
How it was built
RM Assistant was developed alongside a working commercial trucking MGA, on that program's live submissions. Commercial trucking was a deliberate starting point: it has the largest schedules, the heaviest multi-carrier loss runs, and the most rate-driving detail buried in narrative text. A pipeline that survives trucking has already handled the hard version of the problem.
It is now in production across commercial-lines programs, processing broker submissions end to end — from the inbound email through to a reviewed, structured record in the customer's own policy administration system.
Who it is for
MGAs and program administrators whose capacity is bound by how fast the intake desk can type. Wholesale brokers competing on response time. Operations leaders who can see that growth currently means hiring, and would prefer it did not.
It is a poor fit for teams that receive very few submissions a month, where the manual cost is small enough that automation is not worth the change, and for anyone looking for a system that binds business without a human in the loop. We do not build that.
What we hold to
Four commitments that shape what the product does and does not do.
A human approves before anything posts
We are not trying to remove underwriting judgement. We are removing the typing that happens before judgement can start. Every extracted field goes to a review queue with a confidence score and a link to its source page, and a person approves it.
Confidence, not a black box
A system that returns an answer with no indication of how sure it is cannot be operated safely in insurance. Field-level confidence is surfaced so low-certainty values get a human look instead of quietly becoming a mis-rate.
Your data goes into your system
We are the intake layer, not another silo. Structured records are pushed into the policy administration system your underwriters already work in. Submission data is isolated per customer and is not pooled or used to train shared models.
We say what is not built yet
Overstated integration claims survive a website and die in a proof of concept. Our integrations page states, per system, what is live in production, what is in development, and what gets built against your instance.
See it on one of your own submissions
30 minutes, a real submission from your book, the full pipeline while you watch. No slides, no pitch deck.
Book a demoNo sales pressure. We confirm within one business day.