May 2025 - Present

Strategy Context

The organization was at a point where continued growth depended on Sales and Medical Management being able to scale their operations together, but the infrastructure connecting them couldn't support that. Account data sat across disconnected systems, and the gaps between them were being absorbed manually by people, spreadsheets, and by workarounds that had become load-bearing parts of daily operations.

The strategic need wasn't just to replace a failing tool. It was to establish a unified foundation that could serve as a single source of truth across the organization, one that would allow all interconnected functions to grow without the coordination overhead that was slowing them down. Without that foundation, scaling one side of the business would continue to create pressure on others, and the organization's ability to deliver consistently to members and clients would remain constrained by infrastructure rather than capacity.

The Problem

Legacy system misalignment created compounding operational burden: The system was built for a different purpose and had spent years being forced to serve functions it was never designed to support. Rather than enabling the team's work, it actively complicated it—consuming time, introducing risk, and obscuring the true state of the business.

Parallel tracking sheets filled gaps the system couldn't: Because the platform couldn't accommodate the organization's data structure, teams developed informal workarounds—most notably maintaining Excel sheets for information that had no proper home in the system. This fragmentation made it impossible to get a reliable picture of the business at any given time and created a tracking dependency that was neither scalable nor sustainable.

Terminology misalignment introduced friction at every handoff: The language embedded in the legacy system didn't match how the rest of the organization spoke about its work. Every time information needed to move between teams or systems, the inconsistency created friction and increased the risk of miscommunication.

Reporting was unreliable by design: The system offered little flexibility for custom reporting, and open text fields meant the same information was entered differently depending on who completed it. Any reporting that was possible required significant manual cleanup before it could be trusted—making data-driven decisions functionally out of reach.

Unstructured fields undermined pipeline integrity: Without clean, structured inputs, opportunity management suffered. Pipeline data was inconsistent and difficult to work with, limiting the team's ability to track and act on business development activity with confidence.

Group elections created recurring downstream delays: Renewing elections in the existing system was time-consuming, and there was no standardized process for capturing them in a way that made the information accessible to the teams that depended on it. Every renewal cycle generated manual handoffs and downstream delays that compounded an already strained operation.

Approach

My role was to design and drive a migration that three departments were depending on, while keeping operations running throughout and building toward automation infrastructure that didn't yet exist anywhere in the organization.

Discovery started with structured working sessions across Sales leadership and frontline reps, mapping how work actually moved through their hands: where decisions got made, where data got created, and where people had quietly built workarounds that had become load-bearing parts of daily operations. That last finding was the most consequential. Much of what looked like process preference turned out to be adaptation to system constraints, which meant there was significantly more room to consolidate than the surface-level complexity suggested, and that the legacy system had been obscuring the organization's actual workflow logic for years.

From that foundation, I held firm on a single design principle throughout: the cleanest path through the system had to also be the correct path. If doing the right thing required extra steps, people would skip them — and data integrity would erode exactly the way it had in the legacy system. Every decision about field structure, pipeline stages, terminology, and handoff triggers was evaluated against that standard before it was built.

The most deliberate part of the architecture was designing for cross-departmental automation from the start rather than treating it as a future phase. Rather than optimizing each team's workflow in isolation, I structured the underlying data model so that actions in one department could reliably trigger downstream processes in another — so a closed sale could automatically initialize the right workflows in Account Management and Medical Management without manual handoffs. That required establishing shared terminology governance across all three teams before configuration began, which was slower than building each team's module separately, but was the prerequisite for making automation viable at all rather than a feature that would need to be retrofitted later.

Key Decisions

Unified CRM vs. Department-Specific Tools: Three departments had evolved distinct workflows around account data. The tradeoff: build department-specific tools optimized for each team vs. consolidate into unified CRM infrastructure. Department-specific tools would have been faster to build and immediately addressed each team's pain points, but would perpetuate data inconsistency and require ongoing synchronization. Unified infrastructure required complex upfront coordination but would create a single source of truth and enable dynamic data flow—sales events would immediately update Medical Management case context. We chose unified architecture, accepting longer implementation timeline in exchange for eliminating duplicate data maintenance and version control conflicts that had plagued operations."

Custom Build vs. Configure Existing Platform: The legacy system's limitations suggested need for custom development. The tradeoff: build purpose-built CRM from scratch vs. configure existing Dynamics platform with heavy customization. Custom build would give complete control over UX and workflows but require ongoing maintenance resources and limit integration capabilities. Configuring Dynamics meant working within platform constraints but provided enterprise-grade security, maintained compatibility with our data warehouse, and leveraged existing organizational knowledge. We chose Dynamics configuration, investing in extensive customization to match workflows while gaining long-term maintainability."

Phased Rollout vs. Big Bang Migration: Moving three departments off legacy systems simultaneously carried risk. The tradeoff: phase rollout by department (lower risk, longer timeline) vs. migrate all teams simultaneously (higher risk, faster consolidation). Phased approach would allow validation with each team but require maintaining parallel systems longer and create temporary data sync complexity. Big bang migration would eliminate parallel systems immediately but risked disrupting all three departments if issues emerged. We chose phased rollout starting with Sales, using their feedback to refine workflows before migrating Account Management and Medical Management—accepting extended timeline in exchange for validated design before full organizational commitment

Impact

Business Outcomes:

• Estimated $1million a year in cost savings by replacing an inefficient legacy software for client tracking

Operational Improvements: 

• Consolidation of 3 siloed department workflows into a single CRM system, reducing duplicated effort by 30%, for Sales, RevOps, and Product

Strategy Evolution / Iterations

[Section in progress as project is ongoing]

June 2025 - Present

Strategic Context

Medical Management's growth created operational capacity constraints that manual email processes couldn't sustain. Over 30 shared inboxes handled critical member referrals and clinical requests with zero systematic tracking, such as visibility into status, ownership, response times, or volume trends. This created escalating risk: missed referrals could delay care coordination for vulnerable members, leadership lacked data to inform staffing decisions, and as the product portfolio expanded, inbound volume grew rapidly.

A previously purchased off-the-shelf ticketing solution had failed to accommodate our complex workflows, resulting in the loss of 6 months time investment while leaving core operational challenges unresolved. Without centralized intake infrastructure, Medical Management faced mounting risk of operational breakdown as it scaled, through dropped requests, inconsistent member experiences, and inability to demonstrate capacity needs to justify resource investment.

We needed purpose-built ticketing infrastructure that could handle our operational complexity while providing the visibility required to scale sustainably and demonstrate portfolio performance.

The Problem

Zero visibility into operational status: Teams manually triaged messages with no way to track what was being worked on, what was overdue, or where bottlenecks existed. Critical referrals could fall through the cracks without detection, risking delayed care coordination for vulnerable members.

No data for strategic decisions: Leadership couldn't answer basic questions about volume trends, response times, or workload distribution—making it impossible to justify staffing requests with evidence or identify which services drove demand. Resource allocation relied on anecdote rather than data.

Manual triage consumed capacity: Significant team time went to sorting and routing requests rather than direct member support. As portfolio complexity increased, this manual burden grew unsustainable—teams spent more time managing intake logistics than delivering services.

Failed vendor solution validated complexity: The previous off-the-shelf implementation couldn't accommodate our workflow requirements, demonstrating that generic ticketing tools wouldn't solve our operational challenges and establishing skepticism about any new system initiative.

Approach

I owned this project from the ground up, including the abandoned vendor implementation that ultimately defined what we needed to build.

Before any custom development, I led the full evaluation and pilot of a third-party platform being considered for broader organizational rollout. I drove requirements gathering, scoped the implementation, and worked through it with the vendor until it became clear that our operational complexity — the volume of inboxes, the clinical context embedded in requests, the service-specific routing logic — consistently hit the edges of what the platform could support. Rather than rationalizing a bad fit, I made the call to stop. That process wasn't lost time: it gave me a precise picture of where generic tooling broke down and exactly what a fit-for-purpose solution needed to do. It also gave me credibility with a team that had watched six months disappear into a system that didn't work. They needed to see rigorous process before trusting another approach.

The decision to build inside Dynamics was strategic, not default. Medical Management had been operating in Dynamics while the rest of the organization hadn't, which meant I had both platform depth and organizational context that made a custom build viable without starting from scratch on infrastructure. The central design challenge was building something configurable per department without fracturing into something impossible to maintain. I approached each team individually — mapping their workflows and routing logic — while holding firm on a standardized underlying architecture: shared naming conventions, consistent categorization frameworks, unified tracking logic across all queues. That combination of department-specific configuration on a common structural foundation is what made it possible to onboard new teams without rebuilding the system each time, and what separated this build from the one-off customizations that typically create long-term maintenance debt.

Key Decisions

Custom Build Over Vendor Solution: The failed off-the-shelf implementation demonstrated that generic ticketing software couldn't accommodate our workflow complexity. The tradeoff: purchase another vendor solution (lower upfront cost, faster initial deployment) versus build custom platform (higher investment, longer timeline, full operational fit). Another vendor solution risked repeating the previous failure—our workflows involve clinical context, regulatory requirements, and service-specific routing that generic tools don't support. Custom development required [NEED: development cost and timeline] but ensured we could design for our actual operational needs and evolve the platform as requirements changed. We chose custom build, accepting higher initial investment in exchange for long-term fit and eliminating the risk of another costly vendor mismatch that would further erode organizational trust in technology solutions.

Phased Rollout Strategy: Organization-wide deployment from day one carried significant implementation risk given skepticism from the previous vendor failure. The tradeoff: deploy to all departments simultaneously (faster consolidation, immediate org-wide visibility) versus phase rollout starting with Medical Management pilot (lower risk, extended timeline, temporary parallel systems). Simultaneous deployment would eliminate fragmented inboxes faster but risked disrupting multiple departments if issues emerged, potentially cementing resistance to any centralized solution. Phased approach meant maintaining parallel systems longer but allowed us to validate core features, surface edge cases, and build credibility before asking other departments to migrate. We chose phased rollout, starting with Medical Management to prove value with a contained user group before expanding—accepting extended timeline in exchange for reduced implementation risk and stronger organizational buy-in through demonstrated success.

Centralized Intake with Department-Specific Routing: Teams had evolved distinct workflows around their shared inboxes, creating tension between standardization and operational autonomy. The tradeoff: single unified workflow for all requests (maximum standardization, simpler system) versus centralized intake with department-specific routing logic (operational flexibility, increased complexity). Single workflow would have been technically simpler but would force teams into processes that didn't match their service requirements—the exact problem that doomed the vendor solution. Department-specific routing added technical complexity but allowed each team to maintain established processes while gaining centralized visibility and accountability. We built flexible routing that supports 5+ department-specific workflows while maintaining unified tracking and reporting—trading system complexity for operational fit that ensures sustainable adoption.

Graduated Assignment Model Based on Team Maturity: Teams had different preferences for request assignment—some wanted manual control for nuanced workload distribution, others preferred automated fairness. The tradeoff: mandate single assignment approach (simpler to build and support) versus support multiple assignment models (accommodates team preferences, adds complexity). User research revealed assignment preference correlated with change readiness—teams comfortable with automation wanted round-robin efficiency, while teams newer to systematic tracking wanted human oversight initially. We implemented graduated assignment: all teams start with manual assignment during adoption, then can graduate to automated round-robin once they demonstrate system proficiency. This reduces change management friction while moving teams toward automation where appropriate—accepting additional system complexity to match teams' change readiness rather than forcing uniform processes prematurely.

Impact

Business Outcomes:

• Built to serve 3 departments at launch with architecture designed for org-wide expansion — converting a departmental tool into shared organizational infrastructure.

Operational Improvements:

• Cut average response times by 30% during pilot (69–103 hours down to 48–72 hours) — driven by centralizing requests into a single system that gave teams immediate visibility into what was open, owned, and overdue.

• Achieved 100% request visibility from intake to resolution — eliminating the lost and misrouted emails that made tracking member requests in shared inboxes structurally unreliable.

• Real-time analytics enabled data-driven staffing decisions for first time

Strategy Evolution / Iterations

Standardization Over Customization: User feedback revealed staff monitoring multiple inboxes strongly preferred standardization across departments rather than preserving unique conventions. Consistent categorization, naming patterns, and routing logic reduced cognitive load when switching queues and simplified cross-training. This reinforced the centralized platform value—users wanted unified patterns, not departmental customization. The insight validated our architectural choice to build shared infrastructure with configurable routing rather than department-specific systems, as standardization delivered more value than we'd anticipated during initial requirements gathering.

Graduated Assignment Matched Change Readiness: Early implementation revealed teams split between preferring manual coordinator assignment versus automated round-robin. Rather than forcing uniformity, we adopted graduated progression—teams start with manual assignment to build platform comfort, then graduate to automation once proficient. This reduced change management friction while still moving teams toward efficiency. The learning: system adoption often correlates more with change readiness than workflow requirements. Supporting multiple modes during transition enabled broader adoption than mandating a single "optimal" approach would have achieved.

August 2024 - June 2025 

Strategic Context

As we expanded into new regions and products, our informal vendor knowledge management couldn't scale. Directory specific contracts, service variations, and acquisitions created complexity that overwhelmed person-dependent systems.

We needed centralized infrastructure to make vendor information broadly accessible—enabling Sales to discuss partnerships confidently, Medical Management to check vendor availability during cases, and Product Strategy to focus on strategic relationships rather than answering operational questions.

The Problem

No authoritative source of truth created organization-wide execution risk: Critical vendor details—approved partners, contract terms, integration status, and group election mappings—lived across spreadsheets, email threads, and individual knowledge. There was no single place to go for reliable answers to operational questions, meaning every team was operating on incomplete or potentially outdated information.

Sales couldn't confidently represent vendor availability in prospect conversations: Without reliable access to current vendor data, Sales faced uncertainty when discussing approved partners during competitive discussions. This undermined positioning at precisely the moments where confidence and accuracy mattered most.

Medical Management required escalations to complete time-sensitive care coordination: When determining which vendors were approved under specific group elections, Medical Management had no system to consult—requiring them to escalate to Product Strategy for answers. In care coordination contexts where timing is critical, these delays introduced meaningful risk to members.

Product Strategy's strategic capacity was consumed by operational queries: Roughly 40 hours per week went to answering questions that a well-designed system should have handled automatically. Time that should have been directed toward contract negotiations, partnership expansion, and performance optimization was instead spent functioning as a human lookup table for the rest of the organization.

Increasing vendor complexity made the status quo structurally unsustainable: As regional expansion and market consolidation added more vendors to manage, the operational burden scaled with it. What had been a manageable inefficiency became an untenable constraint—one that would only worsen as the business continued to grow.

Approach

My role was to convert tribal knowledge into durable organizational infrastructure by designing a system that preserved Product Strategy's ownership of vendor relationships while enabling Sales and Medical Management to self-serve the operational answers they needed in real time. The core design challenge was that these three audiences had fundamentally different needs from the same underlying data, and building separate solutions for each would have created the same fragmentation problem we were trying to solve.

I started by mapping what each stakeholder group actually needed to do, not what they said they wanted to see. Product Strategy needed comprehensive contract tracking and relationship context. Sales needed quick integration status lookups during live prospect conversations. Medical Management needed group election mappings they could check mid-case without escalating. Rather than building three separate views, I designed unified vendor records containing all necessary data, with role-based security and tailored entry points that surfaced the right information for each team's primary workflow — keeping sensitive contract and revenue details out of read-only access without requiring Product Strategy to maintain separate reporting.

The most consequential design decision came out of iterative testing rather than initial requirements. Early prototypes organized vendors by service type, which seemed logical on paper. User testing with Product Strategy revealed they actually navigated by an internal ranking system (preferred, acceptable, etc), a taxonomy that existed nowhere in documentation but was deeply embedded in how they thought about the vendor landscape. That finding forced a full taxonomy redesign before development finalized, and it validated the principle that drove the entire build: the right architecture reflects how people actually work, not how they think they work. Catching that in prototyping rather than post-launch was the difference between an adopted system and an ignored one.

Key Decisions

To address these challenges, I led development of a Vendor Relationship Management (VRM) system that consolidates vendor information owned by Product Strategy and makes it accessible to all stakeholders who need it—fundamentally transforming how the organization manages vendor partnerships and enabling downstream teams to work efficiently without constant Product Strategy intervention.

Defined Ownership: Vendor ownership was unclear—often defaulting to whoever last contacted the vendor—and complicated by vendors operating as standalone partners, integrated into in-house products, or both simultaneously. Traditional single-owner CRM models couldn't represent this reality. We implemented dual ownership tracking, separating vendor relationship owners from product integration owners. This created distinct views clarifying who manages partnerships versus who owns products incorporating that vendor. As our vendor ecosystem scaled, teams needed to know exactly who held context for maintenance and escalations—preventing delays to sales executives that could cost new client revenue while ensuring we didn't commit to vendors we couldn't reliably partner with. Dual ownership ensured clear accountability across both partnership and integration dimensions, eliminating gaps when issues arose.

Self-Service Information Architecture: Product Strategy wanted Sales and Medical Management to self-serve vendor information without accessing sensitive contract terms or revenue details. The tradeoff: simple reporting dashboards requiring manual updates vs. complex role-based security enabling direct system access. Static reports would quickly become outdated as vendor relationships evolved, forcing Product Strategy to maintain separate reporting workflows. Role-based security was more technically complex upfront but would provide real-time access to vendor profiles, integration status, and group election mappings while automatically hiding sensitive data. We built custom security groups providing read-only access to operational details, enabling Sales and Medical Management to search the VRM directly during client calls and member cases.

Document Storage Links Over Embedded Files: Product Strategy lacked centralized access to vendor documents scattered across SharePoint and email. The issue wasn't storage capacity but discoverability—users couldn't efficiently connect documents to vendors. The tradeoff: build native document storage (delaying launch by 8 weeks) or create links to existing SharePoint locations. We chose SharePoint linking, solving the immediate discoverability problem while preserving future optionality. Links rarely changed, were simple to maintain, and automatically directed users to newest document versions—eliminating version control overhead. Product Strategy gained instant access to vendor contracts directly from vendor records, solving the core workflow need without delaying launch or investing in infrastructure usage patterns later proved unnecessary.

Contract complexity compounded the information problem: Individual vendors often maintained multiple simultaneous contracts—different agreements for different networks with varying dates and terms—creating compliance risk when Product Strategy couldn't quickly determine which contract applied to specific scenarios. The tradeoff: single contract per vendor (simple, fast build) vs. multi-contract tracking with historical records (complex architecture potentially confusing users). Discovery revealed directory-specific contracts were operational reality, not edge cases. We built multi-contract architecture relating each contract to specific networks, tracking individual effective/end dates, and retaining expired contracts as historical records. Product Strategy could now quickly determine contract coverage, receive automated renewal alerts, and reference historical terms during negotiations—transforming contract management from reactive firefighting to proactive oversight.

Dedicated Vendor Profile Page: Stakeholders wanted comprehensive vendor relationship details, integration status, engagement protocols, relationship health, partnership tier—consolidated in one place, but displaying everything on the summary page created visual clutter. The tradeoff: keep all information on the summary page for simplicity vs. build a dedicated vendor profile page requiring custom development. Wire-framing revealed that mixing operational data with relationship context on a single page overwhelmed users and buried critical information. We built a custom vendor profile tab consolidating relationship and operational details in a standardized, hierarchical layout. Sales and Medical Management now knew exactly where to find vendor engagement information, increasing self-service adoption and reducing confusion during time-sensitive lookups.

Impacts

Business Outcomes: 

• Self-service access reduced vendor information queries by 20%, allowing Product Strategy team capacity to be allocated elsewhere.

Operational Improvements: 

• Defined ownership for 95% of vendor accounts, clarifying accountability

• Real-time vendor visibility for Sales eliminated Product Strategy briefing delays 

Strategy Evolution / Iterations

Mobile Access as Essential Requirement for Sales Executives: We initially designed the system assuming desktop workflows—most vendor information would be accessed from team member laptops. Post-launch, we discovered sales executives, a critical audience, were frequently on the move, meeting with prospects in the field. Without mobile access, they couldn't reference vendor capabilities or integration status during these conversations, forcing them to delay responses or interrupt Product Strategy for information—exactly the bottleneck we'd built the system to eliminate. We were tasked with adding mobile capability, facing a choice: redesign for the mobile app (complex security limitations) or optimize for mobile browser. The app's security constraints would have delayed delivery significantly, so we redesigned for mobile browser, prioritizing speed to value over technical complexity. It was a valuable reminder to plan for the environment the audience would be working in rather than assuming their context. Observing post-launch usage patterns became critical—when sales executives consistently struggled to access the system in the field, they were showing us the natural workflow we'd missed in initial discovery.

June 2023 - February 2024 

Strategic Context

Post-pandemic utilization patterns revealed a critical gap, oncology cases surged due to delayed routine care during COVID-19, resulting in later-stage diagnoses and more complex treatment needs. Simultaneously, we were experiencing increased member escalations driven by shifting treatment plans and delayed authorizations, creating friction at the moments members needed support most.

This shift coincided with intensifying competitive pressure. Standalone oncology management point solutions were gaining market traction, and both current and prospective clients were explicitly asking about our specialized approach to oncology during the sales process. Without a differentiated oncology capability, we risked losing ground to competitors offering dedicated solutions.

The Problem

Oncology patients were identified too late to intervene effectively: Medical Management was catching oncology cases reactively, only after treatment delays, authorization issues, or care breakdowns had already occurred. Without early identification mechanisms, the team had no opportunity to get ahead of problems before they materialized for members.

Fragmented support left members without coordinated care when they needed it most: When issues did surface, members encountered disconnected teams rather than a unified support experience. The absence of a coordinated care model meant that complexity fell on the member to navigate at an already difficult time.

Constant reactive escalations consumed capacity and prevented proactive work: The team operated in a perpetual response posture, managing escalations rather than preventing them. As case complexity and volume increased post-pandemic, this reactive model became structurally unsustainable and increasingly difficult to staff against.

Competitive pressure from specialized vendors made the status quo untenable: Oncology carve-out vendors were actively promising earlier intervention and more specialized care coordination. Without a demonstrable shift toward proactive value, there was meaningful risk of losing oncology management to external competitors entirely.

Approach

My role was to architect the shift from a reactive escalation model to a proactive intervention program — and to drive the cross-functional alignment needed to make that operationally real. This wasn't a software project; it required renegotiating how care coordination worked across internal teams, two third-party vendors, legal, and clinical operations simultaneously.

Discovery started with escalation data, not stakeholder opinions. While the instinct across the business was to evaluate oncology point solutions, I focused on understanding where and why members were falling through the cracks. Deep-dive analysis of escalation logs and team interviews revealed that the core problem wasn't a lack of oncology expertise — it was that our entry points were too late and too siloed in the member journey. That finding reoriented the entire program design toward earlier identification triggers rather than a standalone specialist overlay.

From there, I facilitated the cross-functional work to turn that insight into operational reality: adapting plan language, aligning clinical review protocols, and building vendor workflows that could legally and operationally support intervention at the point of diagnosis rather than after treatment had begun. Rollout was staged deliberately — implementing identification triggers in waves so we could observe clinical team behavior and refine logic before scaling. When early flags were generating alert fatigue without improving outcomes, we tightened the criteria to prioritize high-complexity cases before broad deployment.

Key Decisions

Upstream Intervention Point: Stakeholders wanted to make sure that we identified people with an oncology diagnosis earlier in their treatment and not once treatment had already begun. This meant that we were gonna have to make a trade-off between our standard process or updating the plan language to require a pre-note as standard, which would involve bringing in legal and our third-party vendor who helped facilitate the services to coordinate on a plan. It was determined that this additional complexity was going to be a value because if we could engage this member at the time of diagnosis we could start to complete the authorization process and have everything in place before they even began treatment and therefore reduce the risk of issues with the member receiving care. This created an early identification trigger that gave us maximum lead time to coordinate support before treatment began.

App Based Self-Referral Option: Stakeholders wanted to ensure that members could also self refer, which was previously unavailable. We had a new app that would allow us to potentially leverage that to allow members to self refer. The trade-off became do we use it as a one-way messaging system or a two-way messaging system where they could chat with support staff. It was decided that we were not staffed enough and that the demands on the digital app team were higher that they were not going to be able to support two way messaging in time for launch so we pivoted and opted to build out a self referral path in the app that generated an email alert that came to a designated team. This allowed us to quickly triage and refer over without delaying deployment indefinitely.

Escalation Line: The team wanted to ensure that we had a method in order to handle escalations quicker. In working with our third-party who would be handling the authorization it was decided that we could either continue to send to the referral inbox we have been using or we could build out an additional escalation path. What we opted for was to build out a emergency hotline number that could be called into to immediately connect that member with care in the most urgent situations so therefore we were able to swiftly move the most urgent cases in front of someone and get that person prompt in front of a nurse case manager.

Behavioral Health Integration: As oncology diagnoses were being identified, it became clear that members were not consistently being connected with the emotional and psychological support they needed, many of whom were also serving as caregivers themselves. We already had an existing behavioral health product capable of connecting members with coaching and guidance resources, which presented an opportunity to close this gap. The trade-off was accepting a significantly expanded scope that required bringing in the vendor powering our behavioral health product and building out a more complex workflow than originally planned. It was determined that this added complexity was justified given the clear member need, and so we integrated the behavioral health product directly into the oncology support pathway. This ensured that members facing a diagnosis were not only receiving clinical coordination but were also being proactively guided to the emotional and behavioral support necessary to navigate their care journey.

Impacts

Business Impacts

• Dedicated oncology product transformed into a competitive product line doing > $500k in revenue in first year.

• ~30% increase in volume through pre-note identification, which resulted in better outcomes of patients 

Operational Impacts: 

• Maintained unified member experience by expanding existing partnership vs. adding oncology carve-out specialist

• Successfully absorbed post-pandemic case surge without proportional increase in escalations.

Strategy Evolution / Iterations

Sustained Engagement Through Treatment Progression
Early implementation revealed that oncology treatment pathways are rarely linear, patients often fail through initial treatments as part of the expected clinical progression. When one treatment plan fails, patients immediately require a new pre-authorization for the next protocol. We discovered that case managers needed to maintain active engagement beyond the initial authorization to prevent care lapses. We adapted workflows to emphasize continuous case monitoring and proactive re-authorization coordination, ensuring members experienced seamless transitions between treatment regimens rather than hitting authorization delays at critical junctures.

Continuity of Care for New Member Onboarding
Through program rollout, we identified an unexpected patient population: newly enrolled members already in active oncology treatment. As we sold new groups and brought new lives on board, we encountered members mid-treatment who faced potential disruption when transitioning to our plans. The original workflows focused on identifying and supporting existing members but didn't account for continuity of care needs during plan transitions. We built additional processes to proactively identify in-treatment members during the enrollment period, expedite authorization transfers, and ensure members could continue their established treatment plans without interruption, preventing the frustration and clinical risk of hitting authorization walls during plan changes.

January 2024 - May 2025

Strategic Context

Medical Management had emerged as a high-value, fast-growing product line, delivering increasing value to both clients and the members we serve. However, our ability to demonstrate, defend, and scale that value was limited by the absence of standardized analytics and reporting. While member volume and billing scaled successfully, we lacked a cohesive way to tell a unified story about impact, outcomes, and ROI.

This gap created challenges on two fronts. Externally, during a record sales year, our account management team faced repeated requests to demonstrate Medical Management's value to justify billing and secure renewals. The data existed, but had to be manually compiled and could not be delivered promptly, creating risk during critical client conversations. Internally, decisions around product expansion, investment, and strategic pivots depended on ad hoc data requests to other teams, slowing our responsiveness and limiting our ability to act on emerging opportunities with confidence.

To support sustainable growth, Medical Management needed to evolve its approach to analytics, one that could simultaneously support client conversations, guide internal decision-making, and reinforce its position as a scalable, high-impact product.

The Problem

Organizational growth outpaced the analytics infrastructure supporting it: As the business scaled, the existing approach to data and reporting couldn't keep pace. Data integrity issues were common, requiring extensive manual validation before any analysis could be trusted, making even basic insights time-consuming and unreliable by default.

Inconsistent KPI definitions prevented alignment on what success looked like: Without standardized metrics, teams measured performance differently, making cross-program comparisons unreliable and leadership alignment on outcomes functionally impossible. There was no shared language for evaluating whether programs were working.

Reactive, manual reporting created decision lag at critical moments: Ad hoc requests took days to fulfill, delaying decisions and limiting the organization's ability to respond to emerging trends. Every new analysis required custom data pulls and validation from scratch, making it difficult to evaluate program performance, member outcomes, or resource allocation at any meaningful scale.

Leadership lacked visibility into where performance was breaking down: Without a unified analytics foundation, there was no reliable way to identify underperforming programs, track volume trends, or surface optimization opportunities before they became larger problems. Decisions that should have been evidence-based relied instead on intuition.

Inconsistent value articulation created renewal risk: Because insights couldn't be produced reliably or consistently, demonstrating program value to clients was difficult to do with confidence and was approached differently depending on the presenter. This introduced risk at renewal, precisely the moment when clear, credible performance narratives matter most.

Approach

My role spanned three interconnected challenges: building the analytical infrastructure, establishing the governance model that would make it trustworthy, and creating the organizational capacity to sustain it. Getting dashboards built was the straightforward part — the harder work was ensuring the analytics function could operate independently and scale after launch.

Discovery focused on the decisions leaders were trying to make, not the reports they asked for. Teams were requesting comprehensive data access and then spending days manually filtering it down to the two or three numbers that actually drove their choices. I reoriented discovery around a single diagnostic question — what decision would you make differently if this number changed? — which cut through stakeholder wish lists and quickly surfaced the metrics that genuinely mattered versus the ones that just felt safe to track. That framing shaped both the KPI governance framework and the decision to deprioritize raw data access in favor of standardized, curated reporting.

Before any dashboard or report was built, I prioritized data integrity over speed. Years of inconsistent data entry had eroded trust in reported metrics, meaning new reports built on the same foundation would be ignored. I worked with each team to trace data lineage, validate sources, and implement systematic validation — trading the immediate gratification of visible output for the foundational credibility that would determine whether the analytics were actually used.

Rollout was staged by team, with each wave informing the next. When we hit blockers — data gaps, tool limitations, capability constraints — I treated them as design problems rather than stopping points, including building training to close skill gaps rather than accepting limitations as fixed. The final and most consequential investment was structural: I hired and developed a dedicated analytics team to own ongoing reporting, absorb ad hoc requests, and continue expanding the platform's capabilities. Without that, the infrastructure would have degraded back into manual processes as soon as attention moved elsewhere.

Key Decisions

Standardization of Metrics: During initial discussions, stakeholders requested access to as much data as possible, believing comprehensive information would enable better decisions. The tradeoff: flexible exploration of raw data versus streamlined standardized reporting. We prioritized a focused set of standardized metrics, accepting reduced control, stakeholders could no longer dig through raw data themselves, in exchange for speed and consistency. They also gave up some flexibility by relying on us to set report parameters as part of the standardization. Working directly with leadership, I established a governance framework identifying measurement blind spots and defining pivotal KPIs supporting both operations and strategy, focusing on member impact stories, cost savings, billable hours, and case volumes.

Data Integrity as Foundational Requirement: Teams were making strategic decisions based on data they didn't trust, spending significant time manually verifying numbers because years of inconsistent data entry had eroded confidence in reported metrics. The tradeoff: quick dashboards versus foundational trust. We strengthened data integrity at the source before building reporting layers, systematically tracing data lineage with each team, validating sources and assembly logic, and implementing systematic validation processes. This traded the immediate gratification of new dashboards for the foundational trust required to actually use them, reducing manual verification effort and enabling teams to act on insights with confidence.

Rejecting Vanity Metrics for Performance-Aligned KPIs: Teams initially tracked individual case counts as a productivity measure, but these numbers created noise without driving strategic value and risked misinterpretation. The tradeoff: familiar activity metrics versus outcome-aligned performance measures. We shifted focus to billable hours, the performance metric team members were actually evaluated against and that directly tied to business value. This eliminated tracking that didn't move the needle and aligned reporting with how performance was actually measured, ensuring analytics reflected what mattered for both team members and the business.

Storytelling-Based Reporting for Client Value Articulation: Medical Management wasn't effectively communicating the value we delivered, leading to frequent off-cycle requests for impact clarification from clients and our sales team. Past responses were addressed one-by-one, resulting in inconsistent messaging. The tradeoff: continued custom but manual reports versus standardized proactive communication. Through multiple iterations, we developed narrative-driven reporting approaches that framed insights around member impact, cost savings, and health outcomes rather than raw metrics. This created a compelling, proactive storytelling approach that reduced off-cycle client reporting queries, strengthened renewal materials, and enabled our teams to demonstrate impact without manual translation work.

Team Building to Support Sustainable Analytics Capability: As reporting scaled, teams spent increasing time manually compiling reports. The tradeoff: continued manual effort versus investing in dedicated analytics capacity. We invested in hiring and training analysts who could assume ownership of reporting, consistently produce quality reports, build new reporting as needed, and handle ad-hoc requests. This ensured the platform remained relevant and utilized over time, prevented regression to manual processes, and created organizational capacity to respond to new analytics needs as Medical Management scaled.

Impact

Business Outcomes:

• Established reporting cadence used to show value to clients and secure retentions

• Provided functionality required to make decisions around product expansion prioritizations

Operational Improvements:

• ~ 40 hours/month reduction in time spent validating data across teams through strengthened data integrity and dedicated analytics team

• 15+ custom dashboards delivered for stakeholders across 4 departments

• Ad hoc report turnaround reduced from 5 days to under 4 hours for delivery

Strategy Evolution / Iterations

Progressive Automation to Reduce Manual Overhead: As reporting volume increased, so did the frequency of manual refresh requests and demands for updated data. We discovered the extent of this burden when we sat in on a process call and observed teams cycling through data refreshes repeatedly throughout their workflow. By building in automated dashboard refreshes, stakeholders always had access to current data without waiting for manual updates. We opted to automate client-facing reports in a later phase to run as groups approached renewal dates, reducing last-minute reporting requests and ensuring consistent, timely client communication. The lesson: not all reporting needs automation from day one, prioritize automating repetitive, time-sensitive tasks once the underlying reporting is validated and stable.

Matching Tools to Use Cases: As we launched new reports, stakeholder requests for features were constrained by software limitations. We learned that different software has distinct strengths and weaknesses that make it better suited for specific use cases. While organizational pressure existed to consolidate everything into one platform for simplicity, this multi-platform strategy allowed us to leverage the right technology for each reporting need rather than accepting one-size-fits-all limitations. The key was maintaining consistent data definitions and visual standards across platforms so that stakeholders experienced coherence even when reports were generated from different systems.

March 2019 - December 2019 

Strategic Context

Leadership recognized Medical Management as a strategic opportunity, as our advocacy and care coordination products were addressing real member needs and delivering positive health outcomes for members. However, the business case for expanding these offerings was hampered by a fundamental constraint, the entirely manual, paper-based operational model made it impossible to scale.

We couldn't grow the program without demonstrating ROI with confidence because measuring impact required manual reconstruction of fragmented records.  To unlock Medical Management as a viable product line, and be able to compete with individual point solutions by having a holistic Medical Management product offering, we needed to transform it from a collection of artisanal services into a systematized and repeatable program. This platform represented that foundational infrastructure investment, the prerequisite for everything that would follow.

The Problem

Reactive service delivery that missed early intervention opportunities: Case identification relied entirely on emailed referrals rather than systematic data-driven triggers. By the time members were identified, issues had often escalated significantly, 

Manual burden that couldn't scale: Member information was scattered across multiple systems, requiring the team to manually copy and paste data into Word documents for each case. Billable time was tracked by hand on paper logs, making reconciliation difficult and error-prone. Every case meant starting from scratch, hunting for information that should have been readily available.

No way to demonstrate value or measure impact: Without structured outcome tracking, proving program effectiveness meant painstaking manual effort to retrace steps through fragmented paper records and email threads. Leadership couldn't make informed investment decisions about expansion because we lacked reliable performance data.

Approach

My role was to translate a fragmented operational reality into a scalable platform architecture — while simultaneously building the internal consensus needed to get it built and adopted. This required operating as both strategist and executor: defining what the platform needed to become before a clear solution existed, then driving it through design, delivery, and rollout.

I anchored the discovery process in direct observation rather than stakeholder input alone. Interviews and workflow mapping revealed that the team had built their own workarounds — email filing systems, personal tracking spreadsheets — to compensate for data fragmentation. I treated these workarounds as design requirements, not complaints. That reframe shaped the entire platform architecture and prevented us from building against how people actually worked.

The key judgment call throughout was resisting scope creep in favor of sequenced value. Stakeholders pushed for comprehensive functionality at launch — document libraries, provider directories, dedicated modules. I made deliberate decisions to deprioritize features that added complexity without unlocking the core use case, keeping the team focused on the capabilities that would drive adoption and demonstrate ROI first. Rollout followed the same logic: iterative waves with a subset of users before broad deployment, so we could course-correct on real behavior before it calcified

Key Decisions

Strategic Alternatives: Stakeholders initially pushed for quick deployment with out-of-box solutions. The tradeoff: immediate value versus long-term flexibility. We reached consensus to choose Microsoft Dynamics over alternatives like Salesforce, accepting longer time-to-value and higher technical complexity in exchange for maximum customization options and built-in integration advantages within our existing Microsoft ecosystem. This positioned us for future scalability rather than imposed growth limitations.

Member-Centric Record Structure: Traditional CRMs would either fragment member history across duplicate records or force all strategies into one unmanageable case. The tradeoff: simpler one-member-one-case model versus nested scenario complexity. We designed a one-case-per-strategy architecture with scenarios as sub-options, limiting case proliferation while enabling clear delineation across strategies. Case managers working different strategies on the same member maintained visibility into parallel work without cluttering cases or duplicating member records

Automated Data Population: Advocates spent significant time per case hunting member information across five systems. The tradeoff: manual data entry with full control versus automated population with sync risk. We integrated data warehouse feeds to auto-populate key member information at case creation, accepting occasional sync delays in exchange for eliminating guaranteed time loss. This accelerated time-to-action and shifted advocate time from data gathering to member engagement

Integrated Time Tracking and Invoicing: Manual time tracking created billing delays, revenue leakage, and administrative burden for invoice preparation. The tradeoff: simpler standalone tools versus integrated workflow complexity. We built time-tracking directly into the case workflow, capturing billable hours as work occurred and generating consolidated monthly reports for finance. The upfront development investment eliminated ongoing manual reconciliation across spreadsheets, ensured accurate billing, and reduced the risk of billable hours slipping through the cracks.

Outcome Tracking and Impact Measurement: Leadership needed to demonstrate program value, but case histories lacked structured outcome data, requiring time-consuming manual reconstruction for reporting. The tradeoff: flexible free-text notes versus structured fields that increase advocate data entry burden. We implemented structured fields for interventions and outcomes as part of standard workflow, creating an auditable impact record for client inquiries and performance reporting. Dropdown option sets and pre-populated fields offset the additional entry requirements while ensuring consistency and ability for reporting, giving leadership quantifiable program performance data for the first time.

Deprioritize Document Storage: Stakeholders initially required document storage within the CRM, but this would add significant complexity and cost. The tradeoff: complete functionality at launch versus phased approach prioritizing core advocacy workflows. We deprioritized document storage for a later iteration, choosing to move away from siloed documents toward structured data capture that could be readily reported on and shared. This decision accelerated the initial launch timeline and freed resources for higher-impact features like automated data population and outcome tracking. 

Impact

Business Outcomes:

• $1M revenue increase in first year through automated case referral and centralized management

• Platform infrastructure supported the expansion of 4 new product offerings for Opioid Dependence, Specialty Pharmacy, Lifestyle and Maternity in 2019-2022

Operational Improvements:

• ~30% increase in early case identification and automated volume

• ~50% reduction in billing reconciliation time with 10% fewer errors

Strategy Evolution / Iterations

Observed workarounds to identify automation opportunities: Case managers were saving emails to desktop then manually uploading them—a cumbersome workaround that signaled a system gap. By enabling direct email tracking to the case timeline via native Dynamics functionality, we eliminated the workaround and created a complete communication audit trail. Observing post-launch user behavior became a key approach for identifying where the platform should evolve, as when users consistently work around your design, they're showing you the natural workflow.

Unforeseen Collaborative Workflows: As usage expanded, we discovered that certain teams needed to delegate specific tasks to colleagues without transferring full case ownership, a collaborative model the original design didn't account for. We introduced activity creation and assignment capabilities, a native Dynamics feature, allowing teams to route distinct work items while the primary case manager retained case oversight. Each activity had ownership assigned to it, making accountability clear across the collaborative workflow.