loss.run

Start a loss run request in thirty seconds

Ask an account manager how a loss run request starts and you will usually hear the same steps. Open the account. Find the insured's legal name. Dig up the prior carriers from the last submission, an old dec page or an email thread. Type all of that into a request form or letter. Work out who needs to sign. Get the signature. Then send it.

None of those steps is hard. Most of them are retyping. The agency already knows who the insured is and who wrote their coverage before. That information lives somewhere, and the request makes you copy it out again by hand.

loss.run, the loss-run tool in the PolicyOS family, is built to cut that part out. Here is how starting a request works.

Step one: type the insured's name

You start with the one thing you always have: the insured's name. Type it in, and loss.run finds the insured on InsureBio.

Once it has found them, it fills in their prior carriers. You are not opening a second system, searching an old submission or copying carrier names from a PDF into a form. What InsureBio already knows about the insured comes across into the request.

That is the whole point of this step: an agency starts a request without retyping what InsureBio already knows.

Why prefilled prior carriers matter

Retyping is slow, but the bigger cost is what retyping does to accuracy. When prior carriers are entered by hand, a few things tend to go wrong:

  • A carrier gets left off because it was only on the policy for one term.
  • A name is entered in a slightly different form than the one on the policy.
  • Two people on the same account each start a request from different notes and end up with different lists.

Each of those turns into a follow-up later: a request that went to the wrong place, or a loss history with a gap in it that someone has to notice and chase. Starting from what InsureBio already holds means the request begins from the same record every time, instead of from whoever happened to remember the account best.

You still look at what was filled in. You know the account, and the request is yours to send. The difference is that you are reviewing a list rather than building one from scratch.

Step two: answer broker of record, per policy

With the insured and their prior carriers in place, loss.run asks one question: broker of record.

It asks it per policy, not once for the whole request. That matches how accounts actually look. An insured can have several policies with several carriers across several years, and your agency's position may not be the same on every one of them. Answering per policy lets the request reflect that, rather than forcing a single yes or no across lines and terms that differ.

A note on what this step is and is not. loss.run records your answer so the request is set up correctly. It does not decide broker-of-record questions for you, and nothing here is advice on how a broker-of-record situation should be handled. If an account has a dispute or an open question about who the broker of record is, that is something to work out through your agency's usual process before you send.

Step three: send

Once broker of record is answered for each policy, you send the request.

That is the end of the agency's part of starting it. Name, review the prior carriers, answer broker of record per policy, send. The working title of this post says thirty seconds, and that is about this part: the time it takes you to start a request when you are not retyping anything.

It is worth being clear about what that number does not cover. How long a carrier or MGA takes to answer a loss run request is up to the carrier or MGA. loss.run does not set that timeline, and neither does this post. What it changes is how long the request takes to leave your desk.

Step four, if needed: the insured signs once, from their phone

Some requests need the insured's signature. When one does, the insured signs once, from their phone.

This is the step that tends to stall requests. A signature request goes out as an attachment, the insured needs to print it or find a way to sign a PDF, the email sits, and the account manager follows up. Then follows up again.

Asking for a single signature that the insured can give from the phone they already have in their pocket removes most of that friction. They do not need a printer, a desk or a second request for each carrier. They sign once.

And when a signature is not needed, this step does not appear.

What this looks like on a busy renewal desk

Picture a week with several renewals and a couple of new prospects that need loss history before you can market them. Under the usual routine, each of those requests starts with the same ten minutes of looking things up and typing them in, plus a signature chase on top.

With loss.run, each request starts the same way:

  1. Type the insured's name.
  2. Check the prior carriers it filled in from InsureBio.
  3. Answer broker of record for each policy.
  4. Send.
  5. If a signature is needed, the insured signs once from their phone.

The requests are consistent, because they all start from the same record. They are faster to start, because you are not copying data between systems. And the signature, when there is one, asks less of the insured.

For the people answering requests

Carrier and MGA staff who handle loss run requests see the other side of all this: requests with a misspelled insured name, a missing policy, or no clear answer on who the broker is. A request that starts from an existing record, with broker of record answered per policy, is a cleaner request to receive.

Try it on your next request

The next time a loss run is on your list, start with the insured's name and see how much of the request is already done. More on this workflow is at https://loss.run/blog/start-a-loss-run-request-in-thirty-seconds.