Service Design User Flows Client Platform Multi-Brand Fintech

Fixing the Front Door

Haven Servicing • 2024–2025

Borrowers were struggling with registration, verification, and access to core servicing tasks. Key actions like finding tax documents, paying as a guest, requesting loan payoff, or removing PMI were hard to discover or blocked entirely. The result was high support volume and rising costs for servicing clients. We redesigned the front of the platform to reduce support demand and restore client trust.

Role

Owned end-to-end design of borrower access and self-service experiences, from discovery through delivery.

Scope

Redesign of registration, verification, and access to high-frequency servicing actions and self-service content.

Constraints

Complex legacy workflows, limited engineering capacity, and aggressive timelines.

Impact

Reduced support volume and client costs by enabling borrowers to complete common servicing tasks without calling support.

Overview

The Problem

Borrowers could not reliably complete basic servicing tasks. Registration and verification were confusing, and important actions like accessing 1098 tax documents, paying as a guest, requesting loan payoff, or removing PMI were difficult to find or unavailable.

Why It Mattered

When borrowers cannot self-serve, they call support. At scale, this created a major cost problem for servicing clients and eroded trust in the platform.

Who This Affected

Borrowers trying to manage their loans, support teams overwhelmed by preventable calls, and clients paying for inefficiency.

Success Criteria

  • Reduce support tickets related to access and discovery
  • Enable borrowers to complete common tasks without calling support
  • Rebuild client confidence in the platform's ability to scale
Fixing the Front Door

Context & Constraints

Constraints

We needed to reduce support volume within a single sprint without disrupting borrower access. Existing users could not be locked out or forced to re-register. Engineering capacity was limited, and not every solution could ship at once while parallel onboarding and client configuration work continued.

Known Risks

If users did not see improvements quickly, frustration and support volume would continue to rise. Delayed impact risked further erosion of client trust and the loss of confidence to pursue larger platform improvements. Some solutions depended on client-approved support content, a process that had historically slowed progress and could block timely results.

Dependencies

Three client-owned widgets embedded in the platform: pay as guest, request loan payoff, and request PMI removal. Client approval for new support content and article language, with no established review process. A small engineering team supporting both frontend and backend changes.

Tradeoffs

Started with small, low-risk changes intended to reduce support volume quickly. When impact was limited, we shifted toward more visible product fixes at the client's request. That decision meant delaying some planned work for an upcoming 4/1 launch in order to address higher-priority support issues first.

Stakeholders

Servicing clients focused on reducing support costs while responding to lender pressure for better borrower outcomes. Internal product partners balancing speed, near-term impact, and alignment with the long-term platform vision. A small engineering team supporting this work alongside other parallel initiatives.

Approach

Start with what we could see

Support volume was rising, but detailed call-level data was not available. While that view would have been the clearest signal, we used chat logs and Zendesk volume to identify the most common access and discovery issues and focused on those first.

Fix the obvious blockers

Early data showed that many access failures were caused by basic system issues, such as bounced activation emails and blocked traffic. We addressed these first because they were fast to fix and reduced friction without pulling engineering away from other committed work. In parallel, we planned self-service articles that did not require engineering time.

Adjust when results lagged

Those fixes shipped quickly, but support volume remained high and there was little time to measure impact. Client-approved support content was delayed and missed a critical publishing window. As pressure increased, we shifted toward more visible, engineering-driven product changes that clients could clearly see and respond to.

The key decision

With a small team and limited data, we moved quickly and focused on the areas most likely driving support volume, starting with small, low-risk fixes. When those did not reduce volume fast enough, we proposed more visible product changes and reviewed them directly with client leadership. Once aligned, we reprioritized work and created tickets to address support volume within a single sprint.

Design & Execution

The goal of this work was to reduce support volume by helping borrowers self-serve. We focused on improving access to high-impact actions, adding help at moments of confusion, and making critical documents easier to find.

Core servicing actions

Fix 01 — Core servicing actions

How might we help borrowers complete common servicing tasks without calling support?

Why it matters: Calls related to basic actions like making a payment, requesting a payoff, or removing PMI were driving significant support volume. When these actions are hard to find, borrowers assume they are unavailable and reach out for help.

What changed: We increased the visibility and clarity of high-volume actions such as pay as guest, loan payoff requests, and PMI removal. These options were surfaced more consistently within relevant flows so borrowers could act without needing assistance.

Contextual self-service help

Fix 02 — Contextual self-service help

How might we answer common questions at the moment borrowers get stuck?

Why it matters: Many support calls were caused by confusion, not missing features. Without clear guidance, borrowers left the page and contacted support even when answers already existed.

What changed: We added FAQ sections to high-issue pages and paired them with contextually relevant articles. This allowed borrowers to self-serve in place. The same content also expanded chatbot coverage, improving automated responses without additional engineering effort.

Fix 03 — Document discovery

How might we help borrowers find important documents without assistance?

Document discovery

Why it matters: Document access, especially around tax forms, was a recurring driver of support volume. When documents were hard to locate, borrowers called support for confirmation or access.

What changed: We improved discoverability on the documents page so borrowers could more easily find time-sensitive files like 1098s. This reduced repeat calls tied to seasonal document availability.

Outcomes

Support reduction in progress

This work targeted the highest drivers of support volume by improving access, discovery, and self-service. Changes shipped this sprint were designed to reduce calls tied to common servicing tasks, with impact being monitored as rollout continues.

Client confidence regained

This work supported a key servicing client managing over 500K loans. Delivering clear, visible improvements within a single sprint helped reset the conversation, restore confidence, and align on next steps.

"In a make-or-break executive conversation, Chris's preparation and clear communication anticipated feedback, presented options, and aligned leadership around a clear path forward."

Blake C. — COO, Haven Servicing

Reflection

The challenge was never a single UX issue. It stemmed from limited visibility into compounding problems and a gap between the urgency clients were experiencing and the scope of our early responses. Initial improvements were intentionally light-touch, but they did not reflect the severity of the situation.

As pressure increased, incremental changes were no longer sufficient. Rebuilding confidence required visible, substantive action that demonstrated an understanding of the problem and respect for client expertise. This required expanding the scope and addressing the issue systemically rather than through isolated fixes.

By broadening the work across UI improvements, deliverability, and self-service, the effort shifted from incremental optimization to measurable change and helped re-establish trust through action.