Specialist capability
Quote journeys and comparison platforms for regulated and complex markets.
Yeti designs and engineers the complete product, from question flows and eligibility logic to provider connectivity, comparison results, attribution, reporting and ongoing optimisation.
Question flows · Rules and eligibility · Provider integrations · Results · Attribution · Reporting
The complete journey
From first visit to a clear next step.
A quote journey connects customer questions, decision logic, provider requests and comparison results into one continuous path.
The quote journey moves through six stages: arrival, customer questions, route determination, provider quote requests, option comparison and continuation to the selected provider or purchase route. Rules, integrations, disclosures, evidence and reporting support every stage.
Across every stage
Rules, provider integrations, disclosures, evidence and reporting support the journey throughout.
From product rules to a live comparison platform.
Yeti designs and builds the questions, logic, provider connections, results, evidence and infrastructure as one working product.
Quote journey design
The hard part is not the form. It is deciding what happens next.
Products, provider requirements and approved customer information rarely fit together neatly. Yeti works out what needs to be asked, how each answer changes the route, how different results can be presented clearly and what the customer should see when a straightforward quote is not available.
Three stages, not a row-by-row translation. The journey has to account for products and cover options, eligibility and underwriting rules, different provider questions and data needs, required information, disclosures and consent, and what should happen after the customer receives a result. From that, the journey needs to decide which questions are asked and when, how answers affect eligibility, referral and routing, how different provider requirements are handled, how different options are presented clearly, and what happens when a straightforward quote is not available. The customer then gets only the questions relevant to them, clear outcomes as they move through the journey, results presented in a consistent, understandable way, a useful route when no quote is available, and one clear next step.
The journey has to account for
What shapes the journey
- Products and cover options
- Eligibility and underwriting rules
- Different provider questions and data needs
- Required information, disclosures and consent
- What should happen after the customer receives a result
Yeti works this out with you
What the journey needs to decide
The rules and routes are defined once, then applied consistently throughout the customer experience.
- Which questions need to be asked, and when
- How answers affect eligibility, referral and routing
- How different provider requirements are handled
- How different options can be presented clearly
- What happens when a straightforward quote is not available
The customer gets
A simpler experience
- Only the questions relevant to them
- Clear outcomes as they move through the journey
- Results presented in a consistent, understandable way
- A useful route when no quote is available
- One clear next step
When no quote comes back
Declines, referrals and partial results are designed as real outcomes, not error states.
When providers disagree
Differing question sets, data formats and response shapes are reconciled behind one journey.
When options are hard to compare
Prices, cover, limits, excesses and other meaningful differences are presented clearly, rather than reducing the decision to the cheapest row.
When the journey has to change
Question sets, rules and disclosures can be revised without duplicating the same change across individual screens.
Provider connectivity
One request out, several different answers back.
Providers rarely accept the same request or return the same response, and one of them will eventually be slow or unavailable. The integration layer absorbs those differences so the customer journey keeps behaving predictably.
One customer request is adapted into the format each provider requires, sent to four illustrative providers, and their different responses are reconciled into one consistent set of results. Selecting a scenario shows how a slow or unavailable provider is handled without stopping the journey.
Comparison results
Results have to explain the difference, not just rank the price.
A cheaper policy is not a better one, and customers know it. Results are designed so cover, limits and cost are readable in the same view as the decision.
- 01
What is included, and what is not
Included and excluded cover are listed against the same policy, with each limit and excess stated next to it rather than implied.
- 02
Fees and excess in figures
Vet fee cover, policy limit, excess and co-pay are shown as figures beside the price, so a cheaper premium can be read against what it actually covers.
Regulated journeys
What was shown, and what can be evidenced afterwards.
In a regulated journey, it is not enough to show the right information. The platform also needs to record what the customer saw, answered and agreed, so the complete journey can be reviewed later.
Three connected stages in order: what the customer is shown at the point of decision, what the journey records at that moment, and what can be reviewed or evidenced afterwards.
What the customer sees
Presented at the point it matters
Disclosures, terms and required wording appear in the journey where the decision is made, in a form the customer can read.
- Required wording shown at the relevant step
- Terms available before the customer continues
- Clear outcome where no quote is possible
What is recorded
Captured as it happens
The journey records what was shown, what was answered and what was agreed, at the moment it occurred.
- Version of wording shown
- Answers and any corrections
- Consent, with time and context
What can be reviewed
Retrievable afterwards
A single journey can be reconstructed later without reading raw logs, which is what a review or complaint actually needs.
- A complete record of the customer’s journey
- Evidence linked to the quote or journey reference
- Reports for oversight and audit
Yeti designs and engineers the agreed product controls. Legal, regulatory and compliance requirements remain subject to the client’s own advisers, approvals and applicable arrangements.
Multi-brand platforms
One platform, configured for different brands and partners.
A shared comparison platform can support direct, co-branded and embedded journeys. Branding, content, disclosures, provider routes and reporting can be configured for each implementation without creating a separate product and codebase every time.
A shared comparison-platform foundation can support a hosted brand journey, a co-branded partner route or an embedded flow. Each implementation can configure branding, content, disclosures, provider routes, attribution and reporting while using the shared platform foundation.
Shared platform foundation
The platform foundation is shared. Each brand or partner can use an agreed configuration of the journey, providers, content and reporting.
Configured for hosted branded journey
Own-brand journey on its own domain
Configured for co-branded partner route
Branding, content and disclosures are configured according to the agreed client and partner arrangements.
Configured for embedded flow
The presentation can fit the host experience while the journey continues to use the shared platform foundation.
Measurement
See where customers leave, which providers perform and what turns into revenue.
Yeti connects acquisition, journey behaviour, provider responses and commercial outcomes, so product and commercial teams can see what is working and where value is being lost.
Four measurement areas connected by one journey reference: traffic and partners, journey performance, provider and results performance, and commercial outcomes. Confirmed sale and revenue data is only available where the provider or commercial partner returns it.
Traffic and partners
Which partners and campaigns send traffic worth having?
Source, publisher, campaign, landing page and partner reference.
Journey performance
Where do customers leave, and which questions cause friction?
Quote starts, step completion, abandonment, validation errors and time through the journey.
Provider and results performance
Which providers return usable quotes, and what do customers pick?
Requests sent, responses returned, timeouts, partial results, quotes displayed and provider selections.
Commercial outcomes
Which click-throughs turn into confirmed sales and revenue?
Click-throughs, provider references, confirmed sales and revenue where the provider or commercial partner returns that data.
Traffic and partners
Which partners and campaigns send traffic worth having?
Source, publisher, campaign, landing page and partner reference.
Journey performance
Where do customers leave, and which questions cause friction?
Quote starts, step completion, abandonment, validation errors and time through the journey.
Provider and results performance
Which providers return usable quotes, and what do customers pick?
Requests sent, responses returned, timeouts, partial results, quotes displayed and provider selections.
Commercial outcomes
Which click-throughs turn into confirmed sales and revenue?
Click-throughs, provider references, confirmed sales and revenue where the provider or commercial partner returns that data.
A quote or journey reference connects these events from first visit through to the last outcome available.
Confirmed sale or revenue attribution depends on the data returned by the provider or relevant commercial partner.
Delivery approach
From product model to live operation.
- Commercial model
Understand
Map the commercial model, customer needs, products, providers and operating constraints.
- Product definition
Define
Specify the question flow, rules, data, integrations, results, disclosures and evidence requirements.
- Journey testing
Prototype
Test the customer journey, difficult decisions and important failure states before the engineering approach is fixed.
- Engineering
Build and integrate
Engineer the product, provider routes, reporting, administration capabilities and supporting infrastructure.
- Validation
Validate and launch
Test customer, technical, operational and agreed compliance paths before moving into live use.
- Live operation
Operate and improve
Monitor the live journey, maintain integrations and improve the product using customer, operational and commercial evidence through an ongoing engagement.
Worked example
Yeti Compare: a pet insurance comparison product built end to end.
Yeti Compare, a product in development, is used here as an illustrative example of the complete connected product: brand and interface, the customer question journey, eligibility rules, provider connectivity, comparison results and the reporting behind them.
Screens are shown to illustrate product structure. Plans, prices and provider availability vary and are not indicative of any specific quotation.
Ways of working
Different ways to engage Yeti.
Defined product build
A scoped engagement to define, design, engineer and launch a new journey or a major platform release.
Ongoing product team
Continued product, design and engineering capacity for organisations operating and improving an established platform.
Audit and stabilisation
A focused engagement to diagnose journey, integration, reporting or operational problems and establish a practical improvement plan.
Frequently asked questions
Questions about quote and comparison platforms.
Can Yeti work with our existing platform?
Yes. We can work with an existing journey, application, provider layer or wider technology estate. The appropriate approach depends on the current architecture, product constraints and the changes being considered.
Can you integrate with our current providers?
Yes, subject to the provider’s available services, documentation, access arrangements and commercial permissions. We assess each route and design the integration approach around the provider and the wider platform.
Do you build quote-to-lead, click-out and quote-to-purchase journeys?
Yes. Yeti can design and build several commercial journey models, including lead generation, provider click-through, referred applications and more integrated purchase journeys. The final model depends on the product, provider capabilities and applicable commercial or regulatory arrangements.
Can one platform support multiple brands or partners?
Yes. Platforms can be designed around a shared product core with controlled brand, content, attribution, access and reporting configurations. The appropriate level of separation depends on the client’s operating and data requirements.
How do you approach regulated requirements?
We identify the agreed customer-information, disclosure, evidence, data and oversight requirements early and design them into the product. Yeti does not replace the client’s legal, regulatory or compliance advisers.
Who owns the customer and journey data?
Ownership, controller and processor roles, access rights, retention and permitted use are defined in the applicable agreement and supporting data arrangements. The platform should reflect those agreed responsibilities.
Can Yeti continue supporting the platform after launch?
Yes. Yeti can remain involved through live operation, maintenance, integration support and continued product development under an ongoing engagement.
Can you improve an existing journey without replacing it?
Often, yes. We first assess where the meaningful constraints sit. Improvements may be possible through focused work on the interface, rules, integrations, results, reporting or operational model without replacing the complete platform.
What happens when one provider is unavailable?
The appropriate behaviour depends on the journey and integration model. A platform may use timeouts, partial results, clear availability messaging, retry behaviour or alternative routes according to the agreed product design.
Building a quote or comparison product?
Talk to Yeti about the journey, provider integrations, results, evidence, reporting and ongoing product operation.