What actually happens to a policy PDF after you upload it.
No black box. Below is every step a document takes through Insoora — what is read, what is handed back to you, how it finds its customer, and where the renewal date comes from.
- The original PDF is always kept
- Unclear fields are flagged, not guessed
- Access is checked on the server
- Nothing is shared without your action
The whole journey
One document, seven stops.
The seven steps in detail
Step 1
You upload the policy document
Sign in to the agent portal and drop in a policy PDF — one, or the whole folder that built up this week. The batch processes together and each file reports its own state.
Insurer-issued PDFs are the normal case. A photograph or a scan of a printed policy is accepted too, and goes down a different path at step 2.
A file that cannot be read does not stop the others. It is reported as failed and stays in the batch view so you can see what happened to it rather than discovering the gap months later.
Where this stops
Large files and long documents take longer. The batch view is where that progress is visible; there is no email when it finishes.
Agent portal — Upload Sample dataStep 2
Insoora reads the fields off the page
The document's own text layer is parsed first: policy number, insurer, insured name, cover start and expiry, premium, and the vehicle or asset the policy covers.
When a page carries no text layer — a scan, or a photograph of a printed schedule — OCR runs over the image and the result is parsed the same way.
Each field is saved against the policy with the original PDF attached. The record and the document it came from never separate, which is what makes a disputed value checkable rather than arguable.
Where this stops
Accuracy depends entirely on the document. Insurer-issued digital PDFs read best; a phone photograph of a creased printout reads worst. Insoora publishes no accuracy figure, because it does not measure one it could stand behind.
Agent portal — Extracted details Sample dataStep 3
Anything unclear is handed back, not guessed
A field the parser cannot read confidently is marked as needing review. It is shown beside the part of the document it came from, and you confirm it or correct it.
This is the step most products skip, and skipping it is how a wrong expiry date ends up in a renewals list looking exactly as trustworthy as a right one.
Confirming is one click. Correcting replaces the value on the record — never on the PDF, which stays as issued.
Where this stops
A flagged field that is never confirmed stays unverified, and anything downstream of it — including the renewal date — is only as good as the extraction behind it.
Agent portal — Review a flagged field Sample dataStep 4
The policy is filed under the right customer
A policy finds its policyholder by the mobile number printed on the document, matched against the number you already hold for that customer.
When it matches, the policy joins that customer's record and stacks up alongside whatever else they hold, across insurers and across years.
In an agency, sub-agents upload into the same book of business. The agency sees all of it; each person sees only what their role allows.
Where this stops
When no number matches — it was misread, or it is not the one on file — the policy waits in an unassigned list for an agent to pick the customer. It is not filed under a best guess.
Agent portal — Filing a policy Sample dataStep 5
You search, filter and work the list
Find any policy by customer, insurer, policy number, status or expiry window, then sort the result and act on it.
Filters live in the URL, so a view you built can be bookmarked or sent to a colleague with the same access and it opens the same way.
The same filters drive the renewals view, which is what turns a search into this week's working list rather than a one-off lookup.
Where this stops
Search covers the fields Insoora extracted and the customer record. It is not a full-text search inside the body of every PDF.
Agent portal — Policies Sample dataStep 7
Expiry dates stay in view
The renewals view lists policies ending within the next 30 days, sorted by date — built from the expiry printed on the policy itself, not from a reminder somebody remembered to set.
Because the date comes from the document, a policy that was uploaded in March and forgotten about still appears when its month comes round.
The list exports, so the week's renewals can leave the screen as a CSV and go into whatever you already use to make calls.
Where this stops
Insoora does not send reminders. There is no automatic email, SMS or push notification — the renewals view is a list you open, and that is the whole of the mechanism.
Agent portal — Renewals Sample data
Getting started
What the first week actually looks like
No migration project and nothing to install. The honest answer is that you find out how well it reads your insurers by giving it your insurers' documents.
- Day 1
Upload ten policies you know well
Pick a spread of insurers and a mix of digital PDFs and scans. You are testing the layouts you actually receive, not a demo file.
- Day 2
Work the flagged fields
Confirm or correct whatever came back for review. This is the step that tells you how much attention the product will really cost you each week.
- Week 1
Open the renewals view
Once a month or two of policies are in, the expiry list stops being empty and starts being the reason to open the product at all.
Before you assume
Four things this workflow does not do
Each of these is something readers regularly expect from a product described this way. None of them is implemented, so none of them is promised.
It does not notify anyone
No reminder email, no SMS, no push. The renewals view is a list you open. If a notification ever ships, this page will say so.
It does not talk to insurers
There is no integration with any insurer's system. Everything Insoora knows about a policy, it read off a document you gave it.
It does not renew anything
Insoora surfaces the expiry date. Issuing or renewing cover is between you, your customer and the insurer, exactly as it was.
It does not learn your layouts by itself
A stubborn insurer layout is fixed by an administrator writing a rule for it. No model is trained on your documents.
The features page covers each capability and its limits at length, and the FAQ answers the questions agents ask before signing up.
See the screens
Every view in the workflow above, drawn at full size with sample data.
Product in actionThe only honest test is your own insurers' PDFs.
Create an agent account, upload a handful of policies you know by heart, and see how much of each one comes back right.