Implementation guide
What to scope after choosing an insurance software platform
Once an insurance platform has been chosen, the next task is to define the work that turns it into a usable operation. Start with the journey or workflow you need to support, then identify what the platform supplies and what must be configured, connected or built around it.
01
Describe the work from beginning to end
Choose a concrete workflow and map who uses it, what information moves through it and where decisions are made. Record the systems involved and the parts each organisation owns. This provides a starting point for discussing configuration, customer-facing screens, internal tools and integrations.
Separate proposed changes to the provider’s core product from customer-specific work. Confirm platform access, permissions and dependencies before treating either as committed scope. An open question should have an owner and a way to resolve it.
02
Define acceptance and continuing ownership
Agree what the implementation must do and how that will be tested. Include the operating team in deciding what it needs to accept and use the result. Record what will be handed over, who will host and maintain it, and how support will work.
An approved requirement can be enough to start this process. Where uncertainty remains, isolate the questions that affect delivery. The useful output is a scope with responsibilities, acceptance criteria and operational ownership clear enough for the work to begin.
Hypothetical example
Illustrative worked example: a broker submission journey
Consider a hypothetical MGA that has chosen a platform and needs brokers to submit an application. Map the journey from opening the form to the operations team receiving a usable submission. Decide where the application is stored, how missing information is handled and how a broker knows whether submission succeeded.
Suppose the platform provides a submission endpoint but the broker-facing form and confirmation flow still need building. The scope should name those components, the required fields, the integration owner and the behaviour when the endpoint is unavailable. Test the ordinary journey alongside incomplete inputs, duplicate attempts and failed connections. This is an example of scoping, not a description of an Aught project.
03
Produce an acceptance record
Create a table with a row for each required behaviour and columns for the system owner, dependency, test condition, expected result and acceptance owner. Attach unresolved decisions to the relevant row. Before handover, add the test evidence and a link to the operating instructions.
Template
A record you can copy
Copy this table into your own document. The third column is a hypothetical example, not a record from a real project; replace each role with an agreed owner.
| Field | What to record | Hypothetical example |
|---|---|---|
| Workflow | User and operating task | Broker submits an application |
| Required behaviour | Observable outcome | Missing required information is identified before submission |
| System and owner | Component plus accountable role | Broker form—implementation lead |
| Dependency | Access, data or provider input | Confirm required fields and submission API contract |
| Test condition | Situation to exercise | Required field omitted |
| Expected result | Behaviour to accept | Show a specific error; retain other inputs; do not submit |
| Acceptance | Approver and evidence | Operations owner reviews test result before release |
Add separate records for the ordinary journey, duplicate submissions, unavailable connections and handover. Replace each role with an agreed owner.
04
Avoid this interpretation mistake
The existence of an API does not establish that the whole customer journey works. A successful technical request still leaves questions about the data received, the user experience and the operating team’s next action. Accept the complete scoped workflow, with those responsibilities visible.
Checklist
Scoping checklist
- Which user journey or operating workflow is in scope?
- What is covered by the platform, configuration or custom development?
- Which integrations, access permissions and client inputs are dependencies?
- Who approves changes and accepts the implementation?
- What functional and operating requirements will be tested?
- Who receives source access, documentation and the working assets?
- How will hosting, maintenance, support and handover be handled?
Resources
Further reading
For the technical contract, OpenAPI’s API endpoints guide explains how operations and responses are described. Pair that with GOV.UK’s moderated usability-testing guidance when checking whether users can complete the journey.
Related