Suitability reports are a mandatory part of financial advice, explaining why a recommendation is appropriate for a client's circumstances and objectives. At Ekorn, producing one meant leaving our platform for a third-party AI tool, editing the output in Word, then returning to continue onboarding.
I led product design across the project — from early workflow definition and user research through prototyping and validation — and worked with product and engineering to define how source documents, AI extraction and the report template connect.
reduction in average time on the report step
of started migrations reaching report sent
native Ekorn report adoption within 6 months





Producing one report takes eight tools and three different platforms.
Every handoff interrupted onboarding.
Users couldn't review the AI's assumptions before generation.
Once generated, correcting mistakes meant leaving the workflow or starting again.
Advisers want automation without losing control.
Existing client documents and data should do the heavy lifting.
Users want to inspect conflicting values and correct important information before trusting the report.
AI can draft; humans need to review, edit and explicitly approve.
“Every time Saturn produces a charges table, he does it wrong. So you almost have to copy and paste the charges table in. Every time…”
Financial adviser · user interview
Every step now happens inside Ekorn.
Users choose which documents AI should consider rather than blindly feeding everything into the model.
Extracted information and inconsistencies are surfaced before drafting, so errors can be corrected early.
AI produces the starting point, not the final decision.
The adviser remains the final accountable human before completion.
A suitability report draws from documents created at different points in the client journey. Information overlaps, changes over time and conflicts — so the first design decision was which documents get read at all.
For MVP we're working from a single controlled report template. I mapped that template into variables and generated prompts, defining the information required and the likely source for each section.
<client-name> · <risk-level>
<current-plan-value> · <prompt-4>Excerpts from the mapped template. Yellow marks a variable extracted from a named source document; green marks a passage the model writes from the client's data. Working through the template this way also exposed which fields have no reliable source — the ones that later became the conflict-resolution step.
Rather than treating every uploaded document as equally reliable, we designed the extraction logic around recency and source relevance. The most recent information wins where circumstances have changed, while specialist documents stay authoritative for product data such as plan values, fees and charges.
A hierarchy reduces conflicts but can't eliminate them. When the system finds contradictory information, we don't want the model to silently pick an answer.
What doesn't match, and where did each value come from?
The system can recommend the likely answer; the user stays in control.
Once resolved, the verified information becomes the basis for generation.
Four steps, one platform, an adviser signature at the end.




Today generation starts from one controlled template. The direction we're exploring lets a firm upload their own: the system identifies required variables, maps them to trusted client data, and produces a report that preserves the firm's structure and language.