Skip to content

New Project Questionnaire

How to use this document

There are two parts. Part 1 is for the business analyst or delivery lead — plain language questions about how the underwriter will use the system. Part 2 is a shorter technical section for the developer or configurator to complete once the business answers are in.

Part 1 — Business Questions

Section A: About the Client and the Business

  1. What is the name of the insurance company or syndicate we are configuring this for?

  2. What line of business are we configuring? (e.g. Marine Cargo, Cyber, Property, General Liability)

  3. What is the short code you want to use to identify this line of business in the system? (2–3 letters, e.g. MC for Marine Cargo, CY for Cyber)

  4. In which country is this underwriter based? (This sets the platform's base country for address formats, date formats, and currency defaults)

  5. What is the main currency this line of business will be written in?

Section B: How Risks Are Written

  1. How does business come into the platform? Choose all that apply:

    • An underwriter manually creates a risk in the system
    • A broker submits a risk via email and it is automatically created
    • Risks come in via a coverholder/MGA through a bordereau file upload
    • Another method (please describe)

  2. What type of placement is this? (Choose one or more — if unsure, describe how the business works and we'll map it)

    • Open Market — the underwriter quotes and binds individual risks directly with brokers
    • Binding Authority / MGA — a coverholder writes risks on the insurer's behalf under a master facility
    • Delegated Underwriting Authority (DUA) — coverholders submit bordereau files periodically and the insurer manages the oversight

  3. If this is a Binding Authority or DUA: who are the coverholders, and how many are there?

  4. Does an underwriter ever need to do a mid-term adjustment (MTA) on a risk — for example to change the sum insured or extend the period? If yes, briefly describe when and why.

  5. Does the underwriter renew risks at expiry? If so, does the renewal start from a blank slate or does the previous year's data carry forward?

Section C: The Underwriter's Journey — Step by Step

Info

This is the most important section. Walk us through what happens from the moment a risk lands on the underwriter's desk to the moment it is bound. Think of it as describing a typical working day.

  1. When a new risk arrives, what is the first thing the underwriter needs to check or do before they can start working on it? (e.g. check it isn't a duplicate, check the insured is not on a sanctions list, check it falls within appetite)

  2. After that initial check, what does the underwriter need to capture about the risk? (e.g. insured name, inception date, coverage type, sum insured — list all the fields they fill in)

  3. Is there an appetite check — a set of rules that determines whether the risk is acceptable before the underwriter spends time on it? If yes, describe the rules. (e.g. "we don't write risks in certain countries", "minimum premium of $X")

  4. Does the underwriter need to rate the risk (calculate a premium)? If yes:

    • Do they use a spreadsheet/Excel model to do this?
    • Do they use a third-party pricing tool?
    • Do they enter a premium manually?
    • Is the premium calculated automatically by rules?

  5. After rating, can the underwriter quote the risk directly, or does it sometimes need to go to a senior underwriter for sign-off (a referral)? If referrals happen, what triggers them? (e.g. premium above a threshold, certain risk characteristics, location-based rules)

  6. If a risk is referred, what does the senior underwriter need to see and decide? How do they communicate their decision?

  7. Once the underwriter is happy to proceed, what does binding the risk look like? Is there anything they need to confirm, sign off, or record before the risk is bound?

  8. After bind, does the underwriter need to generate any documents? (e.g. a quote slip, a policy document, a certificate, a market reform contract) List all document types needed.

  9. Are there any steps that happen in parallel rather than in sequence? (e.g. the underwriter uploads an asset schedule at any point while the quote is being prepared)

  10. Is there anything else that needs to happen that we haven't covered? (e.g. peer review, compliance sign-off, contract certainty questionnaire, PAS/policy system confirmation)

Section D: What the Underwriter Sees on Each Screen

  1. On the new risk form (when an underwriter creates a risk from scratch), list every piece of information you want them to fill in. For each field, note:

    • What it is called
    • Whether it is mandatory or optional
    • If it is a dropdown, what the options are

  2. On the quote screen, what information does the underwriter need to enter or review to complete the quote?

  3. On the bind screen, what does the underwriter need to confirm or record when binding the risk?

  4. If there is a referral review screen, what information should the senior underwriter see, and what decision fields do they need to fill in?

  5. Are there any fields that should only appear in certain situations? (e.g. "only show vessel name if the risk is Marine Hull", "only show renewal reference on renewal risks")

Section E: Who Does What — Roles and Permissions

  1. List the types of people who will use the system for this line of business. For each person, describe their job in plain language. (e.g. "Underwriting Assistant — logs new risks and runs sanctions checks", "Senior Underwriter — approves referrals and binds high-value risks")

  2. Are there things some users should not be able to do? (e.g. "junior underwriters should not be able to bind risks above $500,000", "operations team can see risks but cannot edit them")

  3. Does the system need to enforce authority limits — where a user can only bind up to a certain premium amount before it requires escalation? If yes, what are the limits per role?

Section F: Data and Asset Schedules

  1. Does this line of business involve a schedule of assets — for example a list of property locations, a fleet of vehicles, or a list of vessels? If yes:

    • What type of assets? (locations, vessels, vehicles, other)
    • What information is captured for each asset? (e.g. address, value, age of building)
    • Does the underwriter upload this as a spreadsheet, or enter it manually?

  2. If assets are uploaded as a spreadsheet, does the column layout change between submissions, or is it always the same format?

Section G: Documents and Clauses

  1. List every document type that needs to be produced from the system. For each:

    • What is it called? (e.g. Quote Slip, Policy Document, Certificate of Insurance)
    • When is it produced? (e.g. after the quote is complete, after bind)
    • Who receives it? (broker, insured, internal)
    • Do you have an existing template we can base it on?

  2. Are there standard clauses that get added to documents? (e.g. Communicable Disease Exclusion, War Exclusion) If yes, list them and note whether each is always included or optionally selected by the underwriter.

Section H: Notifications and Communications

  1. Does anyone need to receive an email or notification when something happens in the workflow? (e.g. "the senior underwriter gets an email when a risk is referred to them", "the broker gets an email when a quote is ready") For each notification, describe who gets it and what triggers it.

  2. If email notifications are needed, does your organisation use a specific email system or relay that Send would need to connect to?

Section I: Bordereau and DUA (skip if not applicable)

  1. What does the bordereau file look like? (Can you provide a sample or template?)

  2. How often does the coverholder submit bordereaux? (Monthly, quarterly, other)

  3. What validation rules apply to bordereau data? (e.g. mandatory columns, date formats, value ranges)

  4. What happens if a bordereau row fails validation — is it rejected, flagged for review, or corrected manually?

  5. What information is captured when onboarding a new coverholder onto the system?

Part 2 — Technical Questions

To be completed by the developer or configurator.

# Question
T1 Client code (short lowercase identifier, e.g. aviva)
T2 DUNS number (9-digit D&B identifier)
T3 Environments to configure and their external gateway base URLs
T4 For each business class: exact type code, product codes, LOI codes, retention codes, sub-class codes, coverage field codes and data types
T5 Rating method — O365/SharePoint (provide site ID, site name, rater Excel file, import/export tab names, table names, WB↔rater field mapping); HyperExponential (auth scheme, API URL, client ID/secret, pricing strategy); Rules Engine; Manual
T6 SharePoint site IDs and names per environment (if O365 rating)
T7 HX auth credentials and config values (if HyperExponential)
T8 Sanctions provider — standard two-line platform check, or custom integration (CSI or other)? If custom: endpoint details
T9 Rules engine rules — conditions and outcomes for appetite, referral triggers, authority limits, and validation
T10 For each notification: HTTP method, endpoint URL, authentication method, payload schema
T11 For email integrations: SMTP host/port/credentials or OAuth endpoint, client ID, client secret, tenant ID
T12 D&B API credentials (if party lookup is needed)
T13 Asset mapping: for each asset field, the JSON path from the Workbench risk and the corresponding rater column name
T14 DynamoDB queue names, bucket names, and database endpoints per environment (usually supplied by DevOps)
T15 Document HTML templates (or confirm design brief is sufficient to build from scratch)
T16 Roles with exact permission sets and authority limit values per currency
T17 Any custom client-rest endpoints being developed alongside this configuration — names and expected request/response contracts