Voice-First Affordability Calculator¶
Brokers currently explore affordability through form fields - the standard lender experience. The idea: replace that with a voice-first interface where the broker simply talks about the case, and Gen H translates that unstructured context into structured calculator inputs, runs the existing mortgage engine logic, and returns a result.
How It Would Work¶
- Broker hits the affordability calculator and chooses the voice option (traditional form fields still available alongside).
- They record a voice note describing the case - income, property value, deposit, employment type, whatever they know.
- The system transcribes and extracts structured data, mapping it to the fields the mortgage engine expects.
- If anything's missing, the UI surfaces follow-up questions - ideally as a short, focused prompt rather than a generic form. The broker can answer by voice again.
- Once the inputs are complete, the mortgage engine runs its existing calculations and returns the affordability result.
The critical constraint: all calculation logic stays in the mortgage engine. This prototype is purely a translation layer between natural language and structured input. No new maths, no parallel affordability model. The value is entirely in the interface, not the computation.
Why the Affordability Calculator¶
Smart funnel targeting. The affordability calc sits at the very top of the broker journey - it's the most casual, throwaway piece of research they do. No credit check, no commitment, no property-specific consequences. Contrast with DIP (soft credit check) or full application (hard credit check + valuation instruction) - those carry real weight.
Brokers won't adopt a radically different input method for high-stakes steps without prior trust in the pattern. But affordability checks? They do these constantly, casually, often while on the phone to a client. That's exactly the context where voice-first is a natural fit rather than a forced one. Prove the mechanic here, and it can migrate down the funnel over time.
The Real Goal: Brand, Not Conversion¶
This doesn't change the underlying affordability decision. A case that works will work; a case that doesn't, won't. The prototype shouldn't pretend otherwise.
What it does change is perception. The reaction you're optimising for is a broker going "wow, nobody else thinks like this" - and then telling other brokers the same thing. The strategic value is:
- Brand positioning: Gen H as genuinely modern, not just claiming to be. Most lender "innovation" is a slightly better portal. This is a different category.
- Memorability: Brokers deal with dozens of lenders. Being the one that did the voice thing makes you sticky in their mental model.
- Organic reach: If the experience is genuinely surprising, brokers will share it. That's marketing you can't buy.
This means polish is non-negotiable. The UX needs to feel magical, not like a tech demo. Voice-first with UI that dynamically loads results and follow-up questions. The transition from "I just talked about a case" to "here's what you can lend" should feel seamless.
What the Prototype Needs¶
Rob (engineering) is on board to explore this. The build involves:
- Speech-to-text: transcribe the broker's voice note
- LLM extraction: parse the transcript into structured fields (income, property value, deposit, employment type, loan term, etc.)
- Gap identification: determine which required fields are missing and generate natural follow-up questions
- Mortgage engine integration: pass structured inputs to the existing calculation layer
- Results UI: present the affordability output clearly, with the voice-first aesthetic maintained throughout
The iterative loop (voice -> extract -> identify gaps -> ask follow-ups -> voice again -> complete -> calculate) is the core interaction pattern. Each round should feel lightweight and conversational, not like you're being sent back to fill in more form fields.
Questions Worth Pressing On¶
- How messy is real broker speech? Brokers might say "the client earns about sixty-five grand" or "they've got maybe forty K saved up" or mix in irrelevant context. How robust does the extraction need to be? This is the make-or-break technical risk. Worth testing with real broker recordings before building anything.
- What's the actual integration path to the mortgage engine? Is there an API, or does this need to go through Active Admin? The answer shapes the prototype architecture significantly.
- How do you measure success? If the goal is brand perception, usage metrics alone won't tell you much. You need qualitative feedback. Plan for that from day one - even if it's just five brokers in a room watching them use it.
- Does this cannibalise the existing calculator? If brokers prefer voice, does the traditional form atrophy? Probably fine, but worth thinking about whether you maintain both long-term or whether voice eventually becomes the primary path.
- What's the competitive moat? If this works and gets attention, other lenders will copy it. The answer is probably "we'll be two iterations ahead by then" - but it's worth being honest that the moat is speed, not defensibility.
Connections¶
- Underwriting CLI - same "remove the interface bottleneck" thesis from the other side of the business. The voice calc removes form friction for brokers; the underwriting CLI removes UI friction for underwriters. If both prove out, Gen H has a coherent philosophy: the bottleneck is never the person, it's the interface between the person and the system.
- Sales Intelligence CLI - both aim to make Gen H look smart and differentiated to brokers, from different directions. Voice calc through the product experience; sales intelligence through the relationship experience.
Smallest Testable Version¶
Before building any UI: take 5-10 real broker descriptions of cases (from sales calls, BDM notes, whatever you have), run them through an LLM with a prompt that extracts mortgage engine fields, and see how accurate the extraction is. If the LLM can't reliably parse "they earn sixty-five K base plus about ten in bonuses, partner's part-time on maybe twenty" into structured income fields, the whole concept has a problem. That's an afternoon's work and it answers the biggest technical risk.