The story
Most applications are standard. The model is about the rest.
A customer sends an application for a new policy. Sales enters it in the CRM and passes it to underwriting, where the risk is assessed with a risk tool: the object, the sum insured, the history. The first gateway asks whether this is a standard risk. For most applications the answer is yes, and the policy administration issues the policy in the policy system. The customer receives the document and the process is over.
For the rest, the model shows the exception path. A non-standard risk gets a four-eyes review: a second underwriter looks at the assessment before the organisation commits. That review is the control step, drawn in blue. It ends in a second gateway, accept the risk or not. If accepted, the application joins the standard path and the policy is issued. If not, sales declines the application and the customer receives the decline.
Four lanes carry this: the customer, who starts the process and receives the result; sales, who records and, where needed, declines; underwriting, who assesses and reviews; and policy administration, who issues. The two decisions both sit with underwriting, which is where the knowledge is.
This is a fictional example model. A real onboarding would add medical or technical questionnaires, broker lanes, premium calculation and payment set-up. The example keeps to the shape that matters: a fast standard path, a controlled exception path, and a clear point where they rejoin.
The diagram
The model as BPMN 2.0.
Two gateways in the underwriting lane. The first sends standard risks down to policy administration straight away; the second closes the exception path. Both yes branches end in the same task, Issue policy, so there is one way to issue a policy, not two.
Elements used
What is in the model, and why.
The model has ten nodes. Each of them is there because leaving it out would hide a role, a decision or a control.
Lanes: Customer, Sales, Underwriting, Policy admin
Four roles. Sales and policy administration are separate lanes because they are separate teams with separate systems; merging them would hide the hand-over after the decision.
Gateways: Standard risk? and Accept risk?
Two exclusive gateways. The first splits the standard path from the exception path; the second ends the exception path. A reader can see at once that a standard risk never passes the review.
Control step: Four-eyes review
The blue task in the underwriting lane. It stands for a rule, not a skill: a second qualified person must look before a non-standard risk is accepted. The .bpmn file marks it as a control step in the documentation.
Systems: CRM, risk tool, policy system
Three systems on three steps. The application is entered in the CRM, assessed with the risk tool, issued in the policy system. The review itself has no system under it: it is reading, judgement and a signature.
End events: Policy received, Decline sent
The happy end sits with the customer, the decline with sales, who sends it. Two end events make the two outcomes countable later; one shared end event would not.
Where the process waits
What to look at in an onboarding model.
The standard path is short. The questions in a workshop are about the exception path and about the hand-overs around it.
What counts as standard?
The first gateway hides a rule. If nobody can say the rule out loud, every underwriter decides differently, and the exception path grows. The model makes the question visible; the answer belongs in the step's documentation.
The second pair of eyes
A four-eyes review needs a second person who has time. If the same senior underwriter reviews everything, non-standard applications wait in one queue. The blue step is where to look.
Re-typing between systems
CRM, risk tool and policy system are three names on three neighbouring steps. Where the data is carried by hand, the model shows the seams.
The decline goes back to sales
Underwriting decides, sales tells the customer. That hand-over is a line from the second gateway up into the sales lane: a place where the reasons for a decline can get lost.
Request the file
The model as a .bpmn file.
The file is a fictional example model in BPMN 2.0 XML. It opens in standard BPMN tools such as Camunda Modeler, Signavio or ADONIS, with lanes, both gateways, the control step and the diagram layout. It is sent by email on request; nothing is downloaded from this page.
The claims side of the same business: claims handling. Gateways and how they split and join: the BPMN guide. Processes in insurance as a whole: insurance.