Skip to main content
Between qualifying a lead and issuing a policy, an advisor does three pieces of advisory work. Need Analysis works out how much cover the client needs. Sales Illustration compares plans and their projected returns. E-Application turns the chosen plan into a binding proposal with nominees, KYC, and consent. This page covers all three.

Need Analysis: how much cover the client needs

A Need Analysis takes the client’s finances and works out the cover they should have and the gap versus what they hold today. Run it from Need Analysis in the advisor portal.

Field guide: the need analysis record

The recommended sum assured, coverage gap, human life value, risk profile and recommended product are all worked out for you from what you enter, and the existing-policies table nets off cover the client already holds. Once saved, a Create draft application button takes you straight to a pre-filled e-application for the recommended plan.

Sales Illustration: compare plans and returns

A Sales Illustration lets you put candidate plans side by side and compare their premiums and projected maturity values, so the client can choose with the numbers in front of them. Run it from Sales Illustration in the advisor portal.

Field guide: the sales illustration record

Each comparison row (an illustration line) shows the plan’s numbers:

E-Application: the binding proposal

The E-Application is the formal proposal to the insurer. It captures the chosen plan, the nominees, confirmation of KYC, and the client’s consent. It cannot be submitted without that consent. File it from E-Application in the advisor portal. It is filed against a lead, so no client record needs to exist first: submitting the application turns the lead into a client with a portal login.

Field guide: the application record

An application cannot be submitted without the client’s consent, and its nominee shares must total 100%. Confirm KYC and capture consent before you try to submit.

From application to policy

1

Advisor files the application against the lead

Complete the proposal with nominees, health declarations, confirmed KYC, and the client’s consent, then submit it.
2

The lead becomes a client

Submitting the application turns the lead into a client with a portal login (see Leads and conversion), then keeps moving through the same page.
3

Admin reviews and underwrites

An admin moves the application to Under Review and runs underwriting, and the system scores the risk and suggests a decision (Accepted / Refer / Declined) plus any premium loading, which the underwriter accepts or overrides. The first premium is also recorded on the application here.
4

Admin approves

Approval is allowed only once the pre-issue checklist passes: underwriting Accepted, KYC confirmed, nominees total 100%, and the first premium received. If anything is outstanding, the approval is blocked with a message naming it.
5

A policy is created

On approval the application becomes a policy, carrying over its nominees, cover and the underwriting loading. See Managing policies.

Who does what

Dependencies

  • Before you start: a lead to work from and an active product catalog to draw plans from. A separate client record is not needed up front: submitting the E-Application creates the client. See Leads and conversion and Product catalog.
  • What the application needs: confirmed KYC, the client’s consent, and nominee shares that total 100%.
  • What the application feeds: on approval it creates the policy that everything downstream (premiums, invoices, commissions) runs on.

Best practices

  • Do the Need Analysis first. A quick needs assessment before you illustrate plans gives a better recommendation and a cleaner application.
  • Illustrate more than one plan. Comparing a couple of plans side by side helps the client choose with confidence and reduces later second-guessing.
  • Confirm KYC and capture consent early. Both are required to submit, so handling them up front avoids a stalled application.
  • Get nominees right in the application. Shares must total 100% here, and they carry straight into the policy, so fixing them once at the application stage saves rework.