Navin Benoy

Professional case study · 04

How to lift adoption when customers want to own the front end

A global lending software vendor · Localising a US-built platform for Australia and New Zealand

2 min read

A$80B

Combined home lending book of the banks that approved the approach.

Headless: the bank owns the screen

The bank's own front endTheir channels, their design
Headless APICalled in the right order
Lending platformDoes the work underneath
Lodge an applicationFirst use case
Each step in the journeyMapped per bank
SettlementOn the roadmap

Start with one use case. Map the journey end to end.

The situation

Banks here run many vendors side by side: core banking, decisioning, documents, channels. The platform came with its own screens. Large banks wanted to build customer journeys in their own channels, on their own front end.

The real problem

Banker interviews showed slow time-to-value and loss of control over the front end were blocking adoption. More screens would not fix either.

The decision

There were three options.

Option 1

Keep selling the full product with its own screens.

Option 2

Build a custom integration for each bank.

Option 3 · Chosen

Make the product an API that any bank's front end could use.

We chose the API, a headless approach, because it was the only one that scaled across banks without a custom build for each.

How to work it

  1. Gather evidence from more than one place.

    I drew on my own time inside a large bank, research on the major Australian banks, and conversations with existing customers in New Zealand. The same insight came from all three: banks want to own their front end.

    TIP

    When three separate sources agree, you have a strategy, not an opinion.

  2. Map the journey before you design the API.

    For each bank we mapped the lending journey step by step: what happens at each step, which API the bank's front end calls, and in what order.

    TIP

    An API strategy is a process problem first. The front end has to call the right API at the right time.

  3. Define the product and the commercial case.

    The API is a product with its own roadmap, so it needs a business case like any other.

  4. Review it inside and outside.

    An internal review, then an external review with customers. Regional leadership endorsed it.

  5. Take it through the customer's governance.

    The customers' steering committees approved it.

  6. Start with one use case.

    The first was lodging an application through the API. The roadmap ran end to end to settlement.

What changed

Banks across Australia and New Zealand, with a combined home lending book of around A$80 billion, approved the approach and built their own digital lending journeys on it. It also opened conversations with major banks, because the platform now matched the strategy they were building internally.

Use this when

  • You want to lift adoption of a product customers already have, and they are asking for control rather than more features.
  • Your product is one vendor among many in the customer's technology stack.