Mortgage servicing · Escrow analysis service design
The question
How can a team choose where to intervene when an escrow analysis is experienced by customers as a single event but produced across many people and systems?
The work
I mapped the process from its triggers through delivery, bringing together the customer's view, operational events, internal roles, systems, applications, and data. The layered view made it possible to discuss a payment-related customer experience alongside the work that produced it.
The judgment
The first useful design artifact was a shared view of the service, rather than an isolated screen proposal. It gave business, product, and design partners a way to see where the experience crossed organizational and system boundaries before choosing a narrower problem to solve.
The result
The initial service view helped the broader business engage with a customer-centered way of framing the work. The team went on to use stage mapping to identify areas for deeper analysis and prioritize possible interventions. This account does not claim a shipped escrow change or measured customer outcome.
Contribution and result
| Field | Account |
|---|---|
| My contribution | Led a multilayered service-design analysis connecting the customer experience to operational and technical activity. |
| Observable consequence | The model provided a basis for cross-functional discussion and subsequent stage-based prioritization. |
| Basis | My firsthand account of the service-design work and its use by the broader team. |
| Boundary | No completed service change, cost reduction, or customer metric is attributed to the map. |
What I carry forward
A service map is useful when it helps a team choose a tractable problem, not merely when it records every part of a complicated process.
Project descriptions focus on my role and the contribution I can describe publicly. Confidential materials are omitted. Illustrations identified as reconstructions explain an idea; they are not original project deliverables.