The agency management portal is the agent portal, with a team inside it.
There is no separate agency portal in Insoora, and this page starts by saying so. The main agent account is the agency — it holds the plan, the credits and every policy — and its sub-agents work in the same portal with the capabilities the agency granted them. Here is what that looks like, screen by screen.
- One account holds the agency's whole book
- Sub-agents in the same portal, not a separate one
- Eight capabilities, granted one at a time
- Two cannot be delegated at all
On this page
Read this before the screenshots
Insoora has three portals, and none of them is an agency portal
If you came here expecting a fourth sign-in with an agency dashboard behind it, that is not how the product is built.
The three portals are the agent portal, the customer portal and the back office. An agency does not get one of its own, because an agency is not a separate kind of account — the main agent account IS the agency. It holds the subscription, it holds the policy credits, and it holds every policy that anybody on the team uploads.
A sub-agent is an employee of exactly one agency. It signs into the same agent portal, sees the agency's book, and can do whatever the main agent granted it and nothing else. It has no plan, no credits and no book of its own.
That is a simpler structure than most agency software, and the simplification has a consequence worth naming plainly: a sub-agent cannot take their policies with them, and the agency cannot be divided into branches or regions. The hierarchy is exactly two levels deep, and if your business needs three, this is not the shape of software you need.
Why the page exists at this address anyway
Because "agency management portal" is what people call the thing they are looking for, and the useful response to that search is an explanation of how it really works rather than nothing at all.
Every screen below is a real screen in the real product, labelled with the portal it is actually in. Nothing on this page is a drawing of an interface that does not exist.
The one agency-specific screen
Sub-Agents: who is on the agency and what they can do
It appears in the sidebar only on a main agent account. This is where delegation actually happens.
The team screen lists everyone on the agency with the capabilities each person holds and how much they have uploaded. Adding a person creates a sub-agent account tied to this agency; there is no invitation to an existing account and no way for a sub-agent to belong to two agencies.
A new sub-agent starts with read access to the agency's book and nothing more. Every further capability is granted individually, which means an agency can staff a role precisely — somebody who uploads but does not confirm, somebody who reviews but never sees an unmasked phone number, somebody who only reads.
The grants are not a convenience for the interface. Each one is a permission checked on the server for every request, so hiding or showing a sidebar entry can never widen what an account is able to do.
- Every person on the agency, with their capabilities and upload count
- A new sub-agent can read and nothing else until granted more
- Permissions checked server-side on every request, not enforced by the sidebar
What it does not do
There is no role template, no copy-permissions-from and no bulk grant. Each capability is set per person, which is fine for a team of five and tedious for a team of thirty.
What an owner looks at
Three screens an agency runs on
All three are in the agent portal. The first is main-agent only; the other two are the whole agency's book, seen by anyone with access to it.
Sub-Agents — the team
Who is on the agency, what each was granted, and who is actually uploading.
Dashboard — the agency's position
The plan and credit balance, how many documents are processing, how many need review, and what failed. On a sub-agent's screen these figures are the agency's.
Policies — one shared book
Everything the agency has processed, whoever uploaded it, searchable and filterable as one list.
The whole delegation model
What a main agent has, what a sub-agent can be given
This is the complete list. There is nothing else to grant, and the last two rows cannot be granted at any level.
| Capability | Main agent | Sub-agent |
|---|---|---|
| Read the agency's policies and documents | Yes | Yes — from the moment the account exists, without being granted |
| Upload policy documents | Yes | Grantable. Uploads spend the agency's credits and the policies belong to the agency |
| Process and review extractions | Yes | Grantable, as two separate capabilities |
| Confirm an extraction into a policy record | Yes | Grantable — and the one most agencies keep central while they learn how their insurers read |
| Assign a policy to a customer | Yes | Grantable. This is what clears the queue of policies whose mobile number matched nobody |
| Export to CSV, and export to Excel | Yes | Grantable, as two separate capabilities |
| See unmasked customer contact numbers | Yes | Grantable. Withholding it lets a reviewing role be staffed without handing over phone numbers |
| Manage sub-agents | Yes | Never. Cannot be granted |
| Billing: plan, credits, payment settings | Yes | Never. Cannot be granted |
An export always follows the access of the person who ran it, so a sub-agent's export can never contain a policy they could not already open on screen.
Setting an agency up
The order that avoids rework
Five steps. Doing the first one second is the mistake worth avoiding.
- 1
Create the agency account first
Register as an agent. This account will hold the plan, the credits and every policy, so it should belong to the business rather than to whoever happened to sign up — a sub-agent account cannot be promoted into it. - 2
Upload a handful of policies yourself
Before anyone else touches it, find out how your insurers' layouts read. That ratio of clean to flagged decides how you want to split uploading from confirming. - 3
Add the people, grant nothing yet
A new sub-agent can read the book immediately. Let them use it that way for a few days; it is often enough for the role they are actually doing. - 4
Grant upload, then decide about confirm
Upload is the capability that removes work from you. Confirming is the one that carries judgement about a figure a customer may later dispute — keeping it central at the start and devolving it later is the common arrangement. - 5
Decide about contact numbers deliberately
Unmasking customer phone numbers is its own capability. It is worth being a decision rather than something handed out with everything else.
Where the structure stops
What an agency cannot do here
Four structural limits. None of them is a setting that can be changed.
No branches, regions or sub-sub-agents
The hierarchy is exactly two levels: an agency and its sub-agents. A multi-branch business cannot model its branches, and a sub-agent cannot have people under it.
No per-person ownership
Every policy belongs to the agency. A sub-agent who leaves takes nothing with them, which is usually the point — but it also means Insoora does not fit a network of independent agents who each want their own book.
No commission, payouts or performance views
Uploads are attributed to the person who made them and a commission rate on a document is stored, but there is no calculation, no split between sub-agents, no payout statement and no per-person revenue reporting.
No task assignment or internal messaging
The review queue is a shared list, not a workflow. Insoora does not assign work to a sub-agent, track a follow-up, or notify anybody that something needs doing.
Frequently asked questions
Questions this page should answer
Keep reading
Where to go next
The pages that cover the next part of this, with what each one adds.
Register the business, then add the team to it.
The account you create holds the plan, the credits and the whole book — so start with the right one.