Mapping the current state of a servicing ecosystem — before deciding its future

The Challenge

The company was preparing for a major transformation of its customer servicing technology. Over years of growth, the servicing environment had evolved into multiple legacy tools used by a large frontline organization: each built for a reason, each solving a real problem, and each capturing information a little differently.

Before anyone could design the future servicing experience, one question needed an honest answer: what actually happens today?

Not what the org charts said. Not what any single team believed. What frontline users actually did, what information got captured along the way, and where that information went once it left their hands.

That was my project.

My Role

I joined the team responsible for servicing capabilities as a Business Strategy Manager MBA intern, working closely with product partners. My mandate was current-state discovery: understand how servicing information was captured, used, and moved across the existing ecosystem, then translate that understanding into prioritized product opportunities for the transformation ahead.

I wasn't responsible for executing the technology migration, and that constraint sharpened the work. My job was to make sure the people who would make those decisions were making them with a clear, shared picture of reality.

How I Approached It

I started by admitting what I didn't know, which was almost everything. So I built the project around structured listening: 20+ interviews across Product, Engineering, MIS/analytics, Operations, leadership, and frontline servicing teams.

To keep a sprawling discovery effort coherent, I ran every conversation through the same four questions:

The framework was deliberately simple. Complicated environments don't need complicated questions; they need consistent ones, asked of enough people that the contradictions start to surface. And they did: teams that believed they were looking at the same information often weren't, and workflows that looked clean on paper had quiet manual detours nobody had documented.

I shared interim findings early, let stakeholders push back, chased down the gaps their feedback exposed, and refined the analysis from there.

Making the Current State Visible

The most valuable deliverable wasn't a recommendation. It was a picture.

I synthesized the research into four end-to-end current-state workflow maps connecting frontline activity, operational systems, data capture, analytics, KPIs, and reporting. Stakeholders could see the full path servicing information traveled: where it was born, where it was used, and where it quietly disappeared.

These maps did something a report couldn't. They gave technical and non-technical teams a shared reference point, and they made the fragmentation legible. You didn't have to take anyone's word for it. You could point at it.

What I Learned / Key Findings

The organization didn't have a data shortage. It had a connection problem. Enormous amounts of servicing information existed, but fragmentation across tools made it hard to link that information across a complete servicing journey.

Fragmented workflows create invisible work. When frontline users stepped outside the primary platform to finish a task, that activity became difficult to observe or measure. The work still happened; the record of it didn't.

Manual handoffs tax everyone twice. Manual reporting and information handoffs cost effort in the moment, then cost accuracy later when teams tried to measure consistently across sources.

Everyone wanted the same data for different reasons. Operations, performance management, customer insights, and product teams were all drawing on servicing information for legitimate, valuable purposes, but fragmented capture kept those perspectives from ever fully connecting.

The upshot reframed the entire effort: the problem wasn't that frontline teams had too many screens. It was that the servicing journey couldn't be measured end to end. That changed the product question from "how do we consolidate tools?" to "how do we design a platform that captures the journey as a byproduct of doing the work?"

Seen that way, the future platform was never just a UI-consolidation project. It was a chance to build a measurement layer, one connecting frontline activity, customer outcomes, and operational performance for the first time.

From Findings to Product Opportunities

I translated the research into three prioritized opportunity areas for the future servicing experience:

For each, I considered the user problem, potential success measures, implementation dependencies, ROI/business value, and trade-offs, because an opportunity without a way to measure it is just a wish.

The goal was never to prescribe a finished solution. It was to give product leaders a sharper framework for deciding where consolidation would create the most value, and which capabilities deserved deeper discovery.

Impact

The deliverables gave product stakeholders a clearer, shared view of the current servicing ecosystem: where fragmentation lived, where measurement broke down, and where frontline friction concentrated.

The prioritized opportunity framework helped inform thinking around the broader servicing transformation and gave teams a structured starting point for future discovery. And the current-state visuals took on a life of their own, becoming a reference for communicating the ecosystem and onboarding new product partners into how the environment actually worked.

Reflection / What I Took Away

The hardest part of this project wasn't analytical. It was earning enough trust, across enough teams, to get honest answers about how work really gets done, including the workarounds nobody puts in documentation.

I came away convinced that current-state discovery is a product skill, not a preamble to one. The quality of every future-state decision is capped by the honesty of your current-state picture. And in a complicated environment, the fastest way to that honesty is a simple framework, applied consistently, to a lot of generous people willing to tell you the truth.

Before you redesign a complex system, make the invisible parts of it visible.